I'm currently on parental leave till September. During that time, I will not read any e-mail or blog comments.

Until I'm back, please read through my archives, take a look at my code/applications and check out my pictures.

Have a great summer, and a splendid winter to you aussies and kiwis!

HTML 5 or XHTML 2?

Published on Monday, February 5th, 2007

Vlad Alexander has written an article entitled X/HTML 5 Versus XHTML 2, discussing what he likes respectively dislikes.

Negative Robert

While I think that both specifications are interesting and definitely contain some nice enhancements, I can’t help but think when, and maybe even if, any of these will be ready for prime time. Maybe I’m just jaded, but for sure there will be endless discussions about which will be the best, different implementations in different web browsers and so on, et cetera…

And just add Tim Berners-Lee’s thoughts and the HTML Working Group Charter to that. Does anyone see a happy united best outcome of this?

Positive Robert

Let’s take a look at some goodies mentioned in the article:

XHTML 2

Any element can contain a href attribute and therefore be a link. Great!
acronym is out. Good riddance! Definitely the way to go to have just one element for that purpose.
The h element and headings sections. Nice!
hr replaced by separator. Hey, that’s a good name, why didn’t we think of that before (anyone seen code like this before: <hr class="separator" />)?
The new role attribute, to add more semantic meaning to an element. Just take a look at these babies: The XHTML Role Attribute! Fantastic! Well needed!

Web Applications 1.0/HTML 5

The dialog element, for, you guessed it: dialogs!
The perfect element, figure, for images and its accompanying text.
Finally, some nice additions to input elements and their data types:
- email
- URL
- date-related
- time-related
- numeric data

Discussion

What’s your take on this? Does any technology seem more interesting than the other? Is any specification/concept generally better than the other, and why? Or, are you better off as we have it right now, maybe with a slew of Microformats thrown in?

Both I and Vlad would sincerely appreciate your input on this, and your thoughts and hopes for the future of the web!

Posted in Developing, HTML/XHTML, Technology | 34 comments

34 comments

George
February 5th, 2007 at 10:18

Nice write up. XHTML 2 certainly looks good and I can only see Microformats growing to increase the semantic holes in XHTML, especially as it will probably take an age to implement. I know a lot of people get irritated by the constraints of XHTML but I prefer it. Perhaps I’m anal…

Little mention of XML and XSLT has been made in these discussions. Combined with CSS and good semantic markup (XHTML or HTML) they are quietly transforming how the web works.

XSLT for example can transform a correctly marked up Microformat into pretty much anything. For me that is more interesting than deciding which dialect of HTML to use.
trovster
February 5th, 2007 at 10:43

The role attribute just seems like consistent/specific ID names for certain common areas, such as navigation. Could be useful, but could be used nowadays if microformats decided to implement a similar thing - consistent naming conventions for sections within a page.

The href attribute on every element might be useful, but I’m unsure how well Joe Public will handle it. They’re used to text (and the odd image) being a link (with an underline and the cursor change). But when you add it to large blocks, what is going to happen?

The figure element is very interesting considering the amount of times you have an image then a description (although, I use a definition list), and I’m sure the dialog element will plug in some hole, but I’ve never had to use it.

I love the required attribute and the whole webforms in HTML5.

section and h are very interesting and will mean user-generated content (from CMS) will adhere nicely to the correct nesting of headings.
Jarvklo
February 5th, 2007 at 12:37

Hmm…
On the subject of seeing a happy united outcome of these discussions…

Take a look at the two suggestions made in the (somewhat compact but very interesting) post http://web-graphics.com/2007/02/01/the-time-to-abandon-backwards-compatibility-is-now-microsoft/

Maybe something along those lines could serve us well during the transition to “(X)HTML-the next generation” (whatever it will be based on or include in the end)…

Well - It’s a nice dream isn’t it?
Carl Camera
February 5th, 2007 at 16:37

What about application/xhtml+XML? Can we make it optional or kill it off altogether? This XHTML 1.1 requirement seems to have impeded XHTML 1.1 adoption. I fear it would impede adoption for any future standard also.

Browsers could be free to receive the document as text/html, test the document, and if it is well-formed, parse it more efficiently. If not well-formed, hand it off to the tag soup parser. Am I being naive about how browsers work? Is this a reasonable request?
Jonathan Rascher
February 5th, 2007 at 16:41

