I usually roll my eyes when people claim that CSS is just too hard to learn, or that these new features are just too complex. I am generally of the opinion that once you are a day-to-day practitioner, CSS does broadly make sense once you build a mental model of how the system works.
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.
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.
> 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.
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.
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.
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.
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. ;)
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.
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 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.
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.
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.
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.
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?
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.
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 ;-)
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 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 ...
> 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.
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...