- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Oct 2011 18:14:43 +0000
- To: public-html-bugzilla@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