Consider taking progressive enhancements into account for the Baseline status

[captainbrosset]

See this thread from @zachleat about Baseline: https://bsky.app/profile/zachleat.com/post/3ljzvytoso22q

Let’s talk about why Baseline browser compatibility doesn’t tell a complete story about whether or not a feature can be used “safely” by developers.

Consider accent-color (Not Baseline) vs. CSS Nesting (Baseline 2023).
Browser compatibility is only a small piece: it’s more important to consider the role it plays and how progressive-enhancement friendly it is.
CSS Nesting requires cross-browser ubiquity. accent-color is much safer!

This has come up a few times already in the past, but looking for an issue tracking this didn't surface anything. So here's one to continue discussing with the WebDX CG.

[dfabulich]

This was the related issue from when we initially defined Baseline. #189 But that issue was talking about polyfills and transpilers, a related but separate idea.

Still, the same problems apply in both cases: I have no idea how I'd define "how easy" it is or isn't to progressively enhance a feature.

IMO, it's a subjective question how progressively enhanceable a feature is. For example, consider Web Push notifications. If the user's browser doesn't support them, you can just not offer them. But if the whole point of your web app is to do timely push notifications, then I think you'd say that, for you, there's no progressive enhancement possible. Your app just doesn't work on browsers that don't support push.

Zach gives the example of accent-color. If the lack of accent-color makes your form controls low/no-contrast on the user's screen, that's really bad. Every feature's progressive-enhancement story depends intimately on how important the feature is to that developer.

What about layout? As flexbox and grid layouts were rolling out, it was common to suggest that developers do a progressive enhancement, showing a simplified (worse) layout to older browsers. Something similar will apply if/when CSS masonry layouts ship. So, are masonry layouts progressively enhanceable? … maybe kinda?

So, how would we incorporate progressive enhancement here in web-features? Surely not with a simple boolean, supportsProgressiveEnhancement: true/false. But, if not that, then, what?

At a minimum, when relying on progressive enhancement, it's incumbent on the developer to test the progressive enhancement, to test on a browser where the feature works, and then again on a browser where the feature doesn't work and a fallback is used.

The point of Baseline is to say, "if this feature is Widely Available, you don't have to test any fallbacks. You don't need to include any polyfills. It's just gonna work."

It does not mean "You can't possibly use this feature in any way at all unless it's Widely Available."

[rachelandrew]

I came here to say more or less what @dfabulich has, almost any feature is a "candidate for progressive enhancement" if you are happy to fall back to a very simple experience. So I don't think there could ever be a PE=true flag. I don't even know what a definition would look like that that included PE, in a way that could be in any way objective, and not muddy the core message of Baseline.

I'm not against trying to do hard things, maybe there is a way to define a similar line for progressive enhancement, but my main feeling when this conversation comes up (and it comes up repeatedly) is that the people who bring it up, to some extent aren't the target audience for Baseline. I don't see any evidence that the core of developers are asking for this. Some expert level developers are, and dev influencers are, but these are people who typically have a far greater ability to make decisions over projects than a developer working in a web team, where getting sign off means that the app functions the same way in all browsers.

I've been banging the progressive enhancement drum since around 2001, telling people that websites don't need to look the same in all browsers, and the majority have kept replying that actually, yes they do.

I think rather than trying to blur the edges of Baseline, it would be good to provide better information about what developers should do with things that aren't Baseline (or that are Newly available, for that matter). I've been describing Baseline as helping you narrow down the features that you'll need to use with more care. If you can assume that everything Widely available you can just use, you then have a much smaller set of Newly available features that you can probably use, but you want to know you've used them so you can test. This is where improved tooling will really help. Your IDE or linter could make it clear when you've used a feature outside of the Widely available group, however that doesn't need to mean a red line and do not use. It could instead flag up the places where additional cross browser testing is important. We can't easily make the subjective decision that this use of a feature is ok, but we could present the information in such a way that makes those subjective choices easier.

So perhaps this is an issue that isn't and shouldn't be solved in Baseline itself, but could be very effectively solved by the information, and in particular the tooling, around it. If developers can feel confident in what is and isn't available, they can then make the subjective decisions for their own situations, backed by tooling that helps support that.

[captainbrosset]

@dfabulich said:

The point of Baseline is to say, "if this feature is Widely Available, you don't have to test any fallbacks. You don't need to include any polyfills. It's just gonna work."
It does not mean "You can't possibly use this feature in any way at all unless it's Widely Available."

