Comments on: HTML 5 or XHTML 2? http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/ Web development and Internet trends Sat, 20 Mar 2010 00:53:38 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Nikita Sumeiko http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-596404 Nikita Sumeiko Sun, 02 Aug 2009 08:45:04 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-596404 Here is the simplest way how to understand transit form xHTML 2 to HTML 5. It will be easier, because it's a painted comic strip: <a href="http://www.manakor.org/xhtml/what-markup-language-to-use-now-xhtml-2-or-html-5" rel="nofollow">http://www.manakor.org/xhtml/what-markup-language-to-use-now-xhtml-2-or-html-5</a> But your attitude to this topic is clear for me. Thanks. Here is the simplest way how to understand transit form xHTML 2 to HTML 5.
It will be easier, because it’s a painted comic strip:
http://www.manakor.org/xhtml/what-markup-language-to-use-now-xhtml-2-or-html-5

But your attitude to this topic is clear for me.
Thanks.

]]> By: Marc K http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-589893 Marc K Tue, 16 Jun 2009 00:36:37 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-589893 So I've been learning a bit about the HTML5 <strong>canvas</strong> element as supported in the latest milestones for Firefox, Chrome and Opera, and how to use JS with it to make a simple 2D painting canvas. It certainly got my attention with how simple it is to use with JS – but I was disappointed to learn that, in Chrome at least, the width and height of the element must be set using <em>presentational</em> tag attributes for it to work properly. Strangely enough, when I tried using CSS for the width and height of the <strong>canvas</strong> element itself and/or a container <strong>div</strong>, a border was applied correctly but the actual drawing routines were messed up. Somehow, it seems that to alter the co-ordinates passed to the JS drawing functions via the <strong>clientX/Y</strong> or <strong>offsetX/Y</strong> properties of the <strong>mousemove</strong> event object, so the 'virtual ink' is drawn at an offset to the actual location of the cursor. This seems rather backwards if it is actually part of the specification, when for years we've been told to abolish presentional markup wherever possible! I thought that it could just be a bug in Chrome and/or WebKit's HTML5 rendering process, of course... But I've just tried it in Opera and the same thing happens. I like SVG too but I don't know of a similarly easy, straightforward and <strong>built-in</strong> way to alter an SVG image using a Javascript/ECMA API. At least, not one that's built into a XHTML spec in the same manner as <strong>canvas</strong> is. I did find a flurry of nice third-party JS API toolkits for manipulating SVG markup, like this simple looking <a href="http://keith-wood.name/svg.html" rel="nofollow">jQuery one</a> – but as good as it may be, that's already quite far removed from a standards-based solution that doesn't involve any external libraries, which is what it looks like the <strong>canvas</strong> proponents are aiming for. Then there's all the fuss over whether to use <strong>object</strong>, <strong>embed</strong>, both those elements together, or XHTML+SVG in the same document... Finally, I love the simplicity of the new DTD, even if it doesn't specify the HTML version which may become problematic if later versions do introduce conflicts despite best efforts... It's such a relief to be able to just type in <strong><!DOCTYPE html></strong> rather than having to copy and paste one of those long, ungainly relics of ancient SGML syntax. I mean, I only recently discovered that the entire purpose of the '-' character in the ludicrous '-//DTD html blah...' is supposed to indicate that the DTD came from an organisation 'that is not registered with the IETF' – with a '+' meaning the opposite. But it's 2009 and I can't remember ever seeing such a doctype declaration with a '+' in it! I was also amazed that the W3C itself, trickling out a steady stream of misunderstood and badly followed doctype definitions for all those years, does not qualify as a 'registered' entity in that sense... Made me laugh though. Can't we get rid of DTDs altogether, at least in XML subsets? To me, it seems that the XML prologue is all that's needed to inform an 'agent' that the document is indeed XML, and the presence of a top-level <strong><html></strong> or <strong><svg></strong> tag (perhaps with a versioned namespace specifier instead of a static 1999 one) could then clarify things... That would change the inner workings of the beast quite substantially though, I suppose. But that's my point: It's too arcane! So I’ve been learning a bit about the HTML5 canvas element as supported in the latest milestones for Firefox, Chrome and Opera, and how to use JS with it to make a simple 2D painting canvas.

