By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,131 Members | 1,425 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,131 IT Pros & Developers. It's quick & easy.

Problems Starting an Ordered List at Zero

P: n/a
I cannot get Netscape 4.79 to properly display the ordered list in the
following fragment.

<P>Get a specific portion of the date.
Depending upon the value of index:
<ol start=0>
<li>complete value, usually as a <code>String</code>, or if
an integral value as an <code>Integer</code>.
<li>year as an <code>Integer</code>
<li>month number as an <code>Integer</code>
<li>day as an <code>Integer</code>
<li>month name as a <code>String</code>
</ol>
....

When viewed under IE6 the ordered list starts with item 0 as I have
requested, but when viewed in Netscape 4.79 the start=0 attribute is ignored
and the list is displayed starting with item 1. Since this web page is part
of the documentation of the product it is essential that the displayed
indexes be correspond to the behavior of the program.

When I go to the W3C website I am informed that the start= attribute is
"DEPRECATED". However I cannot find any alternative way to achieve this
result that is not deprecated.

Any ideas?

--
Jim Cobban jc*****@magma.ca
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438
Jul 23 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
On Fri, 24 Sep 2004 13:33:12 -0400, Jim Cobban <jc*****@magma.ca> wrote:
I cannot get Netscape 4.79 to properly display the ordered list in the
following fragment.
That browser is antique. If it will not observe the start attribute, and
you must accommodate NN4, you'll ned to number manually.
When I go to the W3C website I am informed that the start= attribute is
"DEPRECATED". However I cannot find any alternative way to achieve this
result that is not deprecated.


Deprecated markup is allowed in the Transitional DTD. But as you seem to
need to work with a browser that can't handle it anyway, you might need to
do it differently anyhow.
Jul 23 '05 #2

P: n/a

"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net...
On Fri, 24 Sep 2004 13:33:12 -0400, Jim Cobban <jc*****@magma.ca> wrote:
I cannot get Netscape 4.79 to properly display the ordered list in the
following fragment.


That browser is antique. If it will not observe the start attribute, and
you must accommodate NN4, you'll ned to number manually.


I appreciate that 4.79 is antique, however several of the web sites that I
deal with use a tool, MrSid, that does not support any more recent Mozilla
based browser. That is the tool refuses to install itself into the newer
browsers.
Jul 23 '05 #3

P: n/a
"Jim Cobban" <jc*****@magma.ca> wrote in
news:0Y********************@magma.ca:
I appreciate that 4.79 is antique, however several of the web sites
that I deal with use a tool, MrSid, that does not support any more
recent Mozilla based browser. That is the tool refuses to install
itself into the newer browsers.


LizardTech's MrSid isn't a tool, but a compression method.
If you are using websites that have images that are in
MrSid format, there are a number of ways to deal with such
images, including using a browser plugin, which will work
with more modern browsers than Netscape 4.79 - do a google
search and you'll find info about people getting the plugin
to work in various browser versions, or you could ask in
a browser-specific newsgroup.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/
Jul 23 '05 #4

P: n/a
Neal <ne*****@yahoo.com> wrote:
I cannot get Netscape 4.79 to properly display the ordered list in
the following fragment.
That browser is antique. If it will not observe the start attribute,


It observes the start attribute but does not support a value of "0".
There are some odd deficiencies in browser support to this attribute
(e.g., when you use "0", or negative numbers, or large numbers).
and you must accommodate NN4, you'll ned to number manually.


Indeed, because there's no CSS equivalent to the start attribute.

When the numbers are _essential_, it's probably best to make them part of
the content. The best approach is usually to use a <ul> element, with a
class attribute, say <ul class="numbered">, with numbers in the <li>
elements (<li>0. foo bar</li>) and with a CSS rule like
ul.numbered { list-style-type: none; }

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #5

P: n/a

"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message
news:Xn*****************************@193.229.0.31. ..
Neal <ne*****@yahoo.com> wrote:

When the numbers are _essential_, it's probably best to make them part of
the content. The best approach is usually to use a <ul> element, with a
class attribute, say <ul class="numbered">, with numbers in the <li>
elements (<li>0. foo bar</li>) and with a CSS rule like
ul.numbered { list-style-type: none; }


