W3C home > Mailing lists > Public > www-style@w3.org > October 2012

Re: [CSS21] Proposal to define "Block container element"

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 12 Oct 2012 08:41:35 +0100
Message-ID: <5077C9AF.4050902@moonhenge.net>
To: www-style@w3.org
CC: Peter Moulder <peter.moulder@monash.edu>
On 11/10/2012 08:02, Peter Moulder wrote:
> On Mon, Oct 08, 2012 at 06:45:06PM +0200, Anton Prowse wrote:
>>> That's in any case an outstanding issue with the table stuff, from memory:
>>> [...]
>
>> This is probably true, though I don't think I've got a record of
>> that anywhere for adding to the errata list.  I'm *really* unlikely
>> to spend much time on tables for CSS21 errata.  The chapter is so
>> broken that I don't think it's a productive use of time.  The whole
>> shebang needs rewriting in a css3 spec.
>>
>> Thanks for your comments; let me know if any of rebuttals is
>> unacceptable, else I don't plan to put forward any modification to
>> the proposal.
>
> By what criteria should content of CSS 2.1 be considered unacceptable,
> or what criteria make a proposed change worth making?
>
> Technical soundness (or its lack) used to be a sufficient criterion for
> change, but it's been clear since before CSS 2.1 became a Recommendation
> that that's no longer sufficient grounds to change this spec.  (E.g. the
> above "this chapter is so broken that it isn't worth fixing in this spec.")
>
> Without some clear criterion such as technical soundness, it's hard to know
> what errors should be reported, or what information should be mentioned when
> discussing issues on this mailing list, or even whether it's worth reporting
> errors.

I understand your concerns, and let me try to address them.

In terms of (not) working on tables for CSS21-errata, I was referring to 
me personally rather than speaking for the WG.  My personal opinion is 
that time would be better spent actually doing css3-tables rather than 
trying to patch up the CSS21 Tables chapter.  (Perhaps css3-tables prose 
could then be ported back to CSS21 for errata.)  Others in the WG might 
feel differently.

In terms of which issues people should bring to the mailing list, I 
encourage everyone to bring all issues.  I recognize it can be 
frustrating to bring an issue and be told it's unlikely to be a 
priority; it's happened to me more than a few times, too!  But I 
wouldn't like to encourage anyone to try to "second-guess" which issues 
will meet that response.  All issues are worth being raised in the open.

In terms of which issues are likely to be addressed for CSS21 in errata 
rather than being punted to future levels, I don't have any 
hard-and-fast criteria and I don't believe anyone else the the WG does 
either.  (Certainly, I've never seen anything written down.)  I do think 
it's important to recognize that the spec is already a REC.  Just as a 
book publisher has to make the call whether to issue an erratum or wait 
until the publication of a future edition, so the WG has to make a call 
whether to issue CSS21 errata or wait until CSS3.  In both cases, 
issuing errata has overhead, much more than just fixing the issue prior 
to publication.  Personally, I run with something like "things that are 
confusing but not actually contradictory, wrong or lead to technical 
ambiguities" will most likely be pushed to CSS3".

In the case of the specific tables issue you raised, I see that my reply 
was a bit misleading.  I was specifically saying that I don't have a 
record of the post whether the issue was raised, implying - but I should 
have stated it clearly - that it would be great if you could send one so 
that I can add it to the issues pile.  (Even if I think that an issue is 
unlikely to be addressed for CSS21, my tactic is to add issues to the 
list if there seems to be any possibility that the editors of the future 
spec that would cover the issue might overlook it.)

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Friday, 12 October 2012 07:42:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT