Three ~9hr days of @CSSWG meetings and we still had agenda items remaining:
https://wiki.csswg.org/planning/berlin-2018
Great working with everyone, and welcome first-timers @clagnut & @notwaldorf!
Want to help improve #CSS? Check open issues: https://github.com/w3c/csswg-drafts/issues/
Since #CSS 2.1 has been stable for years, and we now have a plan for rapid editorial & substantial edits and publishing, the @CSSWG agreed to name these bugfix revisions CSS 2.2 nth edition, incrementing n every periodic REC: https://github.com/w3c/csswg-drafts/issues/2008
The @CSSWG accepted my and @gsnedders proposed new workflow for editing & publishing updates to #CSS 2.x as efficiently as we can given current @W3C process: https://github.com/w3c/csswg-drafts/issues/2553
@gsnedders restored it in GitHub to its previously published state.
@tabatkins I agree with that generally as an objective, that is:
Normatively state in CSS 2.1 that the grammar is defined by CSS 3 Syntax, with the key exception that we explicitly exclude any requirement to support scientific notation to maintain the fact that we are not adding any new features to CSS 2.x.
We should note any such exception like that in such a way to not discourage implementations from implementing all of CSS 3 Syntax, that is, something like:
For the purposes of this inclusion by reference, the scientific notation feature is excluded from CSS 2.1 in order to not add any new features to CSS 2.1. Implementations may (and are encouraged to) implement the full CSS 3 Syntax specification, and we expect any new or modern implementations to do so.
All this being said, assuming we can agree on this path forward for resolving this issue, I would like this issue to not be a CR blocker, so we can make incremental progress on CSS 2.x.
In short: the cost of switching CSS2 to use Bikeshed (and the likely fixes / changes needed to Bikeshed to handle producing a multipage spec like CSS2) is not worth the benefits.
@gsnedders has been able to create a branch of CSS2 (see https://github.com/w3c/csswg-drafts/pull/2544) that he can use to regenerate the existing CSS 2.1 REC with 2016 updates.
That is, at this point it is likely easier (less work) to incrementally maintain the tool setup that @gsnedders has setup to build CSS2, than it is to do the work to change CSS2 to use Bikeshed.
My understanding is that @plinss is also able to run the CSS2 build tools, and even do so automatically on the server whenever a commit is made to the /css2/ directory to rebuild the spec accordingly.
PROPOSED: Automate and incrementally maintain existing CSS2 build tools instead of converting to use Bikeshed.
I can see reasons for using either "CSS 2.1 nth edition" or "CSS 2.2 (nth edition)" moving forward. In either case we should use "++nth edition" for subsequent updates rather than incrementing the decimal. Here is what I could come up with and or saw or heard mentioned by others:
Arguments for CSS 2.1 nth edition moving forward:
* no new features, so no need to increment the decimal
* past decision(s) that CSS 2.1 would be the last version of CSS2.
* avoid version number inflation
Arguments for CSS 2.2 nth edition moving forward:
* CSS 2.1 has been a stable (unchanging) document for many years, "2nd edition" does not accurately reflect the extent of likely editorial and substantive edits necessary to incorporate years of accumulated errata and issues
* "CSS 2.2" explicitly sends a signal to browser implementers and detail-oriented web developers that it has (will have) major bug fixes since CSS 2.1 that everyone else has read and referenced (in books etc.)
* Regular updates is a new mode. Since the proposed CSS 2.x editing & publishing workflow (see https://github.com/w3c/csswg-drafts/issues/2553) will be publishing regular updates with changes, it makes sense to provide a new decimal version number to signal this change in expected maintenance as well
* A CSS 2.2 WD has been published, and will forever exist. It would now look weird (possibly be confusing) to have the "latest" CSS 2.x be 2.1, a perceived step backwards from the 2.2 WD
* A single decimal increment over the course of 10+ years is reasonable and provides no danger immediate or subsequent of version number inflation
Based on these reasons, I have some preference for now (continuing) moving forward with CSS 2.2 on the condition that our proposed seasonal/regular iterations use "nth edition" rather than incrementing the decimal.
I also agree that "Just changing the publication date, without updating the spec name, doesn't seem enough to me".
I would be open to incrementing the decimal in the distant future if we make major changes such as replacing whole chapters with normative references to CSS 3 modules, or perhaps obsoleting a whole chapter in deference to one or more CSS module(s) (e.g. perhaps colors.html with css-color-3 and css-backgrounds-3).
PROPOSED: Use CSS 2.2 for the next REC track revision of CSS 2.1, and then append "2nd edition", "3rd edition" etc. for subsequent Edited Recommendations.
There are likely 100x (if not more) links to CSS2.x fragment links from before 2016 than after, and thus it makes a lot more sense to restore the 2011 REC fragment anchors to keep more fragment links working on the web, especially those that were referencing /TR/CSS2/somepage.html#somefragment or /TR/CSS21/somepage.html#somefragment which redirect to the latest version.
PROPOSED: Restore fragment identifiers in CSS2.x to those in the CSS2.1 REC published in 2011.
I would prefer to NOT add scientific notation to CSS2.x because technically it’s adding a feature (and we resolved long ago no new features in CSS2.x), but I can live with it assuming this is the result of some past resolution and will be harder to undo than "keep".
I am also opposed to adding scientific notation to CSS2.x if it requires adding more normative text as opposed to getting it as a side-effect from an external normative reference e.g. to CSS3 Syntax.
That being said, even if/when CSS2.x normatively references CSS3 Syntax for the grammar (see related issue https://github.com/w3c/csswg-drafts/issues/2224), I would prefer to subset that, excluding scientific notation from CSS2.x.
PROPOSED: Do not add scientific notation to CSS2.x, or if it is present then explicitly remove it, or if (when) included by a broader normative reference (e.g. to CSS3 Syntax grammar) then explicitly exempt it from inclusion of said normative reference.
@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
@gsnedders this looks good. I spot checked the 550(!!!) files changed and the diffs I saw were consistent with what I would expect with reverting to 2011 CSS2.1 REC with 2016 updates.
t