If the text of the list item is too long to fit on one line won't it wrap
back to the left margin, rather than being indented to the same horizontal
position as the first letter of the text on the first line?
Jul 23 '05 #6

P: n/a
"Jim Cobban" <jc*****@magma.ca> wrote:
When the numbers are _essential_, it's probably best to make them
part of the content. The best approach is usually to use a <ul>
element, with a class attribute, say <ul class="numbered">, with
numbers in the <li> elements (<li>0. foo bar</li>) and with a CSS
rule like ul.numbered { list-style-type: none; }


If the text of the list item is too long to fit on one line won't it
wrap back to the left margin, rather than being indented to the same
horizontal position as the first letter of the text on the first
line?


Typically, yes. I didn't want to go into the presentational details, but
if you wish to simulate the typical appearance of <ol>, you need to add
some CSS code and probably extra HTML markup (for the numbers) too.
On the other hand, it gets a bit awkward then, so you might also consider
using a table:

<table class="numbered" summary=
"This table corresponds to a numbered list, so that the first
column has item numbers, the second column contains the items."
cellspacing="0" cellpadding="0">
<tr><td align="right" valign="top">0.&nbsp;&nbsp;</td>
<td>foo bar</td></tr>
....
</table>

It's a bit clumsy too, of course, and a bit illogical, since the cells of
the first column should really be headers for the cells of the second
column (<th scope="row">0.</th>). But I just sketched an approach that
works in "pure" (though surely not Puristic) HTML. Of course you could
also use table markup with no presentational attributes (and no &nbsp;
trickery) and handle the rendering in CSS, though then the list would
look a bit odd in CSS-disabled browsing.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #7

P: n/a
Jukka K. Korpela wrote:
When the numbers are _essential_, it's probably best to make them part of
the content. The best approach is usually to use a <ul> element, with a
class attribute, say <ul class="numbered">, with numbers in the <li>
elements (<li>0. foo bar</li>) and with a CSS rule like
ul.numbered { list-style-type: none; }


Seems nasty though to suggest the use of a <ul> element in a situation
where the numbers (and thus presumably the ordering) are so important.

I guess this would end up producing the correct result in the most
situations though.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Now Playing ~ ./white_town_-_your_woman.ogg

Jul 23 '05 #8

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
Indeed, because there's no CSS equivalent to the start attribute.


I wonder why, given that the attribute is deprecated in HTML 4.01
Strict.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Jul 23 '05 #9

P: n/a

"Stan Brown" <th************@fastmail.fm> wrote in message
news:MP************************@news.odyssey.net.. .
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
Indeed, because there's no CSS equivalent to the start attribute.


I wonder why, given that the attribute is deprecated in HTML 4.01
Strict.


Apparently you are supposed to write some complicated CSS code to implement
the counter yourself. Seems overkill, and if they are going to propose such
a complicated workaround I feel they should describe the workaround in the
specification.
Jul 23 '05 #10

P: n/a
In article <Id********************@magma.ca>, jc*****@magma.ca says...

"Stan Brown" <th************@fastmail.fm> wrote in message
news:MP************************@news.odyssey.net.. .
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
Indeed, because there's no CSS equivalent to the start attribute.
I wonder why, given that the attribute is deprecated in HTML 4.01
Strict.


IMHO, they should have included some attribute to hide markers in HTML,
even if deprecated it at the same time.
Apparently you are supposed to write some complicated CSS code to implement
the counter yourself.
ol {counter-reset:foo;}
li:before {content:counter(foo) ".";display:marker;}
li {counter-increment:foo;}

But, IMHO, that is not that bad. I can't think any easier way to code the
same - remember, CSS is not HTML specific, so first and last rule are
needed to tell browser which are the list elements, display:marker is
needed for rendering content as list item marker (it does not workm on
any browser).

It doesn't leave much.
Seems overkill,


IMHO, Counter things in CSS2 are quite nice and easy. They have been
supported by Opera for years. The reson they are hardly ever used is that
no Other browser have implemented them.

