Baseline: a unified view of stable web features | Hacker News Reader

Baseline: a unified view of stable web features

developer.mozilla.org

151 pointsVinnl64 comments

> 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.)

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).

Major versions isn't a useless consistent concept because it's the strategy all browser developers use to determine when major features are added (vs bug/security fixes). Which is what Baseline is for, feature adoption.

So if Safari is adding a slew of major features once per year, and Firefox 6x per year, it doesn't matter. We have a baseline of what features as developers we can now implement without worrying about which browser version supports this or that. We see the baseline, we add the feature.

Last two major versions has been utilized (unofficially) by most people through Browserlist. It's been both suitable and productive.

This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-not... and see. Some of the biggest features get held for the next “major” number bump, certainly, but most point releases include at least as much as most major number bumps in Firefox or Chromium.

In my experience, people haven’t tended to use just “last two versions” with Browserlist: IE has normally been special-cased historically, and Safari has regularly been special-cased in some way, and Safari has actually been the salvation of the “last two versions” strategy because it dragged the baseline down to a more acceptable place, where “last two versions” of only Firefox and Chromium would regularly be disastrous. It has long been a really poorly-thought-out mechanism.

The other point you’re missing is user adoption. “At least one year” for Safari is one thing, but “five weeks” for everyone else is pretty crazy when you look at actual update statistics.

The issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly.

I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.

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.

Given how security critical a web browser is, why wouldn't you be running auto update for it?

Yes, well said. We should just force updates upon users. Block all websites unless user is on latest version, and close the source code to prevent compiling older versions.

Can't be too careful.

Because your OS doesn’t support a newer version.

Chrome 109 is the last version to support Windows 8.

There are a lot of people on systems even older than that.

IMO, this kind of pressure is needed and helpful to let people upgrade the vulnerable OS versions. Without it, people may stay forever with Windows XP.

Fuck that and the rest of the e-waste-generating degenerate corporate-authoritarian brainless drones.

I hear you, I'm not a fan of just throwing things away.

But internet-connected devices are a special case which deserves consideration.

Unfortunately Operating Systems, and the software that runs on them is imperfect. People are spending a lot of energy finding, and creating exploits based on, those imperfections.

An old car can be used almost infinitum, if there's any danger it's likely to be to itself, or at worst very local to others.

However an exploited old machine on a LAN, is dangerous to the entire LAN. And beyond.

There are hardware iterations that create a specific cut-off, but I don't think Windows 10 was one. (As i recall, if it could run Windows 8 it could run Windows 10 AND the upgrade was/is free.)

Yes there is -really- old hardware out there running XP, even DOS, but I'd argue its not something you should expose to the Internet, even as a client.

Running old browers, and related software, to browse the modern Web, is a very risky game with a very large penalty for failure.

In that context I'm happy to build sites targeting "current software".

> e-waste-generating degenerate corporate-authoritarian brainless drones.

If it is e-waste you are worried about you can always use Linux to keep your older machines useful as that both allows them to run better than Windows with a lightweight DE while also using the latest versions of the available software with all the security fixes.

You also get to have more control of how your computer will behave too.

This hypothetical project gets a lot of revenue from people with 10 year old computers to justify a decrease in productivity for 0.56% higher potential reach

Windows 8 and 8.1 is already EOL. No regular consumer should still be on it.

There are still more people using Firefox on Windows 7 than using Firefox on macOS (or if that's not the case anymore, the flip would have been recent).

I ran tech support for the elderly a couple years ago. There was a ridiculous amount of people who were still on Windows 7 because they bought their laptop in 2012 and only use it to exchange emails with their grandkids, do their banking and read the news. They never bought anything new or did any major upgrades because their system doesn't "feel old" so they see no use for it.

This is also why XPs complete ESR support ended in 2019. What I just said about people also applies to certain organizations like governments, who'd rather pay through the nose for that ESR support than upgrade.

That's just the reality of it all. There's a reason why Android is so extremely pushy with installing updates to Chrome et al. in the background (and why Androids old OS depreciation process is so slow) - users just flat out don't update their software or their hardware if they don't feel the need to.

EOL from a company means nothing. People will absolutely stick on years old hardware if they can help it as long as it works for them, and you're going to still be the one on the hook unless it's truly ancient tech. (We're currently at the point where if someone uses Vista, you could probably tell them to update? Keep in mind that Vista got EOLed in 2016. Windows 7 is kinda heading in that direction, but I'm not seeing that happen until another 2 to 3 years have passed at least).

Exactly. The bubble these people in my replies are in and aren't even aware is surprising.

Enterprise, because reasons.

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?

Liability? If you’re a web developer you want people to update so they can have new APIs. That they’re going to be pwned by a 1-click n-day is probably not something you would feel liability for.

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.

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."

What's the relationship between web.dev and Baseline?

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.

I kind of find it useful in the other direction. If I find s feature I want to use, and it's baseline, then I can just use it without worrying.

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".

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.

> This sounds like web.dev...

This post is on mdn.

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.

Step 5 seems like an uphill battle. I suspect it will be more like, gradual extension of the new standard to support advertiser-beloved features, to the point that the original upsides of the standard are broken, as users have to keep chasing feature support.

My earlier comments on this dynamic:

https://news.ycombinator.com/item?id=30727672

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.

i'd assume that wheelchair visitors are usually <1% and hence argue that it's not overly relevant for the decision.

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.

https://developer.mozilla.org/en-US/docs/Glossary/Baseline/C...

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.

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.[...]higher responsibility, more responsive & shared-early, with more safeguards than almost everyone else on the planet

That may be the most buzzword-filled sentence (and comment) I've ever seen in a reply, and it means absolutely nothing.

Google's weapon of monopoly is change. They have the manpower to churn the "standard" more than anyone else and modify their browser accordingly, while at the same time spreading propaganda about using features only their browser (now) has, regardless of whether they're actually necessary.

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.

Oh for fucks' sake... you're talking about an advertising-based megacorp that essentially controls the entire Internet. This isn't "don't be evil" anymore. They've long outgrown that.

The only people who have forced change, so far, are Apple, and then Mozilla, who both banned 3rd party cookies/implemented Intelligent Tracking Protection, without a spec or guidance ahead of time, & then had to walk back & create a bunch of allow lists half the protections to not break the internet.

> That may be the most buzzword-filled sentence (and comment) I've ever seen in a reply, and it means absolutely nothing.

This is flaming. It's just being aggressive. In case I'm not being clear & you really don't get it (which I doubt), let's go over my assertions.

"Chrome has the most fair" - Chrome is by far the most proactive of browsers at getting signals from other vendors. As above with Intelligent Tracking Protection, Apple and Moz just do shit & break shit. Everyone has to tip-tow through talking to Apple about specs because they'll just tank anything that doesn't go their way.

"reasonable" - The first step in launching features is to tell people, write an explainer at a public endpoint, start prototyping, launch origin trials, widen review/seek signals from other vendors. They go so far to be considerate about what's happening. The origin trials allow for end-user experimentation, with a buy in that makes it obvious to users there's not commitment to the feature actually shipping; a trial is a trial is a trial.

"upstream-first" - The guidelines I shared for launching features is to literally start incubating with a public spec. Get a mentor, & start writing specs. Prioritize the public & the spec over the work in the browser.

"pro-social" - As above, incredible commitment to involving other parties to try to build great specifications. No surprises. Everything announced far ahead of time, tested. Spec review & TAG & security review. Everything is extremely public.

"way of developing software the world has ever seen" - There's nothing like this. No one does 1/3rd as much a Google does when trying to advance the web. It's incredible.

"higher responsibility" - Spoken to by the above.

"more responsive" - blink-dev and the spec repos are both incredibly high responsiveness, with enormous amount of back & forth & give & take with external parties of all kinds to see what makes sense to build.

"& shared-early," - So much warm up for anything they do. Incubating with use case/scenarios/explainer. Creating a Chrome Status entry. Announcing to blink-dev. All before any actual work happens. Incredible visibility.

"with more safeguards than almost everyone else on the planet" - I can't think of a single other company with anywhere near this level of maturity about iterating forwards.

> Google's weapon of monopoly is change. They have the manpower to churn the "standard" more than anyone else and modify their browser accordingly,

If this were a problem, wouldn't we see the old web be broken? Do we see that problem? The only instances I'm aware of the web breaking in the past decade or so is Apple shipping Intelligent Tracking Protection, which they had to largely roll back & create allowlists around to allow the web to keep working. Google is now spearheading the effort to make actual specifications to for how we can do similar, but with, you know, actual specs, & just just waving the magic wand & changing things unannounced overnight.

> while at the same time spreading propaganda about using features only their browser (now) has,

The amount of tech that other browsers have adopted from Google is also notably high too. Since Google's open source, heck yes it's great that so many others can re-use & leverage the WebRTC stack Google was core to developing. Heck yes it's great that Google went off & built incredible software WebGL implementations in ANGLE, which again everyone else also uses now.

There just doesn't seem to be a real problem here. We don't have the IE vs Netscape web, where huge amounts of sites just don't work & use fundamentally different technologies. Things seem to mostly work. Most of these techs being built seem to make sense & be helpful & good. They're things we should have.

What is the propoganda Google is spinning here? Where do they haze the competition? If anything I see it as exactly the opposite. Google isn't negatively campaigning. But we see Apple then a week latter Mozilla make a big stink about how proud they are not to be implementing Web MIDI, or Web USB, which can be such direct & competent ways for users to make user of their devices. https://www.zdnet.com/article/apple-declined-to-implement-16...

> Oh for fucks' sake...that essentially controls the entire Internet.

This is the weirdest strangest version of control I've ever seen. I think most people who read blink-dev see an entirely different world. This doesn't seem based in reason, in judgement over the actions of Chrome teams. It seems based in bias, in personal Fear Uncertainty and Doubt. I do think there's real problems with Google as a company, and there are real problems. But this company's success is directly coupled to the web. If you look at blink-dev for real, it's incredibly easy to see the truth of what Google does for the web. They try to take care of it. They try to help. The hypermedium we have has indeed made them big and strong, but the only way for them to stay big & strong is to keep the web from going bad, to keep it a good medium. Which they have done an excellent job of. Which they have poured enormous good genuine unshady effort into doing, for years.

I'm going to say AMP, and hope that's enough to prove their main goal isn't to advance the "great hypermedium", but serve more ads and pay less fees to anyone else.

Google has Chrome because Firefox Safari and IE could cut them out and make other search engines the default, that's about it, the rest are side reasons.

AMP is definitely a bad taste. The bad feelings here are legitemate for sure. Still, I recognize at least some of the desires here. The web did have a huge problem with sites loading slow, and it on average could be better; AMP did prune things down & make a number of picks that would make things a lot faster. It was a careful subset.

People detested that AMP sites got privilege in search rankings, and that was definitely a huge issue & uncool as heck. Right off the bat, Google did say they wanted to try to open up the capabilities to other sites. They wanted to make generic web technology where sites could safely embed content in a "search carousel", without AMP. But AMP stuck around for years as the only way to do that.

The third AMP issue is what they kept wanting to make Google the first party host of a lot of this stuff, again crying that it was the only way they felt sure users would have fast experiences. And again, they said they hoped to have web specs to let them not have to do this in the future, coupled with the above search carousel/packaged site ideas. Which again was just incredibly slow to mature.

I think AMP really polarized people stronger than it should have. It wasn't great. And worse, it was one of the rare times we've seen Google really try to play at picking favorites; they said they were going to open things up so others could also have similar benefits without being AMP, but it was incredibly slow to mature (in part because the standards development for WebPackage has gone soo slow). But they really did tackle real issues & did try to make things better; they really did have a very fast loading, lower jank page system that sites could quickly build with & get consistent good results from. Still, there were so many political land mines they created with this attempt; I want to recognize there are real interests here, but absolutely, in the end, this was an incredibly damaging bad experience.

Still, I think there's an Occam's Razer view here. Either Google is an incredibly crafty top-down well-planned mastermind, who has incredibly complex schemes to "take over" the web. Or it's just a variety of different attempts to try to make things better, different organizational fiefs within a huge entity, and sometimes people are a little short-sighted about what a lightning rod their work might become. Yes: I think AMP is a pretty exceedingly bold & indeed misguided attempt, a huge lightning road for understandable frustration. But it's 7 years old now, and we haven't seen this kind of balderdashery since. Google isn't pushing AMP like they were, they're fine with it being a sparsely adopted toolkit, most of the teams have moved on, and we don't see a lot of similar picking favorites plays since. Some of WebPackage has shipped & we can do a lot of cool things now that AMP dreamed up, with no Google involved.

There's lawsuit discovery that uncovered that Google actively throttled non-AMP search results: https://searchengineland.com/google-throttled-amp-page-speed...

Must be interesting to defend trillion dollar megacorps on the internet.

>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)

