Things CSS could still use heading into 2023 (chriscoyier.net)

The fact they're not is probably hurting accessibility and usability a ton, since just about every individual and business wanting stylistic consistency is stuck reinventing the wheel with 'fake' versions or JavaScript.

https://open-ui.org/prototypes/selectmenu

In Sciter, all input elements are ordinary styleable primitive DOM elements. <select> is there too so you can style it in the way you want:

   select {...}
   select > caption {...}
   select > button {...}
   select > popup {...}
   select > popup > option {...}

This for example is a table that behaves as a <select type="list"> with rows-options:

   <table>
     <tbody style="behavior:select-list; overflow-y:auto;">
     <tr role="option" value="A"><td><td></tr>
     <tr role="option" value="B"><td><td></tr>
     </tbody>
   </table>

I'm not sure what the spec should be though, maybe bezier curve corners. That would allow asymmetry with "setback" and "control-length" for each side of the corner.

https://www.folklore.org/StoryView.py?story=Round_Rects_Are_...

I'd go as far as saying layout properties like `height` and `font-size` shouldn't even be animated. If you pay attention to animations on macOS or iOS, the animations are performed on post-layout pixels: scaling and translating. That gets you very smooth FPS and isn't thrashing the CPU.

So, you’d like to animate the display property: https://css-tricks.com/so-youd-like-to-animate-the-display-p...

It doesn’t, really, if you instead just commit to reserving space for the scrollbars. And this indeed was how viewport units were initially specified a decade ago, and implemented in Firefox: write `html { overflow-y: scroll }` or similar, and vw is now actually what 100% of users want (seriously, there are exactly zero valid use cases for the current behaviour, it’s wrong every single time—just very occasionally useful despite its unknowable-in-pure-CSS rate of error). Unfortunately, no one else implemented it or was interested in doing so (even though this was the only hope of making viewport units correct for >99% of web pages—and remember this was before flex, too, so it was much more common to need correct viewport units) and they ended up ripping it out of the spec and Firefox a few years later.

And it looks like the only hope of ever getting sane viewport units is doing much the same once again, but more likely just with scrollbar-gutter this time. But having monitored relevant issues on the CSSWG bug tracker for years, I’m not holding my breath for any sort of fix. No, it’s pretty clear that no browser makers are much interested in fixing ancient design bugs in scroll bars that take space.

Does above not work?

https://stackoverflow.com/questions/33606565/is-it-possible-...

Or to phase another way: If the scrollbar isn't currently rendered, is a hypothetical scrollbar still excluded or not? Since both ways you answer this question may make people unhappy.

Santa: "That is simply impossible with the default scrollbar model".

You may have infinite loop in layout algorithm in cases when content is close to size of the viewport.

0) remove scrollbars

1) calculate VW;

2) do content layout;

3) if content exceeds viewport height, add v-scrollbar and goto 1 if it has not the scrollbar before;

4) if content does not exceed viewport height, remove v-scrollbar and goto 1 if it has it before;

The only option is to use scrollbars that do not take space: normally scrollbar appears as thin semitransparent bar on top of content. And on mouse hover the real scrollbar appears , but again on top of content.

Such scrollbars do not cause re-layout as you see and VW is a viewport width always.

That's why in Sciter(https://sciter.com) I've added

   overflow:scroll-indicator; 

Seems like someone else in this thread might have solved this problem.

https://news.ycombinator.com/item?id=34116719

https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-g...

So that zooming in on websites has unexpected side effects like some elements ignoring the zoom and staying the same size?

When users zoom they want everything to maintain the same proportions but be larger on their display, but web developers in their infinite wisdom want to do clever stuff when a user zooms so that isn't their experience.

What is a non-abusive use case for this?

   @mixin button-alike {
     border:1px solid;
     border-radius;
     background:gold;
   } 

   a.button {
     @button-alike; // mixin application point
     color:blue;
   }    

   @mixin button-alike(back) {
     border:1px solid;
     border-radius;
     background:back;
   } 

   a.button {
     @button-alike(gold); // mixin application point with parameter
     color:blue;
   }

It would be significantly more useful if we would have universal <frameset>:

   <frameset cols="200px,*>
     <select type="list">...</select>
     <textarea>...</textarea>
   </frameset>

Resizable textareas are quite trivial to implement with barebone JS but such split views require native support from browsers in order resizing to work effectively.

The build tools documentation and DX all seems built with the idea your html come from js or as static assets too. When in reality it is probably handled by a server side framework like Laravel, Django, Rails, Phoenix, etc

I stopped having hopes on mixins. Now i just try to make a product successful enough that i can fund someone or a team to work on the problem in a decade. It feels like the most probable solution.

And that is not a high probability of success...