Often, when strange numbering is needed, numbers should be content. And
just as often, numbering is stylish, but can't be done in certain
browsers exept by putting numbers in content (anything with more than one
level of numbers)

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Jul 23 '05 #11

P: n/a
Toby Inkster <us**********@tobyinkster.co.uk> wrote:
Seems nasty though to suggest the use of a <ul> element in a situation
where the numbers (and thus presumably the ordering) are so important.


I would say just the opposite: if the numbers are really important, then
they should be part of the textual content, and then <ul> is adequate.

The <ol> element is basically the same as <ul> but with different default
rendering. That is, their difference is presentational rather than
semantic.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
Jul 23 '05 #12

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote:
ol {counter-reset:foo;}
li:before {content:counter(foo) ".";display:marker;}
li {counter-increment:foo;}

But, IMHO, that is not that bad.


Except that it does not work, and it uses CSS constructs that are being
phased out rather soon, in CSS 2.1, the strange mix of industry standard
CSS and a few new odd inventions.

It was an unnecessarily complicated thing to handle a simple thing like a
replacement for <ol start="0">.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #13

P: n/a
In article <Xn****************************@193.229.0.31>,
jk******@cs.tut.fi says...
Lauri Raittila <la***@raittila.cjb.net> wrote:
ol {counter-reset:foo;}
li:before {content:counter(foo) ".";display:marker;}
li {counter-increment:foo;}

But, IMHO, that is not that bad.
Except that it does not work,


Yes. That is it's only problem. (of course, problem is not small...)
It was an unnecessarily complicated thing to handle a simple thing like a
replacement for <ol start="0">.


But, it awould make possible to style things with numbers, unlike start
attribute. Of course, it is not good idea for replacing numbers in lists.
But IMHO, OL was bad idea from start, I would much prefer something like
this:

<list><li><marker>0.</marker>First Item</li></list>

And marker would be optional, when leaved out style would come from
stylesheet.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Jul 23 '05 #14

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
The <ol> element is basically the same as <ul> but with different default
rendering. That is, their difference is presentational rather than
semantic.


Hmm, I wonder.

Never mind CSS for a minute; consider just generic documents. My
take on a bulleted list is that the items are equal and could just
as well appear in any order; my take on a numbered list is that theh
numbers are steps in a procedure.

I agree with you that the numbers themselves re not terribly
important, but the fact that "microwave for 10 minutes" comes before
"puree with a blender" _is_ important.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Jul 23 '05 #15

P: n/a
On Sun, 26 Sep 2004 19:28:15 -0400, Stan Brown
<th************@fastmail.fm> wrote:
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

The <ol> element is basically the same as <ul> but with different
default rendering. That is, their difference is presentational rather
than semantic.


Hmm, I wonder.

Never mind CSS for a minute; consider just generic documents. My
take on a bulleted list is that the items are equal and could just
as well appear in any order; my take on a numbered list is that theh
numbers are steps in a procedure.

I agree with you that the numbers themselves re not terribly
important, but the fact that "microwave for 10 minutes" comes before
"puree with a blender" _is_ important.


Yes, but you might note recipes often *don't* use numbered
(lists|paragraphs), and rely on the presentation order to convey the
sequential relation between the steps.

I think in many, maybe even most cases, of UL on the web, people *do* find
the order of their list items important or at least non-arbitrary, but
they don't necessarily want the visually distracting numbering to show. It
is only when the items need to be referenced from elsewhere that numbering
becomes really useful.

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

Jul 23 '05 #16

P: n/a
On Sun, 26 Sep 2004 19:28:15 -0400, Stan Brown
<th************@fastmail.fm> wrote:
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
The <ol> element is basically the same as <ul> but with different
default
rendering. That is, their difference is presentational rather than
semantic.


Hmm, I wonder.

Never mind CSS for a minute; consider just generic documents. My
take on a bulleted list is that the items are equal and could just
as well appear in any order; my take on a numbered list is that theh
numbers are steps in a procedure.

I agree with you that the numbers themselves re not terribly
important, but the fact that "microwave for 10 minutes" comes before
"puree with a blender" _is_ important.


