- From: Shannon <shannon@arc.net.au>
- Date: Thu, 20 Dec 2007 14:20:46 +1100
Jim Jewett said: > Perhaps more importantly, page authors should be able to rely on the spec. As a web author I have *never* relied on the HTML, ECMAScript or CSS specs. What I do is look on 'A List Apart', 'htmlhelp.com' and tutorials spread around the web to see the current state of browser support. This is my reality as a designer and I do not expect HTML5, in any form, will change that. The standard should be aimed at forming a general consensus on what browsers *should* do in the hope that those that can comply - will. For instance there are many open-source browsers and impartial content produces that may rally around a recommendation and this is all we can ever expect. It wouldn't be a good thing if those impartial groups had no recommendations to follow and therefore implemented different approaches. KDE, Xfce, Enlightenment and Gnome used to use different desktop config files. Once a standard was agreed on they became interoperable regardless of the fact neither Microsoft or Apple ever implemented it. We can't use not following a standard as an argument not to make one, especially when that standard is optional anyway. Can anyone guarantee that Microsoft, Apple or Nokia will fully comply with HTML5 if we don't recommend a video codec as some have requested? Big vendors may have monopoly control now but who can say in the future? I've seen IE's share on some of my sites (aimed at wealthy businessmen, not geeks) drop from 98% to 75% over 2 years and it's still going down. The standard is aimed at current vendors but they are not the only stakeholders here. If they are then why does this list exist? > Tying this back to video codecs, it would be great if we could tell > authors "provide at least format X, if the browser can't support that, > it probably doesn't do video at all." It would be bad if we told them > that and it wasn't true -- regardless of why it wasn't true. This is why the video fallback argument is stalled. I have never asked for a *must* statement and a part of the spec that was *not* removed states: -------------- 3.14.8.1. Audio codecs for |audio <http://www.whatwg.org/specs/web-apps/current-work/#audio1>| elements User agents may support any audio codecs and container formats. User agents must support the WAVE container format with audio encoded using the PCM format. ------------- I notice that nobody complaining about MUST in video have objected to this or this: ------------- NOTE: Certain user agents might support no codecs at all, e.g. text browsers running over SSH connections. ------------- Vendors can't say they are working towards a MUST codec while simultaneously acknowledging that some browsers won't support ANY codecs. Nor can you categorically state that all browsers will support PCM (like browsers for the deaf or Lynx). Since there is some serious inconsistencies in the arguments being presented it is hard not to assume this is all just a stalling tactic in support of commercial ends (defacto adoption of h.264). I recommend the WHATWG works out a way to prevent commercial self-interest from moving us towards a royalty-free public standard. If my wealthier clients want to support other codecs that's fine but a recommendation in the spec gives me a better position to recommend they encode an Ogg fallback as well. The argument that we are stuck on is: should we make *recommendations* in a standard that won't be followed by all vendors? I believe we should and apparently there are precedents for doing so. Having said all that I don't want this thread to continue the video codec discussion. What I want is a clearer position statement from WHATWG on the publics role in defining this specification. Shannon
Received on Wednesday, 19 December 2007 19:20:46 UTC