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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14548

--- Comment #9 from theimp@iinet.net.au 2011-11-03 03:23:52 UTC ---
> Importance: normal

Sorry, it was only "minor" when I first created it, and it didn't look like
anyone thought it was an even a minor issue.

> It would be helpful if you could split out your concerns into separate bugs, if you're going to post comments that big.

Sorry, being so verbose is a bad habit of mine.

> 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.

Well, authors don't seem to have used it much yet, even though it's been
supported by every major browser, bar Lynx, for years. I don't think author
confusion is a concern.

On the other hand, consider:

<style>
    ol { padding-left: 1em; }
    li { list-style-type: none; }
    li.five { counter-reset: five 5; }
    li.five:before { content: counter(five) "." "\000009"; }

</style>

...
<ol>

<li class="five" value="5">FIVE</li>

</ol>


If this was used:

    li.five { counter-reset: five +5; }

then it would still be valid CSS2.1; but using +5 in the value attribute would
be invalid HTML. Despite both values having the same meaning and the same
result.

A Content Management System developer might allow users to input the value, and
use just a simple test to ensure that it evaluates to a number in CSS. This
might be stored in a database. When retrieved, the CMS might use the value for
both the CSS (which would be valid) and the value attribute (say, to support
clients that do not process stylesheets). This might even have already
happened, except that support for outputting the value attribute has not been
added yet (due to being deprecated); when it is added to the CMS at a later
date, some pages will become invalid.

While admittedly likely to be a minor case, it might have an impact on what has
been done or might be done.

I, personally, don't see much reason to forbid it unless you were trying to
simplify the attribute to just digits; but the negative sign is allowed (for
probably no more benefit), so I would think it better to allow for consistency
if nothing else.

***

Well, if you're satisfied that this not worth changing the spec. for (even
though it does not affect user agents because they already have to handle it,
and users shouldn't be writing serious HTML5 pages at this early stage), then I
don't really have much else to add. I wasn't necessarily looking to have
anything changed when I reported the bug, anyhow.

Please accept my apologies, again.

-- 
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, 3 November 2011 03:24:21 UTC