cletusw

You can remove the brightly colored (at least in dark mode) lines above every tab in your userChrome.css with:

``` .tab-context-line { display: none; } ```

Source? You can have many buses using a single BRT lane which is much cheaper to build and maintain than the number of lanes you would need to move the same number of people in private vehicles. Even more so once you start building grade-separated highways and their off ramps.

Previous discussion: https://news.ycombinator.com/item?id=48733236

https://Symfonium.app is a good player for Android

In the behind the scenes video the photographer makes an offhand comment that yes, he was going to take the silhouette of the skydiver (and maybe some of the immediate surroundings) and composite it with a mosaic of sun images taken around the same time (but without the paramotor present).

That's the entire point of "war crimes" and "crimes against humanity" definitions like intentional starvation. It doesn't matter what the justification is, they're not allowed by the international law and need to be punished as such in all cases unconditionally.

The difference is for proprietary features, you can just charge that subset of users that care for its maintenance, using that money to hire additional developers, etc. For OSS you instead have a relatively fixed budget of time & resources and have to balance competing interests in a zero-sum manner. On the flip side, there's nothing preventing the vocal minority from forking if the feature is important enough to them!

There are a good amount of lower power ones (e.g. with an N100 CPU) that draw ~15W usually and not that much more at full bore, and some of them are starting to come with USB-PD power inputs (even if they come with a DC power adapter some will accept USB-PD on another port).

Look for "PD in" on this sheet for some examples (columns BW-BY): https://docs.google.com/spreadsheets/d/1SWqLJ6tGmYHzqGaa4RZs...

Ugh, yes. My kids play this one at school and when I read about the game mechanics I was super disappointed. Luckily they stopped begging me to subscribe eventually since I wouldn't budge.

Then middle and upper class people will just keep on polluting at marginally lower rates. The only real solutions to this problem are ones that get the will & finances of the upper classes involved.

Having two completely unrelated UIs – one for mobile, one for desktop - isn't really responsive. When done that way there's some point (e.g. 1199px width in the OP's example) where you suddenly have a tiny mobile web site with a ton of blank space on either side (or worse, it stretches it all out to fit and all the blank space is within every single button and widget).

There should either be several progressively more "mobile" breakpoints, or even better, use component queries so individual chunks of the page can rearrange their contents as their available area shrinks.

This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement.

And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.

Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem. Starting with a framework that has widgets you can reuse is much more interesting and motivating.

That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.

GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.

Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.

Please don't do this. This confuses and possibly prevents screen reader users from using your site.

> "I just wanted something that is small and works like a normal HTML element"

My first stop when looking for a web component is always https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.

Thank you! I wasn't quite getting the 3rd party cookie vs. actual site visit distinction from their post.

HTML Imports were actually among the first (shipped in Chrome), but then ES Modules/import/export took off and now spec authors want to reconcile the two before standarizing.

That's one of the huge benefits of web components -- third parties can iterate quickly to find useful patterns, then browsers can just standardize the best/most popular ones. The old way of discussing ad nauseam in committee then implementing straight in the browser gave much less useful elements. (And it's much less straightforward to convert a popular React component into something browsers could implement natively.)

Honest question: How is React/vue/etc. different in this regard?

Spelling error in title. Should be ... Electric Thruster

Official SpaceX video: https://twitter.com/SpaceX/status/956236301275054080

More good footage + audio: https://twitter.com/nova_road/status/956221490785026053