CSS2 maintenance proposal

[gsnedders]

CSS2 maintenance proposal

Some background:

• In TR space, we currently have http://www.w3.org/TR/2011/REC-CSS2-20110607 and https://www.w3.org/TR/2016/WD-CSS22-20160412/.

  • The former of these is the current CSS 2.1 REC, which was edited-in-place in April 2016 (literally "in place"; the old 2011 dated URL serves the 2016 edition, the only way to view the 2011 spec is on Internet Archive Wayback Machine). The 2016 edition has a number of edits in addition to adding the warning boxes which I believe was meant to be the only change.

  • The latter is a FPWD of "CSS 2.2" also published April 2016 incorporating all errata and some other editorial changes. Note that this predates the Seattle F2F resolution from January 2017 as to how we were going to CSS 2 maintenance.

• In csswg-drafts, we have two copies:

  • "css2" which is essentially the "CSS 2.2" with further edits, including renaming it to "Preview of the next revision of Cascading Style Sheets Level 2 (CSS 2.x)" and turning it into a NOTE (this is roughly what is implied by the Seattle F2F resolution).

  • "css21" which is pretty much the current edited-in-place CSS 2.1 REC.

• There's some concern about the current beyond-CSS-2.1-REC drafts as to whether they match the consensus of the group, and whether some "editorial" changes are actually that.

Generally, mine and @tantek's proposal is:

• We have a single copy of CSS 2.1 in the repo.

• We make purely editorial changes directly to the spec.

• We make substantive changes as informative delta notes in the spec (because we want everyone looking at the current spec with all errata, and this matches the "best practice" suggested in the Process).

• When we go to CR, we replace all the informative delta notes with identical "at risk" text, or replace the existing normative text if a note already has two interoperable implementations.

• When we go to PR, we drop any "at risk" text without two implementations, or replace the existing normative text if the "at risk" text already has two interoperable implementations.

• Semi-regular CR publishing schedule, like quarterly/seasonally, perhaps coincident with F2Fs, with PR/ER follow per Process time periods.

I suggest:

• Having reviewed the changes from the 2011 REC (tagged in the repo as CSS2-20110607-REC) to the 2016 REC (b739b88), which fall into three categories: anchor changes as a result of 914790f; editorial changes related to republication; and adding the warning boxes. See here for a diff excluding the anchors.

We need to:

• Get down to a single copy of CSS 2.1 in the repo.

• Get /TR/CSS22/ to redirect to /TR/CSS21/ (or maybe the latest CR).

• I would personally like to alter the build system to put the built output in a separate directory rather than it mixing it in with the source files.

• Get Travis CI or similar building CSS 2.1 to ensure we keep the checked in built copy up to date (this is needed because the below item might not happen for a while).

• Get drafts.csswg.org building the spec and remove the built copy from git.

• Go through the current errata document and, having made sure they match the WG resolution, add them to the new draft.

• Go through WG minutes and make sure all RESOLUTIONs/ACTIONs affecting CSS 2.1 have open GitHub issues. (Please help!)

• Start going through all the open GitHub issues.

Open questions:

