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.