▲ 135 points
back
44 comments
> New viewport units
These new viewport units frustrate me immensely, because they have completely ignored the longstanding complete brokenness of viewport units on platforms that don’t use zero-layout-width overlay scrollbars (which currently means pretty much all desktop platforms except macOS by default, and even there it’s at least easily possible to turn off overlay scrollbars). Basically, viewport units are always the wrong thing if there might be scrollbars: they’re broken by design.
Instead they’ve fixed the problem with inconsistency of interpretation of viewport height units on mobile browsers, which was, generally speaking, not something that was broken in the same way as the desktop situation, and there were simple (if non-obvious) practical workarounds for the most likely thing people wanted anyway.
So yeah, the new viewport units are worthwhile for what they improve in mobile browsers, but I’m disgruntled that they’re being presented as fixing viewport unit situation when the people involved have continued to basically ignore what I perceive as the real and most significant problem with viewport units, which has been an issue from the very start in all browsers except Firefox, which used to have a tolerable workaround (essentially: `body { overflow-y: scroll }` would make vw exclude the scrollbar) until it was ripped out of the spec and Firefox because no one else was interested in implementing it for some reason.
In short: the new viewport units are still fundamentally broken by design, only in a way that doesn’t affect most mobile platforms or the default macOS configuration.
I believe this is what the scrollbar gutter proposal is supposed to fix:
https://css-tricks.com/almanac/properties/s/scrollbar-gutter...
Essentially, you can specify if a scrollbar is supposed to take up space or render overlaid on top of content. In the case that a scrollbar takes up space, you can specify if the other side should also have a matching amount of space taken up to keep content centered.
If the above proposal passes (which it probably will do), then there is no more issue with the new viewport units.
Concretely, https://github.com/w3c/csswg-drafts/issues/6026#issuecomment... and https://github.com/w3c/csswg-drafts/issues/5254. My summary: a year and two ago, one guy (OK, an Invited Expert, so he is involved in matters and isn’t just a rando) suggested going back to what the spec used to have about `overflow: scroll` on the root, and adding scrollbar-gutter to the ways of activating that behaviour (which would be fair and reasonable), but no one else has really talked about it at all and there’s no movement—and, perplexingly, it doesn’t look to have actually been a motivating case of scrollbar-gutter.
Also scrollbar-gutter is a decidedly incomplete solution, only accounting for block axis overflow (thus inline axis size, vi, almost always equivalent to vw), and failing to handle edge-to-edge styling with classic scrollbars when scrollbars aren’t required. So you’re trading one broken thing for another only-slightly-less-broken thing. In order to be properly useful in the presence of things like full-width elements with background colours or images or whatever, it needs to be able to be paired with env(safe-area-inset-*) (though hopefully with logical unit names) so that in the absence of a scrollbar you can opt into drawing in the space reserved for it.
I'm all in for this units, finally on mobile that navigation bar would not screw up webapps
Funny that the subgrid example actually has a screenshot from a browser that doesn't support subgrid: https://github.com/GoogleChrome/web.dev/issues/7453
Well, that does say something about the dominance of Chrome...
To be fair, Firefox is the only browser that has implemented subgrid. It's a pretty new feature
> It’s a pretty new feature
I’m trying to decide how I feel about that characterisation, and I’m of two minds, but mostly leaning towards “it’s older than you think”.
From an implementation perspective: Firefox has had it for over two years (implemented in early–mid 2019, shipped in December 2019). That’s not especially new in the scheme of things for web features.
From a specification perspective, which certainly doesn’t matter as much but I think should not be completely ignored, it’s even older: CSS Grid started in early 2011, subgrid was added in late 2012, CSS Grid Level 1 became a Candidate Recommendation in September 2016 with subgrid marked as “at risk”, and subgrid was bumped to Level 2 by May 2017, a couple of months after Firefox, Chromium and Safari all shipped Grid in March 2017.
Hmm… Chromium 79 is from about the same time as Firefox 71 which shipped subgrid, did any interesting and quite-visible features land around then? Yeah, there are a few from around that time plus or minus a few releases that I’d be mildly inclined not to call “pretty new”, with a noticeable (though very subjective) correlation with features other browsers have also implemented. My feeling is that if Chromium and Safari had shipped subgrid in December 2019 as well (like all three shipped basic grid in March 2017) it probably wouldn’t be being called “pretty new” now.
That was a fairly useless rabbit hole. :-)
To add a little context to the rabbit hole, I'm fairly certain the reason why subgrid has taken so long on chromium based engines is because it was deemed not worth implementing on their old layout stack and would be much easier to work with in their new layout stack (LayoutNG).
The new layout stack took a little time to get out the door, solving weird issues with certain use cases that just wouldn't be able to be solved with the old layout stack (at least not without becoming a nightmare).
Now that it's out, there's a bunch of commits made from both google and microsoft emails working on reimplementing grid (GridNG) in the new layout system in such a way that grid stage 2 (subgrid) and grid stage 3 (masonry) extensions will be easier to maintain.
Fixed now, thanks for spotting and reporting!
(I'm quite sure the demo was built using Firefox, but then the screenshot was taken later.)
The last feature vanilla CSS needs to render most pre-processors obsolete (imo) is nesting. The latest CSS nesting specs are looking great and it's kinda sad to not see it being prioritized
I'm absolutely horrified at what the "modern web" has become. More complexity, more bugs, more barriers to entry for anyone else wanting to write their own browser and have it be usable for most sites. Google seems determined to squeeze everyone else out with this feature-churn.
If websites/web apps are adopting these features, maybe it's because they're useful? You're free to use a 10 years old browser and keep reading document-like websites. In the meantime I'll be using all the goodness the web can bring today, hoping it will end up fully replacing the very costly, heavy, intrusive native apps, that only work on the system they've been built for.
The problem is exactly that attitude turning what used to be highly accessible and interactive sites into elephantine "web apps" that need the latest and most user-hostile version of $BIG_BROWSER (which doesn't run on older OS and thus hardware too) to do what was perfectly possible with technology of a decade ago, or even less functionality.
I wonder what is more responsible for that; the fact that people don't care about history, or that corporate propaganda has pushed them away from realising it.
If websites are turned into web apps with more features, it's probably because it's bringing in money, in the form of users or consumers, don't you think? If consumers tended to like simple "interactive" websites like we used to have 10 years ago, companies would probably not bother building modern web apps. But that's not the case. Web apps, in general, do provide a way better experience than simple websites, and users do like them. There is no propaganda at work here, just simple market mechanisms.
If anyone is to blame for showing that a better user experience is possible, it's probably those who pushed for quality UI in native apps, that web apps are trying to match.
No, users often have next to no choice in what they are forced to use, or don't know better. It's just that the industry has been saturated with too many web developers who have nothing else to do, and companies like Google trying to increase their browser monopoly --- which ties in with attempting to make sure that users "don't know better".
Talk to people outside of the tech bubble. They hate what's happening, and also feel powerless to stop it.
The problem is exactly that attitude turning what used to be highly accessible and interactive apps into elephantine "native apps" that need the latest and most user-hostile version of $BIG_OS (which doesn't run on older hardware) to do what was perfectly possible with technology of a decade ago, or even less functionality.
I wonder what is more responsible for that; the fact that people don't care about history, or that corporate propaganda has pushed them away from realising it.
The web is way more free and open than operating systems. And if you want to build a website with only HTML and vanilla JS nothing is stopping you. There are websites made in the 90s that still work today. I much prefer the web, web apps and PWAs to their native counterparts.
The problem is that there are so many ways to do things, and every website uses a different subset.
Need to layout your elements? Great, that's what flex is for. I mean grid. I mean float. I mean the position attribute. I mean tables. I mean the margin attribution.
I'm really looking forward to a better integration of Webassembly. Then we can each pick our own libraries for layout/colors/video etc., and writing a browser will be more like writing a VM than writing huge entire ecosystems.
They won that fight a few years ago.
We used to have ACID 2 and ACID 3, do we have something similar to ACID 4? Or at least a subset of features that are guarantee to work across all browsers. While Caniuse is useful for checking support, many times there are browser that support something but it is buggy or differ from one another.
I think the closest thing to ACID these days is the web platform tests: https://wpt.fyi
Instead of one giant test, we have tests for individual features.
The Acid tests were obviously great at the time, but in retrospect some of the choices were not ideal. The concept of having a single page that only renders correctly when all the relevant conditions are met makes it hard to write broad tests for the feature; the Acid tests often depended on deep edge cases of one aspect of a feature, but lacked coverage of other aspects of the same feature. There was also an element of function-follows-form; the requirement to render an overall memorable image in the passing case often meant that the tests themselves were not well isolated, and developers working on the bugs would have to spend considerable time producing reduced test cases. For Acid 3 in particular, the need for 100 exactly tests meant that some features were given extremely shallow coverage, and the general hype around being the first implementation to pass an Acid test encouraged vendors to do the minimum necessary to make the test pass, rather than providing a useful implementation of the feature.
In the time since the Acid tests, there has been much more focus on building up the process for sharing tests as a matter of course in browser development; web-platform-tests is the result of that effort. Interop 2022 adds some more public accountability on top of web-platform-tests, which hopefully creates some of the same incentives as Acid tests for everyone to get the same set of features above the bar where they're no longer providing problems for web developers or end users. But it's intentionally set up to use a library of many smaller tests, and be paced as a marathon rather than a sprint, in the hope of avoiding some of the pitfalls of the Acid-test approach.
Neat. The big players seem committed and there is a scoring system to measure progress.
Shouldn't it be "to improve the web for users" ? Developer Experience is important, but it shouldn't be focused on in isolation from User Experience. If we were just talking about improving an IDE, it's fine, but "the web" is about much more than development.
Personally I think the way web browsers work is kind of insane from a user perspective. "The Web" is obsessed with technical expertise and custom code. An application like MS PowerPoint (pick any other design tool you prefer) is designed for users to create multi-layered media content and display it anywhere, without requiring a college degree or months/years of experience to make something. I don't think people who actively work on the web have considered how over-complicated it all is. For an industry that talks obsessively about "innovation" and "disruption", it can't seem to conceive of a post-web-browser world.
There are places where improvements on both dev experience and user experience intersect. For example, if the big browsers all delivered a much more robust set of easily styleable standard widgets, that would benefit devs by reducing the amount of custom widget work needed and benefit users with more consistent behavior and reduced payload sizes.
Things like that should be prioritized the most. Once all of that is taken care of, browser vendors could start doing cycles of switching between focus on dev experience and user experience.
If they get the interoperability right, the result will less JavaScript to download and fewer hacks. Users will get a faster and less klugey web experience across the board.
Yes. But faster doesn't necessarily mean better. I mean of course we don't want slow. But a fast loading shite experience is still shite.
If development is bad/hard due to inconsistencies needing extra tools for cross-browser, the experience is likely to be worse than necessary for users too. Usually very connected. Never saw something good made with Silverlight.
There's some truth to this. That said - speaking for a friend - (bad) UX designers and (bad) web designers consistently do more damage to users than a friction-y developer experience.
Well, the MS PowerPoint analogue would be any of the tools users use to build content on the web today. My dad runs a Shopify store with a theme he liked and modified. My sisters use Squarespace for their projects and similar tools with massive theme collections to choose from. One of them, originally very non-technical, even learned Twitter Bootstrap when she wanted to go her own way.
The MS PowerPoint user doesn't care about what the Windows application developers are talking about on Windows Hacker News, either.
Also, I think we pat ourselves too hard on the back when we go "surely all this stuff is way too complicated for people." Frankly, things are just becoming easier and easier.
I'm not sure this makes sense. My wife is learning front-end development now as I did 15 years ago and holy shit, to get an actual job you need to basically somehow magically become a mid-level engineer. Unit/automated testing, myriad of FE frameworks, OO and FP, CSS/Less/Sass (grid, flex, cascade, etc), multiple build tools, and this just to get your first job.
Sure, but they're focusing specifically on things that developers are already doing but are just more of a pain than they should be, usually requiring hacky workarounds, preprocessors, or browser specific overrides.
they can always compete for that though, but you don't want them to compete for the protocols
Subgrid and reliable viewport units on mobile devices are the holy grail for me. Very happy about these priorities. Thank you to everyone involved.
> New viewport units
how many units does CSS have?? Shouldnt part of the improvement be to simplify and declutter the web's fundamentals?
Apart from the duplicates (cm, inches, etc which can all be derived from mm with a basic calc) they all do different things. vw, vh, vmin, and vmax are useful for filling a screen, px is obviously related to the screen size, em, rem, ch and lh are relative to the current font or root font. There isn't much clutter there.
You're missing quite a few. Here's all the size related CSS units I could find:
em
rem
ex
rex
cap
rcap
ch
rch
ic
ric
lh
rlh
vw
vh
vi
vb
vmin
vmax
And soon also:
dvh
lvh
svh
Taken from here
I was illustrating how most of them aren't clutter. They do different things. This list just goes further to show that point - all the text related units refer to different aspects of the text, and they all need root and local versions. Same for screen space units like vw, vh, and so on. Any unit where you can't derive one from another means you need both.
There are some where you can do that. Absolute lengths like mm, cm, inch etc could just be one unit. Same for deg, rad and turn. Mostly though, CSS units are very well thought out, and it's easy to understand why the length units are included (USA vs metric).
what about flex units fr etc? they dont count?
Please list any I missed. I only listed things you could set as width, height etc.
There's also units like Hz and so on.
Obligatory XKCD: https://m.xkcd.com/927/
It's been a while since I looked into it, but are storage limits still a pain to handle across browsers?
According to this article, Safari doesn't yet have properly documented limits on storage.
I’m impressed safari is at the table. If I understand correctly, they only fix bugs once every six months, and don’t give any indication of timelines as matter of policy. For example, hasn’t locaStorage been broken in safari for ages? Or am I a bit behind the times? (Would have hoped to see that on the list if so)
Safari has really stepped up their game recently and made amazing strides in a very short amount of time. There's even some features that they're now ahead of the game on (like color mixing and the new color spaces).
Not sure about the localStorage issue. Are you referring to the fact that iPhones (and macs?) will automatically delete the localStorage for websites that haven't been visited in the past week?
There was an actual localStorage Safari bug that was around for a while somewhat recently: https://stackoverflow.com/questions/67324683/safari-14-1-loc...
It’s been fixed for a while, but the update mechanics definitely delayed the fix of the release; it was fixed in WebKit much earlier.