At 17:33 +0000 23/01/08, Philip Parker wrote:
What about having it render as a standard unordered list ( ie,
bulletpoints ) until the entire set of items has been received - and
then re-rendering the list as a numbered type, all properly
calculated
how about assuming that if the source wants it numbered, in reverse
order, it knows what it is doing, and can tell the browser what
number to start at?
it still seems the simplest; an attribute that gives the starting
number (default 1) and an attribute that gives the direction
(increasing or decreasing, default increasing).
James Graham wrote:
Siemova wrote:
On Jan 23, 2008 10:54 AM, David Walbert <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
It's not that simple -- the last line should be
start = 1 + ( (number of items - 1) * step)
if it's assumed that the last item of the list is numbered one by
default.
Alas, we see the ill effects of my hastiness today! I stand
happily corrected. In that case, it's even simpler:
if start is not specified
start = 1
if reverse
start += (number of items - 1) * step
The problem that Jonas originally pointed out is that, given
browsers do incremental rendering "number of items" is not a known
quantity when the list is first rendered. For a pathological
example of why this is a problem, imagine a cgi script that just
kept spewing out reverse numbered list items, one per second,
indefinitely.
It may be that in practice lists are short enough that they are
typically rendered all in one go so this wouldn't be a problem. I
don't think that's obvious, however.
--
David Singer
Apple/QuickTime
