[whatwg] [WA1] <ol type=a> is semantic

[Ian Hickson]

In conclusion, <ol type=...> hasn't been added to HTML. The suggestion for 
addressing the main use case (reference) is to use a hyperlink and CSS to 
do the cross-references; CSS is working on this kind of thing.

In coming to this conclusion, the big concern from my point of view was 
that there was not a huge demand for this feature, and that had the 
feature never existed in earlier versions of HTML, it is likely that in 
fact there would be basically no demand for it at all. I think we should 
keep the bar high for features we add to HTML5.

Here are (slightly) more detailed replies:

On Tue, 11 Oct 2005, Simon Pieters wrote:
> 
> I think that <ol> should allow a type attribute as in HTML4[1].
> 
> An 1,2,3 list is different from an a,b,c list. If you want to discuss a 
> particular list item in the text then it doesn't make sense to say "f" 
> when the list says "6", for instance.
>
> Consider the following real world example[2]:
>
> | Quiz: Complete the sentence,"OpenDocument is ..."
> |
> | (a) An open, XML-based file format.
> | (b) An open standard, supported by the OASIS and ISO standards groups.
> | (c)The default file format for the upcoming OpenOffice.org 2.0 and KOffice
> 1.4.
> | (d) A top prospect for an official format for the European Commission.
> | (e) Our best chance to fight vendor lock-in associated with proprietary
> formats.
> | (f) All of the above.
> |
> | The correct answer is (f) All of the above.
> 
> I think the markup for the above should be something along the lines:
> 
> # <p>Quiz: Complete the sentence,"OpenDocument is ..."
> # <ol type=a>
> #  <li>An open, XML-based file format.
> #  <li>An open standard, supported by the OASIS and ISO standards groups.
> #  <li>The default file format for the upcoming OpenOffice.org 2.0 and KOffice
> 1.4.
> #  <li>A top prospect for an official format for the European Commission.
> #  <li>Our best chance to fight vendor lock-in associated with proprietary
> formats.
> #  <li>All of the above.
> # </ol>
> # <p>The correct answer is (f) All of the above.
> 
> Without "type=a" (and without CSS), the last paragraph doesn't make sense.
> 
> [1] <http://www.w3.org/TR/REC-html40/struct/lists.html#adef-type-LI>
> [2] <http://www.groklaw.net/article.php?story=20050130002908154#whatis>


On Wed, 12 Oct 2005, Mikko Rantalainen wrote:
> 
> I think the reason for not including "type" attribute in HTML is that 
> one shouldn't ever refer to anything by textual label only - we're using 
> HyperText Markup Language so the only way to refer to something should 
> be in form of hyperlink.
> 
> The above example should have markup such as
> 
> ...
> <li id="quizanswer">All of the above</li>
> </ol>
> <p><a href="#quizanswer">Correct answer is ...</a></p>
> ...
> 
> and the UA should take care of the rest. Activating the link should 
> highlight (or indicate in some other way) the correct answer because 
> it's the target of the activated hyperlink.

Indeed.


> This problem has been discussed many times before and there're cases 
> where one needs more complicated item markers than 1,2,3 or a,b,c. An 
> example could be "§1, §2a, §2b, §3, ...". Such thing would still be an 
> ordered list but there isn't a good way to mark up such a content to 
> have semantics of a list. We would need a <ol> (ordered list), <li> 
> (list item) and <lim> (list item marker) and then we could do something 
> like this:
> 
> <ol>
> <li><lim>§1</lim> first item</li>
> ...
> </ol>
> ...
> ... as defined in §1, we can ...
> 
> It would be up to UA, where the contents of <lim> element should be 
> rendered. It could be rendered to the "normal bullet point position" or 
> CSS could be used to give a hint about the author's recommended 
> position.

We could do that. I'm not sure it's really worth it though.


On Wed, 12 Oct 2005, Matthew Thomas wrote:
> 
> I'd also like to see <ol type= reintroduced, for the reasons Simon gave. 
> It is especially semantically important in legal documents (for the same 
> reasons start= is).

I agree there are cases where it is important. I'm not sure they're 
important enough to add type="", though.