1. Should we add scientific notation to CSS 2.1? (#2542)

2. Syntax section readded despite WG resolution (#2224)

3. Naming of revision of CSS 2.1 (#2008)

4. Anchors changed in CSS 2 in-place edit in 2016 (#2551)

5. Use only [css2] and label:css2 on GitHub? (mv label:css22 -> label:css2, [css22] -> [css2], [css21] -> [css2])

Sketch of the flow described above:

[tantek]

@gsnedders @fantasai and I worked on this effort to restart CSS2.x editing & publishing with a formal but efficient workflow during the current (Berlin) CSSWG meeting and we’re pretty sure we can make this work (@gsnedders helping with the restart, build system, and testing, and initially @fantasai and myself as editors), and it's the most efficient we can do this given goals and current W3C process / patent policy constraints.

This is intended to supersede all decisions/resolutions at the past Seattle f2f where the WG last discussed CSS2.x workflow.

Please take a look at the gist and thumbs-up, or add questions / comments / suggested improvements accordingly. Assuming the WG approves this proposed workflow I’d like to document it in a README in the css2 directory https://github.com/w3c/csswg-drafts/tree/master/css2 so its easily discoverable and we can tweak/iterate as needed while actively using it.

Thanks!

Tantek

cc: @astearns @atanassov

(Originally published at: http://tantek.com/2018/102/t2/)

[css-meeting-bot]

The Working Group just discussed Proposed CSS 2.x editing & publishing workflow, and agreed to the following resolutions:

• RESOLVED: Accept this new editing process

The full IRC log of that discussion

<dael_> Topic: Proposed CSS 2.x editing & publishing workflow
<dael_> github: https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce
<dael_> github: https://github.com//issues/2553
<dael_> tantek: I made a diagram based on discussion with gsnedders at dinner.
<dael_> tantek: Proposal: https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce
<dael_> tantek: We want to swtich to 1 copy of css2. We want to make 2 kinds of changes, one is editorial and the substantive we want them to be informative delta notes.
<dael_> gsnedders: And we can publish them without impl.
<dael_> tantek: And putting notes where people find them. When we go to CR those delta notes we ID as normative at risk unless they're interop and then we merge them in. CR to PR we look at the at-risk delta paragraphs. If they're impl we merge and if they're not merge to notes.
<dael_> tantek: Given that we think we can publish semi-regularly. Perhaps at F2F.
<dael_> tantek: [shows diagram on description]
<gsnedders> https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce#file-flow-png
<dael_> tantek: Any substantive changes where there's interop and if we don't have it there's not interop we'll go to CR. Once CR period is done we issue the PR. We ID at-risk and they're merged in or they become notes again. When PR closes we do ED.
<dael_> gsnedders: If there's no substantive changes we go straight to ED>
<dael_> florian: So if no change since last time to impl we can cycle ED?
<dael_> tantek: Yes. Only if there are type 1 changes do we seasonally do an ER. If there are type 2 we do a CR.
<dael_> fantasai: I think that's a lot of extra work for no benefit. Our goal is minimize process. If we don't have impl of anything yet and everything is we're hoping for impl there's no reason for CR>
<dael_> tantek: Type 2 edits are agreement from impl to implement.
<dael_> fantasai: But if there's no...if none of the edits can fold into main line text there's no reason to go to CR with at risk notes. They may as well stay as notes.
<dael_> florian: I think that tweak reduces process churn and increases time spec is in ED.
<dael_> tantek: Okay with that. gsnedders ?
<dael_> fantasai: This whole churn is a lot of work for Chris to set up.
<gsnedders> [gsnedders' shrugs]
<dael_> tantek: Reduce # of transition requests makes sense.
<dael_> astearns: So only got to CR once there is at least 1 interop type 2 change.
<dael_> tantek: Reasonable.
<dael_> tantek: So there's a number of steps to start, which gsnedders has started.
<dael_> tantek: gsnedders committed us down to one version. It reflects the 2011 REC. It's a pull request right now.
<dael_> tantek: [reviews the need to do list]
<dael_> tantek: Assuming WG accepts this we'll drop this and build instructions into the read me.
<dael_> florian: The CSS2.1 PR is in the 2011 state?
<dael_> gsnedders: 2016 state. The 2011REC edited in place 2016 state.
<dael_> florian: Are edits between 2011 and 2016 correct?
<dael_> gsnedders: There's a diff. Except the anchors changing it's fine. There's some changes for pub rules and adding warning boxes.
<dael_> florian: Do you want to merge this and then work through things resolved?
<dael_> gsnedders: Yes.
<dael_> florian: SO a temporary set back to the most up to date ER?
<dael_> ChrisL: It's a stablization phase.
<dael_> florian: Current draft contains mix of correct and mix of not correct.
<dael_> gsnedders: We merge now and work our wait through.
<dael_> tantek: And going forward all changes will be PR that require at least two positive reviews so there's a trail.
<dael_> ChrisL: Inc tests for each change?
<dael_> tantek: Test requirement is when want to change delta notes to normative notes.
<dael_> ChrisL: But collecting tests is useful.
<dael_> tantek: Don't need to block on it.
<dael_> ChrisL: No, not block but collect them.
<dael_> tantek: When implentors impl the tests will be there.
<dael_> ChrisL: I suggest you use wpt tests needed tag
<dael_> fantasai: Andinformative notes contain links to test.
<dael_> florian: Are you going from 2016 to corrected 2018 state quickly? If it will take a long time I want to wonder...I don't want to lose good edits for too long.
<dael_> ChrisL: Good edits should be in errata.
<dael_> tantek: We'll continue to like to errata doc, but the goal is to deprecate it.
<dael_> florian: I'm not an editor for CSS2.anything and I made a PR to merge in line-height. That's not in errata. I'm okay with that being pulled back but not if it's 5 years.
<dael_> gsnedders: I have a list of things that weren't made. Things that went through PR should be relatively easy to land if they've been reviewed.
<dael_> tantek: We've IDed open questions that are a minimum to do another CR. Those are listed on the agenda, but it can be done on telecon on github.
<dael_> florian: Yes, think it's fine. If it takes longer then expected that wouldn't be great, but hopefully it won't happen.
<dael_> astearns: Other comments on this process?
<dael_> fantasai: I think it's great.
<dael_> tantek: Which is good because you're starting as a co-editor.
<dael_> fantasai: I could be a former editor. That would be an accurate representation.
<dael_> tantek: Need a second editor. gsnedders isn't paid for it so he's mostly doing tests and build system.
<dael_> fantasai: I'd propose to have it be gsnedders and have me as a former and say a former editor can review changes at same level.
<dael_> astearns: WE've had resolution on different process, we need a resolution to say we're adopting.
<dael_> ChrisL: Can gsnedders document be added to the read me to our own repo?
<dael_> astearns: That is part of the plan.
<dael_> RESOLVED: Accept this new editing process
<dael_> astearns: I can decree this. I decree fantasai as a former editor.

[gsnedders]

We should add something based on the above gist as a README.md in css2/.