The "brick" layout creates rows, yes. When a regular person looks at it, they will see rows. But Grid Lanes flows content up and down, not across the row.
If you just want content to flow down one row, then the next, then the next, Flexbox is a better solution.
The whole point of masonry layout is that content flows perpendicular to the lane.
I like that the homepage shows the extended hours breakouts (as opposed to Trading View Charts, which just shows $AAPL). I could imagine checking this every day like HN just to see what those are.
To me the signup field is a bit aggressive, with the blinking arrow and the slideshow, but I might just be neurotic about these things, and as I keep my money in index funds I'm unlikely to pay for this anyway.
Why would they be? Russia doesn't tend to fund leftist groups. If they're actually a leftist group, it's far more likely to be about Palestine and of their own accord, or because of direct government oppression against them.
Last time I knew of an attack like this in Berlin, it was a direct retaliation after the government attacked their house with military tanks.
I use the eurokey layout with a US international keyboard.
I've bound caps lock to alt gr while using it as a modifier key in niri at the same time. So `caps_lock => return` opens a terminal and `caps_lock => a` inserts "ä". Since the caps lock key is right over the shift key, it's also easy to type uppercase umlauts.
This is as easy as you can make typing special characters by configuring the keyboard, but it's still annoying. What I really want is to type things like "schoen" and have that automatically converted to "schön" when I press space.
There was a chrome extension to do this called Umlauter[1], but it didn't recognize language, so it wrongly converted umlauts in english text, like "guess" to "güss", which isn't even a german word, but to save space the extension uses heuristics rather then a dictionary.
(Would it to be too much to ask of a browser to include dictionaries for every language the user speaks in a way that can be accessed by extensions and web apps?)
Today, chrome has an API to recognize language, but the extension doesn't work anymore because it doesn't support manifest v3.
I work on a scratchpad[2]. I plan to add something like Umlauter with language recognition, and maybe using other Web AI APIs.
If a web browser doesn't support an API, they're essentially saying: If you want to do this, you have to make people install a native app. And the websites reponse is: Fine, I'll make people install a native app: Chrome.
> The unglamorous answer is that this might be just a documentation problem. MDN is pretty good, even though Mozilla increasingly concerns me as a steward of the open web. What if it were just a little better?
What if it had a comment section where people could discuss these issues, like the PHP docs? What if it had a wiki, where people could collaborate on fixing them, like ArchWiki?
Though, considering how much information tends to get centralized in these comments, I think the wiki-like direction is the way to go. (I know anyone can edit MDN, but it's via github PRs rather than being able to make quick edits on the site.)
I don’t see a problem with the github PR workflow for updating documentation. Yes, it’s one step more, but it’s nothing special when you use github’s online editor.
PS: MDN and MSDN are my favorite documentation sites.
When I pointed out some bugs on Microsoft's docs they just basically replied "hurry up and fix them then!" which annoyed me at first, but they actually poked me until I stopped being lazy and submitted a PR, wherein I actually learned some new things.
Cursor has a browser? That by itself makes me want to try it again.
EDIT: No support for the web midi API though. I guess this is the problem with the browser-in-IDE idea: You only want to use it if it's perfect, otherwise keep wondering whether something is a problem of the browser or your app. Maybe IDE-in-browser is easier, and chrome is approaching that with workspaces.
reply