W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 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: Thu, 27 Oct 2011 04:40:23 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RJHlP-0005LN-6i@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14548

--- Comment #5 from theimp@iinet.net.au 2011-10-27 04:40:16 UTC ---
> I admit, it's difficult to stay up to date in the current situation. But I think it' important to take into account even the latest changes.

Yes, I agree that testing betas is usually important. But what I meant was,
no-one is writing documents based upon these new versions, yet. What I think we
have to worry about is authors who have, over the last 15+ years, relied upon
some particular behavior. We don't really have to worry as much about how far a
given vendor is from implementing the spec. (unless they're going to refuse
altogether).

It's a new spec.; we can do whatever we want. But vendors will not (properly)
implement any spec. that messes too much with what users/authors expect
(wherever those expectations have come from). Raising this bug was just an
exercise in caution. I have no stake in this, and will be just as happy with
WONTFIX, or even INVALID, as any other result.

> A part of the web authoring community, including myself, feels that the start and value attributes have erratically been removed from HTML 4 Strict. There are cases where numbering is important, for example if a ordered list is shortened, you still want the index to be the same.

I'm not here to debate correct usage. I would, with caveats that do not belong
here, agree that sometimes list values are content. But that's neither here nor
there (from my point of view).

The value/start/type attributes don't come close the the flexibility of the CSS
Lists Module. I don't know how much there is to gain even by changing it from
the HTML4 standard (that, looking at the table, no vendor ever quite
implemented correctly anyway). But, again, I'm not saying that this should be
done any particular way.

> Besides, all browsers already allow negative numbering, so lifting the restriction on value makes sense.

Only if you start at a negative number, and count in one direction, and don't
skip any numbers until you get to the positives. But I guess that is, after
all, by far the most likely use case for negative numbers.

> the issue simply isn't really a big deal.

Well, I guess I won't disagree.

> Apparently interoperability wasn't necessary in the past.

On the other hand, I would hope we want to do better in the future. Did it not
matter because there no use case, or because lack of use was caused by the
impossibility of doing what one wanted? To find out, we'd have to look at every
other structure (inline text, tables, etc.) and determine "would they likely
have used the OL structure if it could render zero/negative numbers on all user
agents?".

I am simply concerned that, leaving room for user agents to do what they want
in edge cases, it'll cause problems later. Sure, this example is trivial, but
the number of "trivial" cases that have been exploited to compound or evade
other less trivial bugs is a large part of the history of the web, given that
authors are always pushing the limits of what browsers can do. And worse, once
it starts being (ab)used in such a way, it's extremely painful to specify exact
behavior later because a massive number of pages depend upon it. What about a
theoretical script that sniffs for the user agent by looking at how it handles
limits/overflows?

-- 
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 Thursday, 27 October 2011 04:40:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 October 2011 04:40:33 GMT