UA stylesheets in CSS specs cause interop issues

[zcorpan]

For the record, other UA stylesheets defined include:

• CSS Color Adjustment Module
• CSS Counter Styles
• CSS Generated Content for Paged Media (informative)
• CSS Inline Layout
• CSS Lists and Counters (informative)
• CSS Pseudo-Elements (SHOULD)
• CSS Ruby Annotation (informative)
• CSS Text (informative)
• CSS Text Decoration (informative)
• CSS Transforms has an "initial used value is 0 0 as if > the user agent style sheet contained"(!!!)
• CSS Basic User Interface
• CSS Writing Modes
• CSS 2 (informative)
• Media Queries

Originally posted by @gsnedders in #8573 (comment)

In https://bugzilla.mozilla.org/show_bug.cgi?id=645642 match-parent was implemented in Gecko, and per https://bugzilla.mozilla.org/show_bug.cgi?id=645642#c14 the suggested UA stylesheet for option was implemented. But it was not implemented in WebKit or Chromium.

https://drafts.csswg.org/css-text/#default-stylesheet says

This appendix is informative, and is to help UA developers to implement a default stylesheet for HTML, but UA developers are free to ignore or modify as appropriate.

I do not find these optional UA stylesheets helpful at all, and would prefer if the UA stylesheet for HTML was left entirely to the HTML standard to define.

Maybe there are exceptional cases where a new feature isn't ready to be included in HTML's UA stylesheet. If you want to include example UA stylesheets, please say that they must not be implemented in UAs, so that they don't cause further interop issues.

[tabatkins]

Maybe there are exceptional cases where a new feature isn't ready to be included in HTML's UA stylesheet.

This appears to be the common case for any relatively new spec - HTML's requirements for new additions are pretty strict about support, much stricter than the W3C's requirements for publishing working drafts, or even CRs.

Note that I have no problem with a centralized UA stylesheet location; it's just the significant friction of trying to coordinate between new specs and the HTML spec that I'm going to be annoyed about. Before the spec satisfies HTML's requirements, does the UA stylesheet addition just sit in a PR in limbo, so implementors working off of the spec don't see it? Or does it live in the spec, and hopefully we remember to coordinate and move it at some point?

[fantasai]

Exactly what Tab said. I'm fine with moving things to HTML (and in fact that's been my intention all along) but until the features are implemented, the related UA rules can't live in the HTML spec, so... they need to live somewhere, and that's currently in informative appendices. :/

We should definitely do an audit of them, though, and make sure the ones that are implemented at least get pulled into HTML and cross-referenced from CSS, as should be the end-goal.

[zcorpan]

Agreed with moving things to HTML that are already implemented or stable enough to be implemented now. For the remaining I'd be happy if we could make the appendices not optional and instead say what is expected of UAs implementing the CSS spec, which is to implement the feature but not ship the UA stylesheet until it's ready to be moved to HTML.

[gsnedders]

It's still not clear to me why some are in informative appendices and some are in normative appendices and some are in the body of the spec…

Why should they be informative in the first place?

[tabatkins]

Simply a lack of direction in exactly how they should be presented. The disorder isn't for any particular reason. Centralizing would, of course, help with that (tho we could potentially solve it by just deciding on a consistent approach).

[tabatkins]

So it sounds like the proposed behavior will be:

1. If the spec is mature enough to satisfy HTML's inclusion criteria, we put any associated UA styles into the HTML spec.
2. If the spec isn't at that point yet, we put it in a normative (MUST?) appendix of our spec, with a note that this will move to HTML's centralized stylesheet later.

Sound good? Any other issues?

[zcorpan]

Yes but for (2) we should decide if it's must not implement (until moved to HTML), or must implement. I prefer the former so that it's clear what tests should check for and so that we can achieve better interop with the implemented UA stylesheets. It also allows for review by HTML folks before UA stylesheet changes are shipped in browsers.

[tabatkins]

I think I strongly disagree with that. What's special about the UA stylesheet that means we should discourage testing, while the rest of the specced behavior is valid to test?

Review doesn't block testing; it just means that changes might require testing changes.