I agree with this, but given that the feedback discussed here has come up multiple times already, I fear this point isn't communicated well enough. True, Baseline isn't saying not to use any of the non-Widely available features, but there's a risk that it effectively says so anyway, indirectly.

For example, the eslint/css plugin recently added support for Baseline and, while this is great, here's what running the plugin with its default configuration might result in:

18:3 error Property 'accent-color' is not a widely available baseline feature css/require-baseline

The above css/require-baseline message is marked as an error. Users of eslint can change the level to a warning if they want to (they can even target Newly instead of Widely), but the default configuration might result in people effectively staying away from non-widely available features because they appear as red errors breaking their builds.

@rachelandrew said:

Your IDE or linter could make it clear when you've used a feature outside of the Widely available group, however that doesn't need to mean a red line and do not use. It could instead flag up the places where additional cross browser testing is important.

I filed eslint/css#80

So perhaps this is an issue that isn't and shouldn't be solved in Baseline itself, but could be very effectively solved by the information, and in particular the tooling, around it.

I agree that this is not an issue with the Baseline status itself, which is merely a computed summary of the BCD browser data. But I feel that, we, the people working on Baseline, have a responsibility anyway. How tools convey what Baseline means has consequences on how web devs perceive the platform, and what they use. I don't have a specific recommendation yet (except for the eslint issue mentioned above).

[dfabulich]

I agree with this, but given that the feedback discussed here has come up multiple times already, I fear this point isn't communicated well enough.

Maybe there's a "communication" bug to file, about communicating that you can still use Limited/Newly Availability features with polyfills, transpilers, and fallbacks? (But, I don't have any great ideas about how to communicate this, especially for PE fallbacks.)

But IMO this issue about incorporating PE into Baseline status itself should be closed as not planned.

[zachleat]

Zach gives the example of accent-color. If the lack of accent-color makes your form controls low/no-contrast on the user's screen, that's really bad.

Which scenario are you referencing here? Why would use of accent-color in a non-supporting browser result in a low or no-contrast form control? I’d hate to start this conversation with mismatched or inaccurate definitions.

A few more questions before y’all close this one:

Does Baseline intend to convey that Newly Available features are “safer” to use than Limited Availability features? If not, how can we improve Baseline to fix this?

Further, do y’all think there is there value in categorizing features that have a riskier/larger blast radius when they are not supported in a client’s browser?

[zachleat]

Just to be clear: I do absolutely think you can categorize many (I’m tempted but wary to say all) web platform features as progressive enhancement friendly true or false. I’m sure there are exceptions but I would strongly make an argument that it’s better to make an attempt here!

Happy to give more examples (and would challenge y’all to find a platform feature than couldn’t be categorized as PE-friendly/unfriendly):

• accent-color: true
• CSS Nesting: false
• AVIF: true (via <picture> or Content Negotiation)
• Popover API: true (caveat: HTML->JS polyfill)
• Promise.withResolvers: true
• CSS Subgrid: false
• ESM: true (via type="module" and nomodule)
• Declarative Shadow DOM: true (caveat: HTML->JS polyfill)

Furthermore, I would love it if a side benefit of documenting these would play a small educational role in improving future web platform features by encouraging them to be more progress enhancement friendly (which I believe helps feature adoption!)

[dfabulich]

I do absolutely think you can categorize many (I’m tempted but wary to say all) web platform features as progressive enhancement friendly true or false.

