- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Nov 2024 17:45:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-2024] Add specs to Official Definition`, and agreed to the following: * `RESOLVED: Add new category, shorthanded as "reliable CR"` * `RESOLVED: add MQ4 and Scroll Snap to "reliable CR"` * `RESOLVED: Move Scrollbars to "reliable CR"` * `RESOLVED: Move Grid 1 and 2 to "reliable CR"` <details><summary>The full IRC log of that discussion</summary> <Rossen0> ack fantasai<br> <TabAtkins> fantasai: high-level comment. reason for the snapshot was becasue the status of our specs didn't alway sreflect the actual stability<br> <TabAtkins> fantasai: we'd have a WD that's basically a Rec, etc<br> <TabAtkins> fantasai: was confuising, people didn't know stability<br> <TabAtkins> fantasai: what we ended up with in the snapshot is 3 lists, i think i'm gonna propose 4 lists<br> <TabAtkins> fantasai: we've got "official definition", that's the list of "these are (basically) Recs". some actually Recs, others are same stability level, just waiting on some bugfixes or minor issues<br> <TabAtkins> fantasai: usually blocker is missing an impl report<br> <TabAtkins> fantasai: then we have two lists, one is "these are pretty stable, maybe not enough impl experience, but not really changing"<br> <TabAtkins> fantasai: and "spec is a mess but impls are shipping and roughly interoperable"<br> <TabAtkins> fantasai: poster child is Transitions & Animations<br> <TabAtkins> fantasai: tons of issues, but people wer eshipping and they were widely used<br> <TabAtkins> fantasai: so we have Rec-levle, CR-level with limited impl, and CR-level impl with limited spec<br> <TabAtkins> fantasai: might want a fourth list of "spec is pretty stable, largely implemented, largely reliable for use"<br> <TabAtkins> fantasai: probably a lot of our specs should be there<br> <TabAtkins> fantasai: so i propose we add this new list as the second list (in order) in the snapshot<br> <TabAtkins> florian: altho it's more things, i do think it's simpler overall. too many things that don't fit well in any of our three categories<br> <dbaron> does this mean there are now 2 axes rather than 1?<br> <TabAtkins> ChrisL: i think it makes sense to go thru what Sebastian has done, then go thru th enew category. would rather see that in an ED and then we can move around<br> <TabAtkins> florian: I might be opposed to some of the moves, becuase it's the wrong place; the right place will be the new category<br> <TabAtkins> fantasai: yeah that's why i brought it up too<br> <TabAtkins> dbaron: does this new category mean we're classifying on 2 rather than 1 axis? if so, what?<br> <TabAtkins> fantasai: we've always been categorizing, just missing this quadrant<br> <TabAtkins> fantasai: how stable is spec, how stable is impl<br> <TabAtkins> florian: we had "both great", "impl good, spec bad", and "spec good, impl not". didn't have "both good (but not done)"<br> <TabAtkins> fantasai: rough interop was "we have interop but spec doesn't reflect that"<br> <TabAtkins> fantasai: we just need one where we ahve interop and spec does roughly match<br> <TabAtkins> dbaron: so we had a category for "impl 1, spec 1", "impl 1, spec 0", and "impl 0, spec 1". this new one is "impl 1/2, spec 1/2"<br> <TabAtkins> fantasai: roughly, yeah. (quibble on the exact numbers, but idea is right)<br> <TabAtkins> Rossen0: so it fits the model. my proposal is we go thru the list of specs we have currently here.<br> <TabAtkins> SebastianZ: first is MQ4, current is CRD, last published 2021<br> <TabAtkins> SebastianZ: lots of tests for this spec, interop is very good<br> <TabAtkins> SebastianZ: 98%<br> <TabAtkins> SebastianZ: but still some open gh issues<br> <TabAtkins> florian: i suspect it's really good in terms of syntax, but MQs are notably hard to test<br> <TabAtkins> florian: i suspect there are still quite a few media features that are good ideas but not particularly tested or implemented<br> <TabAtkins> florian: i'm unsure, for example, of overflow-block/inline, unsure about how close reality is for the hover/pointer ones<br> <fantasai> 4 categories: REC-like, reliable spec + implementation, low-experience CR, implemented + badly specced<br> <fantasai> s/implemented/shipping/<br> <TabAtkins> SebastianZ: we'd need to check on that, i was just collecting data around open issues and tests<br> <TabAtkins> SebastianZ: didn't check every feature in those specs<br> <TabAtkins> florian: i know for a long time we were lackign impl and coverage for some features. we might have improved, just not sure where we are now.<br> <TabAtkins> ChrisL: i noticed mq4 doesn't have wpt annotations, that would have helped<br> <fantasai> A) REC-like; B) reliable spec + implementations; C) low-experience CR; D) shipping + badly specced<br> <TabAtkins> florian: for MQ syntax we should have this, no question. but many media features are basically not testable in an autoamtic manner<br> <TabAtkins> florian: so not just lacking annotation, lacking *tests*<br> <TabAtkins> florian: it's "run this on a device with these cahracteristics, and see if it works"<br> <TabAtkins> dbaron: in theory we might eventually want to show that there *is* some impl or device that does each value<br> <TabAtkins> florian: i know we weren't there for a long time, might have gotten there while i wasn't looking<br> <TabAtkins> florian: also i'm listed as a co-editor, and i don't dislike that, but i'm no longer sponsored for it<br> <TabAtkins> florian: i just suspect that until we can properly audit, we can't move it.<br> <TabAtkins> florian: suspect it's good but can't show it<br> <TabAtkins> fantasai: we *could* move it into the new category, reliable spec + impls<br> <TabAtkins> florian: maybe. parts of it at least<br> <TabAtkins> fantasai: i'm fine either way<br> <TabAtkins> SebastianZ: two options, one is to defer it, and add wpt tests so we can see what's covered and what still needs coverage<br> <TabAtkins> SebastianZ: other is to add it to th enew list<br> <TabAtkins> SebastianZ: no strong opinion<br> <TabAtkins> Rossen0: just saying that having 98% interop on what's already tests is great<br> <TabAtkins> fantasai: but if it's jsut testing parsing that's not much<br> <TabAtkins> Rossen0: if there are missing tests, that's on us<br> <TabAtkins> Rossen0: if i'm being a neutral observer, it seems like a spec tha'ts moving along well<br> <TabAtkins> Rossen0: whatever's put in a test case impls are doing, that's great<br> <TabAtkins> florian: i don't know if that's useful, the tests aren't a bar *we* set, they're mostly written by the impls<br> <TabAtkins> florian: passing a lot of tests without evaluating coverage, i don't know if it's saying anything useful<br> <TabAtkins> florian: recentlyw e almost pushed Scrollbars to rec, everyone had super high test rates despite Safari not implementing it *at all*<br> <TabAtkins> Rossen0: I get that, but if you're an editor and not seeing enough coverage, we can say that and outline what parts aren't covered<br> <TabAtkins> florian: for MQ4 i'm saying this was the case a few years ago, last I checked. if somebody fixed it more recently I dunno.<br> <TabAtkins> Rossen0: so I'm looking at Sebastian as someone who's looked at this more recently<br> <TabAtkins> SebastianZ: i didn't check all the features, i checked a few in each spec<br> <TabAtkins> SebastianZ: that's why i put it on th elist to add it to the official definition<br> <TabAtkins> fantasai: i think unless we have some evidence that the behavior is implemented correctly (not just parsing and OM), we can't reasonably put it in rec-like section<br> <TabAtkins> florian: i just checked - some features that didn't have tests before still don't<br> <TabAtkins> Rossen0: so are we moving at all? or leaving it?<br> <TabAtkins> florian: we could move it to the new bucket, it has some sections that are stable but some that aren't. so either leave it or put it in th enew bucket<br> <TabAtkins> Rossen0: so here's ane xample of a spec which'll have the new bucket<br> <TabAtkins> SebastianZ: let's still continue on this one<br> <TabAtkins> fantasai: next is SCroll Snap, i think this is meaningfully implemented everywhere. not 100% interop, and some minor issues.<br> <TabAtkins> fantasai: i'd say this should move either into the "reliable CR" section, and probably next year if we resovle the remaining issues we can put it in "reliable Rec" section<br> <TabAtkins> Rossen: so scroll snap should move to "reliable CR" new bucket?<br> <TabAtkins> Rossen0: we have two candidates already, let's just resolve on the new bucket<br> <TabAtkins> ChrisL: let's<br> <TabAtkins> Rossen0: anyone objecting to adding this new bucket?<br> <TabAtkins> fantasai: I'll call it "reliable CR" as shorthand, work on wording later<br> <fantasai> A) REC-like; B) reliable spec + implementations; C) low-experience CR; D) shipping + badly specced<br> <TabAtkins> SebastianZ: no objection, just wondering if some specs in A would fit into B instead<br> <TabAtkins> Rossen0: we can see what goes in it once we have it<br> <TabAtkins> RESOLVED: Add new category, shorthanded as "reliable CR"<br> <TabAtkins> Rossen0: with that, we'll add MQ4 and Scroll Snap to "reliable CR". objections?<br> <TabAtkins> RESOLVED: add MQ4 and Scroll Snap to "reliable CR"<br> <TabAtkins> florian: i'd argue Scrollbars 1 goes in "reliable CR" too. Very small spec.<br> <TabAtkins> florian: Like I mentioned, Safari has great pass rates but they're going down as tests are reviewed and made to actually fail when not supported<br> <TabAtkins> ChrisL: so we don't know how well it's implemented?<br> <TabAtkins> florian: there are impls, and th ekey aspects do work in chrome and firefox<br> <TabAtkins> florian: details are little more iffy, many have been recently fixed. test suit needs a little work<br> <TabAtkins> florian: better than a CR with no impl, but not Rec. we could leave it where it is if we're not sure.<br> <TabAtkins> fantasai: seems to have a usable level of interop<br> <TabAtkins> florian: there are corner cases, but the core of it works in two browsers<br> <TabAtkins> Rossen0: any objections to moving it?<br> <TabAtkins> RESOLVED: Move Scrollbars to "reliable CR"<br> <TabAtkins> fantasai: Grid 1 and 2 should also move to "reliable CR"<br> <TabAtkins> Agreed<br> <TabAtkins> fantasai: spec needs an update, that's on me. after that it's very stable, we have very few issues agaisnt Grid.<br> <TabAtkins> Rossen0: i think that sounds reasonable. objections?<br> <TabAtkins> SebastianZ: just wondering, we have 12k tests on this spec, 92% interop<br> <TabAtkins> SebastianZ: dont' you think that verifies it to go official?<br> <TabAtkins> fantasai: I'll propose doing that as soon as I publish an update, spec is out of date now. if I get that befor ened of year we can move it<br> <TabAtkins> Rossen0: objections?<br> <TabAtkins> RESOLVED: Move Grid 1 and 2 to "reliable CR"<br> <TabAtkins> Rossen0: are there more to discuss before we move on?<br> <TabAtkins> florian: a bunch<br> <TabAtkins> fantasai: we should triage and come back with a batch resolution<br> <TabAtkins> SebastianZ: i'd like the editors of the specs to post their opinions<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9770#issuecomment-2474321674 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 November 2024 17:45:04 UTC