Re: [whatwg] Reverse ordered lists

[Philip Parker]

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


James Graham wrote:

Siemova wrote:
On Jan 23, 2008 10:54 AM, David Walbert <[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.

Re: [whatwg] html5 + ogg

[Philip Parker]

On 29/12/2007, Henry Mason <[EMAIL PROTECTED]> wrote:
>
>
> If the specification included the Ogg baseline and few web browsers
> actually supported it, what use would the specification be? Simply
> specifying it won't actually make it widely implemented.
>
> There's also nothing stopping you from using Ogg in the things you
> develop right now, so how does the removal change what you choose to do?

If its not part of the spec, then the situation is no different to how
things are now. There will still be the 'fun' of incompatibilities
with codecs and so on. Ultimately you have no choice to  go for the
lowest common denominator for users and this may not be the best
technical choice for all situations ( Im thinking of open source and
patent/copyright/licencing minefields with other alternative codecs ).

If its part of the specification as a fallback position - and is not
implemented then the implementation of the spec is incomplete by the
target browser and they should not be able to claim html5
compatibility. The onus is on them to implement it - not the web
developer to jump through hoops on their behalf. ( after all, there
are enough of those when you think about all the 'fun' with css hacks
that are needed! )

Having ogg as a fallback position means that you can be certain as a
web developer that if you push content in this format to a browser
that is html5 compliant - that it will be displayed properly and as
intended. You can still push other content to them if you want - and
hope their browser can interpret it correctly, but you lose the safety
net that having it in the specification can provide.

> I guess by "rich media elements" you also mean JPEG, GIF, PNG, SVG,
> and Flash? None of those are included as baselines in the XHTML1
> specification either.
>
It'd be great if they were, but if they arent part of the spec they do
not have to be implemented in order to claim they are xhtml1
compliant.
If they arent supported they arent displayed and the onus again
remains with the developers of the target browser to implement a
format that may be used ( depending on popularity ) and on the web
developer to pick a format that will reach a broad enough spectrum of
users.

If content that is outside of the spec is pushed to the users, then as
a web developer you need to be aware that this may not be displayed as
intended. It is however fortunate that these formats have been readily
implemented, it makes life easier!

Isnt this sort of thing what the http-request Accept: header is for
though? To list the types of file that can be accepted and interpreted
by the browser?

There is of course an alternate solution - For any other codec that is
used for the baseline, demand that it is completely opened up with no
'hidden landmines' that can come around to bite anyone that tries to
implement it prior to it being made part of the spec.
I just cant quite see that happening though...

[whatwg] html5 + ogg

[Philip Parker]

As an upcoming potential web developer, soon to graduate from
university -  what use is there in me investing more effort into
learning a specification which can be altered to suit corporate
purposes and not engineering ones?
Surely the point of a specification is to be as good and complete as it can be?

The removal of ogg as a baseline for audio/video implementation
strikes me as ridiculous. Theres nothing stopping other formats from
being used after all - simply to have a completely open one as a
fallback position is a sensible step forward.
As things stand with how easily large corporations can
obstruct/corrupt the process for their own goals, I might as well just
stick to xhtml1 and avoid rich media elements where possible in any
site I may end up developing until - and indeed if sense prevails.