(The intention of my question was whether it should be MUST or SHOULD; this should just match up with whatever the rest of the stylesheet does.)

[zcorpan]

The difference is that a CSS spec's UA stylesheet is a monkey patch of HTML's Rendering section. It makes it harder to reason about what the default rendering rules for HTML are. I think they should be more clearly communicated as being HTML monkey patches, including which existing parts of the HTML spec to remove (if any).

I'm OK with "must implement" if we have a tracking issue in whatwg/html for each such CSS spec.

[zcorpan]

The conformance testing situation could be such that tests in html/ expect only HTML's UA stylesheet to apply, and css/ can expect the monkey patches to apply. A browser that supports an experimental CSS spec will fail some html/ tests until the UA stylesheet is upstreamed and tests are updated.

[tabatkins]

I still don't see how "this behavior difference is implemented via UA style rules" and "this behavior difference is implemented via a keyword that acts differently based on ~some magic~" are meaningfully different to anyone, in any context. Both of them change the expected behavior of the browser, and are testable; the sole difference is in whether the different behaviors are directly observable via the CSSOM or not. (And that is very rarely the precise thing you're testing.) That's absolutely not a difference that should result in us telling browsers they MUST NOT implement something, or in us drawing some funky distinction between the expected results of an html/ test and a css/ test.

[zcorpan]

In the case of text-align: match-parent, it doesn't affect the default rendering of HTML and only does anything if the author chooses to use the new keyword. The UA stylesheet changed default rendering for option for all existing content.

or in us drawing some funky distinction between the expected results of an html/ test and a css/ test.

I thought that distinction would be reasonable; each spec tests what that spec requires.

[tabatkins]

My point continues to be that "behavior defined by text in the CSS spec" and "behavior defined by text in a UA stylesheet (in a CSS spec)" are functionally identical, and drawing a distinction between them for siloing reasons doesn't make sense. Either the behavior is implemented and testable or it's not; trying to say that an HTML test that exercises the area must fail because the now-implemented behavior is specified somewhere else (whether as a stylesheet or in prose) doesn't make a lot of sense. Sometimes things are just interlocked.

[zcorpan]

My point continues to be that "behavior defined by text in the CSS spec" and "behavior defined by text in a UA stylesheet (in a CSS spec)" are functionally identical, and drawing a distinction between them for siloing reasons doesn't make sense.

Sure. I guess the distinction I care about is whether it's a monkey patch of HTML that should be upstreamed when sufficiently stable, or is part of the CSS language.

Either the behavior is implemented and testable or it's not; trying to say that an HTML test that exercises the area must fail because the now-implemented behavior is specified somewhere else (whether as a stylesheet or in prose) doesn't make a lot of sense. Sometimes things are just interlocked.

If a spec with monkey patches is still experimental (any spec, not just for CSS) I think it's generally premature to change the "upstream" tests. But also, as far as I know this hasn't happened to date, rendering tests in html/ just test what's in the HTML spec.

[gsnedders]

This seems partly to be getting into questions about WPT policy, which would be better had in a WPT project space.

[tabatkins]

Yeah, I think my comment (with the clarification that stylesheets are MUST-level) is what we want to decide on.

[zcorpan]

I'd like to add

3. If there's anything in HTML's Rendering section that should be replaced by the new UA stylesheet, the appendix should say so.

[css-meeting-bot]

The CSS Working Group just discussed UA stylesheets in CSS specs cause interop issues, and agreed to the following:

• RESOLVED: Go through specs that have UA sheets. Pull normative things to an appendix and clearly mark as normative. For those that pass CR criteria and apply to HTML elements specifically, move to HTML spec leaving a reference to them

The full IRC log of that discussion