> > The above example should have markup such as
> > 
> > ...
> > <li id="quizanswer">All of the above</li>
> > </ol>
> > <p><a href="#quizanswer">Correct answer is ...</a></p>
> > ...
> > 
> > and the UA should take care of the rest. Activating the link should
> > highlight (or indicate in some other way) the correct answer because it's
> > the target of the activated hyperlink.
> 
> But in the real world, that doesn't happen. Your proposed solution would 
> be bad in Web browsers (you'd have to click to find out the answer 
> instead of just reading it, and even then it would be unclear in legacy 
> browsers), very bad in aural UAs, and extremely bad in print.

The solution would have to also involve CSS cross-references, I agree.


On Wed, 12 Oct 2005, dolphinling wrote:
> 
> I agree that making sure the numbering is correct in legal documents 
> (and other documents that have the same type of structure) is 
> semantically important. I don't think that automatically generated 
> numbering is the way to do it, though.
> 
> In a legal document, as I understand it, the fact that something is 
> *Section 4* is important. Not that it's the fourth section, but that 
> it's *Section 4*. If section 3 is removed, section 4 stays *Section 4*. 
> (Because you'd need to update all the documents which reference it, 
> which would never be done.)
> 
> An ordered list isn't appropriate for that situation. An ordered list is 
> appropriate for the situation in which I have 5 things I need to do, in 
> order. When I realize that I don't need to do thing #2, I now have four 
> things I need to do, in order.
> 
> So I don't think legal documents is an appropriate reason to reintroduce 
> type=.

Interesting point.


On Wed, 12 Oct 2005, Simon Pieters wrote:
> > On Wed, 12 Oct 2005, James Graham wrote:
> > >
> > > <p>The correct answer is <ref target="#correct" />) All of the above</p>
> > >
> > > Getting a decent backwards compatibility story seems, uh, 
> > > non-trivial at the least. Of course this is true of CSS3 generated 
> > > content as well but that doesn't seem to bother people so much...
> > 
> > I like your idea. I don't know that there realy is a back-compat 
> > problem, we could just say that it accepts text content, so you could 
> > write:
> > 
> >    <p>The correct answer is <ref target="#correct">f</ref> All of the
> >    above</p>
> > 
> > ...until such time as enough browsers support <ref> that you don't 
> > worry anymore; since the answer number is (at least in this case) just 
> > additional information (the answer is given right there too) it isn't 
> > a huge problem if it is lost.
> 
> I don't think this is a good solution, simply because authors would 
> never use it. For instance, take any weblog with a quiz[1][2]; is it 
> really expected that the visitors should mark up their comments with 
> <ref>s?

Possibly not; but using type="" wouldn't save you either. What if the 
stylesheet changed the numbering style?


> That's an interesting view. Would it be more appropriate to use, for 
> instance,
> 
> # <ul>
> #  <li>(a) foo
> #  <li>(b) bar
> #  <li>(c) baz
> # </ul>
> 
> ...where the name of the item is more important than the order? If so, 
> that this satisfies my conserns. Thanks.

You could argue that. I suppose it is an unordered list. I'm not sure it's 
really a good idea though.

For legal text I could imagine using <section> and <p> instead of <ol>, 
though.

   <section>
    <p> 1. ...</p>
    <section>
     <p> 1.1. ...</p>

...etc.


On Wed, 12 Oct 2005, James Graham wrote:
> 
> Maybe not, but there's a large class of problems for which this would 
> provide a neat solution e.g. a scientific document ("fig. 15 shows the 
> results of the numerical calculations described in section 3"). For the 
> case you mention, putting the list item label in the content i.e.  
> <li>a) foo</li> is the only method that is sure to work. Indeed,if I 
> were pedantic, I could note that there is no intrinsic need for your 
> list items to be in a particular order and so <ul> is the appropriate 
> container element...

Yeah...


On Thu, 13 Oct 2005, Kornel Lesinski wrote:
> 
> That's another interesting use-case.
> 
> Maybe <ref /> should be implemented as CSS property? Then you could use 
> it like that:
> 
> img {counter: fig; counter-increment: fig;}
> ref {content: counter-of( attr(to), fig );}