Yet I know of no UA which will randomly display ul items but still put ol
items in the strict order they were put in by the author. In reality,
whether you use ul or ol, the items will be listed in the order you put
them. So the ol and ul markup gives a presentational difference to the
user.

If the ordering of the list items is critical, should we rely on HTML
rendering to add the right numbers? W3C says that "ordered and unordered
lists are rendered in an identical manner except that visual user agents
number ordered list items." It would seem a critical requirement of a
conforming UA to add numbering to ol element items. So it would seem
mandatory that ol items will have a numbering according to how we order
them in the source.

To me, it comes to this question: does ol and ul provide any different
semantic meaning in and of themselves, without considering the
presentation? It would seem there is an argument for either position. To
one, the specific markup defines the information as being inherently
ordered or not. To another, the content is in any event ordered as a rule,
and thus the reader will gather an ordering even if we specify ul.

I recall a discussion where it was posited that <l> would be a superior
element to ol and ul. One could use <l type="ordered"> or what have you to
deliver this information to the UA. Whether this eliminates any
presentational demands on the list elements is a matter of debate, but it
would certainly streamline the HTML element set.

Elements which require a specific rendering seem to be the red-headed
stepchildren of HTML, but some are useful. b and i have valid semantic
uses. hr can be useful in some instances. The list elements may be seen as
useful or not, but it remains that, for right or wrong, they are in HTML,
they do have mandated rendering rules, and authors can expect the UA to
respect this.

So, the real question isn't whether ol and ul are presentational or
semantic, as they clearly can be either. It's whether we're using these
elements more for their presentational traits or for their semantic
meaning to the document.
Jul 23 '05 #17

P: n/a
In article <Xn****************************@193.229.0.31>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

The <ol> element is basically the same as <ul> but with different default
rendering. That is, their difference is presentational rather than
semantic.


This is _very_ hard to swallow.

There is an enormous semantic difference between information with some
kind of ordering characteristic to it, and information without.

E.g., if I'm describing the sequence of events, the chronological
_order_ that they occurred in may be critical to understanding how they
are related. With an unordered list, the semantics are that the members
of the list may be re-arranged in any order presentationally, without
changing the meaning or correctness of the information. An ordered list
-- even without presentational hints -- is indicating that the order of
the elements presented is important: that changing the order of the
elements with change the meaning of the overall list itself.

Your statement seems to me to say that <p> and <blockquote> should also
be considered to have no difference other than presentational, which, in
the default case is usually to be a little different. But they're both
just blocks of text, right?

I'd be surprised if you accepted that interpretation of <p> and
<blockquote>, so it also surprises me that you see nothing but
presentational differences between <ul> and <ol>.

--
Joel.
Jul 23 '05 #18

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote in
news:MP************************@news.individual.ne t:
<list><li><marker>0.</marker>First Item</li></list>


I was actually going to suggest something like this, before reading your
post. A document's textual content should not be hidden away in some
element. To be persnickety, I would use

<list><li><marker>0</marker>. First Item</li></list>

because the dot is not part of the number, it is just punctuation. Of
course, dots _could_ be part of a number: in a list of rules, one could
have rule 2.3 and rule 2.4.

Alternately, in designing this hypothetical language, I might allow the
marker to contain non-numerical content and allow the author to put markup
_inside_ the marker to indicate the actual number. For example:

<list>
[...]
<li><marker>Rule <num>2.3</num>:</marker> No blah blah may bladiddy blah
when the ball lands on the line.</li>
[...]
</list>

Of course, some "nums" could have letters in them, such as if one were
referring to "Rule <num>17-C</num>". Or if one used hexidecimal numbers in
the ordered list, for some reason. Perhaps the LIST element should have an
attribute which describes the meaning of the NUM elements' content. Such
an attribute would be inherited from a parent LIST element if not otherwise
specified, if such a parent exists.
Jul 23 '05 #19

P: n/a
Neal wrote:
Yet I know of no UA which will randomly display ul items but still put ol
items in the strict order they were put in by the author.


No, but in doing so they would not be incorrect IMHO. A UA could, for
example, have an option to display all unordered lists in alphabetical
order instead of the author's order.