It certainly got my attention with how simple it is to use with JS – but I was disappointed to learn that, in Chrome at least, the width and height of the element must be set using presentational tag attributes for it to work properly. Strangely enough, when I tried using CSS for the width and height of the canvas element itself and/or a container div, a border was applied correctly but the actual drawing routines were messed up. Somehow, it seems that to alter the co-ordinates passed to the JS drawing functions via the clientX/Y or offsetX/Y properties of the mousemove event object, so the ‘virtual ink’ is drawn at an offset to the actual location of the cursor.

This seems rather backwards if it is actually part of the specification, when for years we’ve been told to abolish presentional markup wherever possible!

I thought that it could just be a bug in Chrome and/or WebKit’s HTML5 rendering process, of course… But I’ve just tried it in Opera and the same thing happens. I like SVG too but I don’t know of a similarly easy, straightforward and built-in way to alter an SVG image using a Javascript/ECMA API. At least, not one that’s built into a XHTML spec in the same manner as canvas is. I did find a flurry of nice third-party JS API toolkits for manipulating SVG markup, like this simple looking jQuery one – but as good as it may be, that’s already quite far removed from a standards-based solution that doesn’t involve any external libraries, which is what it looks like the canvas proponents are aiming for. Then there’s all the fuss over whether to use object, embed, both those elements together, or XHTML+SVG in the same document…

Finally, I love the simplicity of the new DTD, even if it doesn’t specify the HTML version which may become problematic if later versions do introduce conflicts despite best efforts… It’s such a relief to be able to just type in <!DOCTYPE html> rather than having to copy and paste one of those long, ungainly relics of ancient SGML syntax. I mean, I only recently discovered that the entire purpose of the ‘-’ character in the ludicrous ‘-//DTD html blah…’ is supposed to indicate that the DTD came from an organisation ‘that is not registered with the IETF’ – with a ‘+’ meaning the opposite. But it’s 2009 and I can’t remember ever seeing such a doctype declaration with a ‘+’ in it! I was also amazed that the W3C itself, trickling out a steady stream of misunderstood and badly followed doctype definitions for all those years, does not qualify as a ‘registered’ entity in that sense… Made me laugh though. Can’t we get rid of DTDs altogether, at least in XML subsets? To me, it seems that the XML prologue is all that’s needed to inform an ‘agent’ that the document is indeed XML, and the presence of a top-level <html> or <svg> tag (perhaps with a versioned namespace specifier instead of a static 1999 one) could then clarify things… That would change the inner workings of the beast quite substantially though, I suppose. But that’s my point: It’s too arcane!

]]> By: Cultred http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-480352 Cultred Thu, 27 Nov 2008 18:28:21 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-480352 HTML 5 and XHTML should work hand-in-hand. I mean that like they should be treated as completely separate coding languages. The added attributes and tags in HTML 5 should also be added to XHTML. Both should be well-formed, just that HTML 5 documents should be coded using the SGML format, while XHTML pages use the XML format. That's pretty much it. HTML 5 and XHTML should work hand-in-hand.

I mean that like they should be treated as completely separate coding languages. The added attributes and tags in HTML 5 should also be added to XHTML. Both should be well-formed, just that HTML 5 documents should be coded using the SGML format, while XHTML pages use the XML format.

