Specifying codecs for the web

Posted Dec 13, 2007 10:28 UTC (Thu) by ekj (guest, #1524)
Parent article: Specifying codecs for the web

Why can't we get audio and video-tags that work similar to the existing img tag then ?

The img tag does not specify the encoding of the src= referenced image, it just gives the adress. The encoding is specified by the mime-type of that image, and indeed the type of image can be auto-negotiated on the basis of the web-browsers accept: header.

Sure, it's an annoyance that, for example, png-support in some browesers is flaky, and it'd be nice if there was something besides gif/jpg that you could be certain would be supported across the board, but there isn't and somehow we still manage.

Due to popularity, I'm fairly certain all major browsers would support wav and mp3, ogg and flac would be nice, but essentially, if a browser-vendor says: "we won't do that", then they won't -do- that, wishful thinking notwithstanding.

Having it in the standard wouldn't nessecarily help much in practice. There are LOTS of stuff that are in the standards, and has been for a long time, but where you -still- can't use it and trust that it works universally, because a major browser does not infact implement it. There's not many websites actually using fig for anything ....

to post comments

Specifying codecs for the web

Posted Dec 13, 2007 15:30 UTC (Thu) by vmole (guest, #111) [Link] (1 responses)

The whole point of this is to establish baseline support that would be required for HTML5 compliance, so that a provider could rely on the presence of certain codecs, just as they can rely on jpg and gif being displayed correctly.

Specifying codecs for the web

Posted Dec 13, 2007 17:28 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

But none of the major vendors are likely to obtain HTML5 compliance, unless its by watering
down the standard to contain mostly SHOULDs that they can decide not to implement.

HTML is a very qualified success. Tag soup has won out for the most part. Things have improved
in the last ten years, but not very quickly. Can you think of a web browser people use that's
HTML 4 compliant? Not "nearly" or "sort-of" or "the important bits" but the HTML 4 standard as
published ?

Last time I looked Mozilla.org still had bugs open against rarely used HTML features dating
back to the start of the project in the 1990s.

I'm not completely sure I understand how this happened, but one thing that definitely had an
effect was the encouragement to "edit in Notepad" without tools that could verify the
resulting document meant anything, let alone what was intended by the author. Modern tools
have much reduced this tendency (most people now create content in Wikis or blogs where they
can type an ampersand without making the site fail validation).