W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 14548] Grouping Content: algorithm for incrementing value (OL->LI @value) does not match any current user agent

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Nov 2011 21:39:00 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RLiWS-0005Ls-0j@jessica.w3.org>

--- Comment #8 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-11-02 21:38:55 UTC ---
It would be helpful if you could split out your concerns into separate bugs, if
you're going to post comments that big.

In brief:

> If a major vendor used a four-bit counter, and claimed that this was okay
> because 99.999% of lists use only positive numbers and stop before 16, would
> this be an appropriate limit?

Sure. Using that limit might mean that on your particular hardware platform,
you are more competitive. Or, it might be that using such a limit makes you
very _non_competitive and so you lose market share.

> The CSS Box Model was as clear as can be, but probably half of the DIV elements
> and lines of CSS ever written were to force a certain user agent to behave in a
> certain way.

The CSS box model is orders of magnitude more complicated than this case.

At the end of the day, I just don't believe that this limit matters in

> I'd make the the initial positive sign symbol (U+002B PLUS SIGN) valid for
> authors to use. If it has to be supported anyhow, you lose nothing by allowing
> it, but gain complete CSS compatibility for all legal values. I see no reason
> to forbid it, and there's less fuss that way. I understand that it is unlikely
> to encounter such values in CSS, either. Recommend that it not be used, if that
> is a major concern.

I don't really see any reason to allow it. It doesn't do anything useful. By
making it not allowed we let authors know they can omit it.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 2 November 2011 21:39:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:22 UTC