The source data seems to be here:

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.

Yeah I dug around in the YAML but couldn't quite see how to derive what I wanted to know from it.

There's a JSON version of that data available here: https://cdn.jsdelivr.net/npm/web-features/index.json

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.

That explains it! I just found "is_baseline": true four times in https://cdn.jsdelivr.net/npm/web-features/index.json - I hadn't spotted it in there, which is why I was confused as to how it was being exposed.

Wrote about this in a TIL: https://til.simonwillison.net/datasette/baseline

Can I use does that, right?

https://caniuse.com/

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.

Apparently they don't factor in support on current LTS versions, which would have been nice.

Somewhat related: I know there is caniuse.com - so is there a way to pick a baseline, like a date or a selection of browser versions, and using those as a minimum, list all the features that will work? Essentially, a customised HTML/CSS/JS manual?

The way folks handle this in production is with browserslist, which lets you query on different things you want to support: https://github.com/browserslist/browserslist. This in turn tells other parts of your tooling what language features to transpile for production.

I imagine tools could be built on top of that which do what you’re asking too

This seems nice on the surface, but in reality I will be scrolling further down to find if the browser I care about supports the feature. Sometimes not even that original list has that browser listed. Ever designed a web page for an older Samsung signage display? (Really odd feature coverage.)

Reply on news.ycombinator.com