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

Re: [CSS2] Proposed process for maintaining CSS2

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 2 Feb 2017 16:10:28 +0900
Cc: Alan Stearns <stearns@adobe.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>, Stephen Zilles <szilles@adobe.com>
Message-Id: <DE512B1A-F0B8-4CFB-B524-6E2C4358E753@rivoal.net>
To: "Liam R. E. Quin" <liam@w3.org>

> On Feb 2, 2017, at 14:59, Liam R. E. Quin <liam@w3.org> wrote:
> On Thu, 2017-02-02 at 13:57 +0900, Florian Rivoal wrote:
>> We could do that, but the problem is that we kind of know for sure
>> that
>> some edits aren't ready. Presumably they will be eventually, but that
>> could
>> take a fairly long time.
> So make a 3rd edition when they're ready. In the meantime include (in
> the document) notes on the areas that aren't ready that point to an ED?

This is a partly orthogonal question:
* do we keep on updating CSS2.1, or do we create CSS2.2, CSS2.3...
* How do we prepare the changes that go into the next thing that's going to REC (regardless of how we call it) vs those that are still brewing.

My previous comment only addressed the second point.

As to the first one, we do not wish to teach people and search engines about the existence of a new CSS 2, separate from CSS2.1. Once the new REC is out, nobody should ever need to refer to what we currently call CSS2.1, since this is just about rolling in errata (and doing so inline), not adding new things.

Links form all over the place, including search engine results, point to https://www.w3.org/TR/CSS21/, and people know it under that name. There's no benefit to trying to teach the whole world to now ignore it and talk about CSS2.2 everytime they mean CSS2.1.

The delta between the thing we're preparing and current CSS2.1 is also very different from the delta between CSS2.0 and CSS2.1. That was a significant change in scope and functionality. In this case we are only talking about inlining erratas. Using the same numbering scheme for both updates would be misleading.

>> This Note would effectively be a working draft in the plain english
>> sense, as it's the
>> draft we work with, but it would not be a Working Draft in the
>> Process sense,
>> as it is not a document we intend to move along the REC track.
> I'd be much happier seeing it be on the rec track so that patent
> commitments apply.

This is only about errata. There is no new features. We've already got all the patent commitment in the existing REC. And even if we assume that some substantive errata may change the behavior enough that patent coverage would be impacted, then it makes it all the more important to have a process that reaches REC quickly. The goal of this process is to be able get changes that are ready to REC as fast as possible, potentially issuing multiple REC updates to CSS2.1 per year.

> Thanks for replying. Maybe if I'd been able to go to Seattle I'd be OK
> with this, but as it is I'm trying to see if we can't use the existing
> Process a little more efficiently.

Yes, this is a little nasty, but this is the best we could come up with. The process process is fine for doing new documents and getting them to REC including when the new documents supersede some previous RECs, but it doesn't seem to have a convenient way of doing in-place maintenance on existing RECs other than  diff-like errata in a separate document, which are bad, because they mostly unnoticed, and even when you know about them, are hard to read.

If you haven't done so yet, I suggest looking at the Seattle minutes about that.

Received on Thursday, 2 February 2017 07:11:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:06 UTC