- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 08:35:28 +0000
- To: public-css-archive@w3.org
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 move to HTML spec leaving a reference to them`
<details><summary>The full IRC log of that discussion</summary>
<emilio> TabAtkins: zcorpan pointed out that we have a bunch of UA sheet fragments scattered<br>
<emilio> ... it's inconsistent, unclear if they should be normative<br>
<emilio> ... and leads to interop issue<br>
<emilio> ... some people's preference is the html spec should have the ua sheet<br>
<fantasai> Tab's proposal: https://github.com/w3c/csswg-drafts/issues/8959#issuecomment-1591609223<br>
<emilio> ... but we have different maturity levels<br>
<fantasai> zcorpan's addition: https://github.com/w3c/csswg-drafts/issues/8959#issuecomment-1600346659<br>
<vmpstr> q+<br>
<emilio> ... so my proposal is that all normative sheets should be normative, and when the spec is mature we move them to html<br>
<emilio> astearns: what level of maturity?<br>
<chris> q+<br>
<emilio> TabAtkins: we have some leeway there, so CR or earlier<br>
<dbaron> +1 to TabAtkins's proposal, with the caveat we should perhaps check if all the existing ones were intended to be normative<br>
<emilio> ... if we have 2 impls<br>
<astearns> s/CR/CR exit/<br>
<miriam> q?<br>
<emilio> miriam: there's some MUST vs not discussion<br>
<futhark> q+<br>
<emilio> fantasai: this is only for the HTML stylesheet, not only for UA rules that apply to all elements<br>
<andreubotella> s/MUST vs not/MUST vs OUGHT/<br>
<andreubotella> me not sure<br>
<oriol> q+<br>
<TabAtkins> s/OUGHT/SHOULD/<br>
<emilio> fantasai: if you have global ::something styles they should not live in html because they're not html-specific right?<br>
<emilio> TabAtkins: they don't need to live in html but they should be marked as normative<br>
<miriam> ack vmpstr<br>
<emilio> vmpstr: So in view-transitions there's two different stylesheets, a static one and a dynamic one<br>
<emilio> ... updated based on some algorithm<br>
<emilio> ... there's no expectation that the dynamic one needs to go in the html spec<br>
<emilio> TabAtkins: yeah I don't think it'd be useful to pull it out of v-t<br>
<miriam> ack chris<br>
<emilio> ... having a centralized place makes it easier for both authors and vendors<br>
<andreubotella> q+<br>
<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?<br>
<emilio> q+<br>
<emilio> TabAtkins: I don't consider that our problem<br>
<emilio> ... the other suggestion of getting things marked as normative and centralized is the important<br>
<fantasai> vmpstr, the VT stylesheets are not HTML-specific. That's why they don't belong in the HTML spec.<br>
<emilio> chris: just wanted to be clear that we can still have css tests and normative ua sheet bits in specs<br>
<vmpstr> we have a :root { view-transition-name: root }, but I guess that's not just html?<br>
<fantasai> right, it'll apply to arbitrary XML for example<br>
<emilio> ack futhark<br>
<fantasai> Rendering DocBook, any other format<br>
<vmpstr> so should those then live in css? (or v-t I guess?)<br>
<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<br>
<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<br>
<emilio> TabAtkins: maybe? no strong opinion on that<br>
<miriam> ack oriol<br>
<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 (?)<br>
<emilio> oriol: so if it's something that should replace some magic in the html spec it should indicate that<br>
<emilio> TabAtkins: agreed<br>
<emilio> andreubotella: even after the spec is mature it'd be useful to keep that appendix<br>
<emilio> ... or a reference to the HTML spec<br>
<fremy> q?<br>
<miriam> ack andreubotella<br>
<emilio> ... for an implementation that comes later it'd be useful to know what to put in the UA sheet<br>
<emilio> ... for any potential new engines or what not<br>
<emilio> ack emilio<br>
<astearns> +1 to andreubotella but it should only be a reference. No maintaining normative text in two places<br>
<andreubotella> indeed<br>
<miriam> ack emilio<br>
<miriam> ack fantasai<br>
<Zakim> fantasai, you wanted to say we shouldn't remove anythig from our specs until they've been properly published in their target location<br>
<emilio> fantasai: wanted to say that we should not remove anything from our spec until it lands in HTML / SVG<br>
<astearns> +1 to fantasai. No maintaining normative text in zero places<br>
<fantasai> s/lands/lands (and is properly published)/<br>
<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<br>
<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<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8959#issuecomment-1719008520 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 08:35:30 UTC