[css-conditional-4] Need a way in CSS to test for support of HTML features

[jensimmons]

There should be a way to feature detect support for an HTML attribute, HTML element and other things in HTML.

For instance, the switch attribute is new to HTML. It turns a checkbox form control into a native switch, in a progressively enhanced fashion.

Authors will likely want to style their switch with custom styles, while still supporting the checkbox fallback. If they apply styles without writing conditional code, the checkbox is ruined.

This is one idea of how it could work...

@supports selector(input[switch]) {
 /* Would like to put custom switch styles here, so they only apply conditionally. */
}

...but that doesn't work... because it always returns true. The selector is understood by CSS, even when it's not supported in HTML.

How can we provide a mechanism to CSS for testing support of HTML features?

Here's a demo of switch, with custom styles that should be applied conditionally.
https://codepen.io/jensimmons/pen/eYXYZWr?editors=1100

[hober]

Put another way, the reason you want feature detection from CSS is so that you can style the thing on one way instead of in another way. Concretely:

• Write styles that apply to checkboxes but not switches in browsers that support just checkboxes as well as browsers that support both
• Write styles that apply to switches in browsers that support them and don't get applied at all in browsers that don't support switches)

The first one is just input:not([switch]), I think.
The second is really interesting. @nt1m tells me :has() doesn't support pseudo-elements, which is a real bummer, because input[type=checkbox][switch]:has(::track) would be the obvious and nice solution to this if it worked.

[fantasai]

Yeah, I think this would be a good idea. Could even re-use selector syntax, but it would be a different function, e.g. html() or markup() or something. E.g.

• HTML(rb) indicates the UA supports the rb element
• HTML([dir]) indicates some basic level of support for the dir attribute (HTML4-level support would be adequate to return true, because auto hadn't been invented yet)
• HTML([dir=auto]) indicates support for dir=auto
• HTML(input[type=color]) indicates support for <input type=color>

CSS tracks whether features are supported by whether they're successfully parsed, and you probably can't do that here, though so it would require the UA maintaining some kind of registry of what it supports.

[SebastianZ]

I really like @fantasai's proposal. I'd just note to think of SVG and MathML, as well. So either call the function markup() and let it cover all types of markup. Or, to avoid name clashes and allow more precise checks, let the markup() function take keywords to differenciate them or introduce separate functions html(), svg(), and mathml() for them.

Sebastian

[nt1m]

The problem with the above proposal is that a registry of features for each language could go stale, and there's no good way from code to enforce that registry from being updated.

@annevk suggested linked with IDL, which I think is a much better idea, since IDL needs to be updated in order to expose a new web feature.

@supports idl(HTMLInputElement.prototype.switch) or such. (syntax to be bikeshed)

[SebastianZ]

While IDL is good in regard of requiring to be updated, not all elements have an IDL associated to them, like e.g. the <ruby> element.

Therefore, I'd vote for introducing a similar registry for markup, as that would not only allow CSS to check whether something is supported but also have other benefits. E.g. having such a registry would allow DevTools to add autocompletion for tag and attribute names without having to maintain them by themselves. And it also makes markup feature detection generally easier or even possible, which is useful to authors and presumably also for WPT.

Though if such a registry is not possible for some reason and we have to base the checks on IDL, the syntax should made more CSSy and also not include the abbreviation "IDL". It could actually still be mapped to what @fantasai and I proposed earlier, because all IDLs follow a specific naming syntax. The names have the type as prefix, followed by their name, followed by the suffix "Element". And the IDLs also define the attributes. So you could internally translate html(input[switch]) to HTMLInputElement.prototype.switch or svg(clipPath) to SVGClipPathElement.
But again, it would be weird if you can test for html(details) but not for html(summary) just because there's no HTMLSummaryElement interface for it.

Sebastian

[nt1m]

You mentioned DevTools are an example of registry, I do want to say this is a counter example, this isn't something WebKit does a great job at updating well.

I agree the syntax should be as friendly as possible, but not having to maintain a separate registry is as equally as important IMO.

[nt1m]

I guess engines have an atom string registry for both tagnames / attributes, which can be re-used, but I don't think it's well standardized or consistent across browsers (whereas IDL is better standardized)

[SebastianZ]

You mentioned DevTools are an example of registry, I do want to say this is a counter example, this isn't something WebKit does a great job at updating well.

No, what I meant is that DevTools currently have to maintain their own registry for that. I advocate for a central registry of HTML elements and attributes in the engine. So DevTools could make use of that instead. And that central registry would also cater the feature detection used in CSS, which is discussed here.

I guess engines have an atom string registry for both tagnames / attributes, which can be re-used, but I don't think it's well standardized or consistent across browsers (whereas IDL is better standardized)

That is my point. To allow CSS to detect HTML features, the engines need to have some kind of registry it can use and check against. Additional standardization across user agents don't seem to be necessary, engines only need to ensure their registries are consistent and kept up-to-date.

Sebastian

[Loirooriol]

I share Tim's concern about a registry. It's basically the same problem as in #3559 (comment), so I guess @tabatkins is also opposed to a registry.

[nt1m]

That is my point. To allow CSS to detect HTML features, the engines need to have some kind of registry it can use and check against. Additional standardization across user agents don't seem to be necessary, engines only need to ensure their registries are consistent and kept up-to-date.

If engines already had a registry that they are already using I would be happy to leverage it, but the current registries that are available are not great. I still stand by my point that any mechanism used here should be required to be kept up to date by design.

Unfortunately, currently available atom string registries of attribute names / tag names are too vague. E.g. once switch gets added to the attribute registry, then h1[switch] will also return true. This is why I still think IDL is the best mechanism to leverage even if not extensive.

[SebastianZ]

That is my point. To allow CSS to detect HTML features, the engines need to have some kind of registry it can use and check against. Additional standardization across user agents don't seem to be necessary, engines only need to ensure their registries are consistent and kept up-to-date.

If engines already had a registry that they are already using I would be happy to leverage it, but the current registries that are available are not great.

I obviously don't understand enough about the internals of the engines. Though I am wondering why engines e.g. have a consistent registry for CSS properties but not for HTML elements and attributes they can handle.

And a way to test for those features would pave the way for WPTs to test for them. And by having tests for all the different HTML features, we avoid the issue of implementations becoming outdated and push them towards introducing proper registries, so they don't have to manually maintain them.

I still stand by my point that any mechanism used here should be required to be kept up to date by design.

@nt1m Which other mechanism than the above could you imagine that allows for a comprehensive solution?
Should the HTML spec. maintain machine readable definitions for all HTML elements and attributes?

Sebastian

[SebastianZ]

I share Tim's concern about a registry. It's basically the same problem as in #3559 (comment), so I guess @tabatkins is also opposed to a registry.

It's not exactly the same. There, the issue is that implementations would have to maintain contextual information, i.e. whether one property is interpreted in combination with another.
Here, the check aligns with the idea of "Does it parse?", as Tab expressed it. For @supports (grid-template-columns: subgrid) the engine needs to be able to parse the property and the given value. So the property name and its syntax need to be registered. For @supports html(input[switch]) it's similar.
And if it's not close enough to the "Does it parse?" principle yet, how about the following syntax?

@supports html(<input type="checkbox" switch>) { … }

Sebastian