Wow, uh, I… I struggle to understand how you could come to believe this. Either I completely misunderstand this problem space (and I'm curious to learn more) or I'm misunderstanding you completely.

At the very least, I think I disagree with all (both) of your "false" examples, but maybe I just don't understand them.

If true means "You can detect whether the feature is available at runtime, and then provide fallback code, which may or may not include a JS polyfill, and it's always OK if the fallback code runs slower or doesn't look the same in all browsers" then all web features are supportsProgressiveEnhancement: true. You can always write JS or CSS @supports to test for whether a feature is supported, and then write out your fallback that way.

Speaking for myself, I wouldn't use runtime feature detection for any feature that can be reliably transpiled. I'd just send the transpiled version to everyone, then wait for wide availability, and then stop transpiling the feature for everyone.

In particular, I can't understand why you'd write:

• CSS Nesting: false
• ESM: true (via type="module" and nomodule)

Those features seem pretty much the same to me. They've both got great transpilers, so you don't really need to do runtime feature detection.

But you can use runtime feature detection for both features. For CSS Nesting, you can use @supports (selector(&)), or use a JS-based style loader. I wouldn't use that, but I wouldn't use nomodule, either.

You also wrote "CSS Subgrid: false", but https://web.dev/articles/css-subgrid#check_for_support disagrees:

Progressive enhancement with CSS and subgrid is familiar and straightforward. Use @supports and inside the parenthesis ask the browser if it understands subgrid as a value for template columns or rows. The following example checks if the grid-template-columns property supports the subgrid keyword, which if true, means that subgrid can be used

@supports (grid-template-columns: subgrid) {
  /* safe to enhance to */
}

Personally, I think it's possible but impractical to do progressive enhancement for CSS Subgrid. For layout features like Subgrid, I would use an imperfect polyfill or just not use it until wide availability.

But that's a judgment call for the developer to make, isn't it? You could use @supports to implement a nice non-subgrid layout for old browsers. You'll have to implement your entire layout twice, and test it, and maintain it. I think that sucks but that's just, like, my opinion.

Who are you to say subgrid is supportsProgressiveEnhancement: false? Who am I to say subgrid is supportsProgressiveEnhancement: true?

I would challenge y’all to find a platform feature than couldn’t be categorized as PE-friendly/unfriendly

I have no idea what you mean by this. Do you think you just presented eight clear examples? Should it be obvious that CSS Subgrid is false? (Why?) Should it be obvious to me that CSS Nesting is false and ESM is true? (Why??)

Instead of providing examples and challenging others for counterexamples, I think instead we'd need to be more specific about what we mean by "PE friendly."

• Do we just mean "is it possible to feature detect?" (But everything is feature detectable, with @supports and eval.)
• Do we mean "Is the user going to be OK if you use the feature without testing/implementing a fallback?" (But isn't that subjective?)
• Do we mean "The PE fallback works pretty well?" (But isn't that subjective?)
• … or something else?

[zachleat]

If true means "You can detect whether the feature is available at runtime, and then provide fallback code, which may or may not include a JS polyfill, and it's always OK if the fallback code runs slower or doesn't look the same in all browsers"

I wouldn’t agree with that, no. Polyfills are not (necessarily) progressive enhancement — you have to understand the unique relationship between the feature and the implementation. Specifically the runtime pieces: HTML/CSS/JavaScript and the relationship between the three. This is why Popover API is PE-friendly, it adds an HTML method for an existing JavaScript approach, and adding a JS polyfill is no worse than previous methods.

Speaking for myself, I wouldn't use runtime feature detection for any feature that can be reliably transpiled. I'd just send the transpiled version to everyone, then wait for wide availability, and then stop transpiling the feature for everyone.

That’s fine, but transpiling is a separate authoring consideration. It’s irrelevant to know whether or not a web site has been authored in TypeScript or Sass or Coffeescript for the purposes of its Progressive Enhancement footprint. The PE mechanism refers to runtime code, which is why type="module" and nomodule is a PE-friendly option. Additionally, I’d argue that transpiling CSS Nesting negates the runtime benefit of using CSS Nesting.

To be clear, I’m not making the claim that you would use nomodule today, I’m saying it was a PE-friendly escape hatch when ESM was in its Limited Availability/Newly Available era (to use Baseline terms).

I think you’re right to push back on subgrid! Love that a @supports path is available for CSS->CSS PE (even if “impractical”).

To reiterate, runtime polyfills for CSS features are not Progressive Enhancement friendly (JS->CSS).

It seems like there might be some baseline misunderstandings about what Progressive Enhancement is. Happy to provide more resources on the topic if that’s helpful (though I personally don’t want to litigate whether or not the practice is valuable on this thread).

[dfabulich]

In light of this conversation, can you identify a few features that are clearly not PE friendly?

The only two examples you gave where you'd set supportsProgressiveEnhancement: false were CSS features (nesting and subgrid). Since @supports works for both of those, would you now say that they're both PE friendly? What are CSS features that are not PE friendly in your definition? (Are there any?)

It seems like there might be some baseline misunderstandings about what Progressive Enhancement is.

I would say that there are open disagreements about what PE-friendliness is. In general, "friendliness" is not normally a boolean; it's a range, and it's open to interpretation.

[tomayac]

In light of this conversation, can you identify a few features that are clearly not PE friendly?

All Web hardware APIs like WebUSB, Web Bluetooth, Web HID, Web Serial, and Web MIDI are completely not PE friendly.

[mirisuzanne]

I've been teaching and using subgrid as a very practical progressive enhancement since 2019 when it was in a single browser. In most cases you can fall back to something like grid-template-columns: inherit with excellent results - without ever using @supports. Marking features as false negatives on PE seems more dangerous to me than not marking them at all.

I don't know if there's a path forward on this specific issue, but I agree with Patrick. It exposes my main concern about Baseline: authors understand it as a yes/no answer to 'is this feature allowed in production'. That's a major communication problem. And it seems to me like the inevitable result of trying to provide a simple answer to complex browser compat questions. In my mind the best thing baseline can do is complicate it's own answer by:

• showing the progress from new support to wide support (there's no magic that happens at 30 months exactly)
• linking to more contextual information, where PE tradeoffs (and a11y issues) can be discussed in detail

The problem is providing simple answers to complex questions.

[dfabulich]

All Web hardware APIs like WebUSB, Web Bluetooth, Web HID, Web Serial, and Web MIDI are completely not PE friendly.

Again I have to ask what you mean by "PE-friendly" if you say that those features aren't PE-friendly.

I/O features are all designed to support runtime feature detection. For all of the I/O APIs, the fallback is just not doing that kind of I/O. (I gave the example of web push notifications, above.)

But the question of PE-friendliness is always "Is this feature essential to my web app? Is the fallback experience good enough?"

If the whole point of my web app is to do Web MIDI, then all I can do is fail gracefully when the browser doesn't support Web MIDI. But if Web MIDI is "nice to have," then runtime feature detection is enough to provide the user the essential core of my web app's experience, enhancing that experience with Web MIDI on browsers that support it.

And that's why PE-friendliness is always subjective. It depends on my goal as a developer.

[jamesnw]

It could be useful to add a "but" key to non-baseline widely available features that could be editorial.

• Can I use subgrid*? No, but you can use grid-template-columns: inherit.
• Can I use anchor positioning*? No, but you can with a polyfill.
• Can I use accent-color*? No, but probably yes, but check Safari glyphs for contrast first.

(* "without worrying about compatibility issues, if my specific needs are covered by the definition of baseline" is implied to be added)

Whereas the feature descriptions are intended to be static, I'd expect this field to change often.

[captainbrosset]

This issue was discussed during the last WebDX CG call (notes). Attempting to summarize what was said here:

About attaching Progressive Enhancement information to features

• Progressive enhancement is a philosophy, something you aim to achieve to provide good UX in your site/app. Not a category which some features belong in, while others don't.
• Even for something as nich/advanced as the ambient light sensor API, it really depends on what you're using it for.
• Could progressive enhancement data be attached to features in a non-binary way? Like a set of messages attached to non-widely available features.

About how Baseline is perceived

• Some evidence shared that Baseline isn't fully understood by web devs.
• Baseline is binary, which can make some people uncomfortable. Does this simplification work for everyone? Does it work for the target audience/most of the web devs?
• We should clarify how Baseline doesn't tell the fully story ab out a feature, that it's a simplification. We should be clear about what it stands for, and what it cannot do.
• Baseline should not prevent web devs from seeing/using non-widely available features.

Again, this is a summary from the notes. Please see the full notes for more nuance.

[captainbrosset]

I also just went over the comments in this issue. Since there are two separate, albeit connected, topics here: progressive enhancements (PE) and communication about Baseline, I'll open a new issue to track the improvements we could make related to communicating about Baseline (see #2783). This way we can re-focus this one on PE.

So, regarding PE, we have two competing opinions here:

• Whether a feature PE-able inherently depends on your use case and is therefore subjective and can't be attached to Baseline.
• Some features are PE-friendly while others are not.

And an in-between proposal:

• Could we add editorial notes to non-widely available features to provide more information?

[captainbrosset]

@zachleat wrote:

It seems like there might be some baseline misunderstandings about what Progressive Enhancement is. Happy to provide more resources on the topic if that’s helpful (though I personally don’t want to litigate whether or not the practice is valuable on this thread).

@zachleat I agree there seems to be some misunderstanding about PE in this issue. So, in order to help us make progress, could you please provide more examples and resources?

[zachleat]

@captainbrosset it seems like some of the things I added took the thread off track so I’m happy that you’ve recentered things and probably won’t weigh in here further — especially since I’d be happy with any additional notes (“binary” or not)!

I do recognize that the notion of evaluating the PE-friendliness of web platform features seems surprisingly controversial, but that’s probably a conversation for another thread.