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

[Kristof Zelechovski]

Now that you have touched this topic, let me remind you of the problem of
parallel texts in multilingual documents, sort of (ill-formed)

horse Pferd
table Tisch


Of course, it is not appropriate for interleaved linguistic publications but
it is often used in legal documents.
AFAIK, there is no way to express it in HTML at present.  Nor in Microsoft
Word, at least without stepping over semantics (if we can talk about
semantics in Word documents at all).  I do not have current expertise with
other DPS.
Best regards,
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Friday, November 09, 2007 5:23 AM
To: WHAT WG List
Subject: Re: [whatwg] [HTML5] Named start values for lists?

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

[Ian Hickson]

(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:
> 
> 
>   Item 1
>   Item 2
>   Item 3
> 
> 
> 
>   Item 4
>   Item 5
>   Item 6
> 
> 
> 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.
>   
>   
> 
> * What does it mean if  references a ? 
> 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  
> or ?
> 
> * 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.
>   
>   
>   
> 
> * How are references duplicate IDs handled in this situation? (That 
> could probably be the same way  handles it)
> 
> * Which takes precedence out of  and  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  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
> 
> John's favorite fruit was rumoured to be bananas  source="banana_ref">. But this has never been proven.
> 
> 
>   Apples Reference Source
>   Bananas Reference Source
>   Oranges Reference Source
> 
> 
> 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.
> 
> 
>   Apples
>   Bananas
> 
> 
> 
>   Coconuts
>   Dates
>   Figs
> 

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:
> 
> Chores for today:
> 
> 
>   Clean living room
>   Clean bathroom
> 
> 
> When cleaning bathroom, make sure to get all the grout between the 
> shower tiles. Also, the sink needs to be scrubbed, too.
> 
> 
>   Sweep kitchen
>   Wash dishes
> 
> 
> Numbering would start at 1, and continue in source order (superseded, of 

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

[Thomas Broyer]

2007/11/8, Ian Hickson:
> On Mon, 26 Jun 2006, dolphinling wrote:
> >
> > HTML5 brings back the |start| attribute on ordered lists. This allows a
> > list to semantically start with a number other than one. It seems like
> > the major use case for this is to split lists up, so that a single list
> > is marked by multiple s.
> >
> > Would it therefore make sense to allow named start values, so that the
> > author doesn't have to go through and re-number everything when a new
> > item is added at the top? And if so, should they be considered
> > semantically one list? And if so, would it make sense for it to also
> > apply to unordered lists, so that they can be split up, too?
>
> I'm not sure we can put non-numeric values in start="", but I agree with
> your basic proposal. I'm not sure it makes sense for us to add it to HTML5
> at this time -- we have a number of semantic things already added to the
> spec and we don't want to get too far ahead of implementations otherwise
> they'll all start doing different parts and it'll take years to get a
> common subset implemented -- but I think it's something we should consider
> for a future version, certainly.

Semantics put aside (start="" is not really semantic, is it? or why
are counters part of CSS?), you can achieve this using a counter() in
CSS:


ol.mysplitlist1 {
  list-style: none;
}
body {
  counter-reset: mysplitlist1;
}
ol.mysplitlist1 > li:before {
  content: counter(mysplitlist1) ". ";
  counter-increment: mysplitlist1;
}


First item

...

Second item

...

See it in the Live DOM Viewer, tested working in Firefox 2, Opera
9.24, Safari 3.0.3, doesn't work in IE7:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%0A%20%20counter-reset%3A%20mysplitlist1%3B%0A%7D%0Aol.mysplitlist1%20%7B%0A%20%20list-style%3A%20none%3B%0A%7D%0Aol.mysplitlist1%20%3E%20li%3Abefore%20%7B%0A%20%20content%3A%20counter(mysplitlist1)%20%22.%20%22%3B%0A%20%20counter-increment%3A%20mysplitlist1%3B%0A%7D%0A%3C%2Fstyle%3E%0A%3Col%20class%3Dmysplitlist1%3E%0A%3Cli%3EFirst%20item%0A%3C%2Fol%3E%0A%3Cp%3E...%0A%3Col%20class%3Dmysplitlist1%3E%0A%3Cli%3ESecond%20item%0A%3C%2Fol%3E%0A%3Cp%3E...


IMO, the thing to consider for the HTML.next is to add semantic to
replace "the lists share the same class" with "the lists are part of
the same overall list"; for both UL and OL (and DL and DIALOG).

-- 
Thomas Broyer

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

[Ian Hickson]

On Mon, 26 Jun 2006, dolphinling wrote:
>
> HTML5 brings back the |start| attribute on ordered lists. This allows a 
> list to semantically start with a number other than one. It seems like 
> the major use case for this is to split lists up, so that a single list 
> is marked by multiple s.
> 
> Would it therefore make sense to allow named start values, so that the 
> author doesn't have to go through and re-number everything when a new 
> item is added at the top? And if so, should they be considered 
> semantically one list? And if so, would it make sense for it to also 
> apply to unordered lists, so that they can be split up, too?

I'm not sure we can put non-numeric values in start="", but I agree with 
your basic proposal. I'm not sure it makes sense for us to add it to HTML5 
at this time -- we have a number of semantic things already added to the 
spec and we don't want to get too far ahead of implementations otherwise 
they'll all start doing different parts and it'll take years to get a 
common subset implemented -- but I think it's something we should consider 
for a future version, certainly.

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

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

[dolphinling]

dolphinling wrote:
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.


I've mailed www-style (not with any ideas, just bringing it up). The 
thread should be named [CSS 3 counters] Dealing with  and 
 ?


However, my messages have a history of not going through there ( >:o ), 
so if it's not there in a day or so and no one else has started a 
thread, perhaps someone can forward it for me?




Subject: [CSS 3 counters] Dealing with  and  ?

The WHAT WG's WA1 draft brings back the start attribute on ordered lists 
and introduces a value attribute on individual list items, and semantic 
grouping of lists (saying two s are in fact one list) is being 
discussed. Unless I missed something in my (admittedly quick) reading, 
the Counters section in both CSS 2.1 and CSS 3 seems insufficient to 
deal with this.


I don't actually have any thoughts on how to solve it, but just wanted 
to make sure it didn't get lost in the void.


--
dolphinling



--
dolphinling

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

[dolphinling]

dolphinling wrote:
HTML5 brings back the |start| attribute on ordered lists. This allows a 
list to semantically start with a number other than one. It seems like 
the major use case for this is to split lists up, so that a single list 
is marked by multiple s.


Would it therefore make sense to allow named start values, so that the 
author doesn't have to go through and re-number everything when a new 
item is added at the top? And if so, should they be considered 
semantically one list? And if so, would it make sense for it to also 
apply to unordered lists, so that they can be split up, too?


Or would all that be an abuse, and something that's one list should use 
only one  ?


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:


Chores for today:


  Clean living room
  Clean bathroom


When cleaning bathroom, make sure to get all the grout between the 
shower tiles. Also, the sink needs to be scrubbed, too.



  Sweep kitchen
  Wash dishes


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.


--
dolphinling

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

[Lachlan Hunt]

James Graham wrote:

* Would implementations have difficulty with re-numbering list items in
linked lists, when a new  is dynamically inserted into a previous 

list?

I would hope not since that's one of the big attractions of this model.


Perhaps not so much for browsers that natively support it, but for a JS 
implementation designed for backwards compatibility in current browsers, 
it would have to listen for the the events like DOMNodeInserted, 
DOMNodeRemoved and DOMAttrModified (and possibly some others).  They'd 
be needed to handle all cases of list items or entire lists being 
inserted or removed, as well as changing values for the |start|, |value| 
and |continue| attributes for all  and  elements, and then 
update all linked lists appropriately.


That could get quite complex and complexity increases the chances of 
introducing bugs.  Besides, not all current browsers support those 
events, which would make a JS implementation quite limited.


--
Lachlan Hunt
http://lachy.id.au/

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

[Alexey Feldgendler]

On Wed, 28 Jun 2006 19:20:53 +0700, James Graham <[EMAIL PROTECTED]> wrote:


* Can it be defined and implemented in a way that avoids circular
references.  e.g.
  
  


The obvious choice is to use source order i.e. the ID must be defined  
before the continuation in the source, otherwise the attribute is  
ignored. I don't know how hard this would be to implement though.


This raises a number of issues when DOM is manipulated by a script. For  
example, what should happen if there is , and then a  
script inserts an  before that? Or the other way round? Or  
when they are dynamically reordered?


* Which takes precedence out of  and value="3">?



continue should take priority over start.


I'd rather say it should be the other way round. Here is a use case:


  Item 1
  Item 2

Here the writing becomes unreadable; however, I managed to decipher the  
end of the list:


  Item 9
  Item 10


There is a gap in numbering, but still the fragments of the list are  
linked together semantically.



--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

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

[Lachlan Hunt]

Henri Sivonen wrote:

On Jun 27, 2006, at 09:46, Lachlan Hunt wrote:


...



...


However, there are several issues that would need to be addressed:


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.


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.



  Apples
  Bananas



  Coconuts
  Dates
  Figs


--
Lachlan Hunt
http://lachy.id.au/

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

[James Graham]

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'm not sure it does...

> * 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?

IDREF. The other possibility is a nightmare.

> * Can it be defined and implemented in a way that avoids circular
> references.  e.g.
>   
>   

The obvious choice is to use source order i.e. the ID must be defined before the 
continuation in the source, otherwise the attribute is ignored. I don't know how 
hard this would be to implement though.


> * What does it mean if  references a ?
> Should it only be able to link lists of the same type?  (i.e. ol with
> another ol and ul with another ul)

Pragmatically, there is little need for this to work at-all with .

> * What does it mean if it references any other element that isn't a 
> or ?

The continue attribute should be ignored.

> * What should happen if it references a non-existent element?

The continue attribute should be ignored.

> * What does it mean if two lists continue from the same previous list?
> e.g.
>   
>   
>   

That's fine. They both continue from the last value of the list they reference. 
(I can imagine cases where this would be right e.g. a list of instructions for a 
recipe with two variations at the end).


> * How are references duplicate IDs handled in this situation? (That
> could probably be the same way  handles it)
>
> * Which takes precedence out of  and  value="3">?

continue should take priority over start.

> * Backwards compatibility is also an issue, though it could possibly be
> handled with some JavaScript that dynamically calculates and sets the
> start attribute.

There's not really a backwards compatibility problem here -anybody who cares can 
easily implement this in js.


> * Would implementations have difficulty with re-numbering list items in
> linked lists, when a new  is dynamically inserted into a previous list?

I would hope not since that's one of the big attractions of this model.

> * How does it interact with CSS counters.

Good question; don't know. CSS counters seem to have the undesirable property of 
taking content and putting it in the presentation layer.


--
"You see stars that clear have been dead for years
But the idea just lives on..." -- Bright Eyes

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

[Henri Sivonen]

On Jun 27, 2006, at 09:46, Lachlan Hunt wrote:

I recall similar suggestions made on www-html in the past.   
Something like this could be useful:



  Item 1
  Item 2
  Item 3



  Item 4
  Item 5
  Item 6


However, there are several issues that would need to be addressed:


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.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

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

[Ric Hardacre]

Lachlan Hunt wrote:
> dolphinling wrote:
>> HTML5 brings back the |start| attribute on ordered lists. This allows
>> a list to semantically start with a number other than one. It seems
>> like the major use case for this is to split lists up, so that a
>> single list is marked by multiple s.
> 
> Other use cases include the ability to include an excerpt from another
> list in a page while retaining the list item indexes, or breaking a long
> list across several pages.
> 

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

John's favorite fruit was rumoured to be bananas . But this has never been proven.


Apples Reference Source
Bananas Reference Source
Oranges Reference Source


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.



Ric Hardacre
http://www.cyclomedia.co.uk/

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

[dolphinling]

Lachlan Hunt wrote:

dolphinling wrote:
HTML5 brings back the |start| attribute on ordered lists. This allows 
a list to semantically start with a number other than one. It seems 
like the major use case for this is to split lists up, so that a 
single list is marked by multiple s.


Other use cases include the ability to include an excerpt from another 
list in a page while retaining the list item indexes, or breaking a long 
list across several pages.


e.g. Search results with 10 results per page could be marked up as a 
list:  on the first page,  on the second 
page, etc.


Would it therefore make sense to allow named start values, so that the 
author doesn't have to go through and re-number everything when a new 
item is added at the top? And if so, should they be considered 
semantically one list? And if so, would it make sense for it to also 
apply to unordered lists, so that they can be split up, too?


I recall similar suggestions made on www-html in the past.  Something 
like this could be useful:



  Item 1
  Item 2
  Item 3



  Item 4
  Item 5
  Item 6


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.

  
  

* What does it mean if it references any other element that isn't a  
or ?


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

  
  
  

* How are references duplicate IDs handled in this situation? (That 
could probably be the same way  handles it)


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.


* Which takes precedence out of  and value="3">?


* What does it mean if  references a ? 
Should it only be able to link lists of the same type?  (i.e. ol with 
another ol and ul with another ul)


* 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  is dynamically inserted into a previous list?


I noticed you didn't answer my question about whether that would be an 
abuse of the language, and lists shouldn't be split up like that. :)


--
dolphinling

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

[Anne van Kesteren]

Quoting Lachlan Hunt <[EMAIL PROTECTED]>:

However, there are several issues that would need to be addressed:

[List of good points]


* How does it interact with CSS counters.


--
Anne van Kesteren

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

[Lachlan Hunt]

dolphinling wrote:
HTML5 brings back the |start| attribute on ordered lists. This allows a 
list to semantically start with a number other than one. It seems like 
the major use case for this is to split lists up, so that a single list 
is marked by multiple s.


Other use cases include the ability to include an excerpt from another 
list in a page while retaining the list item indexes, or breaking a long 
list across several pages.


e.g. Search results with 10 results per page could be marked up as a 
list:  on the first page,  on the second 
page, etc.


Would it therefore make sense to allow named start values, so that the 
author doesn't have to go through and re-number everything when a new 
item is added at the top? And if so, should they be considered 
semantically one list? And if so, would it make sense for it to also 
apply to unordered lists, so that they can be split up, too?


I recall similar suggestions made on www-html in the past.  Something 
like this could be useful:



  Item 1
  Item 2
  Item 3



  Item 4
  Item 5
  Item 6


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.

  
  

* What does it mean if  references a ? 
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  
or ?


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

* How are references duplicate IDs handled in this situation? (That 
could probably be the same way  handles it)


* Which takes precedence out of  and 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  is dynamically inserted into a previous list?


--
Lachlan Hunt
http://lachy.id.au/

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

[dolphinling]

HTML5 brings back the |start| attribute on ordered lists. This allows a 
list to semantically start with a number other than one. It seems like 
the major use case for this is to split lists up, so that a single list 
is marked by multiple s.


Would it therefore make sense to allow named start values, so that the 
author doesn't have to go through and re-number everything when a new 
item is added at the top? And if so, should they be considered 
semantically one list? And if so, would it make sense for it to also 
apply to unordered lists, so that they can be split up, too?


Or would all that be an abuse, and something that's one list should use 
only one  ?


--
dolphinling