(Incidentally, I would like to see such a feature -- and also a feature
that allows you to right-click on TH elements to sort a table by that
column.)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

Jul 23 '05 #20

P: n/a
In article <Xn**************************@130.133.1.4>, hu****@rpi.edu
says...
Lauri Raittila <la***@raittila.cjb.net> wrote in
news:MP************************@news.individual.ne t:
<list><li><marker>0.</marker>First Item</li></list>
I was actually going to suggest something like this, before reading your
post. A document's textual content should not be hidden away in some
element. To be persnickety, I would use

<list><li><marker>0</marker>. First Item</li></list>

because the dot is not part of the number, it is just punctuation.


No, it is not part of number, put it is part of list item marker. That
period doesn't belong to list item.
Of
course, dots _could_ be part of a number: in a list of rules, one could
have rule 2.3 and rule 2.4.
True. And these are currently hard to get using HTML/CSS.
Alternately, in designing this hypothetical language, I might allow the
marker to contain non-numerical content and allow the author to put markup
_inside_ the marker to indicate the actual number. For example: Of course, some "nums" could have letters in them, such as if one were
referring to "Rule <num>17-C</num>". Or if one used hexidecimal numbers in
the ordered list, for some reason. Perhaps the LIST element should have an
attribute which describes the meaning of the NUM elements' content. Such
an attribute would be inherited from a parent LIST element if not otherwise
specified, if such a parent exists.


I think that num element whitout attribute to tell it's type would be
useless, as people shoud understand what kind of number it is anyway (if
they don't, that is problem outside markup...), but computers could get
something from num element.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Jul 23 '05 #21

P: n/a
Joel Shepherd <jo******@ix.netcom.com> wrote:
In article <Xn****************************@193.229.0.31>,
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote:

The <ol> element is basically the same as <ul> but with different
default rendering. That is, their difference is presentational
rather than semantic.
This is _very_ hard to swallow.


Try it with some spicy CSS! :-)
There is an enormous semantic difference between information with
some kind of ordering characteristic to it, and information without.
But both <ul> and <ol> are inherently ordered - the order of the <li>
elements is significant in both of them. As usual, the HTML
specifications are not explicit in such semantics, but this is surely the
intended and generally understood semantics. It would not be appropriate
for a browser to render (at default settings) <li> elements in a
randomized order, or in any order different from the order in the HTML
source.
E.g., if I'm describing the sequence of events, the chronological
_order_ that they occurred in may be critical to understanding how
they are related.
Surely. But the only difference between <ul> and <ol> is that by using
<ol> you are asking the browser to add numbers to the items (as you could
do in CSS: ul { list-style-type: decimal; }, for example). It's
comparable to adding numbers to headings - often a desirable thing to do,
but not possible in practice without actually changing the content of
heading elements.
With an unordered list, the semantics are that the
members of the list may be re-arranged in any order presentationally,
without changing the meaning or correctness of the information.
That might be a theoretically possible idea, but it's not the intention,
and not a common opinion, and not reflected in any browser's behavior.

If it had been the intention, at least HTML 2.0 specification would have
said it. Instead, the specifications describe <ul> and <ol> as _lists_
(and _sequences_), which implies that the order of subelements is
significant and not mutable. The poor wordings "unordered list" and
"ordered list" cannot change this; logically, an "unordered list" is an
oxymoron, since "list" (as opposite to "collection" or "set") implies an
order; and the simple solution is that the idea always was that <ol> is a
list where the ordering is explicitly expressed using some kind of
numbering.
Your statement seems to me to say that <p> and <blockquote> should
also be considered to have no difference other than presentational,


In actual practice on Web pages, what _is_ the difference if not
presentational? But in this case, the specifications are fairly clear.
The problem is that browsers started using a fixed (and unimaginative)
method of rendering <blockquote> elements, so it was too easy to start
abusing the markup. There's no such phenomenon for <ul> and <ol>; they
were presentational variants from the beginning.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #22

