- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 26 Feb 2008 04:29:19 +0000 (UTC)
- To: whatwg@whatwg.org, public-html@w3.org
- Message-ID: <Pine.LNX.4.62.0802221033160.6407@hixie.dreamhostps.com>
This e-mail is a reply to all the pending feedback related to lists in
HTML5. It covers an array of subjects and contains replies to e-mails from
around forty different people, all of whom are bcc'ed, across two mailing
lists. When replying please select a single mailing list to reply to, and
trim any text you quote to just the relevant parts.
Executive summary:
* Clarified the meaning of <ol>, <ul>, <dl>.
* Added examples.
* Tentatively added <ol reversed> to make reverse lists. We'll remove it
if browser vendors don't like it.
On Wed, 4 Oct 2006, Simon Pieters wrote:
>
> I think the current definition of <ol>[1] seems slightly too vauge:
>
> The ol element represents an ordered list of items (which are
> represented by li elements).
>
> I think <ol> is a list where the order is significant to the meaning;
> where the order is emphasized. For lists that happen to be ordered but
> the order isn't really of a big significance or isn't of higher
> significance than the global order of the document, <ol> shouldn't be
> used IMHO.
>
> In essence, I want the definition in HTML5 be more like the spirit in
> HTML4[2]:
>
> An ordered list, created using the OL element, should contain information
> where order should be emphasized, as in a recipe: [...]
>
> Otherwise people might use <ol> whenever a list happens to be in order,
> e.g. an A-Z list...
That makes sense I guess... Ok, updated.
> ...or a dialogue.
>
> Which brings us to the next point: dialogue. The spec contains an
> example[3] which suggests that <ol> is appropriate for dialogue. I'm not
> convinced that it is. What makes a dialogue a list? While the order of
> dialogue is important, so is the order of any other paragraphs -- I
> don't think it should be emphasized in particular. I think I'd mark up
> the dialogue like this:
>
> <p> <cite>Costello</cite>
> <q> Look, you gotta first baseman? </q>
> <p> <cite>Abbott</cite>
> <q> Certainly. </q>
> ...
>
> Or, perhaps like this (in XHTML5):
>
> <p> <cite>Costello</cite>
> <blockquote> <p> Look, you gotta first baseman? </p> </blockquote> </p>
> <p> <cite>Abbott</cite>
> <blockquote> <p> Certainly. </p> </blockquote> </p>
> ...
<dialog> now covers this.
On Mon, 23 Oct 2006, Henri Sivonen wrote:
>
> HTML+ used <dl> for dialog. As far as default presentation goes, <dl> is
> the best fit for marking up dialog. Yet, the semantic markup party line
> is against it.
>
> I think there are two reasons for insisting that <dl> shouldn't be used
> for dialogs, i.e. that <dl> really is a definition list rather than a
> generic presentational grouping device:
>
> 1) Saving face after years of such insistence.
> 2) Avoiding breaking software that collects term definitions from <dl>s.
>
> I am not a fan of #1-style reasoning. My guess is that case #2 is
> already broken on the real Web.
>
> Is there a good reason for not prescribing <dl> for dialogs?
There is now that we have <dialog>... :-)
On Mon, 23 Oct 2006, Mikko Rantalainen wrote:
>
> I don't think that it's worth the trouble to declare dl element to be
> unordered (http://www.whatwg.org/specs/web-apps/current-work/#the-dl).
> As I see it, it's only to rationalize the #1-style above.
Well, once you get rid of dialog from <dl>, there really isn't a reason
for it to be ordered... except when you're using <dl> as a "switch
statement"-type construction, I guess, which HTML5 does a lot... Hmm. I've
updated the spec to handle this.
> Jukka Korpela has written a somewhat complete article about marking up
> definitions as http://www.cs.tut.fi/~jkorpela/def.html and possible
> markup is presented at http://www.cs.tut.fi/~jkorpela/def.html#markup
>
> The dl element as we know it today is nowhere powerful enough to express
> much more than a simple entry with two parts. I think it would be wise
> to document the real world usage of dl element and *if* we want a
> specific markup for definitions, we can define something better.
Isn't that what we have now?
On Thu, 8 Feb 2007, Jorgen Horstink wrote:
> On Feb 8, 2007, at 9:00 PM, David Latapie wrote:
> > On Thu, 8 Feb 2007 19:17:32 +0000, Nicholas Shanks wrote:
> > > On 6 Feb 2007, at 07:57, Karl Dubost wrote:
> > >
> > > > > unlikely. "div" and "span" elements didn't exist in HTML+.
> > > >
> > > > http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
> > >
> > > Ironically I was just reading that earlier today, then saw your
> > > post! (I hadn't been reading this thread.)
> > >
> > > I wish the <image>fallback</image> tags had made it through the
> > > years. It's so much better than <img alt="blah"> and doesn't suffer
> > > from the self-closing-tag-in-html problem.
> >
> > HTML 3.0 too had some great ideas. I'm still missing
> > - FN (but CSS3 has something about footnote that may fix this)
> > - LH (caption for list! A must-have)
>
> Why not using the title attribute?
Actually with <figure> the <lh> element is now better handled using
<figure> and <legend>.
On Thu, 8 Feb 2007, David Latapie wrote:
>
> On Thu, 8 Feb 2007 21:07:49 +0100, Jorgen Horstink wrote:
> >> - LH (caption for list! A must-have)
> > Why not using the title attribute?
>
> Do you mean <ul title="foo"> <ol title="foo"> ?
That would different, I think.
On Fri, 9 Feb 2007, Charles McCathieNevile wrote:
> On Fri, 09 Feb 2007 02:55:51 +0530, David Latapie <david@empyree.org>
> wrote:
>
> > On Thu, 8 Feb 2007 21:07:49 +0100, Jorgen Horstink wrote:
> >>> - LH (caption for list! A must-have)
> >> Why not using the title attribute?
> >
> > Do you mean <ul title="foo"> <ol title="foo"> ?
>
> attribute values suck as a way of encoding text that should be
> presented. They don't do i18n well, it is impossible to
> highlight/emphasise/denote the importance of some part of the text, etc
> etc.
That too.
On Fri, 9 Feb 2007, David Latapie wrote:
>
> We agree. That is why, out of <div>-ing a list and the previous
> paragraph (which is not a real solution), I don't see any way to
> semantically attach a “caption” to a list, particularly an ordered
> one.
<figure>
<legend> Caption... <legend>
<ol>
<li>...
</ol>
</figure>
(I snipped a number of e-mails here about this topic. If anyone sent
feedback asking for <lh> and isn't happy with <figure> as a solution,
please send further feedback explaining which cases <figure> doesn't
handle. Thanks!)
On Tue, 13 Feb 2007, Michel Fortin wrote:
>
> Image+description should be covered by <figure>, although its current
> restrictions are pretty limitative in my opinion.
Let me know if the recent changes didn't fix this.
On Fri, 9 Feb 2007, Michel Fortin wrote:
>
> The WHATWG spec formalises term/description groups as I said -- starting
> with a <dd> or ending with a <dt> is non-conformant. But the new spec
> certainly could be more explicit about what happens to non-conformant
> lists starting with <dd> or ending with <dt>.
>
> <http://www.whatwg.org/specs/web-apps/current-work/#the-dl>
I've added a couple of sentences to cover that.
On Sat, 10 Feb 2007, David Latapie wrote:
>
> Are you sure?
>
> <dl>
> <dd>How do you call a technically brilliant but socially inept
> person?</dd>
> <dt>A nerd</dt>
> </dt>
Right now this would be a name-value list with two name-value pairs, the
first having a value but not name, and the second have a name but no
value. While the markup in this example is subtly clever it's still wrong.
At least according to the spec. :-)
On Tue, 13 Feb 2007, David Latapie wrote:
>
> A definition list (<dl>) provides a relationship between an important
> element (<dt>) and a less-important one (<dd>). One might argue the 1:1
> ratio is not necessary; One can think of two <dt> for one <dd> or, more
> often, one <dt> and, say, three <dd>.
>
> In a table, the same relation exists between <th> and <td>. Also, both
> <dl> and <table> are block elements (which, IMHO, doesn't matter when we
> talk of semantics).
>
> There is not a mere redundancy here: <table> is able to represent more
> complex relations than <dl> can
> • <caption> has no equivalent in <dl> (LH didn't made it in HTML 3.0)
> • <dl> may only have one relationship (<dt> to <dd>, even with multiple
> <dt>/<dd>) whereas <table> may have two (maybe more, but I am not sure)
Indeed. Similarly, <dl> can depict things that <table> cannot (e.g. with
varying numbers of <dt>s and <dd>s). Also, <ol> is equivalent to a
one-column <table>.
This can't be expressed using a table (at least not in any way that
clearly indicates the relationship between the cells):
<dl>
<dt> 1
<dd> a
<dt> 20
<dt> 21
<dd> b
<dd> bb
<dd> bbb
<dt> 3
<dd> c
</dl>
> Oh, one more thing: we used to bash tables, because they were used for
> layout instead of pure “tabular data” (layout table vs. Excel-like
> tables) but I think there is a “gray zone” inbetween that is
> currently addressed by <dl>. And everything <dl> does, table can do it
> better on a semantic point of view.
<table> certainly has its uses.
On Mon, 5 Mar 2007, Simon Pieters wrote:
>
> I think it should be made clear in HTML5 that multiple <dd>s (and <dt>s
> for that matter) are alternatives and not accumulative. Otherwise people
> might use "<dd>...<dd>..." instead of "<dd><p>...<p>..." when they
> wanted to represent accumulative paragraphs of one description and not
> several alternative descriptions.
Done.
On Wed, 14 Mar 2007, Anne van Kesteren wrote:
>
> The most common use case for href="" on every element seems to be about
> removing lots of characters when creating a navigation menu or a blog roll or
> similar list. So instead of typing
>
> <ul>
> <li><a href="">test</a>
> ...
>
> you would type
>
> <ul>
> <li href="">test
> ...
>
> Maybe we can change the content model of <ul> (and perhaps <ol>) to allow a
> series of <a> elements:
>
> <ul>
> <a href="">test</a>
> ...
>
> For backwards compatibility text content would be allowed inside <ul>
> but must be ignored for the purposes of determining the semantics of the
> content (in a conforming HTML5 UA). This would allow:
>
> <ul>
> <a href="">test</a> |
> <a href="">test</a> |
> ...
>
> Alternatively <nav> could be redefined to have this type of semantics
> when its content model is just <a> elements and text content.
How is <nav> today not already this?
On Fri, 30 Mar 2007, Tim Connor wrote:
>
> <ol>
> <lh>A list on stuff</lh>
> <li>I, Item</li>
> <li>
> <ol>
> <lh>Item, the God</lh>
> <li>Plot synopsis</li>
> <li>Characters</li>
> <li>Stunning conclusion</li>
> </ol>
> </li>
> </ol>
<figure>
<legend>A list on stuff</legend>
<ol>
<li>I, Item
<li>
<figure>
<legend>Item, the God</legend>
<ol>
<li>Plot synopsis
<li>Character
<li>Stunning conclusion
</ol>
</figure>
</ol>
</figure>
On Sat, 31 Mar 2007, Simon Pieters wrote:
>
> How is this better than the following?:
>
> <h1>A list on stuff</h1>
> <ol>
> <li>I, Item</li>
> <li>Item, the God
> <ol>
> <li>Plot synopsis</li>
> <li>Characters</li>
> <li>Stunning conclusion</li>
> </ol>
> </li>
> </ol>
That would be fine too...
On Fri, 30 Mar 2007, Robert Brodrecht wrote:
>
> A <lh> (same as a caption to a table) would be semantically connected to
> the list. That is better semantics than an header tied to "everything
> before the next heading". Furthermore, I need to front load lists and
> not have them tied to a heading or paragraph (e.g. navigation lists).
Does the <figure> case handle this?
> And, according to the example, it'd be more like (sorry don't have the
> original right now):
>
> <h1>A list on stuff</h1>
> <ol>
> <li>I, Item</li>
> <li><h2>Item, the God</h2>
> <ol>
> <li>Plot synopsis</li>
> <li>Characters</li>
> <li>Stunning conclusion</li>
> </ol>
> </li>
> </ol>
>
> That isn't as clean as the example originally provided using <lh>.
Why not?
On Tue, 3 Apr 2007, Tim Connor wrote:
>
> As I see, there is no way to do this (my more complex variation on your
> example), properly, correct? I intentionally threw in a mish-mash of
> ways of doing it, so there is more to work with - flattened, as you did,
> lh's and hn's. We are just supposed to flatten all lists?
>
> <h1>Car and Bicycle Brands</h1>
> <ul>
> <lh>Car</lh>
> <li>Nissan</li>
> <li>Jaguar</li>
> </ul>
> <h2>Bicycle</h2>
> <ul>
> <li><h3>Road Bikes</h3></li>
> <li>
> <ul>
> <li>Raleigh</li>
> <li>Scott</li>
> </ul>
> </li>
> <li>
> <ul>
> <lh>Mountain Bikes</lh>
> <li>Specialized</li>
> </ul>
> </li>
> </ul>
I'd move the <lh> up one level in those examples (to before their <ul>
elements) and use <hx> or <p> at that level.
On Tue, 3 Apr 2007, Spartanicus wrote:
>
> <h1>Car and Bicycle Brands</h1>
> <ul>Car
> <li>Nissan</li>
> <li>Jaguar</li>
> </ul>
> <h2>Bicycle</h2>
> <ul>
> <li><h3>Road Bikes</h3>
> <ul>
> <li>Raleigh</li>
> <li>Scott</li>
> </ul></li>
> <li><h3>Mountain Bikes</h3>
> <ul>
> <li>Specialized</li>
> </ul></li>
> </ul>
Indeed.
On Tue, 3 Apr 2007, Tim Connor wrote:
>
> Can we please have SOME method of strictly, explicitly semantically
> associating headings within lists. Wether it's bringing back a
> deprecated element, or defining li/lu/ol as sectioning elements, or some
> other way, I don't really care. I'm okay with the current usage of a hn
> within a list - heck, we're all pretty practiced at styling that by now
> ;). I'm just confirming that there is no specified semantic tie,
> currently, and asking if that is set in stone.
Does <figure> handle this?
On Tue, 3 Apr 2007, Kristof Zelechovski wrote:
>
> Explicitly semantically: use DD for header, DT as a wrapper for items.
> It means that a top-level list with a header must be wrapped in a DL for
> completeness.
>
> <dl>
> <dt>Sample Menu</dt>
> <dd>
> <dl>
> <dt>File</dt>
> <dd>
> <ul>
> <li>New</li>
> <li>Open</li>
> <li>Save</li>
> <li>Properties</li>
> <li>Close</li>
> <li>Quit</li>
> </ul>
> </dd>
> <dt>Edit</dt>
> <dd>
> <ul>
> <li>Cut</li>
> <li>Copy</li>
> <li>Paste</li>
> <li>Clear</li>
> <li>Show Clipboard</li>
> </ul>
> </dd>
> <dt>Help</dt>
> <dd>
> <ul>
> <li>About</li>
> <li>Contents</li>
> <li>Index</li>
> <li>Search</li>
> </ul>
> </dd>
> </dl>
> </dd>
> </dl>
Yeah, that works too.
On Fri, 30 Mar 2007, Robert Brodrecht wrote:
>
> Front loading can make sense with decent writing, but there are cases
> like navigation lists where saying "this is a navigation list" without
> extra elements floating around outside of the list would be very very
> helpful when trying to work with accessible designs.
<nav>
<ul>
<li>...
</ul>
</nav>
On Thu, 5 Apr 2007, Michel Fortin wrote:
>
> Following the discussion about the limitations of <dialog>, I meditated
> about it a little and came up with the idea to generalize things a
> little more.
>
> When we have a dialog intermixed with actions and other events (like
> "ABC leaves the chat room"), basically we have a sequential list of
> events, actions and spoken parts. And in my later example, the Canadian
> Parliament hansard, they're intermixed with timestamps at regular
> intervals and other notes regarding live translations. Again, this fits
> very well the concept of a list of different kinds of intermixed
> sequential events.
>
> So I propose a <sl> element (sequential list) which can be used to
> replace <dialog> as well as other things. The proposal can be found
> here:
>
> <http://www.michelf.com/documents/whatwg/timeline/>
>
> Basically, <dt> and <dd> work just like they do in <dialog> currently,
> except that you can have more than one <dd> following a <dt>. <li> is
> used for listing events other than speech and <time> is used to insert
> time marks where appropriate. And you don't need to have any spoken
> part, meaning you can use it for system logs, or historical timelines
> too by using only <li> and <time>.
Is there really a need for this?
On Thu, 5 Apr 2007, Simon Pieters wrote:
>
> It seems to me like a sequential list with only <li> and <time> seems
> very much like <ol>, so why not use <ol> for such cases? Authors have
> hard enough time to choose between the various abstract list elements
> already, let's not introduce more of them. :-)
Indeed.
On Thu, 3 May 2007, Thomas Broyer wrote:
>
> In <http://www.whatwg.org/specs/web-apps/current-work/#value> :
> The value attribute, if present, must be a valid integer giving the
> ordinal value of the first list item.
>
> Shouldn't it be "the ordinal value of the list item" instead of "the
> first list item"?
Fixed, thanks.
On Fri, 11 May 2007, Simon Pieters quoted Tommy Olsson as saying:
>
> They changed the semantics of DL from definition list to some kind of
> generic value pair list. For instance, they say that DL can be used for
> markup up dialogues. How will that affect an application that has relied
> on that a DL is a definition list? One example is the DEFINE: feature in
> Google.
>
> In my opinion it would have been considerably much better if they let DL
> continue be a definition list and instead added a new element type for
> value pair lists. Although I suspect that Microsoft was holding it back
> in that respect, by not wanting to put any work into development of IE.
> (This was before Firefox's successes forced them to do so anyway.)
<dfn> is still unambiguously the way to mark the terms in definitions;
used with <dl> (which can no longer be used for dialog) it handles
definitions fine in HTML5, as far as I can tell.
> But the web doesn't just about browsers.
Sure, but browsers are the main access point, so they should be given the
most attention.
Consider motorways. Cars are the main concern of motorways, so motorways
are optimised for cars. Sure, occasionally a plane will use a motorway as
a makeshift runway, but we shouldn't design motorways with that as the
primary use case. Now if cars went out of fashion, and planes were the
only use case for motorways any more, then that would change.
Right now, and frankly for the forseeable future, browsers are and will
remain the main way in which users interact with the Web. We have to
therefore optimise the language with them in mind.
> > From that point of view it doesn't really matter how <p> is defined in
> > the spec -- it doesn't change reality
>
> No, I think it matters a lot. For those who don't read the spec (i.e.
> 99.999%) it obviously has no significanse at all, but there has to be an
> unambigous semantic definition for each element type for the little
> minority who actually want to do things right.
If we assume there are half a billion Web authors, 99.9999% means that
only 500 people will read the spec. There are more than 500 people
subscribed to the WHATWG mailing list. :-)
On Sat, 26 May 2007, Sander wrote, continuing the perenial <di> debate:
> >
> > It's the same reason that we have optional tags, like </p> and </li>
> > -- there's no need to be verbose, only unambiguous.
>
> So <html>, </html>, <header>, </header> and </body> can all become
> deprecated then?
<html>, </html>, <head>, </head>, and <body> are already optional.
> But you insist: </di> could be optional as well ;-)
I just don't see the point of adding it.
> > I don't see how the current DOM isn't "well defined", nor can I see
> > why adding more redundant elements that don't clarify the disambiguate
> > the meaning at all is the "best way". In fact, <di> would only
> > introduce more ways for authors to get it wrong, IMHO.
>
> Maybe I don't always choose the best words as english is not my native
> language.
>
> As for the argument of authors getting it wrong... making things more
> explicit will probably only make it easier to comprehend.
I'm not convinced.
On Sat, 26 May 2007, liorean wrote:
>
> I remember making an argument for this way back when XHTML2 still
> looked like it could be the future for HTML...
>
> <uri:http://lists.w3.org/Archives/Public/www-html/2002Oct/0009.html>
The difference between <section> and <di> is that <section> allows us to
automatically determine the level of the headers without having to
hardcode them using <h1>-<h6>. With <di>, though, we don't actually gain
anything. It's no easier to copy/paste markup, it's no less ambiguous,
etc. Indeed, it just makes things more complex.
> Say you have something like a Skype conversation log, which conceptually
> looks about like this:
>
> <chatlog>
> <item>
> <poster>joe</poster>
> <item>
> <time>yyyy-mm-dd hh:mm</time>
> <message>Blah</message>
> </item>
> <item>
> <time>yyyy-mm-dd hh:mm</time>
> <message>Bleh!</message>
> </item>
> </item>
> <item>
> <poster>jane</poster>
> <item>
> <time>yyyy-mm-dd hh:mm</time>
> <message>SO true!!!!1111!1!11!!!1one!one1eleven</message>
> <item>
> </item>
> </chatlog>
>
> But at the same time, you might want to support another chat log that
> only inserts time stamps at certain intervals, like every five minutes
> or so, but inserts attribution on every item...
>
> <chatlog>
> <item>
> <time>yyyy-mm-dd hh:mm</time>
> <item>
> <poster>joe</poster>
> <message>Blah</message>
> </item>
> <item>
> <poster>joe</poster>
> <message>Bleh!</message>
> </item>
> </messages>
> <messages>
> <time>fifteen minutes later</time>
> <item>
> <poster>jane</poster>
> <message>SO true!!!!1111!1!11!!!1one!one1eleven</message>
> </item>
> </messages>
> </chatlog>
>
> The way I'd turn something like that into definition lists today
> involves nesting lists in definition data. I'd like the definition item
> for getting rid of the extraneous elements. For some cases the timestams
> and posters could be consecutive definition terms, and the messages
> consecutive definition datas, but there is no way to make one definition
> term span several couples of term-data couples of elements, which is
> needed for representing these example cases.
Use <dialog>. :-)
On Tue, 21 Aug 2007, Geoffrey Sneddon wrote:
>
> The definition for |ol| and |ul| says that they represent an "ordered
> list of items" and an "unordered list of items". It doesn't say in what
> way they are ordered. Should the definition be refined to something like
> "A list where the order of the items has meaning."?
I've updated the spec to somewhat say that.
On Thu, 8 Nov 2007, Christian Schmidt wrote:
>
> The description of the value attribute of <li> says:
>
> "The value attribute, if present, must be a valid integer giving the
> ordinal value of the first list item."
>
> Shouldn't "first" be removed here? It looks as too much copy-paste from
> the description of <ol start="xx">.
Yeah, this was raised by Thomas earlier. Fixed. :-)
On Wed, 9 Jan 2008, Simon Pieters wrote:
>
> See: http://forums.whatwg.org/viewtopic.php?t=130
>
> Siemova wrote:
> >
> > I recently wanted to create an OL in reverse order. In scouring the
> > web for a solution, I found no simple way to accomplish this, but came
> > across a number of other people frustrated by the lack of this minor
> > feature. The easiest, most obvious solution would be to create an
> > attribute for Ordered Lists -- let's call it order="" -- which would
> > have two possible values: ftl (first to last) and ltf (last to first).
> > Very much like the dir property for text, and, similarly, it would
> > default/degrade to the normal first-to-last order.
> >
> > The possible applications for this are numerous, of course:
> > count-downs, top n lists, having "most recent" items at the top of a
> > reverse-numbered list, etc. I'm sure anybody can think of times they'd
> > want to do this. It would be particularly helpful for traditional
> > print (newspapers, magazines, etc.) converting their content for
> > internet use. Yes, you can accomplish such things via overloaded
> > tables or CSS hacks, or avoid using an HTML list at all, but my
> > proposal would make this use of lists much more convenient, more
> > standardized, and less likely to break.
>
> (A boolean reverse="" attribute or so would also work, I guess.)
>
> Siemova then kindly provided some useful pointers:
>
> People who are frustrated due to the lack of this feature:
>
> http://www.escapedthoughts.com/weblog/geek/P040710badspecs.writeback
> http://cavlec.yarinareth.net/archives/2003/07/02/prerequisites/
> http://www.michaelhanscom.com/eclecticism/2004/05/31/most-naturally-beautiful-women/
> http://www.mail-archive.com/pcworks@imagicomm.com/msg07788.html
> http://forums.biorust.com/html-php-asp-js/5888-reverse-ordered-lists.html
> http://maisonbisson.com/blog/post/11767/why-not
> http://www.spudart.org/blogs/randomthoughts_comments/P2440_0_3_0/
> http://samablog.robsama.com/?m=20070421
>
> Pages that work around the lack of this feature:
>
> http://monkey.paularms.com/weblog/html/reverse-ordered-lists (404)
> http://archivist.incutio.com/viewlist/css-discuss/18706
> http://www.dominoguru.com/pages/06252007031226.html
> http://tallerthanaveragetales.blogspot.com/2005/12/bit-of-business-from-last-year.html
Hm, interesting.
It would cause problems with incremental rendering, and with pages that
get truncated...
I've added reversed="" to <ol>.
(I've not quoted all the e-mails on this topic, since they mostly were
just discussing ideas around it. I did, however, read all of them.)
On Thu, 10 Jan 2008, Robert (Jamie) Munro wrote:
> >
> > (A boolean reverse="" attribute or so would also work, I guess.)
>
> How about a step attribute that is allowed to be negative?
It's more than just a step, it's a matter of changing the anchor point
from the beginning to the end. step="-1", unless we had a bit of a weird
definition, would result in items -1, -2 (instead of 2, 1).
We can add step="" in a future version if it's required. So far the use
cass mentioned all seem to be about counting down to 1.
On Wed, 23 Jan 2008, Jonas Sicking wrote:
>
> How would incremental rendering work? Imagine the following page
>
> <ol step="-1">
> <li>A</li>
> <li>B</li>
> <li>C</li>
> <li>D</li>
> <li>E</li>
> <li>F</li>
> </ol>
>
> If the browser has only received the first three items it would render
>
> 3. A
> 2. B
> 1. C
>
> a couple of seconds later it receives the rest of the page. It would
> then have to renumber all so far rendered items. This would look very
> strange to the user watching the page as it's loading. This problem is
> even worse if the paragraph above contains something like:
>
> "Make sure to turn on the power after step 2 below".
Yeah... We already have that with tables, though; do we care enough?
On Wed, 23 Jan 2008, Simon Pieters wrote:
>
> I completely forgot about the start='' attribute. :-) If incremental
> rendering is an issue (e.g. if you use a list that will always have 100
> items) the author can just set the start value explicitly:
>
> <ol start="100" reverse>
>
> The lack of start='' would make the numbers update as the list is filled
> with <li>s. This allows both for simplicitly for short lists and correct
> incremental rendering for large lists.
Oh, interesting, you would still have start="" affect the first-in-tree-
order element, instead of the last (i.e. ordinal 1) element? I guess that
makes sense, yes.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 26 February 2008 04:29:48 UTC