W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2007

[whatwg] [HTML5] Named start values for lists?

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 9 Nov 2007 04:22:35 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0711080248300.30809@hixie.dreamhostps.com>

(Continuing the feedback on e-mail on this thread. See earlier message 
for my take on this thread's suggestions.)

On Tue, 27 Jun 2006, Lachlan Hunt wrote:
> 
> I recall similar suggestions made on www-html in the past.  Something like
> this could be useful:
> 
> <ol id="part1">
>   <li>Item 1</li>
>   <li>Item 2</li>
>   <li>Item 3</li>
> </ol>
> 
> <ol id="part2" continue="part1">
>   <li>Item 4</li>
>   <li>Item 5</li>
>   <li>Item 6</li>
> </ol>
> 
> However, there are several issues that would need to be addressed:
> 
> * Should |continue| be an IDREF that can only continue a previous list 
> in the same page, or should it be a URI that can continue lists from 
> other pages?
> 
> * Can it be defined and implemented in a way that avoids circular 
> references. e.g.
>   <ol id="part1" continue="part2"/>
>   <ol id="part2" continue="part1"/>
> 
> * What does it mean if <ol contine="foo"> references a <ul id="foo">? 
> Should it only be able to link lists of the same type?  (i.e. ol with 
> another ol and ul with another ul)
> 
> * What does it mean if it references any other element that isn't a <ul> 
> or <ol>?
> 
> * What should happen if it references a non-existent element?
> 
> * What does it mean if two lists continue from the same previous list?  
> e.g.
>   <ol id="part1" continue="part2"/>
>   <ol id="part2" continue="part1"/>
>   <ol id="part3" continue="part1"/>
> 
> * How are references duplicate IDs handled in this situation? (That 
> could probably be the same way <label for=""> handles it)
> 
> * Which takes precedence out of <ol continue="part1" start="2"> and <li
> value="3">?
> 
> * Backwards compatibility is also an issue, though it could possibly be 
> handled with some JavaScript that dynamically calculates and sets the 
> start attribute.
> 
> * Would implementations have difficulty with re-numbering list items in 
> linked lists, when a new <li> is dynamically inserted into a previous 
> list?

On Tue, 27 Jun 2006, Anne van Kesteren wrote:
> 
> * How does it interact with CSS counters.

All very good points.


On Tue, 27 Jun 2006, dolphinling wrote:
> 
> The simpler named start values that I was thinking of would avoid all 
> that. It wouldn't be tied to any other element's ID, multiple ones with 
> the same name would simply continue the list, one after the other, and 
> an unknown name would start a new list, at one.
> 
> It would also be less powerful: you couldn't rearrange a list, so the 
> later parts were higher in source order, and you couldn't start a named 
> list at a value other than one.

That's a very interesting idea, yes. It does indeed address many problems.


On Wed, 28 Jun 2006, Ric Hardacre wrote:
> 
> It would also be good if the simple number element that has been 
> discussed over the past few weeks could reference a list item, something 
> similar to
> 
> <p>John's favorite fruit was rumoured to be bananas <sup><n 
> source="banana_ref"></n></pre>. But this has never been proven.</p>
> 
> <ol>
> 	<li>Apples Reference Source</li>
> 	<li id="banana_ref">Bananas Reference Source</li>
> 	<li>Oranges Reference Source</li>
> </ol>
> 
> At the mo this would equate to 2, but if another footnote reference were 
> added below Apples then it would automagically allow the citation to 
> change to 3.
> 
> If you also wanted the reference to be an anchor (see wikipedia) then 
> that might make things more complex, however, as you'd need a banana_ref 
> for the number and an anchor named "banana_anc", perhaps.

Right, that's similar to the earlier proposals.


On Wed, 28 Jun 2006, Henri Sivonen wrote:
> 
> Hopefully, the issue list adequately demonstrates that the continue 
> attribute is way too complicated considering that the old start 
> attribute solves the numbering problem in a very pragmatic way.

I think on the long run we probably do want a way to link lists together. 
But I agree that it should be ok for now to just use start="".


On Wed, 28 Jun 2006, Lachlan Hunt wrote:
> 
> The start and value attributes certainly do solve the majority of the 
> use cases.  They don't semantically link the lists together and they 
> place the responsibility of calculating the starting values upon the 
> authoring/publishing system, rather than the browser.
> 
> What are the specific use cases that require the lists to be 
> semantically linked?  If there are any, could they be addressed using a 
> microformats approach?
> 
> e.g.  Lists with class="split-list" (or any other class name) that share 
> the same title could be defined by a microformat to be linked lists. 
> Perhaps, the class name isn't even required, the matching titles could 
> be sufficient.
> 
> <ol class="split-list" title="Fruit">
>   <li>Apples</li>
>   <li>Bananas<li>
> </ol>
> 
> <ol class="split-list" title="Fruit" start="3">
>   <li>Coconuts</li>
>   <li>Dates</li>
>   <li>Figs</li>
> </ol>

That would be a good start to seeing how dire the need is.


On Thu, 29 Jun 2006, dolphinling wrote:
> 
> I've thought a bit more, and *assuming semantically linked, 
> automatically numbered split lists should be allowed* (which so far only 
> one other person has even touched on!), I think the best solution would 
> be something like the following:
> 
> <p>Chores for today:</p>
> 
> <ol listname="chores">
>   <li>Clean living room</li>
>   <li>Clean bathroom</li>
> </ol>
> 
> <p>When cleaning bathroom, make sure to get all the grout between the 
> shower tiles. Also, the sink needs to be scrubbed, too.</p>
> 
> <ol listname="chores">
>   <li>Sweep kitchen</li>
>   <li>Wash dishes</li>
> </ol>
> 
> Numbering would start at 1, and continue in source order (superseded, of 
> course, by any start= or value= attributes).
> 
> This gives the author the power to number however they want, while being 
> much less complex spec- and implementation-wise. A few cases where a 
> list is not only split, but the sections are rearranged on the page, 
> require the author to fall back on start=, but since it doesn't actually 
> remove any functionality, I think that's an acceptable tradeoff.
> 
> As for how this would interact with CSS Counters... It appears counters 
> in CSS 3 are insufficient even to handle the already-in-spec start= and 
> value= attributes. That should probably be taken up with the CSS WG.

Good points.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 8 November 2007 20:22:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:42 GMT