I’m not sure which is necessarily a better standard, but I think HTML5 will do much better in the real world. It’s backwards-compatible with HTML4, and parts of it have already been implemented in browsers (canvas and some forms improvements). XHTML2 is much more of a departure from previous versions of (X)HTML. I do understand and support the desire to make HTML more semantic. I just think XHTML2 is too radical to ever be widely adopted.
Steve Williams
February 5th, 2007 at 17:02

Personally, I’d cull XHTML 2 altogether (what’s the point when 85%+ of users still cannot receive it correctly) to concentrate on HTML 5 and for the medium term, a move to XML or even UML.

Longer term I expect to see web development managed through Final Cut Pro style authoring interfaces, rather than the hand coding we know and love.
Stefan Van Reeth
February 5th, 2007 at 18:56

To me, they look both promising. Maybe a merge of the two would be a nice idea, if not that this would take forever to finish :).

But I wouldn’t bother too much at this moment, since they both will take ages before release, let alone that browsers support also takes long. Even now browsers are struggling to support css2 and XHTML 1.0 (not to mention 1.1) to the letter, while both standards are getting pretty old now.

Yeah, I know, not all browsers adopt new technology slow. But since a great majority of users still uses IE, we’re kind of stuck with what it supports. Unless you love to make browser-dependant pages off course. In that light I don’t expect to do much coding in HTML 5 or XHTML 2 any time soon.
Sean Fraser
February 5th, 2007 at 20:02

I like what HTML5 offers. Further, it removes all arguments for which is better, HTML 4.01 or XHTML 1.0: all well-formed sites with DOCTYPE HTML + text/html would be HTML5. HTML5 can be used this afternoon. One notable site is W3C Web API Working Group which uses DOCTYPE HTML. And, it conforms as HTML 5 in the HTML5 Checker and as HTML 4.01/Strict in the W3C HTML Validator (after switching doctypes).

I don’t have a constructive opinion of XHTML 2.0. Though, if the W3C - Truly -believed it is the future of web applications, Why bother resurrecting the HTML WG? MSIE, perhaps.

I agree that it will be interesting to see what occurs over coming months between the W3C and WHAT working groups.

I don’t know if you have seen it but Help-WHAT.org is the new mailing list for general HTML5 questions.
JMG
February 5th, 2007 at 20:21

And now we’ll have to choose between HTML and HTML… Great. That’s the dumbest thing that could happen : having many different standards and specifications.

Having multiple thinking groups working to get the HTML better is a wonderful idea, and you cite such great ideas from both camps. But having great idea in each specification lacking in the others ? That’s just stupid.

Let’s hope we won’t end up with multiple new HTML specs. Browser support is already lacking, what will happen with multiple standards ?
Tsevdos.com » HTML 5 (Web Applications 1.0) ÎµÎ½Î±Î½Ï„Î¯Î¿Î½ XHTML 2.0
February 5th, 2007 at 21:36

[…] ‰Î½Î®ÏƒÏ‰ Î¼Îµ Ï„Î¿Î½ Robert Nyman Î¿ Î¿Ï€Î¿Î¯Î¿Ï‚ ÏƒÏ‡Î¿Î»Î¹Î¬Î¶Î¿Î½Ï„Î±Ï‚ Ï„Î¿ Î¬ÏÎ¸ÏÎ¿ Ï„Î¿Ï… Vlad Alexander, Î±Ï€Î»Î¬ Ï…Ï€Î¿ÏƒÏ„Î·ÏÎ […]
Douglas Clifton
February 6th, 2007 at 0:00

There’s an old joke: “The nice thing about standards is thereâ€™s so many to choose from.”
Robert Nyman - author
February 6th, 2007 at 9:37

Thank you everyone for your input. Very good and thought-worthy!
Tommy Olsson
February 6th, 2007 at 10:58

Browsers could be free to receive the document as text/html, test the document, and if it is well-formed, parse it more efficiently.

Forgive me for being blunt, but that’s a terrible idea!
That would require two passes to parse a well-formed XML document.

The whole point with serving something as XML is that user agents can expect the document to be well-formed. Thus they can use their fast, light-weight XML parsers and refuse to continue at the first hint of an error.

What in the world is the point of using XHTML markup if you’re serving it as HTML? A user agent must treat that as HTML, so any XML features will be unusable.