Right. I think the HTML element is simply <a href>, but the CSS needs 
work.


On Thu, 13 Oct 2005, Mikko Rantalainen wrote:
> 
> In legal text, the ordering of sections may be important so it should 
> indeed be an ordered list (the order of list items is important) instead 
> of unordered list (the list may be reordered without changing the 
> meaning). The fact that list items inside <ol> have numbers or letters 
> before them is only the default rendering in many UAs.
> 
> However, if we decide that <ol> has indeed the meaning that the list 
> should be numbered instead of just meaning that *order* is important, 
> then forget everything I said.
> 
> > So I don't think legal documents is an appropriate reason to 
> > reintroduce type=.
> 
> I agree, type cannot describe the semantics needed to markup legal text. 
> I'm afraid that most use cases that ol element cannot handle cannot be 
> fixed with something as simple as type attribute. I wouldn't want to 
> repeat the mess known as <img alt> where the correct alternative content 
> would often require markup but the alt attribute can contain only plain 
> text.

Interesting arguments.


On Wed, 12 Oct 2005, James Graham wrote:
> 
> This is clearly useless for the reasons that everyone else has given. On 
> the other hand HTML /is/ lacking an elegant solution to the problem; 
> even if you introduce <ol type=""> or even number the list by hand you 
> still have to update the reference evrytime that a new item is added to 
> the list. The same applies to numbered sections, figures, etc. On the 
> other hand the majority of other tools (MS Word, LaTeX, (presumably) 
> most DTP programs, etc.) offer a convenient way to refer to a numbered 
> item elsewhere in the document. Syntatically this wouldn't be hard to 
> specify, something like:
> 
> <p>Quiz: Complete the sentence,"OpenDocument is ..."
> <ol>
> <li>An open, XML-based file format.</li>
> <li>An open standard, supported by the OASIS and ISO standards groups.</li>
> <li>The default file format for the upcoming OpenOffice.org 2.0 and
> KOffice 1.4.</li>
> <li>A top prospect for an official format for the European Commission.</li>
> <li>Our best chance to fight vendor lock-in associated with proprietary
> formats.</li>
> <li id="#correct">All of the above.</li>
> </p>
> 
> <p>The correct answer is <ref target="#correct" />) All of the above</p>
> 
> Rendering would be accoring to the CSS numbering scheme for the list 
> e.g. "The correct answer is f) All of the above"
> 
> However there are (at least) two difficulties:
> Implementation might be hard. But probably no harder than CSS3 generated
> content.
> 
> Getting a decent backwards compatibility story seems, uh, non-trivial at 
> the least. Of course this is true of CSS3 generated content as well but 
> that doesn't seem to bother people so much...

I would think <a href=""> would be the appropriate markup solution, but I 
agree that CSS would be needed to make it work in the rendering.


On Wed, 12 Oct 2005, Ian Hickson wrote:
> 
> I like your idea. I don't know that there realy is a back-compat 
> problem, we could just say that it accepts text content, so you could 
> write:
> 
>    <p>The correct answer is <ref target="#correct">f</ref> All of the 
>    above</p>
> 
> ...until such time as enough browsers support <ref> that you don't worry 
> anymore; since the answer number is (at least in this case) just 
> additional information (the answer is given right there too) it isn't a 
> huge problem if it is lost.

True. (Wait, am I replying to myself? Oh dear.)


> It would be nice to have an even better back-compat story, e.g. if it 
> worked in current browsers without JS, but I don't see anything that can 
> help us there (it's not like how <input type="number"> can fall back 
> onto type="text" in legacy UAs).
> 
> BTW I'd be tempted to suggest that the attribute on <ref> be for="" and 
> that it take an IDREF rather than a URI, to avoid any chance that people 
> might try to refer to things in other documents and expect it to work, 
> and also for consistency with <label for=""> and <output for=""> -- what 
> do you think?

Well, Past Ian, I think that's an interesting idea, but I would be tempted 
to use <a>, if at all possible. Though your point about URIs vs IDREFs 
certainly is a valid point.


