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: Tue, 25 Oct 2011 18:14:43 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RIlWN-0008Vu-1N@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14548

--- Comment #3 from theimp@iinet.net.au 2011-10-25 18:14:40 UTC ---
Errata to comment #0:

The first five values for Gecko in the table:
> 1,0,1,3,4
  1.0,1,2,3

IE
> * Values less than 0 return an automatic increment of the previous number
  * Values less than 1 return an automatic increment of the previous number

Note:
When the phrase "Values greater than" or "Values less than" are used, it could
be more clearly written as "Value attributes explicitly set to" and "greater
than" or "less than", respectively.

***

> Firefox 9
> IE10 PP2
> Chrome 14

I was only testing release versions.

I don't know if @value is being reintroduced for backwards-compatibility with
pages written to take advantage of older user agents, or if it is intended to
be used with its new behavior going forward to unify HTML with various author
requirements. If it's the former, then the behavior of browsers of the future
are less critical. Also note that the current behavior, as I reported it, has
been stable and predicable for over 10 years in these browsers - I usually went
back to the very first versions. IE 2 was the only major exception to browser
"families" in their whole existence, and that's not a browser that *anyone* is
trying to be compatible with.

> Opera 11.5 only fails 3 tests

I think the table reflects that, yes? Most browsers only failed about three
tests; just not the same ones :-(

***

Personally, I think that allowing negative numbers is useful, and the value
zero is very important. The most consistent results are obtained by forbidding
them; even so, compatibility with the (currently draft) CSS Lists Module
requires allowing them. HTML4 allowed 0, but not negatives; that fact is mostly
academic, though.

The positive sign symbol is, I think, the most difficult part to reconcile.
Personally, I'd either make it fully conforming (Lynx would have to change its
behavior, and as an important and stable browser, that's hard), which would
also gain the benefits of compatibility with CSS; or else, forbid it entirely.
I think that it's not good to specify the behavior but forbid the usage, when
the behavior is not universal.

Do you have any idea what the actual usage of otherwise-valid integer values
prepended with U+002B PLUS SIGN actually is? I would guess it would be
extremely rare.

I wonder if "conforming limits" might be useful. Implementation limits are
essential, because some kind of limit is unavoidable. Realistically, I can't
think of a scenario where a list is practical beyond a few thousand entries, or
is useful with starting numbers beyond a few million. I think the CSS Lists
Module group are considering whether a two- (about 32,000) or four-byte (about
2 billion) minimum limit is acceptable. Most browsers, even extremely old or
mobile browsers, support 4-byte integers (though Opera only uses the 31
least-significant bits).

Also, whatever the limit is - even if unspecified - the spec. should describe
the behavior when exceeded. Should the value be capped within the limit
(probably the best idea, and also the most compatible), or should it be treated
as an erroneous value (with an implied automatic increment)? I agree it's
mostly a rare event, but spec. ambiguity seems to be the result of more wasted
effort than everything else combined. I believe that ensuring that user agents
are consistent is a primary goal of HTML5; if I understand correctly,
reliability is at least as important as functionality for authors, in the
opinion of the HTML5 stakeholders.

I do wonder if it might be better to require either completely-conforming
values or else discard the entire sequence. I don't really think that a value
like "324fq!n6ireb" should return "324". How commonly is this relied upon by
authors? Is this for some kind of DOM- (as opposed to source-) level safety
catch for authors that set attributes with strings instead of integers?

Really, I would imagine that the best idea of what do, exactly, would come from
considering the question: is this mostly for the benefit of legacy documents,
or is there some reconsideration of where list values fit in the
content/structure/presentation triumvirate?

If it is expected that the value attribute will almost entirely be for the
benefit of legacy documents, and that new documents will use the CSS Lists
Module, then it probably should match either where there is current consensus
among major browsers, or where there was once (basically, IE, which was made to
be mostly compatible with Netscape Navigator).

If, however, it is designed to complement the CSS Lists Module, by providing
alternate means of providing the same (at least numerical) information in a way
that is more robust in old browsers or unusual interchanges, I would favor
compatibility with CSS. This would mostly imply that the positive sign symbol
should be permitted.

If it's intended to be a method of marking up lists with complex values that
are actually structure, as an alternative to presentation, then it needs
different rules altogether. Probably starting with a requirement to use it on
all LI elements in an OL block, and no automatic incrementing. Although I
understand that some people believe this is reasonable (frequently, people used
to using document publishing software to create complex lists), I think that
lists where the sequence counters are structure are really tabular information.
So, I don't recommend this idea.

If it's intended to follow the previous standard, then neither the negative nor
positive sign symbols are permitted, and neither are empty values, but the
value zero is. Handling of invalid values is undefined. It might make a good
compromise, but I don't think anyone actually wants this.

In all cases, I think that a reasonable minimum implementation range should be
specified, and error handling for values that exceed this range should also be
specified.

> I think the current state of the spec is a sane one that can be implemented.

Absolutely, although the question that I'm asking is: what is the spec trying
to achieve, given that it's currently another standard to add to the half-dozen
other de facto standards that can be seen now. Is it supposed to unify behavior
going forward, or is it supposed to bridge behavior for those catching up? Or
both? That will pretty much indicate what is better.

-- 
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 Tuesday, 25 October 2011 18:14:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:06 UTC