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
je...@iglou.com
