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.
> <ol id="part1" continue="part2"/>
> <ol id="part2" continue="part1"/>
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 <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)
Pragmatically, there is little need for this to work at-all with <ul>.
> * What does it mean if it references any other element that isn't a <ul>
> or <ol>?
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.
> <ol id="part1" continue="part2"/>
> <ol id="part2" continue="part1"/>
> <ol id="part3" continue="part1"/>
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 <label for=""> handles it)
>
> * Which takes precedence out of <ol continue="part1" start="2"> and <li
> 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 <li> 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
