[whatwg] html5 + ogg

[Philip Parker]

On 29/12/2007, Henry Mason <hmason at mac.com> 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...