I think that ‘allowing’ XHTML 1.0 to be served as text/html is one of the biggest mistakes the W3C have made. Real XHTML (with XML benefits) will never catch on as long as people are allowed to slap an XHTML doctype declaration on any tag soup mess.
Carl Camera
February 6th, 2007 at 18:00

Tommy, do any browsers today behave as you describe? It’s my experience that many documents served via application/xhtml+XML are not well-formed XML. Furthermore, the browsers that support that MIME type don’t refuse to continue as you state above; they do their best to render the page.

Browsers don’t need a MIME type to “expect” well-formedness for lightweight processing — the DOCTYPE should be a sufficient indicator.

I suppose my point is that serving pages as XML doesn’t mean they are XML and browsers that support lightweight XML parsing handle malformed documents via tag soup parsing anyway…so what good has the MIME type served?
zcorpan
February 7th, 2007 at 3:14

Carl, yes browsers behave as Tommy described (except for mobile browsers, which generally do what you describe, and they are non-conforming). If you don’t see it then you’re probably still actually using text/html.

The doctype doesn’t indicate anything, except for text/html where it indicates whether the browser should use standards mode layout or quirks mode layout. In particular it does not and cannot indicate that the document is XML.
Tommy Olsson
February 7th, 2007 at 7:39

Carl, at least Opera, Firefox (et al) and Safari behave this way. A compliant XML parser must abort when it encounters a well-formedness error. Gecko browsers show the infamous Yellow Screen of Death, while Opera first tries to render the document up to the point of error.

The DOCTYPE declaration is pointless (in this respect) for several reasons: it isn’t required; it is only available in SGML-based documents; and it’s located within the file. A user agent needs to know the content type before it starts reading, because that information is crucial when choosing how to handle the document.

If the content type is ‘application of XML’ the UA can choose an XML parser and expect well-formedness. If the content is ‘HTML’ the UA can choose its HTML parser (a.k.a. tag soup parser). If the content type is ‘JPEG image’ the UA can call its functions for displaying the image, and so on.

I suppose my point is that serving pages as XML doesnâ€™t mean they are XML

Yes they are. Or, rather, a UA must assume that they are and parse them as XML. If the document isn’t in fact XML, the parser must abort with an error message.

In the same fashion, if the content type is ‘text/html’ the UA must handle it as HTML. Even if the DOCTYPE declaration says it’s XHTML or if it’s really a JPEG image.

That’s the whole point of sending a MIME type in the Content-Type header: to tell the UA beforehand what type of content it can expect. The UA must believe this and act accordingly. The content sniffing that IE/Win does for ‘text/plain’, for instance, is horrible and contrary to the specifications.
zcorpan
February 7th, 2007 at 8:49

As a response to the original article…

Implementation Of Sectioning Elements
Why would div with a role be any simpler to implement than elements? With roles you can have situations where a div is all of an aside as the main content and a footer and a checkbox at the same time; that cannot happen with element names.

Why is <nl> better than <nav>? A navigation section isn’t always a list, it could equally well be a table or a paragraph or anything else. <nl> can only be used if you have a list.

How do you suggest we improve sectioning elements?

HTML 4 And XHTML 1 Faults Are Perpetuated Into A Future Spec
Faults in HTML4 and XHTML1 can be fixed.

I don’t understand your view on backwards compatibility. Browsers only have one implementation of HTML, or perhaps two (quirks and standards). The more code paths you have in your implementation the more development cost and time, which is not a good thing. Forcing browser developers to add yet another code path when it can be avoided will probably just lead to the spec being ignored by browser vendors.

The problems of numbered headings have been addressed with sectioning elements. The numbers get normalized so it doesn’t really matter which number you use, indeed you could use <h1> for all your headings just like you would use <h> for all your headings in XHTML2.

<i>, <b> and <small> have been added to address the need of being able to mark up things that have typographical convensions but don’t have specific semantic elements in HTML. Using <span class> for all those cases doesn’t really improve anything. <iframe> is heavily used by the advertizing industry, and it is an interoperably implemented mechanism to embed an HTML document into another. Forcing authors to use a less interoperably implemented mechanism to do the same doesn’t really improve accessibility.

X/HTML 5 Does Not Comply With The X/HTML 5 Charter
Being backwards compatible does not mean that you have to include all elements the previous version had. (User agents are expected to continue supporting the elements it already supports but are not part of HTML5.) It also doesn’t mean you can’t redefine semantics. However, for all intents and purposes, in the case of <i> and <small> an HTML5 UA would pretty much do the same as an HTML4 UA.

HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.

What, The font Element Is Supported?
<font> was added because the state of art in WYSIWYG editors don’t yet have a way to deal with semantics, so it’s better to allow them to insert presentational markup when presentation was called for than to try to force the author to use semantics. WYSIWYG isn’t going away any time soon so ignoring them doesn’t lead to better results. (WYSIWYG editors are of course free to deal with semantics and ignore <font>, though.)

WYSIWYG Signature
This has only to do with document conformance (that WYSIWYG editors are allowed to use <font>). It’s an open issue though, and as with anything else in the spec, it may be changed or removed.

Support For Predefined Class Names
Class names are not CSS class names. They have nothing to do with CSS. Essentially, if I understand role=”" correctly (there are some predefined values and it can be extended), it is the same as role=”" except simpler and it was already present in previous versions of HTML.

As with the role=”" attribute, the issue with multiple values has to be looked at to see if it would cause any problems.

HTML 5 Versus XHTML 5
If you want to use XML then use XHTML5. If you don’t want to use XML then use HTML5. Both are fine. If you want to use both at the same time then you can do that too. You have to jump though hoops to do so but those are the same hoops as Appendix C anyway.

If you think there’s too much to choose from then use HTML5. It is compatible with browsers and search engines, and if you want to use it with your “XML tool chain” then all you need to do is replace the XML parser with an HTML5 parser and the XML serializer with an HTML5 serializer.

A Too Hasty Process
The specs, or at least the WF2 spec, started before the WHATWG was created. HTML5 is not a result of too slow process at the W3C, it is a result of browser manufacturers disagreeing with the vision of the W3C with regards to the future of HTML and web applications. The estimated shedule is 15 years for HTML5 to become a Recommendation — you’re the first to say it’s too hasty. The unrealistic timelines and milestones you referred to are the ones the new W3C HTML WG Charter suggested.

Thanks for the feedback!

Cheers,
Robert Nyman - author
February 7th, 2007 at 9:43

Thanks for keeping up the discussion!

zcorpan,

I’ve asked Vlad to read your comment.
Harmen Janssen
February 7th, 2007 at 11:01

Wow, both XHTML 2 and HTML 5 have some great new additions! h, role and the disappearance of acronym sound great.
The new and improved forms in HTML 5 sound great too.

What I don’t understand is; why are these new things specific to either XHTML 2 or HTML 5? Why can’t HTML 5 drop the acronym element too? Why can’t XHTML 2 have cool forms?

All in all I’m a bit skeptical and don’t expect to have to change the way I work anytime soon, ’cause it probably is gonna take ages for browsers (and especially IE) to implement the good stuff.
Carl Camera
February 7th, 2007 at 18:13

@Tommy, Thank you — message is well received. I learned something today and I appreciate the explanation. If you’re coming to SxSW this year, I’ll gladly buy you a beverage of your choosing.. Robert — sorry for sidetracking the original post topic.
zcorpan
February 7th, 2007 at 18:38

Harmen, HTML5 does drop <acronym>. XHTML2 does have cool forms (XForms).

The main difference is not the feature set, but the compatibility with existing content on the web, current authoring practice and existing implementations.

With HTML5, you don’t have to change the way you work even when you want to start using the new stuff (i.e. when they’re implemented in browsers). You just start to use the new stuff and it will work.

HTH,
Vlad Alexander
February 7th, 2007 at 18:51

How do you suggest we improve sectioning elements?
1) Predefined sectioning elements are not extensible. You have to modify the spec to add new sectioning elements in the future.

2) Predefined sectioning elements are too generic and waste the opportunity to add real domain-specific semantics.

3) Vendors of visual Web browsers have to write code to support new elements even if new elements do the same thing from a visual perspective.

If I understand correctly, sectioning elements carry 2 semantics:

1) This is a section.

2) This section is of type X.

The first is independent of the second but the second is dependant on the first. So you would need a two-part construct to model this relationship. I suggest instead a single element with an attribute. For example:

&ltsection>

and

<section role="navigation">

Or, I suggest using a div element instead of section.

Why is nl better than nav?
The spec defines nav as “a section with navigation links”. If you start adding content into this section like tables and paragraphs, this section bulks up and loses its value to future devices that could use this construct for presenting page navigation in a separate window. And the nl element could be very useful for small screen devices.

Faults in HTML4 and XHTML1 can be fixed.
1) X/HTML 5 does not fix them.

2) If it did fix them, then it would not be backwards compatible.

The more code paths you have in your implementation [of Web browsers] the more development cost and time…
Building an XML rendering engine (like XHTML 2) is much simpler than enhancing HTML rendering engines. I speak from experience. It is so complex to build a good tag soup rendering engine that current Web browser vendors have created a barrier to entry by encouraging tag soup. What is the business incentive for current Web browser vendors to encourage valid markup?

The numbers [in numbered heading] get normalized so it doesn’t really matter which number you use…
If that won’t confuse content authors then I don’t know that will. It’s kind of like Alice In Wonderland where things aren’t really how they appear.

iframe is heavily used by the advertizing industry
So is this the real reason browser vendors and search engines are against XHTML 2? Seriously, we all benefit from advertisement programs on the Web. Programs like AdSense from Google financially supports small content providers, which is great. But currently these programs do not work when content is served as XML. I would hope that W3C addresses the needs of ad providers even if it means adjusting the XML spec. Let’s find a non-iframe solution to this very important issue.

Being backwards compatible does not mean that you have to include all elements the previous version had.
This is objective and I bet one can use “set theory” to disprove this.

It also doesn’t mean you can’t redefine semantics.
This is subjective so we can go back and forth on this for a while.

HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.
Great. I think you will find that X/HTML 5 is “compatible” with HTML 4 and XHTML 1 but not “backwards compatible”. But I hope you will also see that there is no need to be backwards compatible.

font was added because the state of art in WYSIWYG editors don’t yet have a way to deal with semantics
We have been producing a WYSIWYG editor that does not have a font selector or a color picker for over 3 years. It’s not rocket science. If we can do it, anyone can.

it’s better to allow them [WYSIWYG editors] to insert presentational markup when presentation was called for than to try to force the author to use semantics.
When you give a WYSIWYG user a font selector and a color picker, they will use them instead of semantic markup. Accessibility goes out the window

WYSIWYG editors are of course free to deal with semantics and ignore font
Guess what, it’s easier to sell candy than carrot sticks.

WYSIWYG isn’t going away any time soon so ignoring them doesn’t lead to better results.
But that is what the spec does - it ignores WYSIWYG editors by letting them do what they want. I see great parallels between the environmental movement and Web standards. WYSIWYG editors are like the polluters of the Web and spec writers are like regulators. In this case the regulators are looking the other way.

Class names are not CSS class names. They have nothing to do with CSS.
Not if you use the class attribute. The spec “overloads” the meaning of class. And also creates opportunities for conflict with existing documents that use class names that will only be predefined in the future.

If you want to use XML then use XHTML5
Here is the problem. The XHTML 5 spec is saying don’t use XHTML 5 when they say “generally speaking, authors are discouraged from trying to use XML on the Web”. Look, if the authors of the spec feel strongly about this, then they should simply dump XHTML 5. Let’s either treat XML as an equal to HTML or dump it!
Lachlan Hunt
February 8th, 2007 at 1:29

OK, it seems that many people fail to realise that there is no debate about HTML5 or XHTML2, the answer is HTML5.

In it’s current state, XHTML 2.0 is virtually impossible to implement. If they go through with their plan to re-use the XHTML 1.x namespace, it will be totally impossible to implement.

Nothing in XHTML 2.0 is well defined. in fact many things are very much undefined.

XHTML2 changes <script> to <handler>. HTML5 just sticks with <script>

XHTML2 reuses <input> for XForms, without using the XForms namespace (so basicallly, xhtml1:input is being redefined in a backwards incompatible way). HTML5, on the other hand, uses incremental improvement and retains backwards compatibility.

XHTML 2.0 adds <h> for headings, retains the numbered (<h1> to <h6> ) headings, yet fails to define how they interact with regards to the structure of the document. HTML5, on the other hand, retains the numbered headings, yets adds the same functionality as XHTML2 in a much more well defined way.

XHTML2 adds href, and other attributes, to almost every element. Browser vendors have reported that this would be extremely difficult to implement, and probably won’t be.

XHTML2 fails to define any error handling, beyond the draconian handling of XML. Error handling needs to deal with more than just syntax errors! e.g. bogus attributes or incorrect values, unknown/unexpected elements, etc.

