W3C home > Mailing lists > Public > www-style@w3.org > February 2015

RE: [CSS21] Ambiguity in tokenizer, "normative appendix G"

From: Arron Eicholz <arronei@microsoft.com>
Date: Wed, 4 Feb 2015 17:29:51 +0000
To: Florian Rivoal <florian@rivoal.net>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, www-style list <www-style@w3.org>
Message-ID: <BLUPR03MB199045BC1B81F130F9283E1AD3A0@BLUPR03MB199.namprd03.prod.outlook.com>
On Wednesday, February 4, 2015 8:33 AM, Florian Rivoal [mailto:florian@rivoal.net] wrote
> > On 04 Feb 2015, at 04:48, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> >
> > On Tue, Feb 3, 2015 at 12:18 PM, Bjoern Hoehrmann
> <derhoermi@gmx.net> wrote:
> >> Hi,
> >>
> >>  In http://www.w3.org/TR/2011/REC-CSS2-
> 20110607/syndata.html#syntax
> >> "These descriptions are normative. They are also complemented by the
> >> normative grammar rules presented in Appendix G." but Appendix G is
> >> marked "This appendix is non-normative." so that doesn't make sense.
> >>
> >> In 4.1.1. the specification apparently fails to say whether
> >> variations of `url(` at the end of the input are FUNCTION or BAD_URI
> >> tokens. They should probably be BAD_URI tokens.
> >>
> >> The CSS 2.2 draft has the same problems.
> >
> > As Zack says, all of the CSS2 grammar has been superseded by CSS Syntax..

It hasn't been superseded until the CSS Syntax is a REC, is part of a CSS Snapshot, and/or reaches maturity (two compliant implementations to a test suite).

Maybe it's time to change some priorities and finish CSS Syntax. Tab??

> >
> > It's quite easy to trace the execution of the spec's tokenizer.  In
> > particular, "consume an ident-like token" will eat the `url(`, then
> > send you down the "consume a url token" algo, which immediately hits
> > the EOF and returns a (valid) url token with an empty url.
> Should we remove from 2.2 all the sections that have been superseded?

No, Maybe... (as you can tell I am on the fence here)

Having an all-encompassing foundational spec is useful in some cases. CSS 2..1 is a foundation for all the browsers and all the new specs, I think it is good to keep it as complete as possible.

If we decide to remove the content, I don't think we should remove the section headings. The headings are useful for other references we haven't removed from the spec. We would have to put in proper notes directing people to newer specs in the relevant sections but I think that is fairly easy to accomplish. 

This will allow CSS2.2 to remain our foundation spec since all the relevant sections are still there just some pointing off to other locations. Also if we follow this pattern, over time CSS 2.2 then CSS 2.3, etc... may make all the sections just a bunch of references. We then can call that document a CSS3 spec, encompassing all the new specs. This then becomes our new foundational spec to build upon.

> "CSS2.2 = CSS2.1 + errata" is already useful, but
> "CSS2.2 = CSS2.1 + errata - superseded_parts" is even better and will lead to
> a lot less confusion. Publishing a new spec with parts that should be ignored
> seems unfriendly to most readers.
> I realize that quite a few things that supersede CSS2.1 are not yet at REC, and
> this does complicate things a bit. But at the very least, we should be able to
> add notes pointing to the newer things, and maybe we can do even better
> than that.

Personally I don't believe we should point to anything that isn't a REC or isn't part of the snapshot (we need a new one of these). The CSS2.1 spec is the foundation that we have been building off of. I think CSS 2.2 should remain that foundation even if it has references to other documents.

Arron Eicholz
Received on Thursday, 5 February 2015 09:14:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC