The Staggering Frontiers of CSS(buttondown.email)
buttondown.email
The Staggering Frontiers of CSS
https://buttondown.email/robinrendle/archive/the-many-frontiers-of-css/
46 comments
The CSS viewport unit situation is so frustrating. First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Then mobile WebKit/Safari broke vh for many use cases, because they couldn't make the obvious behavior perform at 60fps in combination with their UI choices (the actual problem always remained vague: "looks like shit but we can't show you"). Instead these units started ignoring any browser chrome that could change size. This makes them useless for any purpose where the actual size of the viewport matters. Other browsers followed because Safari was not going to change.
Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified.
The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior.
It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.
Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified.
The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior.
It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.
> First they introduced vw and vh, and those did the obvious thing: reflect the viewport.
Well… not the viewport you’d expect. They reflect the viewport including document scrollbars, which means that, if scrollbars are, say, 17px wide, then on a vertically-scrolling document with no margins, 100vw is equal to 100% of the body width plus 17px.
The result of this is that viewport units have always been fundamentally broken and incorrect in the main place people wanted to use them: 100vw will cause overflow if scrollbars take any space.
Then along comes this new generation of viewport units, fixing an artificial problem (as you say), and continuing to ignore the actual bug, because the browser makers don’t care much about non-overlay scrollbars any more, even though that’s still the considerable majority of non-mobile users, and supported even on those non-mobile platforms that default to overlay scrollbars. (Aside: I’m glad that even when Windows is heading in the direction of overlay scrollbars, they’re at least not hiding the thumb whenever possible like macOS and all mobile platforms do. Also I miss Ubuntu’s Ayatana overlay scrollbars from about a decade ago—a bit gimmicky, but they showed care in balancing considerations and generally worked very well.)
And perhaps the worst part of it all? The spec actually included a practical workaround (give the document `overflow-y: scroll` so there’s always a vertical scrollbar, and vw will exclude any space allocated to that scrollbar—and the same for overflow-x/vh), but only Firefox implemented it, and no one else wanted to, and so it was eventually removed from the spec and from Firefox.
Well… not the viewport you’d expect. They reflect the viewport including document scrollbars, which means that, if scrollbars are, say, 17px wide, then on a vertically-scrolling document with no margins, 100vw is equal to 100% of the body width plus 17px.
The result of this is that viewport units have always been fundamentally broken and incorrect in the main place people wanted to use them: 100vw will cause overflow if scrollbars take any space.
Then along comes this new generation of viewport units, fixing an artificial problem (as you say), and continuing to ignore the actual bug, because the browser makers don’t care much about non-overlay scrollbars any more, even though that’s still the considerable majority of non-mobile users, and supported even on those non-mobile platforms that default to overlay scrollbars. (Aside: I’m glad that even when Windows is heading in the direction of overlay scrollbars, they’re at least not hiding the thumb whenever possible like macOS and all mobile platforms do. Also I miss Ubuntu’s Ayatana overlay scrollbars from about a decade ago—a bit gimmicky, but they showed care in balancing considerations and generally worked very well.)
And perhaps the worst part of it all? The spec actually included a practical workaround (give the document `overflow-y: scroll` so there’s always a vertical scrollbar, and vw will exclude any space allocated to that scrollbar—and the same for overflow-x/vh), but only Firefox implemented it, and no one else wanted to, and so it was eventually removed from the spec and from Firefox.
> because Apple couldn't deal with a small temporary framerate drop
and one that we probably Moore'd past pretty rapidly anyway.
and one that we probably Moore'd past pretty rapidly anyway.
I think we Moore'd past the iPhone's sluggishness running decent AS3 code around 2012 once Adobe got Flash Player iOS into beta... still didn't stop Apple from decimating a million lines of my code and destroying everyone's ability to play my games.
For any CSS newbie I would encourage them to learn Flexbox and Grid. I find that layout is the most confusing and those two display modes have greatly cleaned things up. It’s amazing how much they behave the way you intuitively expect them to. They eliminate… I’m going to dangerously say… most newbie gotchas.
Beyond that, 100% in agreement. There’s just so much and when it all interacts it can be a nightmare.
Beyond that, 100% in agreement. There’s just so much and when it all interacts it can be a nightmare.
I have been writing code for over 10 years, I just end up using bootstrap every time.
I have been learning CSS since....as long as it has existed.
And I would like miserably fail any "CSS gotcha" test. ("What does this code do?")
If you learn some subset of CSS you can be productive, but stray outside of that, and who knows.
And I would like miserably fail any "CSS gotcha" test. ("What does this code do?")
If you learn some subset of CSS you can be productive, but stray outside of that, and who knows.
I was complaining on HN about this property the other day, and got quite a bit of pushback. But I really believe that "dynamic viewport" is a terrible decision. Instead of Safari and other mobile browsers simply respecting the viewport itself, we're bending over backwards and adding more complexity to CSS just so they can have this little one-off feature of theirs. It's very frustrating.
[deleted]
People who learn things by increment do not have the slightest idea how hard it is to learn them from first principles. You are reasoning from long term memory. They new person is reasoning from working memory. You can only juggle a handful of new concepts at once.
[deleted]
You know how the Romans made extraordinary concrete but then got conquered and everyone forgot how to make it and it took thousands of years to rebuild the supply chain and even then concrete was less durable.
Remember that whole mess?
Well, let me tell you a story about Macromedia Flash. ;)
Remember that whole mess?
Well, let me tell you a story about Macromedia Flash. ;)
Hah! I feel exactly the same about Oracle Forms.
Never heard of it? 'twas a client-server development IDE which was based on the idea of a "data block", a true-blue bona fide Active Record implementation out in the wild around 8-10 years before Martin Fowler coined the name. Even then the world seemed unaware until Rails arrived.
Never heard of it? 'twas a client-server development IDE which was based on the idea of a "data block", a true-blue bona fide Active Record implementation out in the wild around 8-10 years before Martin Fowler coined the name. Even then the world seemed unaware until Rails arrived.
Allaire also had something similar in ColdFusion (holy crap am I dating myself here): call an array generator with a datasource as its backend and get an array of DB-backed objects you can iterate over.
> Well, let me tell you a story about Macromedia Flash. ;)
Cost money. Great for animation -- not making a button shrink or grow sort of thing, but characters doing things. Lousy for anything to do with websites.
Cost money. Great for animation -- not making a button shrink or grow sort of thing, but characters doing things. Lousy for anything to do with websites.
Flash was excellent for making buttons grow/shrink. So much so that many sites had flash-based navs driving static html pages in the top row of their table layouts.
Flash had its share of footguns in terms of code organization, but animating interaction was never a weak point.
Flash had its share of footguns in terms of code organization, but animating interaction was never a weak point.
> Flash was excellent for making buttons grow/shrink. So much so that many sites had flash-based navs driving static html pages in the top row of their table layouts.
Yeah, but it was a Frankensteinian bastard of a system. Pretty sure the accessibility of that was zero, and changing a link or adding a new button was never trivial.
That was web-design for the worst reasons: for the designers and their clients, but not web-design for the users.
Yeah, but it was a Frankensteinian bastard of a system. Pretty sure the accessibility of that was zero, and changing a link or adding a new button was never trivial.
That was web-design for the worst reasons: for the designers and their clients, but not web-design for the users.
Wrong. There was Flex and MXML and it was amazing.
I have the same feeling about web-assembly and Flash.
History repeats itself:
https://www.simplehtmlguide.com/pagetransitions.php
The issue with IE 5 wasn't that the features were useless, it was that they were proprietary.
It’s a combination.
The feature was a gimmick, and it shows in the design. Not one of the transitions is one you’d actually want to use on, y’know, a web page. No fade (only pixel fade, 12), no slide (only wipe, 4–7). And Page-Enter/Page-Exit was obviously the wrong primitive if you wanted to indicate any sort of relationship between pages, because it would only be “correct” if you navigated in one direction. Basically, it was obviously only even vaguely suitable for slide shows, and not very good even there.
So: the feature was useless. But being proprietary was a part of that: if they’d proposed to Anyone Else “let’s add this thing”, Anyone Else would have said “that’s a stupid design, no one is going to use that well, let’s either do nothing or completely redesign the concept to be useful”.
In fact, the feature is so bad that I suspect it was an idea from someone who didn’t know what they were doing but had power, and the developers put it in half-heartedly rather than resisting. If the developers had been serious about it, it’d surely have ended up with named rather than numbered transitions, and at least a couple of useful transitions rather than the useless ones it got, and some better arrangement for varying transition per link or by navigation direction.
The feature was a gimmick, and it shows in the design. Not one of the transitions is one you’d actually want to use on, y’know, a web page. No fade (only pixel fade, 12), no slide (only wipe, 4–7). And Page-Enter/Page-Exit was obviously the wrong primitive if you wanted to indicate any sort of relationship between pages, because it would only be “correct” if you navigated in one direction. Basically, it was obviously only even vaguely suitable for slide shows, and not very good even there.
So: the feature was useless. But being proprietary was a part of that: if they’d proposed to Anyone Else “let’s add this thing”, Anyone Else would have said “that’s a stupid design, no one is going to use that well, let’s either do nothing or completely redesign the concept to be useful”.
In fact, the feature is so bad that I suspect it was an idea from someone who didn’t know what they were doing but had power, and the developers put it in half-heartedly rather than resisting. If the developers had been serious about it, it’d surely have ended up with named rather than numbered transitions, and at least a couple of useful transitions rather than the useless ones it got, and some better arrangement for varying transition per link or by navigation direction.
> Not one of the transitions is one you’d actually want to use on, y’know, a web page. No fade (only pixel fade, 12), no slide (only wipe, 4–7).
The hardware of the time couldn't do better.
The hardware of the time couldn't do better.
This is the only explanation I’ve ever been able to imagine. It applied to PowerPoint’s slide transitions for a ridiculously long time too—I think it might have been 2007 before it finally got sensible transitions.
But I find it difficult to believe. You could scroll through a web page smoothly, and a slide transition is the same thing. I’m not sure how that was supported technically in those pre-compositor days. Fade is a little more complex, as you’re needing to interpolate each pixel between two images rather than just translating a static double-sized image. Not sure about that one; at 1024×768@60Hz that is 47 million pixel calculations per second, touching up to 38MB of memory for the two bitmaps being interpolated between, and if the CPU had to do the interpolation, it probably couldn’t quite.
But I find it difficult to believe. You could scroll through a web page smoothly, and a slide transition is the same thing. I’m not sure how that was supported technically in those pre-compositor days. Fade is a little more complex, as you’re needing to interpolate each pixel between two images rather than just translating a static double-sized image. Not sure about that one; at 1024×768@60Hz that is 47 million pixel calculations per second, touching up to 38MB of memory for the two bitmaps being interpolated between, and if the CPU had to do the interpolation, it probably couldn’t quite.
> You could scroll through a web page smoothly
Not really, certainly not at 60fps. Hell, even in the late 2000's, smooth scrolling for web pages specifically was still held back by rendering performance, hence the iPhone having much more aggressive scroll deceleration for web content only. In any case, 90's OSes did all sorts of tricks to try to avoid doing this kind of animation because “2D acceleration” wasn't a guarantee. Recall that scrollbars didn't have instant feedback in the past (they scrolled when you let go of the mouse) and neither did window resizing. These transitions would have been designed to work reliably even on the lowest-spec Windows 95 machine, considering they're part of office software, not games.
Not really, certainly not at 60fps. Hell, even in the late 2000's, smooth scrolling for web pages specifically was still held back by rendering performance, hence the iPhone having much more aggressive scroll deceleration for web content only. In any case, 90's OSes did all sorts of tricks to try to avoid doing this kind of animation because “2D acceleration” wasn't a guarantee. Recall that scrollbars didn't have instant feedback in the past (they scrolled when you let go of the mouse) and neither did window resizing. These transitions would have been designed to work reliably even on the lowest-spec Windows 95 machine, considering they're part of office software, not games.
> scrollbars didn't have instant feedback in the past (they scrolled when you let go of the mouse)
I believe that was only the case until Windows 3.11, and 95 scrolled constantly like it works now?
I believe that was only the case until Windows 3.11, and 95 scrolled constantly like it works now?
vs now where the features may be standardized, but almost the entire browser market share are things using the chrome rendering engine.
Came here for that.
If it took almost 25 years to reimplement them you might be able to argue they're actually pretty useless.
But things change. Perhaps it was a solution waiting for a problem. Let's see what happens
If it took almost 25 years to reimplement them you might be able to argue they're actually pretty useless.
But things change. Perhaps it was a solution waiting for a problem. Let's see what happens
Interesting.
As it stands now, all my apps in the wild use a single JS lib I wrote years ago for view transitions ("screen" transitions) - which essentially builds the next screen off the side of the page with a series of async calls, and once it's built without errors, swaps CSS classes with the main screen (each having a simple CSS animation to slide in or slide out). This has the benefit of allowing a screen change to abort if the user is suddenly offline or doesn't have access to the screen they're trying to load, or something like that. Additionally, the thing writes into the browser history if you want it to, and remembers which direction it swapped the screen in from. I'm not sure how logic like this would be addressed with the new view-transition-* syntax; maybe it's really just meant to replace the types of "-in" and "-out" animations I've been using on full-screen holders. I'll be interested to play with it.
As it stands now, all my apps in the wild use a single JS lib I wrote years ago for view transitions ("screen" transitions) - which essentially builds the next screen off the side of the page with a series of async calls, and once it's built without errors, swaps CSS classes with the main screen (each having a simple CSS animation to slide in or slide out). This has the benefit of allowing a screen change to abort if the user is suddenly offline or doesn't have access to the screen they're trying to load, or something like that. Additionally, the thing writes into the browser history if you want it to, and remembers which direction it swapped the screen in from. I'm not sure how logic like this would be addressed with the new view-transition-* syntax; maybe it's really just meant to replace the types of "-in" and "-out" animations I've been using on full-screen holders. I'll be interested to play with it.
> looks like its gonna have a big impact on how websites move.
Is it going to help make them stop? do browsers that support this all support the "don't make me nauseous" settings, or are we going to need to start populating css-construct-blocklists by hand?
Is it going to help make them stop? do browsers that support this all support the "don't make me nauseous" settings, or are we going to need to start populating css-construct-blocklists by hand?
CSS’s prefers-reduced-motion media queries apply[1] to View Transitions.
[1] https://developer.chrome.com/docs/web-platform/view-transiti...
[1] https://developer.chrome.com/docs/web-platform/view-transiti...
When I was a kid we could do 3 things with CSS 18 ways in 5 different browsers, and we liked it that way (not really, though).
I’m happy that CSS is becoming more capable in several ways, and I’ve usually been very pro-progress in cases like this. But I can sense myself sliding into the camp of wondering if some of this is overkill.
Maybe it’s not. View transitions though… I guess if they can be declarative and concise, that’s awesome. And if I don’t like all the crazy shit flying around my screen, I can toggle the prefers reduced motion setting? It seems ripe for abuse, though. I expect to see a whole lot of unnecessary view transitions.
I liked the write up in any case, I appreciate the enthusiasm.
I’m happy that CSS is becoming more capable in several ways, and I’ve usually been very pro-progress in cases like this. But I can sense myself sliding into the camp of wondering if some of this is overkill.
Maybe it’s not. View transitions though… I guess if they can be declarative and concise, that’s awesome. And if I don’t like all the crazy shit flying around my screen, I can toggle the prefers reduced motion setting? It seems ripe for abuse, though. I expect to see a whole lot of unnecessary view transitions.
I liked the write up in any case, I appreciate the enthusiasm.
These are neat new features, but I don’t know if I would call them “big philosophical things”.
> It feels like we’ve entered this new phase in the life of CSS where just keeping up with what’s shipping each year is too much for any one person to keep track of, let alone take advantage of.
So, basically, CSS has caught up to JavaScript ;-)
> It feels like we’ve entered this new phase in the life of CSS where just keeping up with what’s shipping each year is too much for any one person to keep track of, let alone take advantage of.
So, basically, CSS has caught up to JavaScript ;-)
I guess we've gone full circle as CSS replacing JS for hovering on menus was the original cool thing to do with CSS. e.g. https://meyerweb.com/eric/css/edge/
I feel really old, that "pure CSS" still sounds like something to be vaguely proud of << and then I see this website and remember what those menus looked like.
> CSS has caught up to JavaScript ;-)
Google CSS houdini
(Holy Hell)
Google CSS houdini
(Holy Hell)
Is CSS Houdini still alive or is it an ... Actual zombie
CSS Houdini is (I think) still A Thing, but I believe the browser devs have (rightly!) decided to concentrate on fixing more important issues first.
I believe the CSS Painting API[1] is the most advanced of the set? It has shipped in Chrome, behind a flag in Safari, and there's a polyfill[2] that (may/may not) work for unsupported browsers.
But the key issue with Houdini is that it requires JS to be enabled before it can do its magic ...
[1] - https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
[2] - https://github.com/GoogleChromeLabs/css-paint-polyfill
I believe the CSS Painting API[1] is the most advanced of the set? It has shipped in Chrome, behind a flag in Safari, and there's a polyfill[2] that (may/may not) work for unsupported browsers.
But the key issue with Houdini is that it requires JS to be enabled before it can do its magic ...
[1] - https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...
[2] - https://github.com/GoogleChromeLabs/css-paint-polyfill
css has finally become a programming language
Given how css has evolved since the start of my career, CSS will be an AGI by 2030
> View Transitions looks like its gonna have a big impact on how websites move. The TL;DR is that this API gives us control over how new pages load when you click a link.
Reminds me of Flash pages, in a bad way; especially after looking at video examples [1].
I hope it will also bring a renaissance of RSS, this would be a nice pairing.
[1]: https://github.com/tylergaw/mpa-view-transitions-sandbox
Reminds me of Flash pages, in a bad way; especially after looking at video examples [1].
I hope it will also bring a renaissance of RSS, this would be a nice pairing.
[1]: https://github.com/tylergaw/mpa-view-transitions-sandbox
Omg is anchor positioning going to solve native scroll fixed position jitter?!
[deleted]
And then they throw in this dynamic viewport unit stuff, and I realize…oh, I am guilty of hubris. I have angered the CSS gods, and they have struck me down for my arrogance—because this is complicated stuff.
https://blog.logrocket.com/improving-mobile-design-latest-cs...