<emilio> TabAtkins: zcorpan pointed out that we have a bunch of UA sheet fragments scattered
<emilio> ... it's inconsistent, unclear if they should be normative
<emilio> ... and leads to interop issue
<emilio> ... some people's preference is the html spec should have the ua sheet
<fantasai> Tab's proposal: https://github.com//issues/8959#issuecomment-1591609223
<emilio> ... but we have different maturity levels
<fantasai> zcorpan's addition: https://github.com//issues/8959#issuecomment-1600346659
<vmpstr> q+
<emilio> ... so my proposal is that all normative sheets should be normative, and when the spec is mature we move them to html
<emilio> astearns: what level of maturity?
<chris> q+
<emilio> TabAtkins: we have some leeway there, so CR or earlier
<dbaron> +1 to TabAtkins's proposal, with the caveat we should perhaps check if all the existing ones were intended to be normative
<emilio> ... if we have 2 impls
<astearns> s/CR/CR exit/
<miriam> q?
<emilio> miriam: there's some MUST vs not discussion
<futhark> q+
<emilio> fantasai: this is only for the HTML stylesheet, not only for UA rules that apply to all elements
<andreubotella> s/MUST vs not/MUST vs OUGHT/
<andreubotella> me not sure
<oriol> q+
<TabAtkins> s/OUGHT/SHOULD/
<emilio> fantasai: if you have global ::something styles they should not live in html because they're not html-specific right?
<emilio> TabAtkins: they don't need to live in html but they should be marked as normative
<miriam> ack vmpstr
<emilio> vmpstr: So in view-transitions there's two different stylesheets, a static one and a dynamic one
<emilio> ... updated based on some algorithm
<emilio> ... there's no expectation that the dynamic one needs to go in the html spec
<emilio> TabAtkins: yeah I don't think it'd be useful to pull it out of v-t
<miriam> ack chris
<emilio> ... having a centralized place makes it easier for both authors and vendors
<andreubotella> q+
<emilio> chris: the problem we try to solve is having html and css wpts as different things and implementations disagreeing, and I don't think this solves it?
<emilio> q+
<emilio> TabAtkins: I don't consider that our problem
<emilio> ... the other suggestion of getting things marked as normative and centralized is the important
<fantasai> vmpstr, the VT stylesheets are not HTML-specific. That's why they don't belong in the HTML spec.
<emilio> chris: just wanted to be clear that we can still have css tests and normative ua sheet bits in specs
<vmpstr> we have a :root { view-transition-name: root }, but I guess that's not just html?
<fantasai> right, it'll apply to arbitrary XML for example
<emilio> ack futhark
<fantasai> Rendering DocBook, any other format
<vmpstr> so should those then live in css? (or v-t I guess?)
<vmpstr> makes sense I guess, but it seemed like having a centralized spot is good, but i don't know if there's anything that applies to all things
<emilio> futhark: Just want to point out that there's a UA sheet in css-color-adjust that applies only to svg and should probably be moved to the svg spec
<emilio> TabAtkins: maybe? no strong opinion on that
<miriam> ack oriol
<emilio> oriol: Wanted to highlight the last comment of the issue that would be great if the appendix mentioned if something in the rendering updates in html needs to do some magic with it (?)
<emilio> oriol: so if it's something that should replace some magic in the html spec it should indicate that
<emilio> TabAtkins: agreed
<emilio> andreubotella: even after the spec is mature it'd be useful to keep that appendix
<emilio> ... or a reference to the HTML spec
<fremy> q?
<miriam> ack andreubotella
<emilio> ... for an implementation that comes later it'd be useful to know what to put in the UA sheet
<emilio> ... for any potential new engines or what not
<emilio> ack emilio
<astearns> +1 to andreubotella but it should only be a reference. No maintaining normative text in two places
<andreubotella> indeed
<miriam> ack emilio
<miriam> ack fantasai
<Zakim> fantasai, you wanted to say we shouldn't remove anythig from our specs until they've been properly published in their target location
<emilio> fantasai: wanted to say that we should not remove anything from our spec until it lands in HTML / SVG
<astearns> +1 to fantasai. No maintaining normative text in zero places
<fantasai> s/lands/lands (and is properly published)/
<emilio> proposed resolution: Go through specs that have UA sheets. Pull normative things to an appendix and clearly mark as normative. For those that pass CR criteria move to HTML spec leaving a reference to them
<emilio> RESOLVED: Go through specs that have UA sheets. Pull normative things to an appendix and clearly mark as normative. For those that pass CR criteria move to HTML spec leaving a reference to them