[whatwg] Codecs for <audio> and <video>

[Jeff McAdams]

Ian Hickson wrote:
> I considered requiring Ogg Theora support in the spec, since we do have 
> three implementations that are willing to implement it, but it wouldn't 
> help get us true interoperabiliy, since the people who are willing to 
> implement it are willing to do so regardless of the spec, and the people 
> who aren't are not going to be swayed by what the spec says.

Ian, first off, thank you for your efforts to this point, your patience 
in the face of conflicting opinions has been awe-inspiring (and I'll 
certainly include my messages in the set of those requiring patience 
from you)

I feel I have to disagree a bit with what you say above, though.

Yes, clearly publishing the spec with a baseline codec specified isn't 
*sufficient* for definitively "get[ting] us true interoperabiliy[sic]", 
but it certain does *help* get us true interoperability, in two ways 
that I can think of off the top of my head.

First, there is some inherent pressure for implementing the spec. 
Again, some parties have indicated that it is not enough to get them to 
do so, but that eliminates their ability to claim adherence to this 
standard when others are doing so.  (Well, to truthfully claim, anyway. 
  I don't think any of the parties involved here are unscrupulous enough 
to claim compliance when they don't actually comply because of the lack 
of this codec support, but other, non-engaged parties certainly might). 
  Specifying a baseline codec takes away a marketing bullet point that 
can be used to sell their product, while hurting interoperability.

Second, it gives us (people like me) an extra tool to go back to vendors 
and say, "Hey, please support HTML5, its important to me, and the 
<video> tag, with the correct baseline codec support, is important to 
me."  Without the baseline codec being specified, it takes away a lot of 
our leverage, as customers of companies that have said they won't 
support this, to push on them.  (I, personally, as a single data point, 
use a Mac, and mostly to this point use Safari, but have already made 
sure I've gotten the Firefox 3.5-mumble-not-yet-released that has the 
<video> tag support so that I can begin making use of it to some degree, 
and plan to do so more in the future).  Certainly you, of all people, 
can appreciate the benefits to interoperability that we've seen through 
publication of the ACID tests.  No, they aren't full compliance tests, 
but look at the public pressure that has been brought to bear on browser 
makers by the public's awareness of them.  Look at how much better the 
interoperability has gotten over the same period.  No, its still not 
perfect, by a long shot, but at least now we're moving in the right 
direction.  Give us, the end users, the tools we need to help bring that 
pressure for interoperability to bear on the browser makers.



There is one thing that I'm not quite clear on, however.

You've said a couple of things that I perceive as contradictory, here. 
You've said that you want to help bring about interoperability, but then 
you've also said that you're only documenting what it is that the 
browser makers are implementing.  There is room in the standards bodies 
world for both goals, and both goals, at times are valid and beneficial. 
  But, if your intent is to help bring about interoperability, *real* 
interoperability, then I think its pretty clear that the way forward 
involves specifying a baseline codec.

Leaving such an important point of interoperability completely up to the 
whims of "people out there" seems unwise here (I look at MS's latest 
attempt at supporting ODF as a great example of how interoperability can 
actually be harmed, even by a "complying" implementation, when important 
parts of guidelines to interoperability are left out...there are plenty 
more examples).

I think its nearly imperative that important points of interoperability 
contention such as this be specified, else it gives unscrupulous 
developers the ability to intentionally worsen interoperability and 
making the spec considerably less valuable by developing an 
implementation that is "compliant", but not interoperable with anyone 
else ("Oh, I implemented <video> using animated gifs"...yes its absurd, 
but someone could, at least in theory, claim compliance that way).  I 
would also point out that scrupulous developers could unintentionally 
worsen interoperability in the same way.  By allowing this opening, 
end-users see browsers that have the "HTML5" stamp (figuratively), but 
their browsing experience suffers and they start to lose faith in the 
spec as actually meaning anything useful regarding the reliability of 
their browsing experience.

Again, thank you for your efforts, and add me to the camp of believing 
that the baseline codec is vitally important, even without all of the 
browser makers being willing (at least initially) to support it.

-- 
Jeff McAdams
jeffm at iglou.com