Sometimes change for the sake of using the latest bleeding edge thing isn't really worth it.
The main goal of this is to explore the potential of modern CSS in building such a layout. I agree that some of the features aren't supported yet, but that will become better over time. The article shed light on things like container queries, fluid sizing.. etc.
• Container queries have less than a year’s support in any browser;
• Style container queries have only an incomplete implementation in Chromium for a month;
• :has() isn’t in Firefox yet and has been in other browsers for a year at most.
That is: you can’t actually depend on these features yet.
If you want to serve content to human people and not just to eyes or wallets then at least be aware that most modern browser share statistics collected with JS don't reflect the reality you'd see in your webserver logs.
I don't think the demographic is realistically relevant.
Of humans that deliberately disable JS, certainly going to be under 0.1%. (I’m one of them, incidentally, because on average it makes the web much better, lighter and faster.)
Of humans where various JS doesn’t run, due to having an older browser, a corporate proxy that blocks some things, a content blocker like uBlock Origin that incidentally blats your script, unreliable network conditions, and more things… well, that number is regularly quite a lot higher than 0.1%, often above 1%.
As for something like the Statcounter tracker, which these specific stats are built from, their methodology is obviously stupidly broken and has been for many years: ad blockers will tend to block it. (uBlock Origin does by default, and I expect others to as well.) And that number is generally agreed to be well above 10% (some say as high as 40%, though I’m sceptical of that), and heavily overrepresents users of less common browsers like Firefox.
97.23% of internet users do not care.
If you are arguing to not use Working Draft mechanisms in production environments (and you probably are), yes you have a point. Better safe than sorry, it's called a Working Draft for a reason.
But if you are arguing to not use something because Firefox (and only Firefox) does not support it, you are going to have a fun time trying to convince most webdevs to care about just 2.77% of all internet users.
You're essentially saying "I want to use this months old API, and fuck you if you still have a browser from last year." People used to respect some amount of backward compatibility.
There's no reason to "respect" backwards compatibility in an inherently online product that auto-updates.
There's nothing ideological here, it's just about being practical.
And neither Firefox nor Chrome self-updated beyond a certain point on my few years old Android tablet, which is still generally very usable for browsing and YouTube.
And the browser on one of my phones stopped updating, once the OS stopped getting upgrades, for about 2 years before I stopped using that phone (because there was nothing as good as it to upgrade to).
Non-latest browsers are a small percentage of users, but it's a myth some site designers believe that all Chrome, Firefox and Safari installs auto-update to latest versions except where the user decided for themselves to block updates.
To the owner of devices in generally great shape, that work fine with alnost all sites, sites designed with the bleeding-edge assunption can feel a bit "unnecessarily buy a new version of the exact same electronics with your copious spare cash and litter some e-waste landfill to view our content today!".
Site designer's choice of course.
But it's a myth that the current mainstrean browsers stay up to date by default for everyone who doesn't disable it. Some users can't update. This should particularly be in the awareness of designers wanting sites to be readable by people without much disposable income, or some accessibility issues.
So users in that situation should not be punished by web devs who only support the bleeding edge browser versions.
When 90% of users are on the newest version within a couple weeks, that's not "bleeding edge". It's mainstream.
You're also opening yourself up to security vulnerabilities as you browse.
If you turn off auto update, it's up to you to accept the consequences of both security risks and of sites breaking.
you say that like I am the only person who does this.
> When 90% of users are on the newest version within a couple weeks, that's not "bleeding edge".
[citation needed]
Essentially, yes: https://caniuse.com/usage-table
But in this day and age of browsers being Chrome and Chrome and Chrome and Chrome and Safari, all with forced autoupdates, there's little practical weight behind "browser <X> doesn't support it!". If Chrome supports it, the internet supports it whether any of us like it or not.
I think, regrettably, that 2023 might be roughly the time where the "old browser" support consideration is finally put to bed.
For example, you no doubt have to perform all sorts of code contortions to make things work in old Internet Exploder. It means you have to use old coding methods compared to things that are quicker and easier to implement and get working cross-browser & cross-platform in modern CSS. It also means you are writing more LOC, which means more scope for weird little bugs and time-consuming troubleshooting.
Secondly (and perhaps more importantly), making things work in old browsers means you are removing further incentive for people to upgrade. Given the increasing prevalence of browser-based attacks where people can be pwned simply by visiting a website that contains "specially crafted code", I think the quicker everyone gets onto modern browsers the better...
Unsurprisingly we’ve had 0 issues asking our customers to use recent versions of Chrome/Edge/Firefox/Safari. Obviously not using super new APIs like @container before they are fully read on these 4 but still that’s still basically every modern feature.
Isn't it a deliberate choice to have that experience?
Unless you're in an industry that requires not upgrading, backward compatibility is great, up until a point.
But this means my glibc is also an old version. And this OS was released before docker existed in repos (and has no docker support). So I'm using an older brower with JS completely disabled. It displays HTML, text, images, etc pretty well. It's just the for-profit sites that used to cause problems. But now everyone is cargo culting the for-profit stacks, devs are expecting updates to browsers every 2 weeks, and it's getting harder for me.
So yeah, I expect it to be hard. But also, people have legitimate reasons for using old software.
Its not. Its just that many developers have stopped caring about it. Google is releasing new APIs at a ridiculous pace, many of which are not needed for a huge chunk of websites. if developers want, they can avoid using newer APIs, or use them but add fallbacks for older browsers.
> for anything other than Opera.
sure, if you look at the current version of major browsers, support is pretty good for everything. but some users are locked to an old version, either out of personal preference, or work mandates. so its helpful if web developers dont use assume everyone is one the latest browser version. they dont need to support every version of every browser, but I think its reasonable to expect a two year old browser to work with most current websites, and more and more that is not the case.
Worse is that Google demonstrably has no qualms about leaving beta-quality implementations of new APIs in place for months or even years or about forcibly retiring APIs it decides shouldn't be there any more. It has done both of those things many times including with widely used functionality. Don't like it? Sorry guys but you should have been on the pre-alpha-might-release-it-one-day channel so you had a few weeks of notice to rewrite your entire style sheet.
Following one dominant browser at the expense of open standards is exactly how we got years of stagnation with IE6. Those of us who remember that period have no desire to see another like it. But those who do not learn from history...