P: n/a
On Mon, 27 Sep 2004, Jukka K. Korpela wrote:
But both <ul> and <ol> are inherently ordered
In so far as the items of a <ul> have to be presented in the source
code in one particular ordering, I agree. However, the HTML
specification -says- that the items are "unordered", whatever that may
exactly mean.
- the order of the <li> elements is significant in both of them.
I'd have to disagree with that. By using <ul> you are supposed to
be telling HTML that the ordering in the source code is not
substantive to the meaning. Taking their example:

* 100 g. flour
* 10 g. sugar
* 1 cup water
* 2 eggs
* salt, pepper

These ingredients could still make the same recipe if the salt were
listed first, the water last etc.

Whereas it would likely make an entirely different result if these
procedural steps were re-sequenced:

1. Mix dry ingredients thoroughly.
2. Pour in wet ingredients.
3. Mix for 10 minutes.
4. Bake for one hour at 300 degrees.
As usual, the HTML specifications are not explicit in such
semantics,
True enough, and it even goes on to say:

Ordered and unordered lists are rendered in an identical manner
except that visual user agents number ordered list items.

although - as so often - it's not at all clear whether this is
intended as merely an observation about the behaviour of existing
browsers, or a specification of how browsers are required to behave
for all time.

(For example, there might -hypothetically- be a future stylesheet
option for sorting unordered list items into alphabetical order, or by
string length, or whatever...)
It would not be appropriate for a browser to render (at default
settings) <li> elements in a randomized order, or in any order
different from the order in the HTML source.
The exact presentation of the three list types depends on the user
agent. [...] This is a stylistic issue and is properly handled by
style sheets. - (HTML4.01 section 10.1).
Surely. But the only difference between <ul> and <ol> is that by
using <ol> you are asking the browser to add numbers to the items
Semantically, with <ol> you are declaring to HTML that the ordering of
the items is significant. The numbering is an external representation
of that semantic structure.
With an unordered list, the semantics are that the members of the
list may be re-arranged in any order presentationally, without
changing the meaning or correctness of the information.


That might be a theoretically possible idea, but it's not the
intention, and not a common opinion, and not reflected in any
browser's behavior.


I wouldn't expect any browser to resequence list items by default,
indeed.

But consider a compact list presentation.

item item item item
item item item item

There are two entirely plausible ways to sequence these items
(by columns or by rows, I mean).
If it had been the intention, at least HTML 2.0 specification would
have said it. Instead, the specifications describe <ul> and <ol> as
_lists_ (and _sequences_), which implies that the order of
subelements is significant and not mutable. The poor wordings
"unordered list" and "ordered list" cannot change this; logically,
an "unordered list" is an oxymoron, since "list" (as opposite to
"collection" or "set") implies an order;


There's something in what you say; and often the W3C specs read like
the work of a committee who couldn't quite agree, and who then levered
several competing opinions into place without resolving the
contradictions.

all the best
Jul 23 '05 #23

P: n/a
Stan Brown <th************@fastmail.fm> writes:
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in
comp.infosystems.www.authoring.html:
Indeed, because there's no CSS equivalent to the start attribute.


I wonder why, given that the attribute is deprecated in HTML 4.01
Strict.


Which was a mistake, I think - it seems to me to be entirely part of
the content. Consider a list of steps:

11. Prepare foo ...
12. Prepare bar ...
....
17. Take the preparation from step 11 and ...

(Slightly contrived example, I know rewording step 17 would help in
*this* case, and for that matter this list would start at 1 anyway)

The number '11' on the list item is clearly part of the essential
content, so a stylesheet solution is unacceptable. So why deprecate
'start'?

--
Chris
Jul 23 '05 #24

P: n/a
"Rijk van Geijtenbeek" <ri**@operaremovethiz.com> wrote in
comp.infosystems.www.authoring.html:

(reacting to my example of a recipe as needing sequential steps, as
difference between <ol> and <ul> not being presentational)
Yes, but you might note recipes often *don't* use numbered
(lists|paragraphs), and rely on the presentation order to convey the
sequential relation between the steps.


Good point. I think my position falls to the ground. It's the
arrangement itself, not the fact of the numbers -- which, as you
say, aren't usually use in recipes.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Jul 23 '05 #25

P: n/a
Stan Brown wrote:
"Rijk van Geijtenbeek" wrote:

(reacting to my example of a recipe as needing sequential steps, as
difference between <ol> and <ul> not being presentational)

Yes, but you might note recipes often *don't* use numbered
(lists|paragraphs), and rely on the presentation order to convey
the sequential relation between the steps.

Good point. I think my position falls to the ground.


Stick to your guns.
It's the arrangement itself, not the fact of the numbers -- which, as
you say, aren't usually use in recipes.


As is often the case, Alan Flavell has hit the nail on the head:
Whether ordered steps in a recipe are prepended by numbers is
presentational, but the fact that the steps are ordered is semantic. By
contrast, ingredients in a <ul> can be listed in any order without a
change in the semantics.

--
Brian (remove "invalid" to email me)
http://www.tsmchughs.com/
Jul 23 '05 #26

P: n/a
Brian <us*****@julietremblay.com.invalid> wrote:
Whether ordered steps in a recipe are prepended by numbers is
presentational, but the fact that the steps are ordered is semantic. By
contrast, ingredients in a <ul> can be listed in any order without a
change in the semantics.


Many recipes include language like, "combine the first 5 ingredients" or
"fold in the next 3 ingredients". Yes, the instructions could be edited to
remove the dependency upon the order of the ingredients, but in the
original recipe, the order of the ingredients has meaning.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Do not look where you fell, but where you slipped." - African Proverb
Jul 23 '05 #27

P: n/a
Neal <ne*****@yahoo.com> wrote:
If the ordering of the list items is critical, should we rely on HTML
rendering to add the right numbers? W3C says that "ordered and
unordered lists are rendered in an identical manner except that
visual user agents number ordered list items."


I hadn't realized they say that. It's very odd, because it sounds like a
requirement. In fact, some people have said that <ol> should generally be
preferred over <ul>, since numbering the items makes the presentation
more understandable on a _speech_ browser. And this sounds natural,
doesn't it? I even used to favor the idea but then realized I went
overboard; it's ultimately user agents' responsibility to render simple
lists properly - and to allow the user select a rendering mode where all
lists are read as numbered, I think.

Before that, they say, near the start of
http://www.w3.org/TR/html4/struct/lists.html
as follows: "An ordered list, created using the OL element, should
contain information where order should be emphasized, as in a recipe". So
the point is in _emphasizing_ the order. Or, as I would say, making it
more _explicit_. The numbers give no extra information; the just
emphasize an order and allow references by number.

By the way, I noticed that the HTML 4.01 specification contains, in the
Lists section discussed, an example of using the start="..." attribute,
indicated as deprecated. It is followed by a note "Details about
numbers", which mentions that the list item counter can be reset using
the value="..." attribute in a <li> element, without emphasizing, and
without even mentioning, that this attribute has been deprecated, too.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 23 '05 #28

P: n/a
On Mon, 27 Sep 2004, Darin McGrew wrote:
Many recipes include language like, "combine the first 5 ingredients" or
"fold in the next 3 ingredients". Yes, the instructions could be edited to
remove the dependency upon the order of the ingredients, but in the
original recipe, the order of the ingredients has meaning.


And this is exactly where <ol start="blah"> falls down; because the
text is liable to refer to the steps by their intended *presentation*
names, and will work fine on client agents which honour the start
attribute; but support for the start attribute is not mandated, with
the results that you can certainly predict.

This is what I call "leakage": the assumption that one can refer to
step 3, or the "green bullet", or any other presentation detail that's
not mandated by the spec, from the running text. A careful author
will avoid falling into that kind of trap, but it's sometimes hard to
avoid.

Now, in an ancient publishing markup language that I was using a
considerable number of years ago, it was possible to assign labels to
the steps, and to refer to those &flour; and &eggs; and &water; items
in the running text, whereupon the renderer would plug-in whatever
list marker had been used. But HTML is too simple for that.

cheers

Jul 23 '05 #29

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote in
news:MP************************@news.individual.ne t:
In article <Xn**************************@130.133.1.4>, hu****@rpi.edu
says...
Of course, some "nums" could have letters in them, such as if one
were referring to "Rule <num>17-C</num>". Or if one used hexidecimal
numbers in the ordered list, for some reason. Perhaps the LIST
element should have an attribute which describes the meaning of the
NUM elements' content. Such an attribute would be inherited from a
parent LIST element if not otherwise specified, if such a parent
exists.


