search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.36k stars 641 forks source link

Let's make snapshot 2020 while the year is still young #4715

Closed svgeesus closed 3 years ago

svgeesus commented 4 years ago

OK so what specs changed status since Snapshot 2018?

frivoal commented 4 years ago
frivoal commented 4 years ago
SelenIT commented 4 years ago

IMHO, Media Queries Level 5 should be published, since some features like prefers-color-scheme are currently widely supported and increasingly used (maybe even enough to be cleared for broad release as pre-CR Exceptions?).

svgeesus commented 4 years ago

Not sure if this helps, but here is the subset of CSS required by the Open IP TV profile which is then referenced by DVB DASH. Sadly these are all dated references.

Open IP TV merged into Hybrid broadcast broadband TV (HbbTV) in 2014. Their CSS profile does not seem to have been updated since.

5.1 Basic Graphic

Terminals SHALL support CSS Basic User Interface [CSS3UI-20120117] as profiled in section section B.1 CSS Basic User Interface

Terminals SHALL support CSS 2.1 [CSS21-20110607]

Terminals SHALL support CSS Color Module Level 3 [CSS3COLOR-20110607].

Terminals SHALL support CSS Image Values and Replaced Content [CSS3-IMAGES-20120417] as profiled in section section B.2 CSS Image Values and Replaced Content

Terminals SHALL support CSS Backgrounds and Borders [CSS3-BG-20120724] as profiled in section section B.3 CSS Backgrounds and Borders

5.2 Device Adaptation, Layout and Processing

Terminals SHALL support CSS Selectors Level 3 [SELECTORS-LEVEL-3-20110929].

Terminals SHALL support CSS Media Queries [CSS3-MEDIAQUERIES-20120619].

Terminals SHALL support CSS Multi-column Layout [CSS3COL-20110412].

Terminals SHALL support CSS Flexible Box Layout [FLEXBOX-20120918]

Terminals SHOULD support CSS Conditional Rules Module Level 3 [CSS3-CONDITIONAL-20121213]

5.3 Text and Fonts

Terminals SHALL support the [CSS3-FONTS-20130212] as profiled in section section B.4 CSS Fonts Module Level 3

Terminals SHALL support the Web Open Font Format [WOFF-20121213]. Applications can link to [WOFF-20121213] fonts via a @font-face rule ([CSS3-FONTS-20130212]).

Terminals SHALL support CSS Text [CSS3TEXT-20121113] as profiled in section section B.5 CSS Text Level 3

5.4 Advanced Graphic

Terminals SHALL support the CSS Transforms [CSS3-TRANSFORMS-20120911] as profiled in section section B.6 CSS Transforms

Terminals SHALL support CSS Transitions [CSS3-TRANSITIONS-20130212] as profiled in section section B.7 CSS Transitions

Terminals SHALL support CSS Animations [CSS3-ANIMATIONS-20130219]

Terminals SHALL support Canvas 2D [CANVAS-2D-20121217] as profiled in section section C.3 Canvas 2D.

AmeliaBR commented 4 years ago

In addition to any discussion about which specs need to be upgraded to a more stable status, is it worth having a discussion about how we can make this document more useful?

This thought inspired by two recent things…

dbaron commented 4 years ago

It may be worth reconsidering some of the items discussed in #2281.

frivoal commented 4 years ago

@SelenIT Yes, MQ5 should be published, but no, it's probably not ready for the snapshot, it's not that stable yet.

SelenIT commented 4 years ago

@AmeliaBR I wholeheartedly support the idea to make the CSS Snapshot the primary entry point of the modern CSS specs! After all, it has a section called "CSS — The Official Definition", and its short URL seems to imply that this is the main spec of the "CSS in general". Besides Chris Coyier, Peter Paul Koch recently also wrote about the marketing and educational potential of the single name for modern CSS (he suggests "CSS4" for this). I also once wrote a tweet (half-jokingly, but only half) and a short blog post (in Russian) about some benefits of having the clear umbrella terms for the distinct stages of the CSS evolution and the suitability of CSS snapshot revisions for this.

