W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2007

[whatwg] The political and legal status of WHATWG

From: Shannon <shannon@arc.net.au>
Date: Thu, 20 Dec 2007 14:20:46 +1100
Message-ID: <4769DF8E.5040908@arc.net.au>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:38 UTC