> The Web Platform Baseline consists of features natively supported in the core browser set for at least two major versions.
I don’t even know what “two major versions” means. Or why it would be reasonable to consider as a baseline.
For Safari: we’re currently at 16.4 (March 2023); does “two major versions” mean from Safari 15 (September 2021), or from Safari 16.3 (January 2023)? I’m going to guess 16.3.
For Firefox: so this just ignores Firefox ESR? It’s at 102.11.0, while regular is at 113.0. (That is, it’s at nine versions/nine months ago.)
For everyone else: you know that’s permanently as little as about five weeks ago, right? Put bluntly: that’s stupid, nothing like what a baseline should be.
By the sound of it, this may be genuinely ignoring 25–35% of users, and declaring features “baseline” not supported by the browsers used by fully 15–25% of users. (Numbers taken from quick estimation based on https://caniuse.com/usage-table which mostly uses StatCounter’s woefully misleading and wrong numbers because I’m lazy, but I think my error bars are large enough that they’d hold up to more rigorous calculation using other data sets too.)
My only hope here is that “two major versions” means Safari 15. Then all up it’d mean roughly “since September 1–2 years ago” rather than “mostly 5–10 weeks ago”, and that 15–25% would drop to under 5% for most features in the delta, half by simple coincidence.
(Aside: I really wish browser makers would switch to some form of calendar versioning, e.g. YY.MM. There was a great opportunity about now when Firefox caught up to Chromium due to a slightly faster cadence.)
Looking at browser usage for the last two major versions is misleading. That would only be true in a parallel release of a web platform feature in every browser, but that's basically never the case, and it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.
Major versions are always the first number before the first decimal point. So Safari 15 and Safari 16. You can check the linked feature set repo linked in the article and see that for the features, they're only checking that first group of digits. "15" "16" (sticking to the safari example).
Safari has a radically different approach to numbering to all the rest (even though it’s them that changed, not it). It’s bumping its “major” number once per year, whereas Chromium and Firefox are bumping theirs 10–12 times per year. Unless they have radically different deployment strategies, “major versions” is clearly useless as a consistent concept across browsers. But despite Safari being tied to the OS version, when you take everything together (hardware support for their OSes, OS upgrade frequency) it’s only a little different, nowhere near the 10× difference in importance of a “major version”.
All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
100% agree. This is such an idiotic standard, they might as well stop lying and just say the truth: "if you're not on auto update, fuck you".
What's worse is people copycat this "baseline", and if you try to argue sanity, they just say "sure it's what Chrome/Firefox recommend" without knowing or caring that they are only supporting months old browsers now. It's madness.
To be fair, if you don't click the button in the corner and you're not airgapped, what two words better capture my response to the liability of supporting you?
This sounds like web.dev are advocating devs don't do feature detection and progressive enhancement, and adopt a "don't use a feature until it's in all browsers" mindset. I mean, you should detect support regardless just in case, but if you approach building apps with a more "I'll use whatever the user has available" way of thinking you can deliver better experiences (in my opinion), even if it makes a dev's life a little harder in some cases.
It's a surprising move from the web.dev team to say the least. If I was being cynical, and I am, I'd suggest this move is designed less to be 'helpful' and more to highlight how far behind Chrome other browsers are. It's like lots of pages are saying "This is a lovely feature, but don't use it because of clunky old Firefox" rather than saying "This is a lovely feature, and here's how to use it, including a polyfill/workaround for browsers that don't support it yet."
And that's exactly the goal. There's no recommendation against using features that are not in Baseline - and there is a superset of features that are progressive enhancement or polyfilllable, but those are much more use-case dependent - Progressive Enhancement frequently depends on the use case, and Polyfills vary the impact they have on performance, so need more care.
Baseline is being discussed and defined in the WebDX Community Group: https://www.w3.org/community/webdx/. It's not a created by web.dev or Google, but there are people who work on it who are part of the W3C Community Group.
There are more than a dozen perfectly useful browsers with recent releases, some of which have no provisions for css or js. And i'm going to go through the effort to support them, because they are valid. My baseline is bend over backwards to accommodate every user on every browser, configuration, and network. Anything else is just plain uncivilized, like building a museum without wheelchair ramps because only 0.01% use wheelchairs.
> some of which have no provisions for css or js. And i'm going to go through the effort to support them, because they are valid
i wish this would catch on (or even be a mandated accessibility requirement) and every website could have this kind of ultimate compatibility/fallback mode to pure html.
0. Country/state legislators starts discussing mandatory html version for static content.
1. Some website (not « webapps ») start providing an html only version.
2. First users wave engage: plenty of hn readers
, others techies, people with disabilities. Some news enthusiasts find it useful to consume articles (and the web !) as a simple and peacefull content browsing way.
3. First wave share their enthusiasm. Others sites catch up. Second wave with people from all sides, including:
4. PM, advertisers, marketers, businessmans… all at them have different opinions about this. However those who have direct or indirect interests with online advertising also fear kpis decrease.
5. A bunch of ad lobbyist flood the legislators. End of legislation discussion.
Respect to you! This might sound ridiculous to some but is honestly my personal ideal as well.
I have found it hard to achieve in real world settings. The PM wants to know how many visitors aren’t enabling JS before we dare justify any effort towards supporting that case, for example.
You're absolutely right, in "real world" settings of commercial projects, it's rarely a concern. That's why I distanced myself from commercial development.
Are you making this comment as an individual, perhaps building personal web projects? Or, as a representative of a (for profit) business? If so, was this a business decision?
I am not sure the disabled analogy holds. I agree with wheelchair ramps because being disabled is not a choice. However, using a “disabled” browser •is• a choice. One my business has decided isn’t worth supporting and can use the time to add features that the majority of users want.
I'm making this comment as an individual who operates several public-facing web sites, and also writing and supporting a framework for making these websites.
I don't think it is a choice for many people, for example:
If you are using someone else's device where you cannot install anything.
If you are using an older device, which may need JS disabled for performance reasons.
If the browser you're using has special accessibility features that other browsers don't.
If you tried to install another browser, but were not able to.
There are many scenarios, some which I may not even be able to anticipate ahead of time.
My framework's basic features: account registration, posting, commenting, voting, and filtering, are all supported on mainstream or once-mainstream (1% or more market share) browsers released since 1995, to my knowledge, with and without JavaScript.
If I'm able to accomplish this pretty much by myself with a bit of elbow grease, I can't help but think that it's only laziness and excuses which prevent someone with more manpower from at least providing something like mbasic (but not broken like mbasic) to all users, especially on informational read-only sites.
"Can i use this" badges for cross browser features
[Green] If you see the green Baseline badge, then you can trust that the feature will work in the browsers' latest and previous major releases.
[Yellow] If you see a yellow badge showing that a feature is not yet Baseline, then do more research and testing with your site's users before relying on that feature, or wait for it to become Baseline.
I dunno, this feels depressing to me. The new PR campaigns being about lower-common-denominators is sad news.
Alas there's basically just Firefox, Safari, and Chrome in the running. Firefox & Safari are both aligned around anti-features, around baselines, far more than driving things forwards or trying stuff (both with plenty of exceptions to that behavior though). I'd be so much more interested in safe & stable & supported if there were more players out there also trying to push forward & try new web specs. But there aren't. Promoting a "Baseline" or a "unified view" of "stable" features is like the least progressive, least hopeful, most limited vision there is, when only one company is actively really pushing forwards.
when only one company is actively really pushing forwards.
To be clear, they're only doing that to further their monopoly, so the more everyone else refuses to be pulled along like dogs on a leash --- especially when creating sites --- the more actual browser diversity we can have, independent implementations that don't have to continue trying to trendchase an idiotic "living standard".
PPK (whom you cite) is an extreme conservative for the web, as are many many forces about.
I don't think it's possible to have this conversation. People have a deep belief about what they want from the web, and a ton of people want it small & tiny & less than it is.
People are desperate to believe Google has some huge weird agenda. The agenda seems pretty obvious: build a great hypermedium. Build the best protocol for information the world has. Because Google already is everywhere, already has the best search engine, already has a great first party relationship with users, as they start every journey into the web. Google' agenda isn't to block out or hurt other people, it's to be better & do better than all the native apps, to make the connected online experience simply better.
And they're winning. They're doing it: they're making the connected hypermedia world the best option for computing, by having great capabilities, by making it easy for webdevs to do amazing things quickly, by having a good low-level capabilities that endless frameworks can arrange as they see fit, pursuant to the ideals of the Extensible Web Manifesto. https://github.com/extensibleweb/manifesto
They're not being mean or unfair at all. Chrome has the most fair, reasonable, upstream-first, pro-social way of developing software the world has ever seen. https://www.chromium.org/blink/launching-features/ is higher responsibility, more responsive & shared-early, with more safeguards than almost everyone else on the planet, and they do it in public. Their works are specified, they seek review early, they get architecture & security group reviews. It's unprecedented in extreme how far Google goes to make sure web development is open.
But people just cannot possibly imagine there's not some secret cause. Everything is met with hostility, weird personal attacks, & debasement. You basically never hear anyone who is critical but also reasonable or sympathetic or understanding: this is the tell. Almost all the negative feedback against Google & Chrome is to the wall outrage, is 100% on one side, lacking in nuance or balance. There's no recognition of good, no appreciation of the attempt at process. This is a cruel & savage thing the internet has ganged up to do, to be so lopsidedly angry and mean, with so little willingness to recognize optimism, growth, hope, trying, and effort, which have already been such an amazing boon to us.
>I'd be so much more interested in safe & stable & supported if there were more players out there also trying to push forward & try new web specs.
Google is pushing forward to remove the number of players. The more features have to be implemented the less players are able to afford the number of developers that are needed to keep up.
The silly thing is that Google is trying to turn the browser into an application platform. To a certain extend that's justified but with Java, they already have such a platform, but they chose to break the compatibility of the byte code. If they realign with the java byte code, there would be no need to push features in browsers. Developers could ship libraries for whatever they need on the Java platform.
the idea seems useful to reduce workload for coders and managers (less debugging, hacking, decision making...).
google pushing web standards surely is a double edged sword and putting some limit on feature-fomo should probably not remain a unformalized role of apple and mozilla.
Questions I haven't yet been able to answer from browsing the various Baseline sites:
- What are the exact browser versions that are included in Baseline? "Everything that is fully supported in the most recent two versions of major browsers will be part of Baseline" isn't enough information for me - I want it to tell me exactly which browser versions those are, ideally with rough estimates as to the percentage of users who are covered by them.
- Which features are part of Baseline? Do I have to browse through every page of MDN to find out? I'd rather see a single big table showing me them all in one place (and ideally also a JSON file or similar)
I am very much struggling to find anywhere that actually lists versions currently counted as ‘baseline’, or any definition of what a ‘major version’ is though.
I'm one of the people working on https://github.com/web-platform-dx/feature-set. Only 4 features are only marked as Baseline currently, for a minimal initial launch on MDN. The ambition is to cover the whole web platform, and at that point a list of all Baseline features could be generated.
The core browser set is not defined in exact versions of browsers, since many browsers release every 4-6 weeks. The two most recent major versions refers to the number before the first point. So, for Chrome it would be 113 and 112, for Safari it would be 15.x and 16.x.
But the crucial point is, it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.
Maybe showing the version numbers on the widget per feature might be useful.
Readit News
I don’t even know what “two major versions” means. Or why it would be reasonable to consider as a baseline.
For Safari: we’re currently at 16.4 (March 2023); does “two major versions” mean from Safari 15 (September 2021), or from Safari 16.3 (January 2023)? I’m going to guess 16.3.
For Firefox: so this just ignores Firefox ESR? It’s at 102.11.0, while regular is at 113.0. (That is, it’s at nine versions/nine months ago.)
For everyone else: you know that’s permanently as little as about five weeks ago, right? Put bluntly: that’s stupid, nothing like what a baseline should be.
By the sound of it, this may be genuinely ignoring 25–35% of users, and declaring features “baseline” not supported by the browsers used by fully 15–25% of users. (Numbers taken from quick estimation based on https://caniuse.com/usage-table which mostly uses StatCounter’s woefully misleading and wrong numbers because I’m lazy, but I think my error bars are large enough that they’d hold up to more rigorous calculation using other data sets too.)
My only hope here is that “two major versions” means Safari 15. Then all up it’d mean roughly “since September 1–2 years ago” rather than “mostly 5–10 weeks ago”, and that 15–25% would drop to under 5% for most features in the delta, half by simple coincidence.
(Aside: I really wish browser makers would switch to some form of calendar versioning, e.g. YY.MM. There was a great opportunity about now when Firefox caught up to Chromium due to a slightly faster cadence.)
All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
What's worse is people copycat this "baseline", and if you try to argue sanity, they just say "sure it's what Chrome/Firefox recommend" without knowing or caring that they are only supporting months old browsers now. It's madness.
It's a surprising move from the web.dev team to say the least. If I was being cynical, and I am, I'd suggest this move is designed less to be 'helpful' and more to highlight how far behind Chrome other browsers are. It's like lots of pages are saying "This is a lovely feature, but don't use it because of clunky old Firefox" rather than saying "This is a lovely feature, and here's how to use it, including a polyfill/workaround for browsers that don't support it yet."
If its not baseline I can head over to caniuse and see coverage, add progressive enhancement, find polyfills and do on.
It that context it saves me worry, and also creates a baseline of things I have yo document as being "browser dependant".
This post is on mdn.
i wish this would catch on (or even be a mandated accessibility requirement) and every website could have this kind of ultimate compatibility/fallback mode to pure html.
1. Some website (not « webapps ») start providing an html only version.
2. First users wave engage: plenty of hn readers , others techies, people with disabilities. Some news enthusiasts find it useful to consume articles (and the web !) as a simple and peacefull content browsing way.
3. First wave share their enthusiasm. Others sites catch up. Second wave with people from all sides, including:
4. PM, advertisers, marketers, businessmans… all at them have different opinions about this. However those who have direct or indirect interests with online advertising also fear kpis decrease.
5. A bunch of ad lobbyist flood the legislators. End of legislation discussion.
I have found it hard to achieve in real world settings. The PM wants to know how many visitors aren’t enabling JS before we dare justify any effort towards supporting that case, for example.
I am not sure the disabled analogy holds. I agree with wheelchair ramps because being disabled is not a choice. However, using a “disabled” browser •is• a choice. One my business has decided isn’t worth supporting and can use the time to add features that the majority of users want.
I don't think it is a choice for many people, for example:
If you are using someone else's device where you cannot install anything.
If you are using an older device, which may need JS disabled for performance reasons.
If the browser you're using has special accessibility features that other browsers don't.
If you tried to install another browser, but were not able to.
There are many scenarios, some which I may not even be able to anticipate ahead of time.
My framework's basic features: account registration, posting, commenting, voting, and filtering, are all supported on mainstream or once-mainstream (1% or more market share) browsers released since 1995, to my knowledge, with and without JavaScript.
If I'm able to accomplish this pretty much by myself with a bit of elbow grease, I can't help but think that it's only laziness and excuses which prevent someone with more manpower from at least providing something like mbasic (but not broken like mbasic) to all users, especially on informational read-only sites.
[Green] If you see the green Baseline badge, then you can trust that the feature will work in the browsers' latest and previous major releases.
[Yellow] If you see a yellow badge showing that a feature is not yet Baseline, then do more research and testing with your site's users before relying on that feature, or wait for it to become Baseline.
https://developer.mozilla.org/en-US/docs/Glossary/Baseline/C...
Alas there's basically just Firefox, Safari, and Chrome in the running. Firefox & Safari are both aligned around anti-features, around baselines, far more than driving things forwards or trying stuff (both with plenty of exceptions to that behavior though). I'd be so much more interested in safe & stable & supported if there were more players out there also trying to push forward & try new web specs. But there aren't. Promoting a "Baseline" or a "unified view" of "stable" features is like the least progressive, least hopeful, most limited vision there is, when only one company is actively really pushing forwards.
To be clear, they're only doing that to further their monopoly, so the more everyone else refuses to be pulled along like dogs on a leash --- especially when creating sites --- the more actual browser diversity we can have, independent implementations that don't have to continue trying to trendchase an idiotic "living standard".
Related: https://news.ycombinator.com/item?id=9961613
I don't think it's possible to have this conversation. People have a deep belief about what they want from the web, and a ton of people want it small & tiny & less than it is.
People are desperate to believe Google has some huge weird agenda. The agenda seems pretty obvious: build a great hypermedium. Build the best protocol for information the world has. Because Google already is everywhere, already has the best search engine, already has a great first party relationship with users, as they start every journey into the web. Google' agenda isn't to block out or hurt other people, it's to be better & do better than all the native apps, to make the connected online experience simply better.
And they're winning. They're doing it: they're making the connected hypermedia world the best option for computing, by having great capabilities, by making it easy for webdevs to do amazing things quickly, by having a good low-level capabilities that endless frameworks can arrange as they see fit, pursuant to the ideals of the Extensible Web Manifesto. https://github.com/extensibleweb/manifesto
They're not being mean or unfair at all. Chrome has the most fair, reasonable, upstream-first, pro-social way of developing software the world has ever seen. https://www.chromium.org/blink/launching-features/ is higher responsibility, more responsive & shared-early, with more safeguards than almost everyone else on the planet, and they do it in public. Their works are specified, they seek review early, they get architecture & security group reviews. It's unprecedented in extreme how far Google goes to make sure web development is open.
But people just cannot possibly imagine there's not some secret cause. Everything is met with hostility, weird personal attacks, & debasement. You basically never hear anyone who is critical but also reasonable or sympathetic or understanding: this is the tell. Almost all the negative feedback against Google & Chrome is to the wall outrage, is 100% on one side, lacking in nuance or balance. There's no recognition of good, no appreciation of the attempt at process. This is a cruel & savage thing the internet has ganged up to do, to be so lopsidedly angry and mean, with so little willingness to recognize optimism, growth, hope, trying, and effort, which have already been such an amazing boon to us.
Google is pushing forward to remove the number of players. The more features have to be implemented the less players are able to afford the number of developers that are needed to keep up.
The silly thing is that Google is trying to turn the browser into an application platform. To a certain extend that's justified but with Java, they already have such a platform, but they chose to break the compatibility of the byte code. If they realign with the java byte code, there would be no need to push features in browsers. Developers could ship libraries for whatever they need on the Java platform.
google pushing web standards surely is a double edged sword and putting some limit on feature-fomo should probably not remain a unformalized role of apple and mozilla.
- What are the exact browser versions that are included in Baseline? "Everything that is fully supported in the most recent two versions of major browsers will be part of Baseline" isn't enough information for me - I want it to tell me exactly which browser versions those are, ideally with rough estimates as to the percentage of users who are covered by them.
- Which features are part of Baseline? Do I have to browse through every page of MDN to find out? I'd rather see a single big table showing me them all in one place (and ideally also a JSON file or similar)
https://github.com/web-platform-dx/feature-set
There’s a bunch of YAML files in the ‘feature-group-definitions’ directory and the ‘leaf node’ ones have ‘is_baseline’ keys in a ‘status’ dictionary. See e.g. https://github.com/web-platform-dx/feature-set/blob/main/fea...
I am very much struggling to find anywhere that actually lists versions currently counted as ‘baseline’, or any definition of what a ‘major version’ is though.
There's a JSON version of that data available here: https://cdn.jsdelivr.net/npm/web-features/index.json
https://caniuse.com/
But the crucial point is, it's not the same for every feature. A feature like subgrid was launched years ago in Firefox, last year in Safari and will be launched later this year in Chromium. So, by the time it's in Baseline, it will be in two versions back for Chromium browsers, but 20+ versions back for Firefox and over a year old in Safari.
Maybe showing the version numbers on the widget per feature might be useful.