Instantly share code, notes, and snippets.

Embed
What would you like to do?

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 (b739b88dc9d2252de3c6bfcf27647f15a56d63ea), which fall into three categories: anchor changes as a result of 914790fe62140c5deb389ac3dfea7b128b860fa8; 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])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment