Slashdot Mirror

It's nice to see such advances in standards.
Unluckily, implementations (all of them) will either be partial or buggy or even both.
There's still little support for a tag as old as the COL. We can imagine what will happen: more browser incompatibilities.
What if this wonderful standards committee would ask for some commitment from the (main) implementers?
Just see how much the standards are taken into account by authors:
The R.I.P.E.
MIcrosoft

the functionality already exists
its called P3P from the w3c, it is specified in your headers on every request and specifies what the company who is setting the cookie does with your information
http://www.w3.org/P3P/

in IE8 > safety > web page privacy policy

Firefox supports P3P policies but its a convoluted setup and is well hidden from the user (why?)
http://mozilla.gunnars.net/firefox_help_firefox_cookie_tutorial.html#Advanced_Cookie_options

> You're comments show you haven't read the SVG specification

Uh... Trust me, I have. See http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=from&hdr-1-query=bzbarsky&index-grp=Public_FULL&index-type=t&type-index=www-svg

> SVG doesn't have timer support, its scripting language does, which is open.

I have no idea what "open" means in this case. SVG 1.2 Tiny support would presumably include support for the SVG 1.2 uDOM (that's the only profile of SVG 1.2 Tiny defined section 1.2.1 of the SVG 1.2 Tiny specification) which includes the things I listed in my comment. The uDOM is a language-independent interface specification; there is no "SVG scripting language".

> My SVG render supports setTimer in Javascript

I have no idea what setTimer is (nor does Google, in the context of SVG). The SVG 1.2 Tiny timer object is created via createTimer on the global object (typically the Window). See http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGGlobal_createTimer

Are you quite sure you've read the SVG 1.2 Tiny specification?

> I was going to go one

One what?

> your post translates into 'Firefox support for SVG is absolutely ass-tastic'

Firefox support for SVG 1.1 Full is sorta-ok (not great, by any means).

Support for SVG 1.2 Tiny is an explicit non-goal for every single browser implementor, because of the issues I mentioned. Given that when the browser implementors raised precisely these concerns during the standardization process the SVG Working Group basically told them that they weren't meant to implement this specification, I'm not sure why you're suddenly demanding that they do.

Now SVG 1.2 Full, which is being worked on, is a very different beastie. We'll see how it works out. It's probably a few years from being in CR (and hence call for implementations) at this point.

> You're comments show you haven't read the SVG specification

Uh... Trust me, I have. See http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=from&hdr-1-query=bzbarsky&index-grp=Public_FULL&index-type=t&type-index=www-svg

> SVG doesn't have timer support, its scripting language does, which is open.

I have no idea what "open" means in this case. SVG 1.2 Tiny support would presumably include support for the SVG 1.2 uDOM (that's the only profile of SVG 1.2 Tiny defined section 1.2.1 of the SVG 1.2 Tiny specification) which includes the things I listed in my comment. The uDOM is a language-independent interface specification; there is no "SVG scripting language".

> My SVG render supports setTimer in Javascript

I have no idea what setTimer is (nor does Google, in the context of SVG). The SVG 1.2 Tiny timer object is created via createTimer on the global object (typically the Window). See http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGGlobal_createTimer

Are you quite sure you've read the SVG 1.2 Tiny specification?

> I was going to go one

One what?

> your post translates into 'Firefox support for SVG is absolutely ass-tastic'

Firefox support for SVG 1.1 Full is sorta-ok (not great, by any means).

Support for SVG 1.2 Tiny is an explicit non-goal for every single browser implementor, because of the issues I mentioned. Given that when the browser implementors raised precisely these concerns during the standardization process the SVG Working Group basically told them that they weren't meant to implement this specification, I'm not sure why you're suddenly demanding that they do.

Now SVG 1.2 Full, which is being worked on, is a very different beastie. We'll see how it works out. It's probably a few years from being in CR (and hence call for implementations) at this point.

Haha. The W3C doesn't even use it on the "Accessibility" page that describes how.

http://www.w3.org/TR/WCAG-TECHS/H59.html

Oh yes, bleeding-edge W3C specs. Like CSS level 2, which was released in... 1998! Yes, I'm aware of CSS 2.1. I'm aware MS supposedly supports it. Yet 99% of the time, IE (in its various incarnations, this includes IE8 as well) is the only browser that gives me headaches when developing cross-browser sites. I really wish it would die a already.

Not with table-layout: auto (which is the default behavior). If you use table-layout: fixed it will dramatically reduce the render time, but you will have to specify the column widths (using the little-known COLGROUP tag).

One thing you can do to improve rendering speeds on auto-layout tables is to follow the W3C's spec and declare your footer before the body (so... THEAD, TFOOT, TBODY).

Opera web site is actually a pretty impressive piece of code. It has all that nifty stuff like drop-down menus, and yet it also renders perfectly in Lynx (with menus as lists) - disable CSS and JavaScript in your browser, and you'll see. Meanwhile, it validates to XHTML 1.0 Strict.

It shouldn't be surprising, however, given that Opera guys are pretty keen on all Web-related standardization efforts - they've played a big role in initiating HTML5 effort (and are still very active in its development), before that they've participated in past W3C HTML/CSS standardization efforts, and they push for open standards (such as SVG) otherwise.

Actually all this begs the question of what typographic controls are available? Can one access things like contextual ligatures and the ssalt## (stylistic alternates 1--20) tags?

This is all Greek to me, but my impression is "Not yet, but we're thinking about it." The recent www-style thread "advanced font features in CSS" seems to discuss this kind of thing. Not that I have the faintest idea what the features being discussed are.

Being able to embed "@font=sexagesimal.ttf" (or whatever the syntax is) would be very handy, but not if we're forced to convert our ttfs to Microsoft's worthless alternative format.

It's trivial to do with open-source utilities, such as ttf2eot for Linux. Not a big barrier, just serve both formats.

This isn't about protecting copyrights on fonts, its about Microsoft making sure IE isn't quite compatible with every other browser, and making sure we have to use their tools if we want anything to work on their dominant platform (and, if history is anything to judge by, eventually buy a license to do so).

Well, originally EOT might have been that. But it's been openly specified since March, months before any non-IE browser shipped web font support AFAIK. There's a fully open-source ttf -> eot converter.

(The only bit that's not an open standard at this point is MTX compression — Microsoft doesn't hold patents to that, Monotype Imaging does. Monotype has said they're willing to license them in a GPL-compatible fashion if browsers are willing to support the compression as part of a web standard [it looks like they're not]. In any event, you can ignore that if you're only encoding the fonts, not decoding: just don't use that feature.)

The reason to object to EOT is things like RootStrings. But again, you don't have to use those if you don't want to. One major contender for a future web standard all browsers are willing to support is some form of "EOT Lite" that's EOT with some objectionable features removed.

Now the real problem is largely solved but these font weenies are still coming-up with crazy schemes to make text look a certain particular way and it is pretty ridiculous the amount of effort that has been spent over the years on this with schemes that end-up only working for a few short years before something new shows-up on the horizone when for the most part electronic text is about information rather than the appearance. Don't try and tell me that this is simple until you look up EOT.

I'm not sure what you're saying here. EOT is a very thin wrapper around OTF, it doesn't deserve to be called a font format. You can read the EOT spec yourself: "FontData points to a TrueType or OpenType font whose format is specified in The Open Font Format (ISO/IEC 14496-22)." It just adds some metadata, some obfuscation, and optionally MTX compression.

Why is font licensing any different from image licensing?

Because Microsoft refuses to implement raw TTF support, for the sake of font foundries. If Microsoft didn't care, there would be no discussion: we'd just all use whatever preexisting format was most convenient. But now everyone has to actually care what the font authors think, because Microsoft says so. At least if you hope to get a single interoperable format, and not have to serve EOT+TTF forever.

FWIW, some Microsoft employees have said they think images should also have had some sort of impediments to casual unauthorized reuse, but it's obviously too late for that. You can read all the gory details if you go back through the www-font archives. There's been lengthy but scattered discussion on www-style too, including a gigantic thread just a month or so ago that moved to www-font when fantasai complained that it was off-topic.

I followed all the discussion for a while, but it's clear at this point that no one is going to agree on a format in the immediate future. The non-Microsoft browser vendors in the discussion (mainly Mozilla and Opera) seem content to take a wait-and-see approach. Meanwhile, none of the browser vendors have given a completely unambiguous statement of their requirements, so we don't know if there's even any common ground for a shared format even in principle. There seems to be the potential for agreement on a format that's obfuscated enough not to work out-of-the-box if you dump it on your desktop, plus served with same-origin restrictions by default. But the details have to be worked out, and nobody seems to be doing that.

So I don't foresee anything actually happening unless a rep from each vendor is locked in a room and they aren't let out until they shove a completed specification with all their signatures on it under the door. For now everyone will just serve two font formats.

Why is font licensing any different from image licensing?

Because Microsoft refuses to implement raw TTF support, for the sake of font foundries. If Microsoft didn't care, there would be no discussion: we'd just all use whatever preexisting format was most convenient. But now everyone has to actually care what the font authors think, because Microsoft says so. At least if you hope to get a single interoperable format, and not have to serve EOT+TTF forever.

FWIW, some Microsoft employees have said they think images should also have had some sort of impediments to casual unauthorized reuse, but it's obviously too late for that. You can read all the gory details if you go back through the www-font archives. There's been lengthy but scattered discussion on www-style too, including a gigantic thread just a month or so ago that moved to www-font when fantasai complained that it was off-topic.

I followed all the discussion for a while, but it's clear at this point that no one is going to agree on a format in the immediate future. The non-Microsoft browser vendors in the discussion (mainly Mozilla and Opera) seem content to take a wait-and-see approach. Meanwhile, none of the browser vendors have given a completely unambiguous statement of their requirements, so we don't know if there's even any common ground for a shared format even in principle. There seems to be the potential for agreement on a format that's obfuscated enough not to work out-of-the-box if you dump it on your desktop, plus served with same-origin restrictions by default. But the details have to be worked out, and nobody seems to be doing that.

So I don't foresee anything actually happening unless a rep from each vendor is locked in a room and they aren't let out until they shove a completed specification with all their signatures on it under the door. For now everyone will just serve two font formats.

Fantasy (also monospace) is one of the generic font types available already - see eg http://www.w3.org/MarkUp/Guide/Style (section: "Setting the font family") from 2002.

Actually, neither <i> nor <b> have been deprecated.

http://www.w3.org/TR/html5-diff/

They are both now considered semantic and not presentational. Think of the old manuals of style.

You joke, but between the Canvas and Web Socket standards, I don't see any reason why they couldn't.

Granted, WebSockets have yet to be implemented in browsers, but I hear Google owns a fairly popular one...

for the implementation of innovative technologies and up to date standards on the web, what with their own homepage's use of a table-based design, inline javascript, and .NET with an utter lack of validation.

Graphics:
http://www.w3.org/Graphics/SVG/
http://en.wikipedia.org/wiki/Canvas_(HTML_element)

Filesystem access:
http://www.w3.org/TR/offline-webapps/
http://gears.google.com/

Point is, there won't be much local filesystem access. Read the blog post again.

The software architecture is simple â" Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform.

..and..

They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files

Google expect all your data to be stored on their servers. All. Local storage is only a convenience in that it can act as a buffer that keeps things running while your're on the subway or otherwise temporarily offline.

Most importantly..

For application developers, the web is the platform.

That's it right there. There is no "native Chrome app", and local filesystem access is meaningless when the whole user experience takes place on a webpage. There is only the web.

[disclaimer: I'm not claiming this is a good idea! ;-) ]

Graphics:
http://www.w3.org/Graphics/SVG/
http://en.wikipedia.org/wiki/Canvas_(HTML_element)

Filesystem access:
http://www.w3.org/TR/offline-webapps/
http://gears.google.com/

Point is, there won't be much local filesystem access. Read the blog post again.

The software architecture is simple â" Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform.

..and..

They want their data to be accessible to them wherever they are and not have to worry about losing their computer or forgetting to back up files

Google expect all your data to be stored on their servers. All. Local storage is only a convenience in that it can act as a buffer that keeps things running while your're on the subway or otherwise temporarily offline.

Most importantly..

For application developers, the web is the platform.

That's it right there. There is no "native Chrome app", and local filesystem access is meaningless when the whole user experience takes place on a webpage. There is only the web.

[disclaimer: I'm not claiming this is a good idea! ;-) ]

If that's their concern, it should have been mentioned at the working group. Their paper never mentions the subject. Nokia, on the other hand, does mention the need for hardware decoding, and insinuates that Ogg is proprietary.

They've been un-deprecated in HTML 5:
http://www.w3.org/TR/html5-diff/#changed-elements
http://dev.w3.org/html5/spec/Overview.html#the-i-element

So continue using b and i without fear. They're still in HTML 4 (if "deprecated") and will almost certainly continue to be in HTML 5.

They've been un-deprecated in HTML 5:
http://www.w3.org/TR/html5-diff/#changed-elements
http://dev.w3.org/html5/spec/Overview.html#the-i-element

So continue using b and i without fear. They're still in HTML 4 (if "deprecated") and will almost certainly continue to be in HTML 5.

The use of i and b tags is (officially) discouraged. http://www.w3.org/TR/html4/present/graphics.html

Because the browser vendors are the W3C and WHATWG.

Work on HTML5 started when Apple, Mozilla and Opera founded the WHATWG (after becoming concerned about the W3C's focus on XHTML). The W3C subsequently adopted HTML5 again and is now dropping XHTML2.

The W3C is a consortium formed by member organizations with an interest in the creation of web standards. E.g. browser vendors.

Because the browser vendors are the W3C and WHATWG.

Work on HTML5 started when Apple, Mozilla and Opera founded the WHATWG (after becoming concerned about the W3C's focus on XHTML). The W3C subsequently adopted HTML5 again and is now dropping XHTML2.

The W3C is a consortium formed by member organizations with an interest in the creation of web standards. E.g. browser vendors.

Well, I don't quite understand if this is feature complete compared to XHTML (the missing metadata confuses me): http://dev.w3.org/html5/spec/Overview.html#mathml

I have been told that making page uses XML compatible HTML makes for a more predictable browsing experience and also lowers memory requirements.

You've been told wrong. Making your HTML or XHTML valid does make for a more predictable browsing experience, and may even lower memory requirements. Writing HTML that looks a bit like XML (e.g., using self-closing tags) and then serving it as HTML is completely pointless.

Looks like your whishes were heard
Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion â" with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation â" has wasted decades of productivity. This version of HTML thus returns to a non-SGML basis.
from the HTML 5 specs

It also deprecated a lot of the older tags that were made obsolete by CSS hence encouraging better separation of document structure and presentation. Unfortunately HTML5 undoes this particular good work because it caters to the lowest common denominator (i.e. bad developers who don't "get" separation of concerns and trivially parsable markup).

I think you read a different version of HTML 5 to me. It still deprecates or removes all of the tags that HTML 4 and XHTML 1 removed, for example removing the center and font tags which were only deprecated by HTML 4.

Where it introduces new tags, it is for expressiveness. A lot of the 'separation of content and presentation' folks seem to think that HTML just needs three tags; span, div, and object. HTML 5 doesn't add more presentation elements, but it does add more tags with well-defined semantics. Examples of this include section and nav tags. These don't specify anything about the presentation, they just indicate that a part of the document is a section, or a set of navigation commands. A mobile browser, for example, might have an option to hide and show the nav section to conserve screen space.

Take a look at the current draft of HTML 5. You'd be hard-pressed to find anything presentation-related. Presentation still goes in the stylesheets, HTML 5 just adds tags for common things so you don't need quite so many class attributes.

That's not true, check the spec such as here for some good examples:

http://www.w3.org/TR/html401/present/graphics.html#h-15.2.1

Stuff like bold, italic and so forth which are clearly presentational rather than structural elements aren't deprecated in HTML4.01 and similarly are not so in HTML5 although the meaning has changed somewhat it's not ideal.

Demonstrate something that HTML 5 "purposely breaks".

From Absent Elements and Attributes in HTML 5:

• HTML 5 removes the <tt> element. The dialect of HTML in use on Slashdot is known to use this element to mark up inline source code expressions instead of the proper <code>.
• The name attribute of the <a> element. The last time I tried to use id as if it were name in HTML (or in XHTML served as text/html), it didn't work. I filed a bug in bugzilla.mozilla.org about this issue years ago, but it got closed as either INVALID or WONTFIX.
• The accesskey attribute on several elements.
• Reverse link relations: <link rev="made" [...]> and all other values of the rev attribute.
• Attributes of the <object> element that allow a user agent to find software components capable of handling a given media type.
• The cellpadding and cellspacing attributes of <table>, because deployed versions of Windows Internet Explorer still don't understand the corresponding CSS.

Demonstrate something that HTML 5 "purposely breaks".

From Absent Elements and Attributes in HTML 5:

• HTML 5 removes the <tt> element. The dialect of HTML in use on Slashdot is known to use this element to mark up inline source code expressions instead of the proper <code>.
• The name attribute of the <a> element. The last time I tried to use id as if it were name in HTML (or in XHTML served as text/html), it didn't work. I filed a bug in bugzilla.mozilla.org about this issue years ago, but it got closed as either INVALID or WONTFIX.
• The accesskey attribute on several elements.
• Reverse link relations: <link rev="made" [...]> and all other values of the rev attribute.
• Attributes of the <object> element that allow a user agent to find software components capable of handling a given media type.
• The cellpadding and cellspacing attributes of <table>, because deployed versions of Windows Internet Explorer still don't understand the corresponding CSS.

But, XHTML has corrected many wrong thing that HTML developpers used to do.

No it hasn't! Writing valid code (be it HTML 4.01, XHTML, or HTML 5) and checking it with a validator is what has corrected many wrong things that HTML developers used to do. Valid HTML 4.01 is still just as legitimate as XHTML ever was.

So, I'm reading here that they convert the XML into proprietary metadata and compress that.

Why not use EXI (Efficent XML Interchange) http://www.w3.org/XML/EXI/ which has been tested as more efficient that gzip and requires less memory to parse? Especially since the XML processing can remain the same, since the nodeset is the same.

CSS3 does all you want: http://www.w3.org/TR/css3-page/

What you want to do already exists. The W3C released media specific stylesheets, which allow you to create an HTML page with CSS optimized for the specific media you're using. It's most frequently used to create "printer friendly" versions of webpages without having to maintain two separate files. There's even an author who used HTML/CSS to create a book.

Practical information about using media specific stylesheets can be found at these articles:
Printing a Book with CSS: Boom! by Haåkon Wium Lie, Bert Bos
ALAs New Print Styles by Eric Meyer

W3C information:
CSS Print Profile
CSS3 Module: Paged Media
XHTML-Print

What you want to do already exists. The W3C released media specific stylesheets, which allow you to create an HTML page with CSS optimized for the specific media you're using. It's most frequently used to create "printer friendly" versions of webpages without having to maintain two separate files. There's even an author who used HTML/CSS to create a book.

Practical information about using media specific stylesheets can be found at these articles:
Printing a Book with CSS: Boom! by Haåkon Wium Lie, Bert Bos
ALAs New Print Styles by Eric Meyer

W3C information:
CSS Print Profile
CSS3 Module: Paged Media
XHTML-Print

What you want to do already exists. The W3C released media specific stylesheets, which allow you to create an HTML page with CSS optimized for the specific media you're using. It's most frequently used to create "printer friendly" versions of webpages without having to maintain two separate files. There's even an author who used HTML/CSS to create a book.

Practical information about using media specific stylesheets can be found at these articles:
Printing a Book with CSS: Boom! by Haåkon Wium Lie, Bert Bos
ALAs New Print Styles by Eric Meyer

W3C information:
CSS Print Profile
CSS3 Module: Paged Media
XHTML-Print

You are trying to reinvent docbook. Not only is everything you want done, it is implemented in several tools (XMLMind and oXygen are two I know of), has a standard method of converting it to any form you want (XSL, XSLT, XSL-FO), and there are tools that are already written to take advantage of those standards (Apache FOP being a FLOSS one). The latest version of DocBook uses XML namespaces, so you can mix in other markup languages as well; the canonical example is DocBook + MathML + SVG, which covers 99.9% of the math/science based literature out there. BTW, if you DO plan on going down this path, I suggest picking up a copy of XSLT, 2nd edition by Doug Tidwell. The latest version of the DocBook book is supposed to be out in August; don't buy the version currently on sale, it is 10 years old, and does NOT cover the current version of DocBook.

CSS has had attributes for page breaks since CSS 2.1. I've not played with them for a while, but Opera supported them correctly back in 2003, so I'd imagine that they work well now. You can find the relevant part of the specification here. It lets you specify margins, soft breaks, rules for two-sided printing and so on. I played with the idea of using HTML instead of LaTeX for a while, but decided not to for two reasons. First, LaTeX is easier to type and read, and second because LaTeX produces nicer-looking output.

That example sounds like it could be well rendered using MathML... http://www.w3.org/Math/

Something that would make no use of CSS?

Given that CSS does this already, what's the advantage of adding another way of doing it without CSS?

This is exactly what CSS is designed for, presentation. The CSS3 Paged Media module already defines a number of the properties and settings you're going for. It even includes positions such as @bottom-center to allow you to position footnotes and references. The only thing missing is a way to mark this up in HTML, which could easily be done with anchors and the longdesc attribute, coupled with the CSS content: property. What you're looking for is a CSS3 enabled browser, not a new specification.

XHTML 2 is way cooler anyway. Why does anybody give a damn about HTML 5?

Perhaps because XHTML 2 is now officially dead.

Perhaps it is a stupid question but why do the vendors have a say what goes into the spec and what doesn't?

Because HTML5 started as a vendor effort (Mozilla & Opera initially, IIRC). It wasn't even a W3C spec then, it was designed by WHATWG - which was essentially founded specifically to design HTML5 and related specs.

Meanwhile, W3C was playing silly games with now effectively forgotten XHTML 2.0, which was all XML and neat and tidy, but totally backwards incompatible, so no-one bothered to implement it - not even FOSS projects.

HTML5 was developed by WHATWG for 3 years, and eventually the browser vendors on W3C working groups got the upper hand and voted for adopting it as a W3C draft. However, the people working on it are essentially the same as in WHATWG - representatives from all major browser vendors (Microsoft, Mozilla, Apple, Google, Opera). As such, it is on one hand a very pragmatic spec that meticuously documents many existing practices that are universal to all browsers, even when they're not very neat or even downright messy (e.g. content sniffing).

But on the other hand, it's fundamentally based on consensus and compromise - since it's meant to be a spec that browsers are actually going to implement, rather than end up like XHTML 2.0. It works towards pragmatic goals, and mandating support for a format that two major browser vendors out of five flatly refuse to support would work against that.

Perhaps it is a stupid question but why do the vendors have a say what goes into the spec and what doesn't?

Because HTML5 started as a vendor effort (Mozilla & Opera initially, IIRC). It wasn't even a W3C spec then, it was designed by WHATWG - which was essentially founded specifically to design HTML5 and related specs.

Meanwhile, W3C was playing silly games with now effectively forgotten XHTML 2.0, which was all XML and neat and tidy, but totally backwards incompatible, so no-one bothered to implement it - not even FOSS projects.

HTML5 was developed by WHATWG for 3 years, and eventually the browser vendors on W3C working groups got the upper hand and voted for adopting it as a W3C draft. However, the people working on it are essentially the same as in WHATWG - representatives from all major browser vendors (Microsoft, Mozilla, Apple, Google, Opera). As such, it is on one hand a very pragmatic spec that meticuously documents many existing practices that are universal to all browsers, even when they're not very neat or even downright messy (e.g. content sniffing).

But on the other hand, it's fundamentally based on consensus and compromise - since it's meant to be a spec that browsers are actually going to implement, rather than end up like XHTML 2.0. It works towards pragmatic goals, and mandating support for a format that two major browser vendors out of five flatly refuse to support would work against that.

From the HTML5 spec:

"This specification does not specify which image types are to be supported."

As was argued by the original author, you're left in a situation where if Ogg were specified in the standard, you'd have folks who followed the standard at a disadvantage in quality and/or bitrate.

The idea was not to restrict the supported codecs to Theora. The idea was to mandate at least Theora support. The way HTML5 video element is specified, you can provide several streams in various formats, letting browser pick the preferable one automatically. Mandatory Theora support would simply mean that everyone could provide one of the streams in it, and know that any browser can display it out of the box. Presumably, if e.g H.264 is also provided, all browsers that support it would just pick it, so there's no quality loss.

Besides, W3C doesn't say which image file formats are allowable, why should it specify a codec?

Not specifying image formats proved to be a problem - witness how long it took PNG to be supported, in part because of that. In addition to that, HTML5 is by far the most pragmatic of all W3C specs - it's designed by people who actually make browsers, not by academics, and as such it tries to standardize as many useful (or simply already common) things as possible, to encourage interop.

It's interesting to note, however, that HTML5 spec explicitly refuses to mandate support for any image types:

"This specification does not specify which image types are to be supported."

I agree that if they want to mandate a specific codec for video, they should do the same to images as well. We may have a de facto standard for that today, but it needs not be a stable state of affairs.

From the HTML 4.01 Spec:
src = uri [CT]
This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG.

Now true, that doesn't say that any formats are recommended, well at least not until you head to the W3C PNG specification:
http://www.w3.org/Graphics/PNG/

They also have a nice section on SVG:
http://www.w3.org/Graphics/SVG/

From the HTML 4.01 Spec:
src = uri [CT]
This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG.

Now true, that doesn't say that any formats are recommended, well at least not until you head to the W3C PNG specification:
http://www.w3.org/Graphics/PNG/

They also have a nice section on SVG:
http://www.w3.org/Graphics/SVG/