Things CSS could still use heading into 2023
chriscoyier.net
chriscoyier.net
I would like to have CSS units of viewport size that automatically subtract the scrollbar width. A cross between 100% (which discounts scrollbars but is unaware of viewport) and 100vw (which is aware of the viewport but does not exclude scrollbars). I understand that such a unit of measurement means overcoming infinite loops caused by edge cases. This is where your elves come in.
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-...
(a) it only works on elements whose parents are the full viewport width, such as the body (simplifying the rules a little—there’s much finer nuance to the interpretation of percentages), and most of the places you might want viewport units aren’t suitable; and
(b) that’s literally just a longwinded way of writing “100%”, because mathematics.
100vw - (100vw - 100%) = 100vw - 100vw + 100% = 100%
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.
The above is easily fixed; however, I have also seen designs like this one [0], where a team has painted itself into a corner by assigning max-width to the body element; yet also wanting to have hero elements inside of the body element that would break out of the confines of the body and span the whole width of the viewport. They tried to use 100vw for the hero, which resulted in the infamous horizontal scrollbar.
(I have since learnt — from Josh Comeau, I think — that their design problem could have been cleanly solved by designing the layout with CSS grid)
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;
Please consult the list of gifts you brought to us for Christmas before the last. You will find included in that list the scrollbar-gutter property. With scrollbar-gutter set to stable, you could safely skip steps 3 and 4 in your algorithm, thus avoiding the infinite loop. Would you please consider giving our wish a second thought?
Check your mobile devices that use such scroll indicators. We haven't heard any major complaints about them.
“Unit vmin refers to the smallest dimension of the viewport. Just like is the case with unit vw, unit vmin needs recalculation to subtract the scrollbar from the viewport width.
https://www.terluinwebdesign.nl/en/css/incoming-20-new-css-v...
"Caveats
There‘s a few caveats to know about Viewport Units:
- None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification."
Notice that although the example in the above paragraph uses the well-known vw unit, the text explicitly says "none of the viewport units".
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...
> Animate to Auto
Still isn't possible with vanilla CSS in 2022 just boggles the mind, especially given jQuery managed to get it working decades earlier.
Similarly, why can't we have different visible and scroll/auto values for overflow? Like, this feels like the weirdest limitation to be stuck with decades later:
> The computed values of ‘overflow-x’ and ‘overflow-y’ are the same as their specified values, except that some combinations with ‘visible’ are not possible: if one is specified as ‘visible’ and the other is ‘scroll’ or ‘auto’, then ‘visible’ is set to ‘auto’. The computed value of ‘overflow’ is equal to the computed value of ‘overflow-x’ if ‘overflow-y’ is the same; otherwise it is the pair of computed values of ‘overflow-x’ and ‘overflow-y’.
Such utterly bizarre design choices that don't take designer/developer expectations into account at all.
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.
I actually can't imagine any other use for vh that isn't related to screenjacking (giving you a "full screen experience" mid-article) or scrolljacking (changing how the page scrolls). Parallax effects, maybe? I like the current limitations.
Creating fixed panels on the left or right side of the viewport that are full height and sticky.
Sciter supports animate to min/max-content. This
div {
height:0;
overflow-y:hidden;
transition: height ease 300ms;
}
button:checked + div {
height:min-content;
}
<button|checkbox checked>Show/hide</button>
<div>
This is a summary
</div>
Do any of them do this? On my iPad right now the MDN example (1) isn’t animating, and last time I checked Chrome didn’t either.
(1) https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...
> The browser doesn't know what the auto size is any more than you do until it performs a layout (reflow). Layouts are expensive and must be minimized. And what if content is changed in the middle of the transition? Should it recalculate the new auto size? Maybe we will get it some day, but there are good reasons to be cautious.
Unfortunately these are good questions to answer and probably the reason browsers don't have it yet.
Last time I had to animate `width:auto` and `height:auto` I came up with quite a clever idea. I wrote `width: var(--width-from-js, auto)` and `height: var(--height-from-js, auto)` (CSS Variables (called CSS Custom Property[2]) with a fallback to `auto` when the variable is not defined) and later in JS I calculated the real width and height (using `getComputedStyle` or `getBoundingClientRect`) and just set `--width-from-js` and `--height-from-js` as inline style on the element. I also added event handler for the event that could change the size of this element (like browser window resize) and rerun this code to set updated CSS Property valaues.
This way the changes required in JS were minimal, most of the things was in CSS. As a plus when one day browser would support animation to `auto` I would only have to delete the JS code.
I need to write about this technique on this 3-pages stackoverflow question one day ;)
Interesting observation was that when there was an animation in progress and the code for calculating the width of the element had run (because I resized the browser window) then the animation would just stop. I wouldn't mind if this was also the behavior if browsers would someday support animation of `width/height: auto` natively.
[0]https://github.com/w3c/csswg-drafts/issues/626 [1]https://stackoverflow.com/questions/3508605/how-can-i-transi... [2]https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...
So, you’d like to animate the display property: https://css-tricks.com/so-youd-like-to-animate-the-display-p...
Yes, yes, yes.
I actually didn't love Adobe's standard, and I thought some of the criticism of it was warranted. But the overall feature would be very nice to have. I'm just not sure exactly how it should be approached. ----
If I can be greedy, I know these aren't necessarily great features to add, but I would love:
- an (optionally) less performant text-justification algorithm: Justified text on the web is basically unusable today, I think because of performance concerns with reflowing containers. There are scenarios though where I would be very willing to pay a performance penalty to get nicely justified text, even if I had to like mark a container in CSS as unable to resize/reflow or something.
- CSS vertex shaders/custom filters: This is never going to happen as far as I can tell because of privacy concerns, and I have no idea how to get around those privacy concerns, and it's a feature I would almost certainly turn off in my own browser for most websites, but... I still want them.
----
Also I'm hoping that 2023 is potentially the year where I can start to feel safer about using container queries: https://caniuse.com/css-container-queries. I think once they hit mainline Firefox, Chrome/Safari/Firefox will be good enough support that I'll be comfortable including them at least in niche projects and just using progressive enhancement and a slightly uglier style as a fallback for other browsers.
By whom however I don't mean Chris Coyler even though his css-tricks.com when he was still running it certainly profited off CSS' let's say less-than-razor-sharp scope.
Everyone that helped Chrome and Electron apps to be widespread, don't have anyone but themselves to thank for.
The browser platform is incredible because it doesn't break backward comparability, and has a very wide set of features to allow you to do 90% of what you want, but at an (occasional) cost of performance for the 1% of cases. WASM is there for that 1%.
Figma is a good example, JS+SVG+Canvas+DOM would be too slow for their use case so they built a WASM renderer. But that renderer is limited in functionality to exactly what they need, that is where they gain there performance improvement. Not by being able to magically solve problems the browser devs haven't been able to. It just a case of having a simpler renderer.
That's where WASM shines (for rendering), allowing you to simplify to gain speed improvements.
It's exactly the same with using JS+Canvas for performance critical drawing where the DOM is too slow. Use a simpler toolkit.
Running a whole browser in WASM will always be slower, and doing what you suggest would just result in a single implementation "monoculture" anyway.
(On the monoculture comment, there isn't one, Safari is massive because of Apples block of other engines on iOS. Loose that block then there may well be a monoculture)
Today I’m using PostCSS to get over these problems, but I wish I didn’t have to.
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.
Or are you trying to keep the status quo, where people hack some shit out of divs that you can't change the appearance?
I believe firefox got this natively after greasemonkey died, but I never looked how to do it.
Calling the problem "aesthetics" though is too narrow. There are numerous things people would like to see in a native select:
- Optional search/filtering of options (without the need for an input field and JavaScript wiring).
- Being able to style.
- HTML in an option for example multi-line options.
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>Is there a way to reserve the scroll bar space but only show it on auto?
https://www.quirksmode.org/blog/archives/2010/12/the_fifth_p...
Basically a version of position:fixed that doesn't get zoomed in on when zooming the rest of the page on mobile, so it's always actually visible. would be hugely useful for making bottom/top menus like apps have, without having to re-implement zooming in javascript.
Edit: I’m very happy with the last decade of progress in CSS at the feature level, but at the language level I get the sense that there’s a fundamental disconnect with web developers.
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...
It would be the most massive DX positive change to CSS. It had been on my want list for years.
But it seems all the momentum went into shadow DOM and we stopped talking about it.
"All" we need in theory is someone willing to take the mantle and shepherd it. There is previous work on it from the `@apply` experiment that could be leveraged. In theory it should not be too hard.
But noone has the time in the people that want it it seems.
@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;
}@mixins are built-in in Sciter and I don't know any other HTML/CSS UA that supports that.
Correction on the last part: so long as it’s not `overflow: visible`. Doesn’t need to be `overflow: hidden`, and indeed my experience is that you normally want `overflow: auto` on resizeable things.
Also “anything” is inaccurate: you mostly can’t use it with replaced elements like img/audio/video/iframe, though it varies by browser (e.g. my recollection is that resize works on iframe in Blink but not Gecko).
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_...
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?
Ah, yes, I knew that.
(mind silently blown)
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.