It's not bad. But in older browsers that don't support those new CSS features it always defaults to the single column "small" version even with a large browser window. That's not optimal. The current www.vox.com site displays perfectly fine in older browsers.
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.
https://gs.statcounter.com/browser-market-share Unless you're targeting some really niche market people will have a relatively up2date browser. It's not a problem to use recent features once they've been implemented by Chrome and Safari.
There's a lot of selection bias in collecting statistics with a package that'll only execute properly in the latest browsers and those running JS (as opposed to looking at webserver logs directly). I'll grant that vox probably only cares about serving content to people that can also see it's ads so it's a legitimate cut corner in this context. Their demographic is accessible eyes on ads and wallets, not people.
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'd be very shocked if the percentage of all human users that have JS disabled is more than <0.1%. Even web crawlers and other bots can (and do) execute JS these days.
I don't think the demographic is realistically relevant.
Some crawlers execute JS, but last I heard or checked even Bing’s crawler seldom did, and Google’s clearly tried to avoid doing so.
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.
I'd add Firefox to that list; specifically, you shouldn't be using :has until Firefox implements it, and afaik it's not implemented in Firefox because it's still a Working Draft and not finalized. Chrome and Safari implemented it early, and without any vendor prefix, but the implementation details are still subject to change. (Someone correct me if I'm wrong.)
>you shouldn't be using :has until Firefox implements it,
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.
The fact that most browsers aggressively push or even force updates should not be used as a justification for this.
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.
Fwiw, Safari doesn't auto-update beyond a certain point if you are not running the latest OS version from Apple, which may be for several good reasons, but your hardware being unable to run it is surely the top reason.
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.
not sure about Chrome, but you can turn off update on Firefox. I do this, and for good reason. I dont like the constant churn of browser UI moving around and changing every few months.
So users in that situation should not be punished by web devs who only support the bleeding edge browser versions.
caniuse uses statscounter. It's really no surprise that statistics collected via javascript fail to include browsers that aren't executing it or don't have the modern JS "features" it uses. https://en.wikipedia.org/wiki/Streetlight_effect
Web devs should not punish such users, agreed. Who will pay extra on top of the hourly rate to address the needs you have? Especially when it's your problem with somebody else's software (Firefox) that would require this extra investment.
its not a problem with the software, its a problem with the web site adding features that only work with the newest browser, without any fallback for older browsers.
In times past I would have fervently agreed with you.
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...
I work a niche B2B product and we basically made this a requirement.
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.
At my last company we were selling into the NHS which was traditionally very conservative with browsers (they were one of the last users of IE6). But even they're on Chrome these days.
Yeah I always think it's strange that because you have made the deliberate choice to not upgrade your browser in years, ignore all of the "feature not supported on your browser" messages, ignoring security updates, etc. that I should be focusing on your experience, instead for the 98% of people who do do those things.
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.
In my case the text to speech software I use to interact with my computer doesn't exist in the same form in modern operating systems. The modern installable version and voices are much worse. So I stick to an old OS that supports my text to speech.
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.
if you’re using an older browser there’s a good chance you’re vulnerable to a bunch of security holes too, unfortunately we’re past the days of only updating every 2 years
Your sarcasm isn't hitting the way you think it is. I've spent enough time doing my job and enough time on CanIUse to know that the era of worrying about browser compatibility is behind us. I dismiss Opera because it's only at 1% use. There has never been an expectation at any point in my 15 years doing that that I should browser test for browsers at !% use. And realistically, the properties that aren't currently browser compatible are one's that I never use and have little need for. Some are cool and will be compatible before long. But I can't really remember the last time I looked up a property I wanted to use and found it would be problematic for anything other than Opera. Granted, my attitude might be different if I was building sites for an international audience.
> I've spent enough time doing my job and enough time on CanIUse to know that the era of worrying about browser compatibility is behind us.
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.
Google is releasing new APIs at a ridiculous pace, many of which are not needed for a huge chunk of websites.
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...
Sometimes change for the sake of using the latest bleeding edge thing isn't really worth it.