Open gsnedders opened 6 years ago
Note that if we do resolve to keep the text after all, we need to actually fix https://github.com/w3c/csswg-drafts/issues/412 in the text because otherwise we have a contradiction.
We just need to remove it again (I'm not sure any of this text was added back...). No spec uses the old parser, and there are more differences beyond #412.
Hmm; we can't just remove it for the next update, because otherwise we can't update CSS 2.1 REC until CSS Syntax 3 is a PR, and Syntax 3 is nowhere near PR.
We can normatively undefine CSS grammar in 2.1, with an informative reference to Syntax.
@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.
(Originally published at: http://tantek.com/2018/102/t7/)
While I think that's the only major feature addition, https://drafts.csswg.org/css-syntax/#changes-css21 lists all the actual changes from 2.1 that have been made (that I remembered to document).
See also: #412
Yes, that's documented in the changes section I pointed to. It's a change, but not a "feature", which Tantek seems to be drawing a distinction between.
Tangentially, I continue to assert that treating 2.1 as a separate artifact that can be usefully implemented on its own is worthless; it's correct treatment is as the grab-bag CSS module for anything that hasn't yet been explicitly ported into a properly-named module of its own. To the extent that W3C process interferes with this, it's W3C process where the bug lies, and shouldn't be part of our decision-making process.
As such, I'm still in favor of just making CSS's syntax officially undefined in 2.1, with Syntax being the normative definition for implementations. There is no value in trying to subset Syntax for 2.1 purposes; it does literally nothing for anyone, and is purely an exercise in box-ticking for Process purposes. Officially-undefined is a useful way to indicate that CSS's syntax is no longer defined by that document, supporting my "2.1 is a grab-bag module" assertion. And dropping things never reduces test coverage, either, so there's no Process problems with that. ^_^
I'm going to point out that CSS Syntax has taken a lot of changes since its last publication on /TR, so using it as a reference from CSS2 REC seems unlikely to be a useful suggestion until that's resolved.
I think both can be true:
The Working Group just discussed Should we add scientific notation to CSS 2.1?
, and agreed to the following resolutions:
RESOLVED: take 4.1, 4.2 and 4.4, change them to informative notes, and add notes to those sections + appendix G showing where the newer work is being done. Links to newer works are informative notes.
I'm pretty sure we can't just make them informative, because this leaves loads of dangling normative references.
e.g.,
Counters are denoted by case-sensitive identifiers (see the 'counter-increment' and 'counter-reset' properties). To refer to the value of a counter, the notation 'counter(
)' or 'counter( , <'list-style-type'>)', with optional white space separating the tokens, is used. The default style is 'decimal'.
Do we just want to make the 'counter(
Yes. Once again, the choice is either that 2.1, taken as an implementation artifact all by itself (for whatever miniscule worth such a thing has), has some officially-undefined behavior that we just handwave about, or we actually do some non-trivial work to subset Syntax 3 to conform to some notion of "no new features" relative to the previous 2.1 approach.
Given the extremely low cost of the former, and low benefit of solving the problem, I'm still strongly of the opinion that it's far preferable to the latter.
Presumably, there's no point reapplying all the existing errata to the CSS 2 syntax given even once we've done that we won't match level 3, and as such all the issues for them (#2773, #2775, #2776, #2777, #2780, #2786) can all be closed as wontfix?
Imo yes.
The CSS2 Syntax section got readded based on feedback (from @fantasai, IIRC) in 3652e8b, despite seemingly there being a resolution for it being removed ("RESOLVED: Remove CSS grammar section in CSS 2.2 and have a pointer to CSS syntax", 2016-10-12), presumably because neither of those involved were aware of the WG having resolved that.
We should either resolve to go against the earlier resolution, or we should redo the edits to remove it.