Anyway, who said that?
I have never claimed there were no HTML cross-platform issues
Yes, there are cross browser issues with HTML. No, your proposed 'solution' is still terrible, and unworkable.
What would having the corps get together and abolishing the W3C solve? A standard is a standard and not all of them develop the standard. And as someone said earlier, there are representatives of the browser manufacturers working with the W3C. I can't see how getting rid of the W3C would help anything, but can definitely see a lot of harm.
Also, as for the "XHTML pages won't load at all so it'll save pros time" is far from the truth. It takes me... 0.0001 seconds to see if my site is valid or not. I just glance over at the little circle that has a check mark or X indicating if it's valid or not. However, if you create a CMS and give it to your clients to use and they forget to close a paragraph tag and break their whole site... that sounds like a DEFINITE downside to me.
If you create a CMS and give it to clients to use and are expecting the CMS to genetrate XHTML pages then the CMS should not allow the client to enter invalid code. It should fix the code for them. Your CMS really ought to be doing that even if you are using HTML.
Anyway XHTML isn't for everyone. Back when XHTML was first created those who created it thought that everyone would eventually swap to using it (which is why there is no HTML equivalent to XHTML 1.1 or XHTML 2.0). Those currently developing (X)HTML5 realise that it will never happen because there are too many non-professionals throwing pages together without any knowledge of HTML and so HTML wil still be needed for those people even after all the professional web developers swap to using XHTML. (and are therefore creating both variants).
I agree about your CMS point, however in many cases that isn't really practical.
Look at Dreamweaver. Probably one of the most advanced (or at least the best funded ;)) WYSIWYG editors out there, but even it cant' correct everything and often generates invalid code itself.
It's not something you can ever really have full control over. Besides, if it's invalid in the first place, you can't necessarily tell how it's supposed to be (i.e., if you're missing a </p>, how can you tell where it's supposed to go?).
I still have difficulty seeing the full benefits of XHTML. I know what they are, but I can't really see them being put to full use in the majority of projects.
When browsers are left to guess what to do about invalid tags then there is no rule says that they all have to guess the same way. At least if your CMS does the guessing then you know all browsers will handle it the same rather than making different guesses.
Yes, but from a non-tech point of view, if it shows up it's better than it's not. If you build stuff properly, a missing </p> may cause something weird, but it's unlikely to break the entire site.
I agree with most of what markbrown said: there's no reason not to start learning HTML5 now. XHTML is pretty much dead, as many have said here it's only XHTML if you serve it as XML and that's not a practical option.
And HTML5 doesn't invalidate any of HTML 4, it just adds some new things, many of which you can start using straight away without adverse effects (like the new form input types, for example). Even though it's not finalized, HTML5 is being actively adopted by both browser makers and developers, and clients are going to start asking for it sooner rather than later. There's no point starting out your career already behind the game.
It is no more dead than a baby is when there's still at least seven months to go before it is born. If it is dead then why did Microsoft introduce support for it this week.
Of course that doesn't change the fact that swapping to XHTML when it does become practical will be easier the better you know HTML 4 first.
Here's where a lot of people will start saying "but what if you want to parse your HTML as XML?" Why would you want to do that? It's much simpler to develop an API on the server side that can serve up an XML representation of your data directly, and that has a number of advantages over trying to use your markup as an API. For one, a real API will be stable and not at risk of being broken by a page redesign that moves things around. It's also more efficient, as you're not sending a lot of presentational information to a machine that just wants the data.
Plus "All we need is for IE8 to die"? That's not realistically going to happen for at least another 3-4 years, because of XP. So you want to hold out that long to be able to use a technology that no standards body is paying attention to anymore, that's worse in terms of reliability than the technology we already have (HTML), and that there's no good reason to use in the first place?
We also need to remember that "when IE8 dies" is a VERY long time away. We are just barely able to drop IE6 now (it's only down to 3% in US, but it's still at 25%+ in some countries, like China).
IE6 was released August 2001. It took almost 10 years to drop down to 3%~30% usage. If IE8 follows suit (which in all likelihood it will), it won't be until 2019 until we can consider dropping support for IE8. Is XHTML1.0 still going to be relevant in 8 more years, when we're already debating it's relevance now?
Personally I think we'd be better off ditching XHTML all together and focusing all our efforts on HTML. Then we'll be able to improve HTML much quicker than we are now.
When IE8 dies? That could be a *very very* long time away.
Look, I'm all for XHTML. I was hoping XHTML2 would win out over HTML5, because XHTML showed a lot of promise and HTML5 seems to just reinforce bad behaviours.
HTML 4.01 Strict is the best starting point for any beginner, because as someone mentioned, HTML5 takes nothing away from it, it just bolts new things on. It's compatible with every browser around, and it just works.
I would learn with HTML 4.01 (and look at XHTML too) and experiment with HTML 5. That way you can understand the current standards and get a little experience with the upcoming standard. The only thing I wouldn't do is build a whole page with HTML 5 since the standard has not been finalized and probably won't be for some time.
It has taken over 10 years from when the HTML 4 standard was introduced until all browsers properly support it and still over 90% of actual web pages are still using at least some HTML 3.2. Just because HTML 4 has been the standard for the last 14 years doesn't mean that more than a small minority actually use it. Assuming that HTML 5 were to become a standard in 2012 (it will probably take a lot longer but let's take it as that anyway) then based on the take up of HTML 4 we might see perhaps 5% of web sites actually using HTML 5 by 2025 - most will still be using HTML 3.2 as few people seem to be bothered about actually completing the transition to HTML 4 - they change their doctype from HTML 3.2 to HTML 4 transitional and then don't actually even start transitioning or if they do start they make the changes so slowly that it will take 20 years for them to finish transitioning).
HTML 3.2 introduced all the functionality in HTML that those building their own personal sites are looking for so effectively everything after that is only being used by web professionals.
The one other thing to remember (for those who suggested scrapping the W3C and setting up a new standards group) is that the members of the W3C are the companies that write the web browsers. The W3C standards are those the web browser writers have agreed should be the ones all their browsers should support. The speed at which they actually implement the new standard varies between W3C members. Also the standards dictate what the browsers should support. The standards say absolutely nothing about what is appropriate to use in a web page. As with most languages there are good bits and bad bits and those developing web pages properly should only use the good bits. The bad bits are there so that novices can throw together something that will display as a web page without their having to spend the time to learn anything beyond HTML 3.2.
XHTML 1.0 by it's spec, particularly if you follow the compatibility guidelines is completely deployable all the way back to IE 5.0 -- the 1.0 version of the spec was created for that explicit purpose! Anyone telling you otherwise is full of it!
As to the OP's question, HTML 5 is in DRAFT, meaning "not for real world deployment" -- and in terms of actually creating markup it's a fat bloated idiotic spec filled with a bunch of new tags that offer no tangible benefits over it's predecessor, new structural rules for no good reason other than to piss all over existing accessibility rules, loosens the structural rules to the point of validation being pointless, and the inclusion of elements just to satiate the desires of the sleazeball pieces of filth who are still vomiting up HTML 3.2, slapping a 4 tranny on it and saying "close enough" -- it's such total idiocy I cannot fathom why anyone would WANT to use HTML 5 in the first place!!!
So my advice, stick with STRICT, forget 5 even exists. I prefer XHTML for the stricter structural rules -- which is one of only two legitimate reasons to choose XHTML 1.0 STRICT over HTML 4.01 STRICT -- the other being that you MIGHT be able to data scrape it more efficiently using an XML parser.
I truly feel bad for the nubes who are basically being preyed upon by the people promoting HTML 5 -- since the only legitimate reason I can see for it is to sell new books, instructional DVD's, and all the other snake oil that goes with it... what I don't get is the experienced developers I see slapping the 5 lip service on their documents... for them I have nothing but contempt.
Just because something is newer doesn't make it better.
Try opening http://www.felgall.com/realxhtml.php in any version of IE prior to version 9 and see what the browser does with it. That page is real XHTML 1.0 strict not just HTML 4 pretending to be XHTML.
obviously HTML 5.0 as to grow with the market, you've to get with the latest as it is supported by mobile and IPhone applications. So, you have to decide.