And having a first-hand reference of actual CSS properties, values, and their maturity status directly from W3C in one place would be extremely useful for everybody!

@frivoal this particular feature (prefers-color-scheme) has a surprisingly good browser support and has been actively promoted by many tech evangelists during the last half year or so. That's why I thought it would be nice to make this feature "less experimental" :)

frivoal commented 4 years ago

@SelenIT So far, we've let sites like caniuse or MDN worry about tracking how well implemented things are. We might change what we do with the snapshot, but for now, it is not trying to be a competitor to those, and fulfills a different role: that of tracking which specifications are REC or not-quite-REC-but-nearly-as-stable. Media queries 5 doesn't qualify, even though it does have some very nice features with good adoption.

SelenIT commented 4 years ago

@frivoal I'm not suggesting making the CSS Snapshot kind of duplicate for caniuse or adding the entire MQ5 spec into it. I only supposed than one particular well-adopted feature might be a good candidate for addition to this section.

And I wouldn't underestimate the importance of the ability to easily tell the "not-quite-REC-but-nearly-as-stable" features apart from the experimental ones for the web developers. The W3C statuses alone, unfortunately, are not always informative enough, e.g., the WD status can mean the early stage of the spec lifecycle as well as the former CR (or even REC) being updated after minor corrections. So being included in the snapshot (like, e.g., CSS Multicol 1) seems to be a more reliable indicator of the "readiness" of the spec.

svgeesus commented 4 years ago

For a list of all properties, descriptors, and values there is the CSS index but that links to the relevant spec for the actual definition (it is really an index).

dbaron commented 4 years ago

So four specs that I suggested for 2018 to be promoted to the lowest-status "fairly stable" list because I thought there was a bunch of implementation work happening for them, but which were not because the specs had too many open issues at the time, were:

I think it's worth looking at whether these specs have fewer open issues now.

dbaron commented 4 years ago

Also, editorially, the "CSS Easing Functions" spec should be referred to by name, like the other specs, and not just as "[CSS-EASING-1]".

css-meeting-bot commented 4 years ago

The CSS Working Group just discussed Let's make snapshot 2020 while the year is still young.

