[whatwg] on codecs in a 'video' tag.

James Graham jg307 at cam.ac.uk
Tue Mar 27 05:12:39 PDT 2007


Bjoern Hoehrmann wrote:
> * James Graham wrote:
>> I think you are mistaking a requirement for all UAs with one for UAs that 
>> support the display of images. For UAs that support the display of images, 
>> authors rely on GIF, JPEG and PNG support being avaliable. The specifcation 
>> should reflect the reality that any UA with image support that intends to work 
>> on the web must support these formats.

> Why should some of these be called out in
> the "HTML specification", and if only some of them, why bother
> with that at all?

Some of these are relevent to the document layer of the UA i.e. the part that 
deals with interpreting HTML documents, others are part of some other part.

 > Adobe Flash

Agreed (much as I dislike Flash). Unfortunatley the fact that Flash is 
effectivley implemented by a single binary plugin and the public specification 
has a "no implementations" license makes this impossible to include.

> XMLHttpRequest

Is included.

> SSL, TLS, IDNs, HTTP Basic Auth, a range of URI schemes

Part of the networking layer of the UA. Only explicit interaction with the 
document layer is important.

> Cookies

Well the spec points to RFC 2109 and defines how the cookie attribute works on 
HTMLDocument.

> a broad range of character
> encodings

The spec does have something to say about character encodings and I would very 
much like a list of baseline encodings that a UA should support.

>  some subset of CSS

I have no problem with the spec stating that UAs SHOULD support CSS. However 
many people would argue that style is less important than content and, since 
images are part of content, it would follow that CSS support is not as important 
as image support.

> XSLT 1.0

Irrelevant for the vast majority of the web.

> And what if, say, some consortium of mobile solution provides agree
> on additional required features

Then either those won't be widely used on the public web and so are irrelevant 
or they will be widely adopted and should be specified in the HTML specification 
(or the HTTP specification or wherever they fit).

 > They [authors] would
> not be helped in their decision what they can use. So, who's this
> for?

Partly it's for documentation: a statement of what you need to produce a 
functional web browser. Partly to give vendors a well-defined target; it is only 
very recently that IE has grown full support for PNG files, for example.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead



More information about the whatwg mailing list