That’s pretty much it.

]]> By: Huri http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-469436 Huri Mon, 03 Nov 2008 18:23:46 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-469436 In most ways, I agree with Dustin. XHTML 2.0 is the proper move forward. If there are some things from the HTML 5 spec that are worth while, bring them over to XHTML 2 (like the dialog tag). However, that said, I actually think the best approach would be to use Modularization for everything. Rather than just remove current style forms, allow the use of an XHTML 5 Forms module, along with a core XHTML 2.0 module. Namespaces should be supported everywhere. The whole "keep XML off the web" part is the biggest mistake I've ever seen. We should be keeping TagSoup off the web, and focusing on moving entirely to an XML-based web. With XML Namespaces and other such technologies, content authors should be able to pick which models they use. The two places where this is most important is having support for existing style Forms, and scripts. Allowing every tag to have an href and src attribute is a welcome change, blowing away the presentation-specific tags is a welcome change. I do like the HTML 5 forms, as XForms seem overly complex for simple pages. XForms and XML Events should be optional modules, with XHTML 5 Forms and Scripts support available as well. So I guess what I'm really recommending, is taking the good stuff from HTML 5, adding better Namespace handling, and releasing XHTML 2 as a fully modular markup language. Continuing to support Tag Soup style HTML is stupid, please let it die! In most ways, I agree with Dustin. XHTML 2.0 is the proper move forward. If there are some things from the HTML 5 spec that are worth while, bring them over to XHTML 2 (like the dialog tag).

However, that said, I actually think the best approach would be to use Modularization for everything. Rather than just remove current style forms, allow the use of an XHTML 5 Forms module, along with a core XHTML 2.0 module. Namespaces should be supported everywhere.

The whole “keep XML off the web” part is the biggest mistake I’ve ever seen. We should be keeping TagSoup off the web, and focusing on moving entirely to an XML-based web.

With XML Namespaces and other such technologies, content authors should be able to pick which models they use. The two places where this is most important is having support for existing style Forms, and scripts. Allowing every tag to have an href and src attribute is a welcome change, blowing away the presentation-specific tags is a welcome change. I do like the HTML 5 forms, as XForms seem overly complex for simple pages. XForms and XML Events should be optional modules, with XHTML 5 Forms and Scripts support available as well.

So I guess what I’m really recommending, is taking the good stuff from HTML 5, adding better Namespace handling, and releasing XHTML 2 as a fully modular markup language. Continuing to support Tag Soup style HTML is stupid, please let it die!

]]> By: Dustin Boyd http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-288099 Dustin Boyd Fri, 30 May 2008 05:46:04 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-288099 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. 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.

]]> By: Michael http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-276907 Michael Mon, 19 May 2008 03:52:02 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-276907 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. 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.

]]> By: Michael http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-276906 Michael Mon, 19 May 2008 03:51:44 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-276906 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. 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.

]]> By: Thoughts on HTML 5 - Robert’s talk http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-67286 Thoughts on HTML 5 - Robert’s talk Thu, 07 Jun 2007 20:31:42 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-67286 [...] HTML 5 or XHTML 2? Posted in Technology, Developing, HTML/XHTML | Share your thoughts [...] [...] HTML 5 or XHTML 2? Posted in Technology, Developing, HTML/XHTML | Share your thoughts [...]

]]> By: Anita Hardick http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-55709 Anita Hardick Thu, 03 May 2007 08:40:53 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-55709 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 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

]]> By: Jens Meiert http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-43428 Jens Meiert Mon, 19 Mar 2007 19:48:39 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-43428 German readers, there is an <a href="http://meiert.com/de/publications/translations/xhtml.com/xhtml-5-vs-xhtml-2/" rel="nofollow">revised and improved German translation</a> available now. You're right, Robert, it's a nice article :) German readers, there is an revised and improved German translation available now.

You’re right, Robert, it’s a nice article :)

]]> By: Robert Nyman http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39566 Robert Nyman Fri, 02 Mar 2007 08:37:40 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39566 Siegfried, Axel, Thanks for your comments! Siegfried, Axel,