HTML5 already has many features implemented in major browsers. XHTML2 is not, and will not be, implemented by any major browser.

Basically, HTML5 can do everything that XHTML2 can do, and much more.
Robert Nyman - author
February 8th, 2007 at 8:31

Again, I really appreciate this discussion and the great input. Thank you!
Siegfried
February 26th, 2007 at 15:35

Hi,
xhtml2 offers much more for the future. Mainly exactly because it is not backwards compatible. But then if you see that the most used browser in the real world does not even understand xhtml1.0 you can be sure that html5 will be adopted sooner. And indeed it has some nice features. And so why not?

This is somewhat similar to microformats (aka lightweight semantic web) vs. rdf: One is at hand now and usable now but limited, the other is very very promising but it is future.

But then, one day this future will be the current day and today will be past and forgotten. So basically we need both: What we can have and use now, we should use now, but without letting the real future out of sight.
Axel Rauschmayer
March 2nd, 2007 at 0:58

The HTML5 FAQ should recommend a route away from the current tag soup chaos. I was really worried that this was not a goal any more (considering the negative tone about XML). The following blog entry partly allayed my fears: http://blog.whatwg.org/html-vs-XHTML

Still, the HTML5 FAQ should make it clear that having easily parsable (X)HTML is still a long-term goal.
Axel Rauschmayer
March 2nd, 2007 at 1:21

As for microformats: I really like RDFa as a longer-term (and much more extensible) alternative.
Robert Nyman - author
March 2nd, 2007 at 9:37

Siegfried, Axel,

Thanks for your comments!
Jens Meiert
March 19th, 2007 at 20:48

German readers, there is an revised and improved German translation available now.

You’re right, Robert, it’s a nice article
Anita Hardick
May 3rd, 2007 at 10:40

I have a question that I hope will be answered soon. I have an idea for the most incredible website and since I am still technichally challenged, I need to have feedback from those of you that have the experince and knowledge to coach me through the process of creating my delicious website.Of course the extreme adult content I have planned has been the reason I am seeking your input. Thank you
Thoughts on HTML 5 - Robert’s talk
June 7th, 2007 at 22:31

[…] HTML 5 or XHTML 2? Posted in Technology, Developing, HTML/XHTML | Share your thoughts […]
Michael
May 19th, 2008 at 4:51

For those of you complaining about the ad industry, don’t worry. s is being dropped in favor of . Object can include any type of content, including Flash or TagSoupML in an XHTML2 document.
Michael
May 19th, 2008 at 4:52

For those of you complaining about the ad industry, don’t worry. iframes is being dropped in favor of object. Object can include any type of content, including Flash or TagSoupML in an XHTML2 document.
Dustin Boyd
May 30th, 2008 at 6:46

I’m not a fan of the way (X)HTML5 is being designed. If it is served as HTML, the document is HTML5, but if it is served as XML or XHTML, then the document is (X)HTML5. What I don’t like is the fact that an (X)HTML5 parser will be required rather than a normal XML parser. It defeats the purpose of using XML, IMHO. This fact alone causes a fundamental problem - DOCTYPEs will be used for more than switching browsers into standards mode still, a problem that (X)HTML5 is supposed to be able to solve. How else would a browser (or any user agent, for that matter) distinguish between XHTML 1.0, (X)HTML5, HTML 4.01, etc. to figure out which markup parser to use?

XHTML 2.0 is rather nice. I’ve been behind it 100% ever since I found out about it.

(X)HTML5, on the other hand, I’m not much of a fan of… I really don’t understand why the canvas, audio and video elements are needed, for example. I’ve seen things like a Mario Kart clone that used JavaScript and the canvas element. Technologies like Flash or Silverlight, however, could have been used to achieve the same result with extra features. No, I didn’t miss the point - proving it could be done without such proprietary technologies - but such a game would run considerably smoother using Flash. As for the audio and video elements, what is wrong with the object element?

I may be missing the point of (X)HTML5, but it doesn’t seem nearly as useful as XHTML 2.0. In addition, (X)HTML5 introduces elements specifically for presentation (canvas, audio, video), something that was supposed to disappear thanks to XHTML, especially XHTML 1.1 and XHTML 2.0.

All the proceeds from ad clicks will go to charity. However, if you like to give something directly to charity yourself, I recommend choosing from the listed ones below.