6 ms·

Baseline: a unified view of stable web features

151 points by Vinnl 3y ago

chrismorgan 3y ago
> 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 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.)
- waboremo 3y ago
  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).
  - chrismorgan 3y ago
    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).
    - waboremo 3y ago
      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.
      - chrismorgan 3y ago
        This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-notes 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.
- 2h 3y ago
  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.
  - simonw 3y ago
    Given how security critical a web browser is, why wouldn't you be running auto update for it?
    - 2h 3y ago
      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.
    - tambourine_man 3y ago
      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.
      - dialogbox 3y ago
        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.
        userbinator 3y ago
        Fuck that and the rest of the e-waste-generating degenerate corporate-authoritarian brainless drones.
        bruce511 3y ago
- atopal 3y ago
  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.
simonw 3y ago
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)
- jrmg 3y ago
  The source data seems to be here: https://github.com/web-platform-dx/feature-set 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/feature-group-definitions/cascade-layers.yml 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.
  - simonw 3y ago
    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 https://cdn.jsdelivr.net/npm/web-features/index.json
  - foolip 3y ago
    I'm one of the people working on https://github.com/web-platform-dx/feature-set 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.
    - 3y ago
rektide 3y ago
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.
- userbinator 3y ago
  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 https://news.ycombinator.com/item?id=9961613
  - rektide 3y ago
    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 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/ 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.
geraldhh 3y ago
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.
parasti 3y ago
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.)
onion2k 3y ago
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."
- Thorrez 3y ago
  What's the relationship between web.dev and Baseline?
  - andreban 3y ago
    Baseline is being discussed and defined in the WebDX Community Group: https://www.w3.org/community/webdx/ 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.
- bruce511 3y ago
  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".
  - andreban 3y ago
    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.
netzego 3y ago
"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/Compatibility https://developer.mozilla.org/en-US/docs/Glossary/Baseline/C...
layer8 3y ago
Apparently they don't factor in support on current LTS versions, which would have been nice.
forgotmypw17 3y ago
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.
- geraldhh 3y ago
  > 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.
  - aziaziazi 3y ago
    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.
    - SilasX 3y ago
      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 https://news.ycombinator.com/item?id=30727672
detrites 3y ago
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?
- noahtallen 3y ago
  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 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

151 points by Vinnl 3y ago

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

waboremo 3y ago
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).
- chrismorgan 3y ago
  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).
  - waboremo 3y ago
    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.
    - chrismorgan 3y ago
      This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-notes 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.
2h 3y ago
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.
- simonw 3y ago
  Given how security critical a web browser is, why wouldn't you be running auto update for it?
  - 2h 3y ago
    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.
  - tambourine_man 3y ago
    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.
    - dialogbox 3y ago
      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.
      - userbinator 3y ago
        Fuck that and the rest of the e-waste-generating degenerate corporate-authoritarian brainless drones.
        bruce511 3y ago
atopal 3y ago
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.

simonw 3y ago

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)

jrmg 3y ago
The source data seems to be here: https://github.com/web-platform-dx/feature-set 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/feature-group-definitions/cascade-layers.yml 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.
- simonw 3y ago
  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 https://cdn.jsdelivr.net/npm/web-features/index.json
- foolip 3y ago
  I'm one of the people working on https://github.com/web-platform-dx/feature-set 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.
  - 3y ago

rektide 3y ago

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.

userbinator 3y ago
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 https://news.ycombinator.com/item?id=9961613
- rektide 3y ago
  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 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/ 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.

geraldhh 3y ago

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.

parasti 3y ago

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

onion2k 3y ago

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

Thorrez 3y ago
What's the relationship between web.dev and Baseline?
- andreban 3y ago
  Baseline is being discussed and defined in the WebDX Community Group: https://www.w3.org/community/webdx/ 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.
bruce511 3y ago
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".
- andreban 3y ago
  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.

netzego 3y ago

"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/Compatibility https://developer.mozilla.org/en-US/docs/Glossary/Baseline/C...

layer8 3y ago

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

forgotmypw17 3y ago

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.

geraldhh 3y ago
> 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.
- aziaziazi 3y ago
  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.
  - SilasX 3y ago
    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 https://news.ycombinator.com/item?id=30727672

detrites 3y ago

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?

noahtallen 3y ago
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 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