Thanks for your comments!

]]> By: Axel Rauschmayer http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39498 Axel Rauschmayer Fri, 02 Mar 2007 00:21:18 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39498 As for microformats: I really like <a href="http://en.wikipedia.org/wiki/RDFa" rel="nofollow">RDFa</a> as a longer-term (and much more extensible) alternative. As for microformats: I really like RDFa as a longer-term (and much more extensible) alternative.

]]> By: Axel Rauschmayer http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39493 Axel Rauschmayer Thu, 01 Mar 2007 23:58:05 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-39493 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: <a href="http://blog.whatwg.org/html-vs-xhtml" rel="nofollow">http://blog.whatwg.org/html-vs-xhtml</a> Still, the HTML5 FAQ should make it clear that having easily parsable (X)HTML is still a long-term goal. 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.

]]> By: Siegfried http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-38767 Siegfried Mon, 26 Feb 2007 14:35:31 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-38767 Hi, xhtml2 offers much more for the future. Mainly exactly because it is <em>not</em> 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 <em>now</em> and usable <em>now</em> 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. 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.

]]> By: Robert Nyman http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34289 Robert Nyman Thu, 08 Feb 2007 07:31:30 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34289 Again, I really appreciate this discussion and the great input. Thank you! Again, I really appreciate this discussion and the great input. Thank you!

]]> By: Lachlan Hunt http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34198 Lachlan Hunt Thu, 08 Feb 2007 00:29:21 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34198 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. 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.

]]> By: Vlad Alexander http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34101 Vlad Alexander Wed, 07 Feb 2007 17:51:05 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34101 <b>How do you suggest we improve sectioning elements?</b> 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: <code>&ltsection></code> and <code><section role="navigation"></code> Or, I suggest using a <code>div</code> element instead of <code>section</code>. <b>Why is <code>nl</code> better than <code>nav</code>?</b> The spec defines <code>nav</code> 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 <code>nl</code> element could be very useful for small screen devices. <b>Faults in HTML4 and XHTML1 can be fixed.</b> 1) X/HTML 5 does not fix them. 2) If it did fix them, then it would not be backwards compatible. <b> The more code paths you have in your implementation [of Web browsers] the more development cost and time...</b> 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? <b>The numbers [in numbered heading] get normalized so it doesn't really matter which number you use...</b> 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. <b><code>iframe</code> is heavily used by the advertizing industry</b> 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-<code>iframe</code> solution to this very important issue. <b>Being backwards compatible does not mean that you have to include all elements the previous version had.</b> This is objective and I bet one can use "set theory" to disprove this. <b>It also doesn't mean you can't redefine semantics.</b> This is subjective so we can go back and forth on this for a while. <b>HTML5 does comply with its charter, but perhaps we have to define backwards compatibility.</b> 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. <b><code>font</code> was added because the state of art in WYSIWYG editors don't yet have a way to deal with semantics</b> We have been producing a <a href="http://xstandard.com" rel="nofollow">WYSIWYG editor that does not have a font selector or a color picker</a> for over 3 years. It's not rocket science. If we can do it, anyone can. <b>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.</b> 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 <b>WYSIWYG editors are of course free to deal with semantics and ignore font</b> Guess what, it's easier to sell candy than carrot sticks. <b>WYSIWYG isn't going away any time soon so ignoring them doesn't lead to better results.</b> 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. <b>Class names are not CSS class names. They have nothing to do with CSS.</b> Not if you use the <code>class</code> attribute. The spec "overloads" the meaning of <code>class</code>. And also creates opportunities for conflict with existing documents that use class names that will only be predefined in the future. <b>If you want to use XML then use XHTML5</b> 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! 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!

]]> By: zcorpan http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34095 zcorpan Wed, 07 Feb 2007 17:38:46 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34095 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, 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,

]]> By: Carl Camera http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34092 Carl Camera Wed, 07 Feb 2007 17:13:26 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34092 @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. @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.

]]> By: Harmen Janssen http://robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34022 Harmen Janssen Wed, 07 Feb 2007 10:01:52 +0000 http://www.robertnyman.com/2007/02/05/html-5-or-xhtml-2/#comment-34022 Wow, both XHTML 2 and HTML 5 have some great new additions! <code>h</code>, <code>role</code> and the disappearance of <code>acronym</code> 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 <code>acronym</code> 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. 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.

]]>