I think that num element whitout attribute to tell it's type would be
useless, as people shoud understand what kind of number it is anyway
(if they don't, that is problem outside markup...), but computers
could get something from num element.


This would work fine with the attribute in the LIST element as mentioned
above. If different numbering schemes are used in a list, then NUM is
meaningless anyway.
Jul 23 '05 #30

P: n/a
On Mon, 27 Sep 2004 20:55:58 +0000 (UTC), Jukka K. Korpela
<jk******@cs.tut.fi> wrote:
By the way, I noticed that the HTML 4.01 specification contains, in the
Lists section discussed, an example of using the start="..." attribute,
indicated as deprecated. It is followed by a note "Details about
numbers", which mentions that the list item counter can be reset using
the value="..." attribute in a <li> element, without emphasizing, and
without even mentioning, that this attribute has been deprecated, too.


Noticed that too. Sloppy. :(

Jul 23 '05 #31

P: n/a
Stan Brown <th************@fastmail.fm> writes:
Good point. I think my position falls to the ground. It's the
arrangement itself, not the fact of the numbers -- which, as you
say, aren't usually use in recipes.


This is a user interface issue. More numbers in a recipe means more
confusion. Did step 2 say to crush 4 cloves of garlic, or did step 4
say to crush 2 cloves? The same issue (IMO) hurts phone information
systems that offer to automatically dial a number "for an additional
charge of 35 cents by pressing the number 1..." All those extra numbers
make it harder for me to remember the phone number I just heard. Maybe
that's on purpose to get me to choose the auto dial function.

However, for sequences of steps that don't otherwise involve numbers, I
think <ol> can be helpful. I agree with Jukka that in contexts where
steps might be referred to by number elsewhere in the text or in another
persistent medium, the numbers should be part of the text.
Jul 23 '05 #32

P: n/a
On 28 Sep 2004 11:41:16 -0400, Bruce Lewis <br*****@yahoo.com> wrote:
Stan Brown <th************@fastmail.fm> writes:
Good point. I think my position falls to the ground. It's the
arrangement itself, not the fact of the numbers -- which, as you
say, aren't usually use in recipes.


This is a user interface issue. More numbers in a recipe means more
confusion. Did step 2 say to crush 4 cloves of garlic, or did step 4
say to crush 2 cloves? ...
However, for sequences of steps that don't otherwise involve numbers, I
think <ol> can be helpful. I agree with Jukka that in contexts where
steps might be referred to by number elsewhere in the text or in another
persistent medium, the numbers should be part of the text.


Well, unfortunately we're left with something resembling the q problem.
(If we add quotes to text in q elements, some users see double; if we
don't, some see none.)

The proper semantic markup for a list which the author intends to be
followed in a prescribed order is ol. It will add numbers, like it or not.
CSS can strip these for CSS renderings, but Lynx and others will add them.

If we add numbers to the content in an ol we get doubled numbers on some
UAs. If we avoid this by using ul, we are abusing semantic markup.

Best solution IMO is to use ol, and style with CSS, and accept the
numbered rendering in non-CSS renderings. If it is impossible to do what
you want that way, perhaps:

<div class="fooli"><div class="fooln">1.4.5</div>This is information
relative to 1.4.5, and make it wrap to test.</div>

and something along the lines of this - off the cuff, probably won't
actually work, but you get the general idea.

..fooli {margin-left: 5em; position: relative; top: 1.2em;}
..fooln {position: relative; left: 5em;}

And be it known that I would prefer the list markup any day to this div
soup, unless the efect was needed and otherwise impossible.
Jul 23 '05 #33

P: n/a
Perhaps a paragraph break would have helped clarify what I was saying.

I think <ol> and putting numbers in the text are two mutually exclusive
options, the former more convenient, the latter providing more control
over exactly what numbers you'll get. I never intended to advocate
putting numbers in the text in <ol>.

Jul 23 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.