Re: Codecs for <video> and <audio>

On Fri, Jul 3, 2009 at 12:07 PM, Ian Hickson <ian@hixie.ch> wrote:

> I removed audio
> codecs section just for consistency and because in the big picture it
> doesn't make any sense to have just that section if we don't have the
> others (since as far as I'm aware, all the codecs that we could put in
> this section -- namely just Wave PCM -- are being implemented by everyone
> anyway).


As Doug noted, removing something from the spec because you know everyone's
going to do it anyway is absurd.

On Fri, 3 Jul 2009, Robert O'Callahan wrote:
> > One problem with taking private feedback into account is that clearly
> > some of that feedback is completely bizarre and inexplicable.
>
> Yup. In this instance the feedback had no effect on the spec and the
> relevant vendors were convinced to implement Wave PCM regardless of their
> opinion, so that's moot. I'm starting to really regret mentioning this at
> all...


In this instance, I believe you.

But as a general rule, I don't believe you alone can always provide the best
possible response to feedback.

> It's fine for people to send you private feedback, but taking it into
> > account when editing the spec is irresponsible.
>
> So if you ever point out a typo to me over lunch, I can't fix it? :-)


Obviously if something is uncontroversial beyond reasonable doubt, that's
not a problem. If you're not sure where the line should be drawn, I think it
would be OK to ask your lunch partners to email their typo discoveries to a
mailing list, or mention the person's name in the SVN commit. I'm sure
that's a tiny minority of all the feedback you get.

> > I really don't see much value in mentioning Wave PCM when we don't
> > > require any other codecs, image formats, etc.
> >
> > The spec should require other codecs and image formats.
>
> This would be pretty unusual for W3C specs. Why the change?


Doug pointed out other W3C specs that do this. Anyway, HTML5 is better than
other W3C specs, paying a lot more attention to the details required for
interop. Referencing codecs, image formats and other supporting formats is
part of that.

> will be looking there already.
>
> > HTML5 is a natural place for this, since authors using <img> or <video>
> Surely PNG support applies to SVG and CSS just as much, and XMLHttpRequest
> would need HTTP support as much (or as little!) as HTML, and so on. I
> don't see why this is HTML5-specific.


It's not. CSS should reference PNG, GIF and JPEG as formats that need to be
supported.

> Even if a better place can be found, why not follow your previous policy
> > of adding a section to HTML5 and moving it out if/when a better venue is
> > found?
>
> Because this isn't required for interop, and so it's not critical.
>

Of course common image formats and codecs are required for interoperability.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]