The full IRC log of that discussion <dael> Topic: Let's make snapshot 2020 while the year is still young
<dael> github: https://github.com/w3c/csswg-drafts/issues/4715
<TabAtkins> page-size I don't care about, nobody uses it. background-size is a reasonable counter-argument; we're inconsistent either way. :(
<dael> chris: I wanted to start. Last time we did a snapshot was a while ago. We were trying to publish at beginning of year.
<dael> chris: Nothing to propose, but I'd like people to look and comment and add what spec you want.
<dael> chris: Also discussion on what snapshot should mean. Would prefer that separate unless it resolves quickly. Would like to get a snapshot out.
<dael> florian: Would say we aim for a ready to approve snapshot by next F2F. Let github discussion happen and then someone, maybe me, can write a draft
<dael> florian: Important part is the few things that ought to be in snapshot and missing one pub. we should deal with them first
<dael> chris: There is an issue with the FPWD we agreed to pub. Separate thing I need to deal with. fantasai the patch tool isn't working, I might not be doing it right.
<dael> fantasai: Let's talk about it.
<dael> astearns: Sounds like plan is hash out what goes into snapshot in the issue with reminders on calls. Have a draft ready before we meet in Cork?
<dael> chris: Sounds great
<dael> astearns: Changes to the schedule?
<dael> jensimmons: Just a comment about scope of snapshot convo to be about snapshot. I agree. There does seem to be a growing convo about if we should define css 4 or a more marketing term. I agree that's a separate thing. THe snapshot is a function of the WG. It's a good idea to consider something like css 4 but that's a different topic
<dael> astearns: Might be good to raise a separate issue on the messaging. We should keep this github to publishing the snapshot we've engaged in producing.
<dael> astearns: Anything else on snapshot?
<dael> astearns: Please do look. There are a number of questions about which drafts should go in.
<florian> I'll make an ED today, so that we can start to iterate.
fantasai commented 4 years ago

Agree with putting css-display-1 into the "completed design work" note. Cascade 4 and Easing 1 should move into snapshot proper, they're implemented and very stable.

fonts-4 can probably go into into rough interop once it gets trimmed down to the implemented subset, which I think the editors are planning to do?

color-4 seems close to "design complete" but isn't finished yet afaict.

ruby is nowhere near ready

frivoal commented 4 years ago

Alright, I've put up an editor's draft for the 2020 snapshot: https://drafts.csswg.org/css-2020/

For now, it is a copy of the 2018 snapshot, with the following changes:

I have not yet added any other spec, or moved any other spec from one note to another or to the main section, as I'm waiting for the dust to settle a little more in this conversation.

css-meeting-bot commented 4 years ago

The CSS Working Group just discussed Snapshot, and agreed to the following:

The full IRC log of that discussion <fantasai> Topic: Snapshot
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/4715
<fantasai> astearns: I think all we need to decide is which specs go in which category
<fantasai> astearns: At the moment, there are four specs proposed to graduate to official CSS
<fantasai> astearns: 2 to graduate to "rough interop"
<fantasai> astearns: and 6 into "fairly stable"
<fantasai> astearns: Proposed to add to official set
<fantasai> astearns: Grid 1
<fantasai> astearns: Contain 1
<fantasai> astearns: Cascade 4
<fantasai> astearns: Easing 1
<heycam> fantasai: I don't think Grid is stable enough yet
<heycam> fantasai: shouldn't go into snapshot in the current state
<heycam> ... still waiting on test cases
<fantasai> chris_: What does stable mean?
<fantasai> chris_: People are relying on it
<fantasai> fantasai: Original purpose of snapshot, and we may want to rethink its purpose
<heycam> fantasai: the original purpose of the snapshot, might want to rethink, we had a whole bunch of specs that were basically recs
<heycam> ... but didn't have a completed "all tests pass, full test suite" etc.
<heycam> ... known limitations of the test suite, known bugs unfixed
<heycam> ... we wanted to capture the fact that these specs are basically recs, but have a few things need fixing up, which might take a while
<heycam> ... the bar for getting into that top level is really high
<heycam> ... another problem right now, we have a lot of specs which should be in CR but are not
<heycam> ... the poster child for these: animations, transitions, those kinds of things
<heycam> ... we added a note to the snapshot saying these are widely implemented, with fiddly bits not worked out yet. that new category
<AmeliaBR> q?
<heycam> ... then for completeness, we have a bunch of CRs, may as well put them in there. but there not at the "this is a Rec" level
<heycam> ... that's how we got to this point with those cateogries
<heycam> ... not sure what we need from the snapshot right now
<dbaron> I'm not quite sure I agree with the description of the third category...
<heycam> ... the purpose of the snapshot was to communicate things which were not obvious from the official status of the specs
<heycam> astearns: I propose we don't discuss the purpose of the snapshots today
<heycam> ... we have a list of specs that have been suggested to add, we can just move through them, and choose not to move individual specs if we want
<heycam> ... for the remaining things, that are being considered to be put into the official section, any objection to contain-1, cascade-4, and easing-1?
<TabAtkins> I object to Grid being omitted; I don't think that this is worth anything to authors if something of Grid's practical status is omitted.
<heycam> ScribeNick: heycam
<heycam> fremy: it's really weird that you would have contain but not grid
<heycam> florian: contain is a rec, grid is not
<heycam> fantasai: grid is not stable, the spec text is not at the same level of stability
<heycam> TabAtkins: regardless of still tweaking grid, authors are depending on grid in its current form in production all over the place
<heycam> ... if it's not considered stable for the snapsthot, I'm not sure what message it's communicating if grid is not there
<heycam> fantasai: it wasn't originally intended for authors
<heycam> ... hence we might want to discuss the purpose of snapshots
<heycam> dbaron: I think Grid is in a similar state to what we thought about animations a few years ago
<heycam> ... when it went into this category
<heycam> astearns: the first category is "roughtly interoperable"
<heycam> fantasai: grid belongs there, not the top category
<heycam> AmeliaBR: three categories are: official stable specs, roughly interoperable but needs more testing/bug fixing, fairly stable but needs more impl experience
<heycam> ... transitions, animatinos, grid, these are all in the "rough interop" category
<heycam> ... moving one up and not the others, not sure what the argument is for that
<heycam> astearns: to make some progress, I didn't hear objections for contain-1, cascade-4, easing-1
<dbaron> (BTW, I think I was confused about what was proposed to move where when I made my last comment.)
<heycam> RESOLVED: Move contain-1, cascade-4, easing-1 to the official snapshot
<heycam> astearns: two candidates for adding to "rough interop"
<heycam> ... align-3 and cascade-4
<heycam> fantasai: I thought cascade-4 was at the top now?
<heycam> astearns: cascade-3 is in the official part, cascade-4 is currently in the "fairly stable" part
<heycam> fantasai: cascade-4 I think is revert + scoping?
<heycam> ... shadow DOM scoping stuff
<heycam> dbaron: I have comments on align, but maybe we should talk about cascade first
<heycam> florian: cascade is part of the resolution we just took
<heycam> astearns: sorry, my duplication problem
<heycam> ... let's talk about align
<heycam> dbaron: one question about align is to what extent it's roughtly interop varies depending on what you're talking about
<heycam> ... align is pretty interop if you talk about it applying it flexbox
<heycam> ... but for applying display:block, it's mostly not implemented at all
<heycam> ... so I think that makes it a little unclear where it should go here
<heycam> AmeliaBR: are the parts of align that were originally defined in terms of flexbox/grid, is that text still in those spec? or has it been moved out to align
<heycam> fantasai: believe it's in flexbox, was never in grid
<heycam> astearns: seems like enough for me not to move it up to "rough interop"
<heycam> heycam: might want to split out the application to block to a separate level
<heycam> astearns: yes but there's still value to having the aspiration in the current spec
<heycam> chris_: there is a cost to splitting it out, can cause impls to slow down
<heycam> dbaron: in this case, we're in a position where the longer we wait, the more likely we'll have compat problems if we do it
<heycam> ... to the point that from a Gecko perspective we wouldn't be comfortable implementing first
<heycam> ... if we impl, find it is compatiable, nobody else impls, then a year later we find it's no long compatible, and we have to take it out
<heycam> astearns: for snapshot purposes, let's move on
<heycam> ... the last category is "fairly stable"
<heycam> ... 5 spec suggested to move into it
<heycam> ... writing-modes-4 (fairly small), display-1, fonts-4, font-loading-3, color-4
<heycam> chris_: despite being the editor, I will argue against color-4
<heycam> ... it's not quite ready
<heycam> ... the working color spec needs to be added
<heycam> ... fonts-4, I would argue for that
<heycam> ... the variable font part is good, rest is fairly reasonable
<heycam> ... I will resist splitting out the color font stuff
<heycam> ... I want to encourage impls by having it in there
<heycam> fantasai: there are a lot of open issues on fonts-4
<heycam> chris_: 67 of them
<heycam> fantasai: putting it into stablish category usually means fewer issues
<heycam> ... in terms of open issues, what does that look like?
<heycam> chris_: lots of little issues. a pile related to generic font families, ~20 of them
<heycam> ... many will be closed with no effort or dealt with
<heycam> ... think it's reasonably mature though
<heycam> fantasai: if it's reasonably mature, we should try to get it into CR and push it forward
<heycam> ... if it makes sense to push out the generic fonts stuff to level 5...
<heycam> chris_: I did ask i18n for wide review today
<heycam> ... but I give them a 3-6 months to CR guesstimate
<heycam> fantasai: I would love to see fonts-4 in CR
<heycam> ... at that point it would be great to add to the snapshot
<heycam> ... but given there are significant open issues, I don't think it qualifies as "fairly stable"
<heycam> ... but I think you're not far from there, could probably add it later in 2020
<heycam> astearns: so let's not add it to the snapshot for now
<heycam> ... we're down to 3 new candidates
<heycam> ... writing-modes-4, display-1, font-loading-3
<heycam> dbaron: I would like to change display-1 to display-3, since display-1 doesn't exist
<heycam> astearns: any concerns with those three specs going into the "fairly stable" bucket?
<heycam> ... any objections?
<heycam> RESOLVED: Move writing-modes-4, display-1, font-loading-3 to the "fairly stable" bucket
<heycam> astearns: organizational question about the buckets
<heycam> ... two are sections, one is a note. why not have 3 sections?
<heycam> fantasai: I think that would probably make sense!
<heycam> astearns: any objections to having 3 sections?
<heycam> chris_: sgtm
<heycam> RESOLVED: Have snapshot buckets all be sections
<heycam> chris_: who's pushing it forward? florian made the first draft
<heycam> florian: I am the editor
<dbaron> FWIW, I think I somewhat preferred the note setup rather than switching to sections, but I'm ok with sections
<heycam> ... I'm OK with doing some of it
<fantasai> dbaron, why?
<dbaron> fantasai, I guess I liked the idea of the snapshot defining one thing rather than three things
tabatkins commented 4 years ago

I strongly disagree with Grid not being in the official snapshot yet; it's widely-implemented and widely-used in production. If that's not a sufficient condition for it to be in the "official" part of the snapshot, I don't understand what the purpose of the category is in the first place.

The purpose of this document is to give useful information to authors about what they can use. "Official" is "go ahead and use it, should be fine"; "fairly stable" is "probably usable, be a little careful with details". Grid is "official" under that definition.

If those definitions are not what we're using to define the categories, then I challenge the worth of the categories in their entirety.

frivoal commented 4 years ago

@tabatkins How's this different from say, transforms? I don't think transforms and grid belong in a different bucket. Currently, they're in the "pretty good" bucket, not in the "done" bucket. That seems appropriate. But then again, depending on who the audience is, maybe there is not a clear need to separate "pretty good" and "done". Or maybe there is?

SelenIT commented 4 years ago

I'd suggest that "Safe to Release pre-CR Exceptions" section also should come right after the three buckets. so there would be a single unbroken list of CSS features considered more or less "ready" to the given date. It's OK if the detailed explanation what different "kinds" and "levels" of "readiness" come after that list.

AmeliaBR commented 4 years ago

The purpose of this document is to give useful information to authors about what they can use.

We agreed not to debate the purpose on last call, but the abstract explicitly says “The primary audience is CSS implementers, not CSS authors, as this definition includes modules by specification stability, not Web browser adoption rate.”

SelenIT commented 4 years ago

Both CSS Cascade Level 3 and CSS Cascade Level 4 simultaneously being part of the Official Definition looks quite confusing. Shouldn't the older level be obsoleted by the newer one at this level of readiness?

fantasai commented 3 years ago

@SelenIT Done in #5111!

fantasai commented 3 years ago

Florian and I triaged all the CSS specs, and we have a few suggestions to make for the 2020 Snapshot before we publish it. (It's otherwise ready to be published, based on earlier discussions.)

svgeesus commented 3 years ago

And the perceived relevance of this will be greater if it is called Snapshot 2021. And published, as I originally suggested, while the year is young.

Publishing Moratorium - End of Year: December 23 - January 1

svgeesus commented 3 years ago

Is Color 4 ready to add somewhere?

Yes, clearly. "completed design work, and are fairly stable, but have not received much testing and implementation experience yet" seems accurate - Safari has implemented some, BFO has implemented it all, and other browsers are discussing how to implement. Most issues are closed, so it seems fairly stable. I'm aiming at CR in Spring 2021.

Is Fonts 4 ready to add to rough interop? (Seems too unstable for “stable”, but also seems mostly implemented?)

Also stable with limited testing. The instabilities are primarily in the areas of

  1. New generic font families
  2. Fonts and privacy

Large parts are widely implemented, in particular the variable fonts stuff. The color fonts stuff is stable but not implemented, which is holding back deployment of color fonts since people need to adjust them in a stylesheet, not by opening a font editor. And font-variant-alternates, which was pushed from Fonts 3 because of slow implementations, is still Firefox only although Chrome did say they would implement it.

svgeesus commented 3 years ago

What should we do about CSS Grid Level 2? Subgrid is stably defined, but Grid 1 spec is still rough.

That would imply splitting off Grid 2 was premature. Is is really that rough?

svgeesus commented 3 years ago

CSS Sizing Level 3 to Stable + Limited Testing? (We're just waiting on HR to request CR.)

Clearly, otherwise it wouldn't be ready for CR

svgeesus commented 3 years ago

Add Color Adjust 1 to "rough inteop" since it seems to be widely implemented now?

Probably, although the lack of a test suite does not give much confidence. Is it untestable?

css-meeting-bot commented 3 years ago

The CSS Working Group just discussed 2020 Snapshot, and agreed to the following:

The full IRC log of that discussion <fantasai> Topic: 2020 Snapshot
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0105.html
<dael> fantasai: Last publication issue. florian and I reviewed 2020 snapshot. It is ready based on earlier discussion. We think a few specs should be added/shifted though
<fantasai> https://github.com/w3c/csswg-drafts/issues/4715#issuecomment-745856263
<dael> fantasai: If it's okay I'd like to ask WG about possible changes.
<chris> github: https://bugs.webkit.org/show_bug.cgi?id=149772
<chris> oops
<dael> fantasai: First is add css box module L3 to top tier since it has no new functionality. Pretty stable
<dael> github: https://github.com/w3c/csswg-drafts/issues/4715#issuecomment-745856263
<dael> fantasai: Let's go one by one
<dael> Rossen_: Objections to moving box to the top?
<dael> Resolved: move box to the top
<dael> fantasai: Next [missed]
<dael> fantasai: ditto for images L3 since we cleaned that up
<dael> fantasai: It is now in sync with all the changes and pretty stable
<dael> fantasai: Not top level as top, but stable spec with limited testing
<fantasai> https://drafts.csswg.org/css-2020/
<dael> Rossen_: Objections to moving images 3 to stable bucket?
<dael> RESOLVED: Move images 3 to stable bucket
<dael> Rossen_: Moving css ui 5 to stable limited test
<dael> RESOLVED: Moving css ui 5 to stable limited test
<dael> fantasai: Next few less sure
<fantasai> s/ui 5/sizing 3/
<fantasai> s/ui 5/sizing 3/
<dael> fantasai: There was an issue against snapshot about transforms l2 to rough interop bucket
<dael> chris: It has one impl
<dael> chris: Chrome has a bug on it
<dael> fantasai: transforms 2 I thought multi impl of 3d transforms
<dael> chris: Yes, but single transform is only one impl
<dael> florian: Seems short for rough interop
<dael> fantasai: Could add and exclude those bits or save for next year
<dael> florian: Save it
<dael> fantasai: Other was color adjust 1. Maybe save for next year as well
<emilio> hmm, Gecko ships individual transform properties iirc
<dael> chris: Doesn't have any tests so claim of interop is hard to substantiate. Is it only human testable?
<dael> fantasai: SHouldn't require human interaction to work. We can do it next year
<dael> fantasai: I asked about color and font 4
<dael> chris: I responded.
<dael> Rossen_: 2021
<gsnedders> WebKit has an impl, but not shipped in Safari
<dael> chris: Color 4 is stable. A few bits are not. Closed enough that I expect cr in jan or feb. stable and getting impl
<gsnedders> s/an impl/an impl of individual transform properties/
<dael> fantasai: color 4 in stable needs testing or save for 2021
<dael> chris: let's say stable and needs testing.
<dael> chris: Same with fonts 4
<dael> Rossen_: color l4 move to sable needs testing
<dael> RESOLVED: color l4 move to stable needs testing
<dael> fantasai: fonts 4 a lot of open issues. Lot of impl happeneing but spec text mayne not stable
<gsnedders> do we not have tests for most of color l4 in WPT from when impls implemented it?
<dael> chris: It is. I disagree on issue. 2 groups of long running issues. generic font families and privacy issues. It's stable apart from those bits.
<dael> florian: There are 76 open issues. Are they all what you said?
<dael> chris: At least 3/4 of them
<dael> Rossen_: Seems a little early with number of issues
<dael> chris: I'll push a little but I'll fallback with graceful degredation
<dael> fantasai: I think we want to save that for next year
<dael> chris: Fine
<dael> fantasai: Prop publishing the snapshot 2020 as a note
<dael> chris: Grid 2
<dael> fantasai: Oh, yes. Grid 1 is rough interop but needs more testing. Grid 2 is a superset of 1.
<dael> fantasai: Part that's different in L2 has had no issues
<dael> fantasai: Might make sense to put them in the same bucket
<dael> chris: Makes sense to me
<fantasai> s/same bucket/same bucket, since what's holding 2 back is the shared part/
<dael> Rossen_: Publishing snapshot as a note. Objections?
<fantasai> s/bucket/bucket as 1/
<dael> fantasai: Didn't resolve on grid 2.
<dael> Rossen_: I thought we were not going to move
<dael> fantasai: Add to snapshot in same place as grid 1
<dael> Rossen_: Objections?
<dael> RESOLVED: Add grid 2 to snapshot in same place as grid 1
<dael> Rossen_: And now, are we ready to push snapshot 2020 as a note?
<dael> RESOLVED: Publish snapshot 2020 as a note
<dael> chris: What state is it in and when to prepare for publication?
<dael> fantasai: Need to make resolution edits. Tomorrow, I'm guessing
<dael> Rossen_: Anything else for publication?
<dael> fantasai: That's all I got
<dael> florian: I'm done
svgeesus commented 3 years ago 
LINK ERROR: Multiple possible '@media' maybe refs.
Arbitrarily chose https://www.w3.org/TR/css3-conditional/#at-ruledef-media
To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:
spec:css-conditional-3; type:at-rule; text:@media
spec:css2; type:at-rule; text:@media
''@media''
LINK ERROR: Multiple possible ':lang()' maybe refs.
Arbitrarily chose https://drafts.csswg.org/css2/#selectordef-lang
To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:
spec:css2; type:selector; text::lang()
spec:selectors-4; type:selector; text::lang()
'':lang()''
 ✔ Successfully generated, with 2 linking errors
svgeesus commented 3 years ago

(I'm pubrule checking with what we already have, so I can report any errors and request publication asap)

svgeesus commented 3 years ago

December 21, 1200Z: Deadline for publication requests before moratorium December 22: Last publications before moratorium December 23 - January 1: No publications January 5, 2021: Publications resume

FPNote requires manual publication, so only slot is Tues 21 December. FPNOTE requested 16 Dec

svgeesus commented 3 years ago

If a feature is unstable (i.e. the spec has not stabilized yet), yet

The repeated "yet" is awkward, speed readers may miss the doubled word. Perhaps

"If a feature is unstable (i.e. the spec has not yet stabilized), but"

jensimmons commented 3 years ago

Oh, I agree with @svgeesus — we should change the name to CSS 2021.

2020 has terrible branding. ("branding" — aka, ugh, 2020)

This will be A Thing at the very beginning of 2021, so let's signal it's forward-facing / The New. Instead of marking it with a year that's over.

svgeesus commented 3 years ago

Thank you, @jensimmons note that I started this issue in January 2020. Given it is now December, then even given we can publish on 21 December, to make it seem relevant it would be better to call it Snapshot 2021. Who wants to be reminded of 2020? It's still March, right?

svgeesus commented 3 years ago 
9 errors (and 11 warnings)

38 rules were checked. Hover over the rows below for options.
Tip: review the metadata that was inferred from the document to make sure that there are no errors.

    Error

    Shortnames differ between This and Latest Versions.
    Document identifier information must be presented in a dl list, where each dt element marks up an identifier role ("This Version", "Latest Version", "Previous Version", etc.) and each dd element includes a link whose link text is the identifier.
    Error

    Deliverer not found. An attribute data-deliverer must be in the SotD
    The Working Group(s) id(s) must be listed in a data-deliverer attribute in the section "Status of This Document".

    Include this source code:
    <p data-deliverer="@@ID1@@,@@ID2@@,...">
    Error

    Unable to find the deliverer
    It must include the name of the W3C group that produced the document. The name must be a link to a public page for the group.
    Error

    No stability warning paragraph.
    It must set expectations about the (in)stability of the document. The recommended text (see also ideas for status sections regarding the stability of group notes) is:

        Publication as a Working Group Note does not imply endorsement by the W3C Membership.

    Include this source code:
    <p>Publication as a Working Group Note does not imply endorsement by the W3C Membership.</p>
    Error
    Couldn't not determine the patent policy the WG is operating under. Check the WG's charter.
    Error
    The document must mention the governing process: 15 September 2020
    Error

    No “status of this document” introduction (eg absent, not using HTTPS, wrong copy).
    It must begin with the following boilerplate text:

        This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

    Include this source code:
    <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/">W3C technical reports index</a> at https://www.w3.org/TR/.</em></p>
    Error

    No “status of this document” introduction link to TR (or perhaps not using HTTPS).
    It must begin with the following boilerplate text:

        This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

    Include this source code:
    <p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/">W3C technical reports index</a> at https://www.w3.org/TR/.</em></p>
    Error
    See rule in context
    Report a bug
    [3783@197] Bad value “https://drafts.csswg.org/css2/#valdef-border-width-length” for attribute “href” on element “a”: Illegal character in fragment: “<” is not allowed.
    HTML validator
    All normative representations must validate as HTML5 with the following limitations:
        Inline markup for MathML is permitted but should use a (fallback) alternative.
        If the HTML5 validator issues content warnings, the publication request must include rationale why the warning is not problematic.
svgeesus commented 3 years ago

So Bikeshed understands FPWD but not FPNOTE. I used WG-NOTE, which it understands, but then there are complaints about no previous version etc.

@tabatkins Bikeshed is missing FP-WG-NOTE and FP-IG-NOTE as valid status. And the boilerplate for CSSWG Notes needs to add the data-deliverer attribute. It looks like the patent policy and process links need updating, too. (Note that the CSSWG charter, plus a bunch of other charters, were updated today (Member-only link) to the new Patent Policy. So, totally understand that Bikeshed boilerplate is not yet updated. I can do it manually for this publication, which is the last in 2020).

fantasai commented 3 years ago

... GH should not mark an issue fixed if I'm pointing to a comment in it. :/

fantasai commented 3 years ago

We're publishing this as css-2020 because it represents the state of CSS spec development in 2020! The 2021 Snapshot will have even more stuff in it that we will be preparing in 2021. Not all of 2020 has to suck.

fantasai commented 3 years ago

@svgeesus OK, should be prepped for publication, aside from mechanics. Note that Patent Policy stuff is getting fixed in https://github.com/w3c/specberus/issues/1069 and https://github.com/tabatkins/bikeshed/pull/1834 I'll have a look at what it takes to add FP-NOTE to Bikeshed later. What's this data-deliverer stuff? Seems new, what are we supposed to put here exactly?

svgeesus commented 3 years ago

What's this data-deliverer stuff? Seems new, what are we supposed to put here exactly?

It isn't new, we just don't publish a lot of notes. From Snapshot 2018:

<p data-deliverer="32061">This Note was produced by the
            <a href="http://www.w3.org/Style/CSS/members">CSS Working Group</a>.</p>
svgeesus commented 3 years ago

Publication requested 18 Dec, expected 22 Dec

svgeesus commented 3 years ago

Published 22 Dec 2020