- From: James Graham <jg307@cam.ac.uk>
- Date: Tue, 27 Mar 2007 13:12:39 +0100
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
Received on Tuesday, 27 March 2007 05:12:39 UTC