On Thu, 13 Oct 2005, Lachlan Hunt wrote:
> 
> I like that too.  I was thinking something along the same lines when I 
> read the earlier posts in this thread, though (as you mentioned) I would 
> have used the for attribute as an IDREF instead.
> 
> I can, however, think of the following issues:
>
> 1. Can it only refer to a <li id="foo"> element?  Are there any
>    use-cases for allowing it to refer to other elements?
> 
> 2. What about <li>s in <ul> or non-<li> elements?  What value would be
>    used, or should it just use the fallback content?
> 
> 3. Assuming <ref> gets replaced with the value of the counter from the
>    target element, what happens if the counter has been removed with CSS
>    i.e. what's the default value?  Should it just use the fallback
>    content provided in such cases?

Good points.


> 4. Authors are likely to provide fallback content that is dependant upon
>    the presentation.  i.e. Your example used "f", but assuming no
>    type="a" attribute and no CSS, the list item's counter will probably
>    display "6." instead.
>    It's probably not a serious issue, since users may be smart enough to
>    work out that "f" is the 6th letter, and thus refers to the 6th item.

This argues for us not bothering to worry about any of this at all, 
frankly. Just use whatever numbering style you want, and people will work 
it out if the numbering style used doesn't match expectations.


On Thu, 13 Oct 2005, ROBO Design wrote:
>
> I was reading the thread and ... I was also thinking that the initial 
> suggestion of allowing the use of the TYPE attribute would not really 
> solve (all) the problems.
> 
> The suggestion with which James came up is really good, but the FOR 
> attribute should allow more than one IDs. Here's why: a quiz can have a 
> question which allows multiple answers. Yet, there are a few things open 
> to discussion if this would be done: such as displaying the answers (we 
> all know designers probably want various 'cool' ways to delimit each 
> answer et cetera).
> 
> If it will be decided to allow things such as <ref>s then I'd say: do it 
> all the way.

Ironically that's actually a reasonably good argument for not doing it at 
all!


On Thu, 13 Oct 2005, Lachlan Hunt wrote:
> 
> It could possibly be defined as IDREFS instead of IDREF, but what's 
> wrong with just using multiple ref elements?
> 
> e.g.
> <p>The answers are <ref id="foo">a</ref> and <ref id="bar">b</ref>.</p>
> 
> That would also be much more flexible for user agents to do something 
> with. For example, activating each ref element could highlight the 
> associated element in some way, or it could be activated like a link to 
> #foo and then be styled using the :target pseudo-class.  With multiple 
> IDs, such behaviour may not be so easy.

True.


On Wed, 12 Oct 2005, Kornel Lesinski wrote:
> 
> I like the idea, but I see some minor problems:
> 
> - user agents may need to stop progressive rendering if there is forward 
> reference (<ref /> before referenced list item).
> 
> - what if CSS markers/list-style are dynamically chaged (on hover or 
> using js)? Should references be changed realtime as well? As far as I 
> know there isn't any similar element in CSS, so engines may not be 
> prepared to support something like that.

These are (or would be) both CSS problems.


> - what should be done with references to non-existant ID? I think that 
> if fallback content is displayed in such case, it will lead to 
> hard-to-spot errors:
> 
> <ol><li id="foo" /></ol>
> See <ref to="f00">1</ref>.
> 
> In testing it will seem OK to author, but will break when list is 
> changed.

Very good point.


On Thu, 13 Oct 2005, Lachlan Hunt wrote:
> 
> A validator would issue an error: reference to non-existent ID, much 
> like what happens with <label for="FOO"/><input id="foo"/>

Also a very good point.


On Wed, 12 Oct 2005, dolphinling wrote:
> 
> [...] The point is that it's possible to have a document refer to a 
> specific way it's presented, but it's a bad idea to do so because that 
> presentation might change. In your example, the list could have been 
> ordered with numbers or capital letters with colons (i.e. "F:"), or 
> anything else and it would have had the same meaning. In mine, it could 
> have been blue and yellow (for colorblind people), or had a checkmark as 
> the list item, and again would have meant the same thing. In both cases, 
> and in every other similar case, it's the fact that the content referred 
> to the presentation that caused problems.

That seems like a good argument to me. I'm not sure everyone will agree, 
of course.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'