Is there a reason why these two standards are being developed separately? They seem to be solving the same problem but what are the differences and, if they are to remain separate, what roles are they expected to take in web development in the future?
Browser vendors care a great deal about backwards compatibility. The group speccing XHTML2 didn’t.
Note that XHTML2 isn’t solving all the same problems HTML5 is solving. HTML5 is much broader in scope than XHTML2. HTML5 covers processing models, JavaScript APIs, video, audio, application widgets, etc. but XHTML2 does not.
As for expected roles, representatives from top browser vendors participate in the HTML WG but not in the XHTML2 WG. On the other hand, people showing interest in the “Backplane” are participating in the XHTML2 WG.
See also David Baron’s post about how the W3C works.
This article only answers part of the question. It doesn't explain what the likely roles of the two standards will be in the future.:
X/HTML 5 Versus XHTML 2
As for the likely roles, people are saying that:
W3C started work on XHTML 2, throwing away backward-compatibility
Some people didn't like that, and started to define HTML 5
Eventually, W3C were persuaded to adopt HTML 5 as well
Browser vendors seem to be behind HTML 5 (but not XHTML 2)
If browser vendors don't support XHTML 2 then I don't know what its role is. On the other hand XHTML 2 can be more-or-less converted to XHTML 1, e.g. using an XSL transformation, so it seems to me that it would be (much) easier for anyone to support, if they wanted to, than HTML 5 will be.
XHTML2 is dead.
Have a look at the first chapter of HTML5 FOR WEB DESIGNERS by Jeremy Keith which explains superbly the differences in a summarized way.
This is largely an accurate explanation, IMO, but it should be noted that HTML5 isn't backwards compatible - new elements like section cannot be styled with CSS in even IE7. Yes, there are JavaScript work-arounds but these aren't sufficient, both because not everyone has JavaScript enabled, far from every developer will become aware of these, and similarly not every developer has the ability to use JavaScript in this way.
HTML 5 has been constructed with backwards compatibility in mind, unlike XHTML 2, which was created in order to break away from restrictions involved with backwards compatibility.
The W3C allowed the XHTML 2 working group to expire, essentially ending development of XHTML 2. HTML 5, with backwards compatibility and new features, will become the doctype of the future.
Related
All modern browsers understand HTML, so what is the point of being XHTML compliant other then writing more characters found on the far right side of the keyboard.
There is no point that I can think of. The W3C has canceled XHTML 2.0, although there is supposed to be an XHTML5, which I guess is HTML5 for masochists. Originally XHTML was going to lead us into the world of "correct" HTML documents, but it generated as many (or more) problems than it ever solved.
We validate against either HTML 4.01 Transitional or HTML5 (to the degree that you can do that). That plus clean CSS gives you about the best you can shoot for.
XHTML was originally supposed to be a "next generation of HTML", as well as a stricter version of HTML (which would cause failures if any error showed up in the page). Due to a variety of loopholes and any number of other issues with XHTML (such as pages serving up the wrong mimetype), hardly any pages are actually XHTML, they're just HTML with some extra characters.
Eventually, HTML5 was proposed, w3c split into two groups, then the people working on XHTML 2.0 switched to something better (HTML5) and now everyone is talking about HTML5 taking over everything.
For a longer version (with far more detail), check out this chapter from Dive Into HTML5: http://diveintohtml5.ep.io/past.html
According to http://www.dev-archive.net/articles/xhtml.html, one of the reasons XHTML was created was:
to add the XML ability to extend the language through namespaces. This will make it possible for an author to express more structures and richer semantics than is possible with HTML today. In effect XHTML inherits the possibility of supporting more than one language — instead of extending HTML in a monolithic fashion, XHTML can be extended through modules, where each module define a specific subset of the language.This, theoretically, means extension of the language can be done without the need for a browser upgrade.
XHTML is meant to make the use of XML–based languages in end–user applications such as browsers easy, but can also be used for various data processing and storage purposes in situations where the web is only one of several channels. XHTML take advantage of the extensibility of XML to support multiple namespaces and through them languages.
That article also notes that for most people this won't be useful:
Recommendations
If you don’t have any specific need to deliver XML–based structures to the client, e.g. due to mixing namespaces such as having MathML content in your pages, using Ruby (XHTML 1.1) or techniques such as ACCESS (XHTML 1.2) then consider whether you won’t be better off simply by using HTML 4.01 Strict.
Edit with additional thoughts:
I forgot to mention the point I popped in here to bring up too - XHTML can be more easily manipulated into other languages using XSL transforms.
I am really new to this so please forgive the basicness of my question...
I want to learn to design websites and I have a program which I am planning to learn (Dreamweaver CS5) using tutorials from Lynda.com. However on the tutorial it says you should have a good grasp of HTML and CSS before starting Dreamweaver.
I looked at the Lynda.com video for HTML but it is all focused on XHTML. http://www.lynda.com/tutorial/47603
Now I am a bit confused. I heard a new standard was coming in (HTML5). If I learn XHTML - does that mean that I will then have to go back at a later date and learn HTML4 so that I can then catch up and learn HTML5 or will I be able to use my XHTML knowledge and add the future HTML5 code to it?
For example there is a Lynda video on HTML5 but the author says you need a knowledge of html before you can watch it.
Do you think the Lynda.com video on XHTML/HTML is a good place to start or do I need to get a book on HTML4 instead?
If you were starting out now would you learn HTML4 or XHTML?
Thanks
XHTML, absolutely.
Last recommended HTML version was 4.x, and it's from 90s era.
Learn XHTML as much as possible, and try to use strict versions.
I agree with #Matías, if only because of it's strictness which will likely result in cleaner code in the long run. That said, porting from one html version to another shouldn't be too difficult regardless of which one you choose.
I find that when programming the use of XHTML is nice because it allows me to catch errors in my markup at compile time instead of some obscure bug showing itself way later when I modify a page.
The whole lack of XHTML 1.1 support in IE has been a pain, but there are work arounds such as XSL transformations and the such. IE9 has finally added support.
Once (X)HTML5 support becomes strong in the major browsers I intend on using XHTML5 in any web projects I do for work. Supporting legacy IE versions will still be a pain, but it will be manageable.
I would learn HTML4.01, but only because I detest XHTML.
It doesn't matter that much, making the port from (X)HTML x.xx to (X)HTML y.yy is not that hard. You'll have a few pitfalls, but that's all.
On the other hand, HTML5 is quite different and you can start learning it already. It's already happening.
Whatever you learn, make sure you learn the Strict version.
Check this out for future proofing: http://blog.twostepmedia.co.uk/css3-still-novelty-or-usable-in-everyday-web-development/
To the O/P, learn the basics of HTML4 and then get straight onto HTML5, you'll be way ahead of the pack and your websites WILL stand out :)
I would personally work on learning HTML5. By the time you get proficient at it to be good enough to professionally code websites, most of the major browser vendors will have adopted it as the standard.
Remember, web technology moves fast! What's hot today will be obsolete tomorrow, and what's in beta now will be hot tomorrow.
I found this http://headjs.com, a modernizer, here on Stack Overflow, which is used to future-proof web applications. This makes learning and using HTML5 markup a possibility today, so that as browser vendors update their applications, they'll slide right into the HTML5 functionality.
Make CSS apply only for Opera 11?
For a brief summary:
HTML 4.01 is the current standard of markup languages for the internet.
XHTML 1.0 was forked off from HTML 4.01. It introduced greater strictness in validation, more XML-like syntax (eg. <br /> instead of <br>) and XML namespaces for things like MathML (for embedding mathematical equations in pages.... very infrequently used). In theory XHTML allowed people to define their own tags.... but in practice this never happened. In actuality, the only real different it has from HTML 4.01 are the self-closing tags, a different doctype (the header at the top of HTML documents), and a few attributes on the <html> tag.
XHTML 1.1 was a natural progression from XHTML 1.0. It introduced even greater strictness, and enforced things like mime-types for served documents. However, because it declared it was XML instead of HTML, and had to be served to the browser as XML (which Internet Explorer to this day does not support), it never took off.
XHTML 2.0 was a draft recommendation that got scrapped along the way. No-one subsequently uses it.
HTML 5 is the next evolution from HTML 4.01. It adds a lot of new tags, new functionality such as local storage (meaning more web-app type applications are possible), and some other goodies. It comes in two flavours - HTML 5, which uses HTML-style syntax, and XHTML 5, which uses XHTML syntax with self-closing tags (and is not to be confused with XHTML 2, which is dead remember.) It is 'the next big thing' in web markup languages, but is still in draft stage. Some browsers are introducing support for new HTML 5 tags, but legacy browsers have no support.
HTML 5 cannot be safely used in current sites, due to the draft nature of the specification. Some sites are doing so, but those sites can possibly get the whole nature of the language yanked out from under their feet.
HTML 5 is not expected to be a formal recommendation until 2022.
In summary: The current language of the web is HTML 4.01. HTML 5 expands on that greatly, but is not ready for everyday use. And the differences between HTML 4.01 and any flavour of XML, are minimal at best.
XHTML's main benefit, as Matias said, is it's XML compatibility, and also the other way round; I regularly use an XSLT to transform an XML document into XHTML. Although XSLT can output HTML, it's HTML that's compliant with XML anyway.
Strictly speaking, there's no reason you can't write HTML5 that's totally XML compliant; for that reason alone, I'd say go with HTML5, and by writing it so that it IS XML compliant, you also get all the benefits of XHTML.
I'm starting a project where the client has mandated the use of XHTML 1.0 Strict. Now I'm wondering whether the problems described in Sending XHTML as text/html Considered Harmful are still current and whether I should try to convince the client that this (very strongly stated) requirement is counterproductive.
Does Internet explorer handle application/xhtml+xml correctly by now?
IE9 handles application/xhtml+xml, including SVG inside it, one of the main reasons to want to use this media type. (Otherwise, there's relatively little point in using it to date, as you get a bunch of scripting changes, and IE<9 incompatibility, in return for relatively little if any performance gain at the moment.)
I don't agree with Hixie that serving XHTML as text/html has ever been really harmful. Using the HTML-compatibility guidelines, XHTML poses no problems to any browsers since the ancient Netscape 4. Although it doesn't really get you anything on the client-side, it can be helpful to your own page handling workflow if you're working with XML processing tools. And the XML syntax rules, being stricter-but-simpler than HTML, are a good thing to author to; this gives the validator a chance to pick up on errors that are valid constructs in SGML/HTML but which are almost certainly not what you meant. (On the other hand, since the validator won't enforce HTML-compatibility guidelines there are a couple of places where it can let through well-formed-but-troublesome markup, most commonly self-closed <script> tags breaking the whole page.)
Specifically, to answer his points: /> and related SGML issues are only a problem to tools that really believe HTML is SGML—which is no browser ever, in the past. In the future, it is specifically allowed in non-XML HTML5.
Hiding scripts/stylesheets from ‘legacy’ (pre-HTML 3.2!) browsers hasn't been an issue for a decade or so: I came up with the mangled comment hack he (rightly) derides as ridiculous, but it was only an exercise; I never intended anyone to use it except in some strange hypothetical emergency. It's certainly not ‘necessary’ for using embedded scripts and stylesheets in XHTML-as-HTML... a straight //<![CDATA[ hack is enough if you need to be able to include < and & characters, and more commonly you don't even need that.
No-one actually wants to sniff for XHTML-as-HTML and treat it differently, so that whole section is moot. “Sending XHTML 1.1 as text/html is NEVER fine” has been changed by W3C (it now is fine after all), and XHTML 2.0 is dead.
So yes, use XHTML 1.0 Strict, or XHTML 1.1 or XHTML5, if you like. But until IE9 is your baseline browser (and that's not going to be the case for ages), you'll have to stick with text/html.
Internet Explorer 9 will handle application/xhtml+xml documents through a tag soup parser.
Internet Explorer 8 and earlier will prompt the user to save the document or open it in another application.
Internet Explorer 6 and newer all have significant market share (although this does depend, to some degree, on your market).
Nothing significant has changed as regards browser support for real XHTML for many years.
It is still far more trouble than it is worth unless you actually use XML parsers in your production chain (in which case, good luck persuading them to output XHTML that meets the HTML Compatibility Guidelines).
This depends on what you mean by "Internet Explorer".
For instance, IE6 is still from something like 2001 (that hasn't changed), and no, it still doesn't handle it correctly.
Over the past one year, (27th May 2017 - 27th April 2018), the combined share of IE 6, 7, and 8 comprises 1.72% according to netmarketshare.
Every other major browser supports real XHTML (i.e. sent with the application/xhtml+xml MIME type. My answer to you is "No, it's not harmful".
Whether it's advantageous, I would guess it doesn't matter much until you actually grok and use XML technologies (SVG, MathML, etc) on the web comfortably (yes HTML syntax also supports them, but it's virtually a hack).
If browser makers put more effort into XML parsers, it could still matter for pure parsing speed.
So HTML 5 has been widely publicised as expected to be ready in 2022. This is a long time to wait, and the test for that readiness is that "at least two browsers to completely pass [HTML 5 test suites]"
Obviously for browsers to pass this test they have to start implementing usable HTML 5 features before that. The list of new HTML5 features supported is looking thin at the moment. But there are a couple of significant changes to existing elements such as allowing A tags to surround block level that could be very useful now.
There are sites that are using HTML 5 now, so what are the factors that will make you start, or keep you from, building sites with an HTML 5 doctype?
Myself, I'm toying with HTML5 in a couple of personal sites, but will wait a while for work sites until things like a reliable validator appear.
It helps to divide this question into several parts.
1) When should one start using the HTML5 doctype?
The HTML5 doctype causes browsers to render pages in Full Standards mode. Unless you're currently using a strict doctype, pages may display differently. So you'll need to weigh up the amount of rework required if you're converting a existing site, and you'll need to understand the difference in rendering behaviour. Secondly, the doctype will cause the w3c validator to select HTML5 as the default language to validate against. Given that HTML5 is still in draft, this means aiming at a moving target. Is validity important to you? Some features that are valid in HTML4 are not currently valid in HTML5. Should you change your markup now to remove those features, given that HTML5 may change to make those features valid again? Provided you're comfortable with this, you can start using the HTML5 doctype now.
On the other hand, on it's own, what are you gaining? If you want browsers to render in Full Standards mode, you can use a strict doctype from HTML 4.01 or XHTML 1.x. Do you need HTML5 validation given that it will pass things that may not at present be handled consistently across browsers? Be aware that any HTML5 feature that currently works in browsers, works regardless of whether you use the HTML5 doctype or not.
2) When should one start using features that are currently interoperably implemented in the major browsers, but standardised for the first time in HTML5?
You can use these now, but try to make sure that your pages are properly accessible. Canvas, for example, does not provide good support for non-sighted users.
3) When should one start using features that are current implemented in some browsers, and will be standardised by HTML5?
This depends on your target users and delivery schedules. Will your users be using a browser that supports these features by the time your site goes live? What happens if they don't? Does the page fall back gracefully? Do you care if some users can't use your site?
4) When should one start using features of HTML5 that are not implemented at all yet?
Why would you want to do that? It might be reasonable for training purposes or investigating fall back behaviour, but HTML5 is still in draft form, and it's quite possible that some features will never be implemented, or will be implemented in a totally different way to that currently described, so you could waste a lot of effort.
Summarising, what matters is not so much what's in the HTML5 draft, as what is practically usable today. The draft describes a range of features, some of which have been in browsers for years, some which are new but have support or good fall back behaviour, and some which are not currently and may never be usable.
For me, I'll be holding off until I need an HTML5 feature, and I know that that feature is implemented in a consistent and stable way across the major browsers. That will probably happen some time during HTML5's Last Call phase, or possibly during the Candidate Recommendation phase.
Already have started using it for personal and client work.
For validation I use Henri Sivonen's excellent http://validator.nu/
When IE supports it. I work in the corporate world, and IE is required.
I use the doctype now! (for some projects at least)
As for the features, things like <canvas> and <video> are cool and useful now because there are often ways to make the content available for users whose browsers don't support HTML5 yet.
Semantic page structure tags like <sidebar> and the lot don't seem very urgent to me. I'll let those sit for another year or two.
i want to migrate our website to Xhtml 5 or css 3.0 how to i migrate our site
do you really need to do that right now? keep in mind that broswers like Internet expplorer 6, 7 and Opera don't support CSS3 at the moment and even moere, if you care about valid CSS code, the current validator will not approve your code.
However, if you still want to do that, be aware to keep the most important parts of your code still compatible with mentioned broswers, and user CSS3 features (they are just awesome!) wisely. You could start learning here:
http://www.smashingmagazine.com/2009/06/15/take-your-design-to-the-next-level-with-css3/
There is also a good tutorial on nettuts, be sure to check it out (sorry, I cannot post more than one link here)
Once you have done, you could use CSS3, or CSS2.1 style sheets for different browser using conditional statements. Do some google research on it.
Hope this helps
Using HTML5 is one thing (most browsers won't support much of HTML5's APIs) get a book or find a site that outlines HTML5 and what it has to offer.
But if you want your site to validate as HTML5/CSS3, run your pages through W3C's HTML validator
use validate by URL > more options and choose your document type, in your case HTML 5.
Fix errors, repeat.
Keep in mind that there is no XHTML 5, only HTML 5. That's probably what you want.
While there are 3 different doctypes in HTML 4.01, there is only one in HTML 5:
<!DOCTYPE HTML>
Use that as your doctype when you migrate.
For CSS use W3C's CSS validator. Be sure to choose CSS3 in the options
Fix errors, repeat
i want to migrate our website to Xhtml 5 or css 3.0
For what reason?
HTML 5 has not yet reached Recommendation status and is still subject to change. Most of the significant changes in the spec aren't widely supported yet by browsers, either.
Same thing for CSS 3 - it has not been finalized, nor are many of its new attributes supported by all major browsers. You can start using CSS 3 stuff in your existing stylesheets, but be prepared for them to not work for many users yet.