5.1, 2016? Ha!
By the time Microsoft, Apple, Google and Firefox have full support for a complete (not beta) version of HTML 5.1 in their latest browsers, China will be making iPhones on the moon. :P
The Worldwide Web Consortium (W3C) says it's still on track to release the final HTML5 specification in 2014 – and to prove it, it's issued a tentative plan outlining the steps it will take to bring the web markup language to its next version and beyond. The plan still needs to be approved by the HTML Working Group – naturally …
>Yeah, 'cos Microsoft has always been right up there for prompt standards conformance
Two of the new editors are MS staffers - the chances of MS not supporting these versions of HTML5 are near abouts zero.......while workable support for the WTF version of HTML5 which promises a richer landscape and pixie dust for everyone is just as unlikely.
Either way, it's time to stop pretending. Dealing with denial is the first stage of browser dependence - get yourself a course of CBT - Java/Obj C [dual-therapy is more effective] or at the very least grab a self-help book from Doctor O'Reilly.
.....and start working on witty answers to 'what's a web browser Grandad?' as that will be more relevant when these burnt offerings are actually slated to become Full (nb not Candidate] Recommendations @ W3C.....
for HTML 5.1?
Since the absurdly generic and uninformative !DOCTYPE HTML has been assigned to indicate HTML 5 (with the convoluted DTD DOCTYPEs relegated to earlier versions), will we finally see the version number and ONLY the version number set as the doctype parameter, i.e. !DOCTYPE HTML 5.1?
I think the idea was to do away with version numbers. It will have the same doctype as will all future versions. The thinking being that HTML is a living spec or something which can accomodate for future changes without making older pages break. No idea if this is good, bad or irrelevant....
On Android, stock browser or better alternatives like opera, Firefox can do 99% of stuff those "apps of sites" (absurd) can do via html5.
Why do they ship apps? Check permissions circus of their app things, you will understand. A browser will ask if a page requests your location, you will say "yea, right" and leave if they ask your phone number. Why bother? Put blame on w3c and keep spying.
It seems that the author forgot that back in 2000, the W3C recommended XHTML, not HTML anymore. And preferably, Strict, so as to be forward compatible with the future XML-only browsers.
So, err, a good part of the last 12 years was busily helping everybody forget that «XHTML 1.0 is the current W3C Recommendation»
http://web.archive.org/web/20000815053902/http://www.w3.org/MarkUp/
This post has been deleted by its author
...but html5 doesn't have to be well-formed? You can drop closing tags etc. Which is the major WTF moment for me, but they wanted to keep the standard 'simple' for all those people migrating away from geocities obviously.
Mine's the blink tag with a marquee inside it.
"Which is the major WTF moment for me, but they wanted to keep the standard 'simple' for all those people migrating away from geocities obviously."
No, they wanted to stop website from returning a yellow screen of XML death just because some web author somewhere forgot to close a break tag. Whilst XHTML is great it's not at all suitable for publishing content on the web.
"No, they wanted to stop website from returning a yellow screen of XML death just because some web author somewhere forgot to close a break tag."
So now we define our standards to avoid embarrassing the lazy or incompetent? At least with XHTML you knew you could point an app at it and process it as XML. With HTML5 you'll be able to do that for SOME pages (because they use HTML5 with the XML syntax) but not for other, unidentifiable ones.
Great.
Not quite. If it's proper XHTML then it has to be served with as application/xhtml+xml. Using XHTML markup server with text/html strictly speaking is "invalid" HTML but browsers being the forgiving applications they are let you get away with it (e.g. look at img http://www.w3.org/wiki/HTML/Elements/img#HTML_Reference - it doesn't use the XML short form for an empty element). XHTML after all is only a more formalised version of HTML 4.01 - see the Abstract http://www.w3.org/TR/xhtml1/. This means you COULD write a single document that can be served quite happily with either content type simply by sticking to the stricter XHTML and letting the browsers' interpretations gloss over the notational differences.
Extending the above concept further, the HTML5 specification gives up dictating notation by focusing entirely on the abstracted Document Object Model itself. It's up to the developer which notation, HTML or XHTML, they want to use in their projects.
To be completely honest, while it's NICE to have a well formalized language, I can't see a practical advantage of XHTML over HTML other than to be parsable by an XML document reader which as far as I can tell is actually a bit of an edge case as either the document would returned in a machine reabale format in the first place a la SOAP or JSON or you can access the DOM directly. If you're can't do either, then what exactly ARE you doing? Screen scraping somebody else's material?
Semantically it IS the same, that's the point - each element has a precisely defined behaviour. Its only the subtleties of notation that differ - for which the W3C even provided a helpful guide http://www.w3.org/TR/xhtml1/#guidelines
I take your point with compilers second guessing, and I agree with the principle of failing early and often to catch mistakes, but at the end of the day, they both have roots in SGML and both can be parsed unambigiously. If you want to see another GML based lanuage that does a similar thing but with less redundant information, take a look at WML spec.
This post has been deleted by its author