How To Use HTML5 Today

heh by Pojut · 2010-07-12 03:47 · Score: 5, Funny

Smith also discusses IE work-arounds, such as HTML 5 Shiv

Shanks a lot for the info ::fft fft::

--
Living With a Nerd

Re:heh by mcgrew · 2010-07-12 06:53 · Score: 4, Informative

Pardon the interruption, and sorry I'm a little late to the party, but I wish they would link the quick loading single page version of TFA rather than five ad-laden three paragraph apiece pages.
I avoid infoworld and many other such sites because of this cluelessness. Annoying your readers is a grat way to keep them from coming back. This is the first infoworld article I've read in quite some time; now I remember why I quit going there.

--
Free Martian Whores!
Re:heh by WillKemp · 2010-07-12 12:43 · Score: 1

i thought it was pretty clear that html5 isn't even going to get off the ground...
It's pretty clear to me that html5 is already well and truly off the ground. Youtube serves up html5 for a start - and there's not many sites that are bigger than youtube.
Re:heh by marcosdumay · 2010-07-13 02:04 · Score: 1

That is not a list of reasons for the video tag not taking up. That is a TODO list from somebody that is helping that tag to take up. You should be able to know the difference. Most problems will be sorted out in no time, content protection (AKA DRM) won't and neither will camera and microphone access. Ok, the later may be solved by JavaScript someday, but it is out of the HTML domain.

--
Rethinking email

Meanwhile, back at the ranch ... by Infernal+Device · 2010-07-12 03:58 · Score: 2, Insightful

We wait around while the W3C tries to pull it's thumb out of it's ass.

How hard is it to decide on a new standard? Do the members not check their email more than once a year?

--
"My God...it's full of trolls!"

Re:Meanwhile, back at the ranch ... by bunratty · 2010-07-12 04:01 · Score: 4, Interesting

Why wait? I use HTML5 today. I start documents with and code away. The W3C validator even validates HTML5 documents. What are you waiting for? Maybe for Internet Explorer, but that's Microsoft's responsibility to update.

--
What a fool believes, he sees, no wise man has the power to reason away.
Re:Meanwhile, back at the ranch ... by geminidomino · 2010-07-12 04:18 · Score: 2, Insightful

Maybe for Internet Explorer, but that's Microsoft's responsibility to update.
And it's web developers' responsibility to make sure that their shit works for its target audience, even if that means holding back because the clueless masses that comprise said audience insist on using Microsoft's cripple-ware.
Re:Meanwhile, back at the ranch ... by bunratty · 2010-07-12 04:22 · Score: 1

Yes, of course, but we can't blame the W3C for deficiencies in Internet Explorer, now can we? If we're waiting on Internet Explorer to catch up, we should blame Microsoft for lagging behind.

--
What a fool believes, he sees, no wise man has the power to reason away.
Re:Meanwhile, back at the ranch ... by GreyWolf3000 · 2010-07-12 04:26 · Score: 2, Informative

You can include a tiny bit of javascript and have IE7+ (and 6 as well), "understand" all of the new elements. Google it.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:Meanwhile, back at the ranch ... by fuzzyfuzzyfungus · 2010-07-12 04:27 · Score: 5, Insightful

The problem isn't "deciding on a new standard"(though there certainly can be engineering challenges and whatnot), the problem is that the W3C doesn't have any power beyond a modicum of respect and whatever consensus it can hammer out.

They could pump out purely theoretical standards, either with no real implementations, or an alpha implementation stashed on somebody's git repo somewhere, all they like, as fast as their merry little legs could carry them; but that would be basically meaningless.

The delay comes out of the fact that, unless enough parties from the various browser makers can be convinced to care, the standard is dead on arrival. Politicking is slow.
Re:Meanwhile, back at the ranch ... by shentino · 2010-07-12 04:44 · Score: 2, Insightful

Politics is never easy.
Especially when the various members have a way to profit from making things proprietary at the expense of everyone else.
The recent wrangle on a standard video codec is a prime example with everyone pushing their own pet patented algorithm.
Re:Meanwhile, back at the ranch ... by antnil · 2010-07-12 05:14 · Score: 1

Problem is, most computer users are usung IE because they dont know how to get another browser and install it on their computers, so until then, the MSIE defacto standard still forces web developers to use hacks, workarounds and other crap of the same nature, to make a given site IE-Friendly. Until then, HTML5 will remain a cute and fun buzzword for marketing and sales... and a headache for the web developers. Whenever you see the word "Work-Around" it means alot of work, it means that code wont be clean, and it means it will not be so easy to maintain, which, from my experience, is crucial for web dev.
And let's face it, Microsoft will take as little time as possible to support the standard if ever: they have their own technologies and agendas to promote, just like Apple has is pushing its tech and agenda with iOS ...
This kind of crap is what made me get out of the web dev business and after over a year, i dont regret if for a second. I even sleep better at night!
Re:Meanwhile, back at the ranch ... by Korin43 · 2010-07-12 05:19 · Score: 1

You don't need Javascript, just add some CSS telling it what the new tags are (article{ display:block; }, etc.). Of course, the tags that are easy to include aren't the interesting part.
Re:Meanwhile, back at the ranch ... by BrokenHalo · 2010-07-12 05:37 · Score: 1

You can also set up a routine that instructs the user how to install a real browser. Simple.
Re:Meanwhile, back at the ranch ... by cervo · 2010-07-12 05:38 · Score: 2, Insightful

This is not flame bait. A site that doesn't work with Internet Explorer is ignoring a huge chunk of the market. Most businesses cannot afford to ignore the IE users...
Re:Meanwhile, back at the ranch ... by hkmwbz · 2010-07-12 06:03 · Score: 1

What are you talking about? There are multiple implementations of various parts of HTML5. Opera, Chrome, Firefox, Safari, IE9 all implement parts of it. Often the same parts. HTML5 is a result of browser makers getting together.

--
Clever signature text goes here.
Re:Meanwhile, back at the ranch ... by e4g4 · 2010-07-12 06:23 · Score: 1

they have their own technologies and agendas to promote, just like Apple has is pushing its tech and agenda with iOS ...
You mean just like Apple is pushing HTML 5?

--
The secret to creativity is knowing how to hide your sources. - Albert Einstein
Re:Meanwhile, back at the ranch ... by brunascle · 2010-07-12 06:27 · Score: 1

That doesn't work. IE doesn't add the new tags to the DOM properly; tags withing the tag will be added as siblings to the , rather than children. The only way I've found to make an HTML5 site work in IE is to surround all the new tags with old tags, and reference the old tags in the CSS.
For example: <div class="article"><article>...
Re:Meanwhile, back at the ranch ... by GreyWolf3000 · 2010-07-12 06:55 · Score: 1

Have you tried the shiv technique mentioned in TFS?

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:Meanwhile, back at the ranch ... by elrous0 · 2010-07-12 07:02 · Score: 2, Insightful

Blame whomever you want, I still have to go to a client and explain to them why the webpage I designed for them doesn't work right in the most popular browser on the market (and then explain to them why they shouldn't fire me).

--
SJW: Someone who has run out of real oppression, and has to fake it.
Re:Meanwhile, back at the ranch ... by Timex · 2010-07-12 07:24 · Score: 1

And it's web developers' responsibility to make sure that their shit works for its target audience, even if that means holding back because the clueless masses that comprise said audience insist on using Microsoft's cripple-ware.
It's really pretty simple: The W3C should be defining the standard, and if a browser developer doesn't keep up, then they'll just lose out.
If we waited for a Mozilla and Microsoft to adhere to standards 100%, then we'd still be dealing with 1.0 or 1.1 specs. Instead, we're looking at HTML5.
Let W3C write the standard. Allowing multiple source tags for video elements is brilliant, and will make it easy enough for web developers to work around the problem of archaic browsers.
Of course, how or why anyone would not support "open source / royalty free" codecs is beyond me. It's not like they'll be paying a fortune for license fees...

--
When politicians are involved, everyone loses.
Re:Meanwhile, back at the ranch ... by brunascle · 2010-07-12 07:34 · Score: 1

Only just now. It works. I'm a little hesitant to rely on it though, as the styling would be completely messed up for IE users with javascript disabled. But then again, the percentage of IE users with javascript disabled is probably very low.
Re:Meanwhile, back at the ranch ... by Pieroxy · 2010-07-12 07:50 · Score: 1

What are you talking about?
He's responding to a post. Did you care to check?

--
Write boring code, not shiny code!
Re:Meanwhile, back at the ranch ... by Simetrical · 2010-07-12 08:46 · Score: 1

We wait around while the W3C tries to pull it's thumb out of it's ass.
How hard is it to decide on a new standard? Do the members not check their email more than once a year?
The standard is basically decided upon. Most of the important parts look about the same now as they did two years ago. What we're waiting for is implementation. It's all very well to write a spec, but implementing it efficiently and correctly takes far more time. This is why every new browser release touts all the new parts of the HTML5 standard they implemented: the spec is mostly stable, and browsers are in the process of implementing it.
I do think you're underestimating the difficulty and complexity of writing a several-hundred-page spec, though. There's a reason it took a few years.

--
MediaWiki developer, Total War Center sysadmin
Re:Meanwhile, back at the ranch ... by geminidomino · 2010-07-12 09:02 · Score: 1

I wasn't blaming them. I thought that referring to IE as "cripple-ware" would make it clear where I place the blame.
I was just offering another POV on what seemed to me to be a rather cavalier attitude towards supporting what is, for better or for worse (mostly worse), still the majority browser.
Re:Meanwhile, back at the ranch ... by Stan+Vassilev · 2010-07-12 10:03 · Score: 1

Why wait? I use HTML5 today. I start documents with <!DOCTYPE html> and code away. The W3C validator even validates HTML5 documents. What are you waiting for? Maybe for Internet Explorer, but that's Microsoft's responsibility to update.
By writing that you don't use "HTML5", you only use the HTML5 recommended doctype. As you know, it largely does nothing, except kick in "standards" mode in all browsers, and yes, including Microsoft browsers as well, so you've proactively blamed them for nothing.
That doctype working doesn't mean all in the HTML5 recommendations will work, including even in browsers like Safari, Opera and Firefox, given HTML5 is still a spec in progress, and it's highly modular, meaning we may not see the entirety of it for decades to come.
Re:Meanwhile, back at the ranch ... by onlyjoking · 2010-07-12 10:14 · Score: 1

If you're referring to front-end web development I also left it years ago for the same reasons. Back then it was getting columnar layouts to play nice with IE6. Days of my life wasted working around browsers bugs. I decided my time was much better spent coding Perl + database stuff but I recently dipped my toe back into the morass of HTML, CSS & javascript on the understanding that I could finally get away with telling IE6 users to take a hike. A moment of glee at the prospect of using IE7 as the bottom line was short-lived when I was hit by the HTML5 hype and just didn't get it. To me it looks like 2001 all over again. Multiple platforms/browsers, increasing diversity and nothing even half-finished. Give me a break. Back to Perl for, oh, at least another 7 years. So much for the fast pace of technological change.
Re:Meanwhile, back at the ranch ... by Thinboy00 · 2010-07-12 11:40 · Score: 1

YouTube doesn't work with IE6 anymore.

--
$ make available
Re:Meanwhile, back at the ranch ... by bunratty · 2010-07-12 11:52 · Score: 1

Yes, you should test your page on Internet Explorer. But you can't blame the W3C for Internet Explorer's deficiencies, can you? My point was that we're waiting around for Microsoft to support HTML5 in IE, not waiting for the W3C to do something.

--
What a fool believes, he sees, no wise man has the power to reason away.
Re:Meanwhile, back at the ranch ... by bunratty · 2010-07-12 11:54 · Score: 1

I made no comment about supporting or not supporting a browser. I said that if we're waiting on anyone to do something, we're waiting on Microsoft to add HTML5 support to Internet Explorer before we can use HTML5 features. We're not waiting on the W3C to do something.

--
What a fool believes, he sees, no wise man has the power to reason away.
Re:Meanwhile, back at the ranch ... by kurzweilfreak · 2010-07-12 13:22 · Score: 1

If more sites started working correctly without worrying about IE, it either might actually get MS to fix it or get people to install browsers that "work".

--
kurzweil_freak
5th Kyu Genbukan Ninpo/KJJR student
Be the darkness that allows the light to shine.
Re:Meanwhile, back at the ranch ... by RobertM1968 · 2010-07-12 16:13 · Score: 1

Maybe for Internet Explorer, but that's Microsoft's responsibility to update.
And it's web developers' responsibility to make sure that their shit works for its target audience, even if that means holding back because the clueless masses that comprise said audience insist on using Microsoft's cripple-ware.
Those with mod points... you may not like his message, you may not like the way he worded it... but if you've ever been a web developer for any company that needs a web presence everyone can use, then you know what geminidomino says is true. So... why is it modded flamebait?

--
StarTrekPhase2 - The Five Year Mission Continues!
Re:Meanwhile, back at the ranch ... by Nadaka · 2010-07-12 16:48 · Score: 1

BRILLIANT!?
No. Not brilliant.
There is a proper way for an element to fail over to alternate content when the src fails for any reason.
That is to display the content of the tag instead.
Nesting the video tags would have been a simpler, safer, more logical and precedented way of handling graceful failover.
Don't even get me started on how ridiculously retarded the poster attribute is. Its like an img alt attribute, except that it too can fail.
Re:Meanwhile, back at the ranch ... by BZ · 2010-07-12 18:24 · Score: 2, Informative

> How hard is it to decide on a new standard?
Generally, not much harder than writing any piece of technical writing of the same length which has multiple authors with different (and generally conflicting) agendas. The time will also depend on the desired quality of the standard, of course. Writing a standard that says "do something here" or "behavior is not defined" takes less effort than one that carefully describes what a conforming implementation is supposed to do.
The length in this case is order of 1000 pages, last I checked. The desired quality is high (in that "behavior is not defined" stuff is being avoided). The number of authors depends on how you count them, ranging from a minimum of 1 to a maximum of several thousand depending on whom you ask. Realistically, there are at least 5 separate organizations (each with internal politics!) that have veto power over things they don't like, plus the editor, the three working group chairs (one of whom belongs to none of the above 5 organizations), and various invited experts, etc.
That's not even counting the bikeshedding that goes on.
Typical mail volume on the mailing list is around 900 messages a month or so, from a quick look at the archives (conveniently available at http://lists.w3.org/Archives/Public/public-html/ ). Another 400 messages a month or so on the whatwg list (archives at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ ).
I'm assuming you've either never been involved in a standardization effort of any kind or got very very lucky when you were involved and dealt with something small and uncontroversial.
Re:Meanwhile, back at the ranch ... by jesset77 · 2010-07-12 20:43 · Score: 1

There is a proper way for an element to fail over to alternate content when the src fails for any reason. That is to display the content of the tag instead.
Wrong. You only need to fail over into nested content when the browser doesn't know how to parse the tag.
Video tag does that. Browsers that don't know how to parse Video tag ignore it and display the contents instead.
Browsers that DO know how to parse the HTML of a video tag might not understand this or that mime type, so they just go through the source tags until they get the one that they like. How does that not work for you? Why on God's green earth would they have to nest?
As for the poster frame, meh. While deciding if you want to play the video, you can look at an image or failing that look at a black rectangle. I'm not sure I'd want to look at text instead, and I can't see the helpfulness to text browsers to have alt text for a video. Unlike <img>'s, video's are never used as navigational icons.
The one part of the standard I DO take offense to, however it the "whanh we don't want a fullscreen mode". That has to be the dumbest thing I've heard of. Everyone's been using flash video for years, which supports fullscreen. Who does the specification think it is to truncate wildly popular technological possibilities over corner-condition security concerns? It should be up to the browsers to determine if they want to support fullscreen, how to support it and how to help make it secure.

--
People willing to trade their freedom of expression for temporary entertainment deserve neither and will lose both.
Re:Meanwhile, back at the ranch ... by truespin · 2010-07-12 22:12 · Score: 1

My sites degrade gracefully for IE...
Design for worst case, then pretty it up for best case (many of us are doing it the other way round).
Providing *acceptable* baseline experiences for older browsers doesn’t reduce the overall experience.
Users of these browsers (IE 6,7,8 and various other older browsers) should expect to not have the full web experience that the html5 capable browsers enjoy. But, they'll simply miss some rounded corners, drop shadows and nicer typography, but the essence of the pages are the same. Hopefully this technique will also push users towards the newer browsers...
I assure you my pages *do* work in IE6, but they certainly look much better in Safari 5, Chrome, Opera (and to a certain extent Firefox).
Re:Meanwhile, back at the ranch ... by DaVince21 · 2010-07-13 02:25 · Score: 1

HTML5 will remain a cute and fun buzzword for marketing and sales... and a headache for the web developers.
Honestly, HTML5 is designed to remove headaches. It's even rather easy to add support for HTML5 on old browsers (rendering errors excluded, of course). If enough developers, or at least big enough companies (like Google) use it, browsers and users won't have a choice other than to upgrade. And heck, IE9 supposedly does have much better HTML5 support.

--
I am not devoid of humor.
Re:Meanwhile, back at the ranch ... by Nadaka · 2010-07-13 06:34 · Score: 1

I know how it works.
But it works wrong.
There are vastly better ways to handle fail over.
And who says that you shouldn't be able to use a video as a link?
Re:Meanwhile, back at the ranch ... by mini+me · 2010-07-13 06:46 · Score: 1

What is interesting is that Flash developers do not hold back. Try using a version of Flash that is a version or two out of date and you will quickly hit a site forcing you to upgrade. Why is it okay to force users to upgrade Flash to watch your video, but not their browser to watch your video?
Furthermore, Internet Explorer will display your content just fine if you remove your CSS and Javascript declarations. That is the beauty of HTML. It automatically degrades for those using older browsers. You do not have to hold back on the latest and greatest features just because some people choose to use browsers that do not include the full feature-set.
If you are trying to backport your "new-fangled" features and styles to an ancient browser like IE6, you are doing it wrong. Someone still using IE6 today really doesn't really care what your website looks like or your little Javascript trinkets anyway, else they would not be using IE6. Give them plain HTML and let them do what they want to do: Access your content.
Re:Meanwhile, back at the ranch ... by Tubal-Cain · 2010-07-13 07:08 · Score: 2, Insightful

Users don't appreciate having to jump through hoops just to watch the funny cat.

Is HTML 5 still structured as XML? by Crazy+Taco · 2010-07-12 03:58 · Score: 4, Interesting

Is HTML 5 still structured like XHTML? I hope that it is, because one of the biggest pains in the HTML standard was the inconsistent syntax. I think a strength of strict XHTML was that it could be easily parsed by an XML parser, and if we are going back to the syntax of HTML 4 I think that's a step backwards.

--
Beware of bugs in the above code; I have only proved it correct, not tried it.

Re:Is HTML 5 still structured as XML? by GreyWolf3000 · 2010-07-12 04:01 · Score: 4, Informative

There is an XML syntax for HTML5 that you can optionally use.

--
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Re:Is HTML 5 still structured as XML? by dzfoo · 2010-07-12 04:59 · Score: 1

So, if a developer opts to not use it, what does he use? Are we back to the days of un-balanced paragraph and table cell tags, with each web browser making its own assumptions regarding conflicting layout possibilities?
-dZ.

--
Carol vs. Ghost
...Can you save Christmas?
Re:Is HTML 5 still structured as XML? by TheRaven64 · 2010-07-12 05:15 · Score: 1

Then he uses the SGML binding instead of the XML one. As with HTML, this has well-defined semantics. Each tag indicates in the DTD whether it requires closing, overlapping tags (e.g. ) are not permitted, just as they were not with HTML. The parser needs to be aware of tag semantics, so self-closing tags (e.g. br) must be used carefully and you can not use other XML formats (e.g. SVG) inline.

--
I am TheRaven on Soylent News
Re:Is HTML 5 still structured as XML? by shutdown+-p+now · 2010-07-12 05:29 · Score: 2, Insightful

I don't think that it helps in a sense GP implies. If HTML5 was XML-only, that means that any automated tools (such as web scrapers) can just use XML parsers to process content. If it's up to the author, that means we'll have to keep dealing with special parsers for tag soup for decades to come.
Re:Is HTML 5 still structured as XML? by mcgrew · 2010-07-12 05:30 · Score: 1

...one of the biggest pains in the HTML standard was the inconsistent syntax.
Can you elaborate, or give examples?

--
Free Martian Whores!
Re:Is HTML 5 still structured as XML? by maxume · 2010-07-12 05:51 · Score: 1

The markup->DOM algorithm is completely specified, so it should be less of a problem (and they are trying to make sure to have at least 2 separate working implementations of the parser, so there is even a chance they will get it right).

--
Nerd rage is the funniest rage.
Re:Is HTML 5 still structured as XML? by gsnedders · 2010-07-12 06:02 · Score: 1

HTML5's text/html syntax is not defined in terms of SGML, it is a separate syntax specific to HTML, defined at http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html.
Re:Is HTML 5 still structured as XML? by gsnedders · 2010-07-12 06:06 · Score: 1

The HTML syntax. While it is allowed to do, e.g.,
foo
bar, there are (as there were in HTML 4) strict rules about when a tag can be omitted. As for parsing, HTML5 defines how to map any character stream into a DOM (from which normal CSS rules can be applied, without knowledge of the raw source, consistent with how browsers are already architectured) -- defining this was a large part in the reason for HTML5 existing at all.
Re:Is HTML 5 still structured as XML? by gsnedders · 2010-07-12 06:11 · Score: 1

Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then. The big advantage of HTML5 with dealing with arbitrary content is that it has defined parsing rules for any input stream, mapping it to a DOM. This means libraries that parse XML into a DOM can be interchanged with libraries that parse HTML (several already exist following HTML5, see the Validator.nu/Gecko parser (Java/C++) and html5lib (Python, and far less regularly updated PHP/Ruby).
Re:Is HTML 5 still structured as XML? by shutdown+-p+now · 2010-07-12 09:59 · Score: 2, Insightful

Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then.
The main reason why XHTML didn't help was because it didn't add anything on top of HTML4 except for XML syntax. Consequently, most browsers didn't even bother properly supporting it back then - they simply added a few more kludges to their existing HTML parsers to handle XHTML as a kind of "broken HTML" that they realistically had to deal with, anyway.
HTML5 is different in that it adds a lot of new features. If it also mandated that anyone using them (and, in general, "DOCTYPE html") must serve well-formed XML, the uptake would be much quicker. What more, XHTML5 already requires the documents to be well-formed, and the parsers to report an error if that is not so rather than trying to parse them as tag soup, and browsers supporting HTML5 do enforce that rule (just checked - Firefox, Opera and Chrome all complain on malformed XHTML5 input instead of rendering the page). If only XHTML was allowed, and browsers were refusing to render invalid XHTML, that would ensure that any site picking up HTML5 would serve well-formed XHTML, readily parseable.
HTML5 parsers? Sure, you can have one, but we already have XML parsers for many more platforms - mainly because they're so much easier to write. You linked to stuff for Java, C++ and Python; good, but what about plain C? what about .NET?
Re:Is HTML 5 still structured as XML? by Denis+Lemire · 2010-07-12 10:13 · Score: 2, Insightful

HTML had far too many ways to do things relative to XHTML
* Uppercase or lower case tags, who cares, they're case insensitive
* Single quote or double quote attributes values, take your pick or mix them, who cares
* Do attributes even have a value? Sometimes...
* Close your tags, don't close your tags... It varies, who cares?
* Etc...
All of these made parsing HTML a pain cause you couldn't make any assumptions about the syntax. Often you would find inconsistencies with the above within one document. XHTML was far stricter. HTML5 seems to have mostly thrown that progress out by making the strict well formed XML syntax 'optional.'
Re:Is HTML 5 still structured as XML? by gsnedders · 2010-07-12 10:43 · Score: 1

What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence). I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed). As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages. Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
Re:Is HTML 5 still structured as XML? by gsnedders · 2010-07-12 10:46 · Score: 1

Gah, I always expect paragraphs to be added automatically in CMSes; to repost with paragraphs (albeit probably still with too few):
What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).
I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into most CMSes... heck, at a more basic level try U+0000). There's a very long way to come before software is anywhere near ready to be able to output XML safely everywhere (and ideally use a serializer to ensure that all output is well-formed).
As for the complexity of XML parsers relative of HTML5 ones, I'm not convinced having been involved in writing both. There's a lot of complexity both in tokenizing and parsing doctypes in XML. As for other languages: there was talk a couple years ago of libxml2 moving to the HTML5 parsing algorithm for its HTML parser once the spec stabilizes (which, for parsing at least, bar a few bugs in the foreign content insertion mode, it more or less has) which would cover C (and also most platforms), here's a C#/.NET one, though now outdated, and there's a Perl one on CPAN. I'd expect implementations to continue to appear in more and more languages.
Sure, getting the diversity of implementations to the level of XML will take a while, but quickly with implementations in C++, Java, Python, Ruby, C#, PHP, Perl you're already covering a large majority of applications today. Having only an XHTML serialization may have helped with future content, but there's a couple of decades worth of legacy content that will probably never go away: if you want to deal with the majority of web content you're still going to have to deal with HTML. (Equally, if you leave parsing undefined, you still need to run around reverse-engineering browsers, which is not a sustainable approach.)
Re:Is HTML 5 still structured as XML? by shutdown+-p+now · 2010-07-12 11:02 · Score: 1

Gah, I always expect paragraphs to be added automatically in CMSes
"Options -> Comment Post Mode -> Plain Old Text" will make every blank line count as paragraph.

What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).
IE, as usual...
Anyway, I consider "use XML parser first, fall back to HTML one if XML is not well-formed" a hack as well, since the end result is the same.
Overall, I guess you're right, anyway. Still, a geek isn't a geek without bitching about the missed opportunity for making something more elegant every now and then... ~
Re:Is HTML 5 still structured as XML? by Nadaka · 2010-07-12 16:56 · Score: 3, Interesting

Unfortunately, No. HTML5 was designed by the guys that thought that XML was to hard, So they wrote a 5000 page spec that codified all the ways that browsers tried to handle broken syntax and made that the standard...
You think I am joking. I am not.
My hat of html05 know no limit. (ok, so thats a joke, but few here will get it.)
Re:Is HTML 5 still structured as XML? by DaVince21 · 2010-07-13 02:28 · Score: 1

He probably means the self-closing tags. "Do I or do I not close an img tag?"
Of course, experienced developers are well aware of these, and know why they're self-closing in the first place.

--
I am not devoid of humor.
Re:Is HTML 5 still structured as XML? by mcgrew · 2010-07-13 06:01 · Score: 1

Hmmm, I consider all but the attributes thing and closing tags to be a plus, not a minus.

--
Free Martian Whores!
Re:Is HTML 5 still structured as XML? by Simetrical · 2010-07-13 09:35 · Score: 1

HTML5 is different in that it adds a lot of new features. If it also mandated that anyone using them (and, in general, "DOCTYPE html") must serve well-formed XML, the uptake would be much quicker.
No, it wouldn't. Authors would not want to use XML, just as they do now. Browser implementers are not willing to work on features that authors don't want to use, so they'd just implement all the features without the XML requirements.
Actually, this is pretty much exactly what happened. The W3C tried to do new features only in XML. The browser implementers got sick of it and started work on HTML5 outside the W3C, ignoring the W3C standards. (Correctly, in my view, because XHTML2 et al. were bad ideas in practice, but some people still dispute that.) Eventually the W3C accepted HTML5 because the alternative was being completely ignored.
So, the W3C tried it. Didn't work. Browsers aren't going to try it, because they compete, so they're forced to cater to actual users and authors, and almost none of them want to use XML if given the choice.

--
MediaWiki developer, Total War Center sysadmin
Re:Is HTML 5 still structured as XML? by shutdown+-p+now · 2010-07-13 09:55 · Score: 1

No, it wouldn't. Authors would not want to use XML, just as they do now.
Actually, surprisingly many authors use XHTML even today, and most HTML5 demos I've seen are written in well-formed XHTML in practice.

Actually, this is pretty much exactly what happened. The W3C tried to do new features only in XML.

The problem with XHTML2 didn't have anything to do with the fact that it was XML-only. The problem was that they threw out most existing HTML elements, and changed semantics for many that remained, so it wasn't backwards-compatible even with XHTML1. So the only migration path was rewriting your website from scratch. Of course everyone ignored that!
The thing discussed here is different - retain backwards compatibility on DOM level. This means that 1) any XHTML1 website just works, and 2) any HTML4 website can be automatically translated to XHTML1 - on the fly, if needed - and also just work.
The only reason to have HTML mode alongside XML in HTML5 that I see is to allow people with HTML4 websites to start using new HTML5 features without going XHTML. I do wonder how much this is an issue in practice, though, as the group of people most interested in HTML5 seem to be the same folks who proudly put "validated by W3C" stickers on their websites, and who moved it all to XHTML ages ago, anyway.
Re:Is HTML 5 still structured as XML? by Simetrical · 2010-07-14 05:33 · Score: 1

Actually, surprisingly many authors use XHTML even today, and most HTML5 demos I've seen are written in well-formed XHTML in practice.
Really? Which authors use well-formed XML reliably, and which HTML5 demos are well-formed XML? The only major site I know of that serves well-formed pages reliably is Wikipedia. Remember that with XML, you don't get points for effort: if some minority of your pages are not well-formed, they fail to display.

The problem with XHTML2 didn't have anything to do with the fact that it was XML-only. The problem was that they threw out most existing HTML elements, and changed semantics for many that remained, so it wasn't backwards-compatible even with XHTML1.
I wasn't only talking about XHTML2. In 2004, Mozilla and Opera proposed that work begin in the W3C on incremental improvements to HTML independent of the path that the W3C was already pursuing. This path included XHTML2, but also XForms and other things (XML-based across the board). The W3C rejected their proposal, and that's how the WHATWG was formed. You can read a summary from the perspective of the browser implementers.
This wasn't only about XML, you're right, it was also about all-around impracticality. But XML was a big part of the picture. I can say with pretty good certainty that browser vendors would have refused to restrict new features only to XML even if that's all that was on the table. After all, implementers wrote HTML5, and had the choice to limit it to XML, but didn't. It's too brittle and hard to write correctly. One mistake and your page goes up in flames, and some of the mistakes you can make are very subtle.
Someone pointed out that on Unix, if you have a weird filename (non-printable characters) and try to visit a file:/// URL in some versions of Firefox, you get a well-formedness error. So even Mozilla can't get well-formedness right all the time. It's really hard to catch that kind of thing; XML is just too strict and too complicated. Errors about nesting are even worse, because they can't even be detected when you emit things unless you use an XML parser to build your output instead of string functions.

The thing discussed here is different - retain backwards compatibility on DOM level. This means that 1) any XHTML1 website just works, and 2) any HTML4 website can be automatically translated to XHTML1 - on the fly, if needed - and also just work.
So then you'd have to have a reliable HTML parser anyway, and you're saying it should be deployed on the server side instead of the client? What sense does that make? There are millions of servers, but at most five major clients. Implementing the parser in the client is much more reasonable, and much easier to implement. (Which is why that's what's actually done.)

The only reason to have HTML mode alongside XML in HTML5 that I see is to allow people with HTML4 websites to start using new HTML5 features without going XHTML. I do wonder how much this is an issue in practice, though, as the group of people most interested in HTML5 seem to be the same folks who proudly put "validated by W3C" stickers on their websites, and who moved it all to XHTML ages ago, anyway.
Actually, HTML5 advocates mostly get into violent arguments with XHTML advocates. ;) In practice, though, it would be a major problem. HTML5 is not only meant for standards advocates, it's meant for everyone. Plenty of Google properties use HTML5 features, but basically nothing they output is well-formed. Five or ten years from now, Joe Q. Author is expected to be slapping down video tags just like img tags, and almost no authors use well-formed XML.

--
MediaWiki developer, Total War Center sysadmin

Dive into HTML5 by 0100010001010011 · 2010-07-12 03:59 · Score: 5, Informative

Is also a great resource. With less ads, things broken up by chapter, examples, how to detect if something is enabled, etc.

http://diveintohtml5.org/

Re:All well and good... by 99BottlesOfBeerInMyF · 2010-07-12 04:07 · Score: 4, Insightful

But why do I have a sinking feeling that adoption of this new standard will be held back by Internet Explorer's atrocious handling of it?

I think between Google Chrome Frame and HTML 5 Shiv, MS will have a lot less power to hold back Web standards than they usually wield.

a single year by digitalsushi · 2010-07-12 04:14 · Score: 1

I predict that in a single year from now, the vast majority of browsers being run will be html5 ready; it's only been in the past few years that the browsers began self-updating; everyone wants html5, and so developers will be firmly able to count on it existing very soon.

--
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue

Re:All well and good... by Randle_Revar · 2010-07-12 04:15 · Score: 3, Informative

IE8 is a lot further along than IE7; and IE9, which should hit beta later this year, supports all HTML5 elements.

--
Climate Progress - Hell and High Water

Re:All well and good... by bunratty · 2010-07-12 04:16 · Score: 3, Informative

IE8 was released last year and passes Acid2. IE9 will be released soon, and it performs much better than IE8 on Acid3 (the latest preview scores 83/100). Yes, they are still lagging behind, but they're at least trying to keep up with the pack.

--
What a fool believes, he sees, no wise man has the power to reason away.

Standards by Irick · 2010-07-12 04:34 · Score: 2, Interesting

HTML is not a finished standard. Should this prevent people from starting to use it? No, in fact, hell no, we should start using it right now to increase the uptake and motivate the developments of better technologies for utilizing it. A trial by fire will by itself weed out the un-needed portions of HTML 5 and perhaps show the usefulness of features that would otherwise be left out. Should IE's abysmal standards compliance prevent you from writing properly formated code? No, again, you should always motivate the use of new web technologies for helping to implement an advanced and open web.

Minor improvements by Animats · 2010-07-12 04:36 · Score: 4, Interesting

(Read the "print" version of the article, instead of the "tiny blocks of text spread over many pages of ads" version.)

I have misgivings about HTML5. It gives the page more control, and the user less. That's been a trend in HTML for years, and it's getting worse.

I'm dreading "canvas". Ad blockers need to get smarter. Noticed that popups are winning over Firefox's popup blocking? We're also going to see pages that use 100% of the CPU just for display. We're going to need a browser option for "don't run canvas code for windows that aren't on top.

The "input type" mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").

Dynamically-loaded fonts have been working for some time now in all the mainstream browsers. (IE6 and Firefox 3.5 were the last mainstream browsers not to have it.) We've been playing with that for our steampunk site. Downloadable fonts without anti-aliasing turn out to look ugly for small font sizes, because most of the display-type fonts have too much detail and not enough hinting for small font sizes. (In an annoying piece of Apple incompatibility, the iPad requires fonts in SVG, of all things. Everybody else, including Microsoft, is going to Web Open Font Format.) I'd recommend against using this feature much unless you have a good sense of typography. (Bad example: our steampunk search engine.)

Re:Minor improvements by Serious+Callers+Only · 2010-07-12 04:56 · Score: 1

The iPad does not require fonts in svg. Like other modern browsers it supports @font-face using standard OTF fonts. iPhone does the same with ios 4.
Not sure if web open font is required personally, but if catches on I'm sure weblog will support it.
Re:Minor improvements by 99BottlesOfBeerInMyF · 2010-07-12 05:00 · Score: 4, Informative

I have misgivings about HTML5. It gives the page more control, and the user less. That's been a trend in HTML for years, and it's getting worse.
I disagree. HTML5 gives the user more control. Right now we're hampered by proprietary plug-ins to provide functionality, like Silverlight and Flash. With HTML5 taking over those functions, the browser codes it, so you can choose which browser you want based upon how well it lets you control the elements on the page. It's basically moving parts of Web pages from single vendor closed implementations to open implementations that compete to serve you best.
Well, that and a lot more nice tags to break up pages into sections, add support for custom fonts, etc. But that doesn't mean the user loses control. These are markup languages meant to be interpreted. If you don't like custom fonts, noting stops a browser from offering an option of rendering the all as a font of your choosing in the color of your choosing, etc.

We're going to need a browser option for "don't run canvas code for windows that aren't on top.
And we can add it. Moreover, we can add a lot more finely grained controls than that, since it is now specified in the canvas element instead of a Flash movie. It's no longer just "run" or "don't run". It can be "run but never let the sound get above this volume, confine it to the page, and modify the way it runs so it never overlaps any text". Hell, we could add the option of making canvas elements that overlap other elements 90% transparent by default and always having a close and display button.

They should have provided for either regular expressions...
They did. It's even demonstrated in the article.
Re:Minor improvements by Serious+Callers+Only · 2010-07-12 05:14 · Score: 1

Meant to say I'm sure weblog will support it, not weblog!
Re:Minor improvements by TheRaven64 · 2010-07-12 05:20 · Score: 1

HTML5 gives the user more control. Right now we're hampered by proprietary plug-ins to provide functionality, like Silverlight and Flash
The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.

--
I am TheRaven on Soylent News
Re:Minor improvements by hedronist · 2010-07-12 05:26 · Score: 1

Actually, that page is an excellent example of why you shouldn't use a display font for normal text. It immediately went on my list of What you don't want your site to look like websites that I show to my customers.
Re:Minor improvements by rockNme2349 · 2010-07-12 05:49 · Score: 2, Informative

The "input type" mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").
If you had RTFA you would have seen that one of the new validation types IS regex in the HTML 5 draft.
<input type="text" pattern="REGEX HERE">

--
Sewage Treatment Facilities - "Our duty is clear."
Re:Minor improvements by 99BottlesOfBeerInMyF · 2010-07-12 06:29 · Score: 1

The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off.
I guess that depends upon the page, doesn't it? On some pages Flash is added for ads and is not related to the main content. In others, like Hulu, Flash IS the main content of the page. For still others, (like Homestarrunner) the whole page including navigation is built in Flash.
If you only use Flash on sites that only use it for ads, then I agree this will make it more complex to block those ads. On the other hand, for those that rely upon content currently in Flash and other closed plug-in formats, this is a net win for control.
Re:Minor improvements by e4g4 · 2010-07-12 06:33 · Score: 2, Funny

I'm sure weblog will support it.

Meant to say I'm sure weblog will support it, not weblog!
Yeah - that really clears it up...

--
The secret to creativity is knowing how to hide your sources. - Albert Einstein
Re:Minor improvements by Animats · 2010-07-12 06:42 · Score: 1

The iPad does not require fonts in svg. Like other modern browsers it supports @font-face using standard OTF fonts.
Typophile, TypeKit and Fast Company all say the iPhone/iPad don't support TTF or WOFF downloadable fonts, just SVG. Also, selection doesn't work right for SVG fonts on the iPad, and loading multiple weights of the same font is said to crash the browser.
Please disable Jobs Reality Distortion Field before using.
Re:Minor improvements by Simetrical · 2010-07-12 08:57 · Score: 1

The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.
No, it would be trivial. Just display all canvases as blank, and don't display their contents until the user lets them. You can treat canvas operations as no-ops, or have them execute but not draw the results to the screen until the user requests it.
This won't stop pages from using 100% CPU, but they can do that anyway. They usually don't, and I don't expect canvas to change that.

--
MediaWiki developer, Total War Center sysadmin
Re:Minor improvements by lee1 · 2010-07-13 04:17 · Score: 1

iPhone does the same with ios 4.
I just tried it on this font-face demonstration site and it didn't work. Do you have an example of a url that I can load in mobile safari that will show me font-face working?
Re:Minor improvements by tepples · 2010-07-13 07:57 · Score: 1

Just display all canvases as blank, and don't display their contents until the user lets them.

Then watch pages display all the text and images inside a canvas, so that if you turn off the canvas element, you turn off everything.
Re:Minor improvements by Simetrical · 2010-07-13 08:14 · Score: 1

Just display all canvases as blank, and don't display their contents until the user lets them.
Then watch pages display all the text and images inside a canvas, so that if you turn off the canvas element, you turn off everything.
They can already do this with Flash, and in fact some do. It's not going to be any easier or more reliable to do this with canvas than Flash in the near future. Flash has had well over 95% market share at various points, and few sites did this despite that. Canvas doesn't change anything. Non-HTML sites are a pain in the neck and lose a lot of functionality that users expect.
In the end, anything evil that can be done with canvas can be done with Flash, since canvas provides a subset of Flash's functionality. Canvas is not going to cause any problems for users that did not already exist with Flash.

--
MediaWiki developer, Total War Center sysadmin
Re:Minor improvements by Serious+Callers+Only · 2010-07-14 09:12 · Score: 1

Sorry, my mistake, it supports fonts in OTF format using @font-face for local pages in a webview, but for some reason they have deactivated this support in Mobile Safari.
Weird. Works perfectly for local pages using a normal OTF font and UIAppFonts to load it, but as you say it requires SVG for mobile safari.
Hopefully they will fix this in an update, as I imagine a lot of people will be asking for it. Since the webkit bundled actually supports using normal OTF fonts, I've no idea why it is disabled when browsing - they were worried about the security of their font loading code perhaps?
Re:Minor improvements by Serious+Callers+Only · 2010-07-14 09:14 · Score: 1

Sorry, I was wrong, Mobile Safari doesn't at present support loading fonts, only local webviews support this.
Re:Minor improvements by lee1 · 2010-07-14 11:32 · Score: 1

Too bad, I was hoping you were right.

Re:All well and good... by Runaway1956 · 2010-07-12 04:47 · Score: 1, Informative

I have to ask what you mean by "minority". I hate IE as much as anyone, but the fact is, it is used by more people than all other browsers put together. I don't tailor my view of reality based on what I like, and you should get out of the habit.

Whoa - I went looking for a link to give my claims some weight - and I found this:

http://www.w3schools.com/browsers/browsers_stats.asp

I guess if you are only measuring home users and technical users, you might get figures like that! But, when you include ALL COMPUTERS, you get quite different results.

http://marketshare.hitslink.com/browser-market-share.aspx?qprid=0

--
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br

Re:All well and good... by shentino · 2010-07-12 04:48 · Score: 1

You have to wonder what's going on when having a broken out of date IE6 is considered a feature in corporate environments on account of how badly it breaks facebook and youtube.

Re:All well and good... by 99BottlesOfBeerInMyF · 2010-07-12 04:48 · Score: 1

Who mods this crap up? IE is still over 50% and by far the most popular browser. Mainstream web developers need to test in IE or have a workaround for IE. IE's dominance is still a huge influence on Web development. The difference is, there are now practical ways to rewrite code on the fly for IE, or install a plug-in in IE that makes it behave as though it were standards compliant for a site.

Re:All well and good... by 99BottlesOfBeerInMyF · 2010-07-12 04:49 · Score: 2, Insightful

...and IE9, which should hit beta later this year, supports all HTML5 elements.

Citation?

Thanks, no by thePowerOfGrayskull · 2010-07-12 04:51 · Score: 3, Insightful

I've learned long ago that developing against standards that are not yet official is the road to pain. This is demonstrated even in the summary itself:

Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way.

So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"?

Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."

Soo... now I'm already having to code workarounds before the standard is even official? Again - thanks, no. I'll wait until it's ratified as a standard, and the first revision of major browsers offers compliance.

Re:Thanks, no by 99BottlesOfBeerInMyF · 2010-07-12 05:13 · Score: 1

Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way.
So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"?
This is something of a straw man. No one recommends you implement the features that aren't readily available in all major browsers. It just goes through a list of features that seem likely to soon be available in all browsers. You're the only one saying you should implement those particular items.

Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."
Soo... now I'm already having to code workarounds before the standard is even official?
Yes, since everyone in their right mind can see IE does not now and is unlikely to soon implement standards compliance. You implement work arounds for IE now in all your pages don't you, just like all the rest of the world that does Web development? Why would you think that is going to change? So here's a nice list of the new standard you can actually use now, and the work around code to make IE behave like a real browser. That's exactly what every developer needs to implement any feature on the Web, regardless of how much of a "standard" it is.
By all means feel free to ignore HTML5 and not implement any of it. It just means your site will be crappier than sites being reworked with support for some of the nice new standards. The game is changing, but there's no reason you have to get on board. By all means, sit on the sidelines until you feel comfortable.
Re:Thanks, no by TheRaven64 · 2010-07-12 05:25 · Score: 1

HTML 5 is being developed incrementally. Some parts of the standard are final, some are considered early drafts (you can see which by checking the spec - it's annotated with this information). For something to be final, it must have feedback from two independent implementations.
Things like HTML 5 Shiv are part of the design of HTML 5. It is intentionally designed in such a way that it can be implemented in legacy browsers using a combination of plugins and JavaScript. This is not a workaround, it's a migration path. You can start using the features before their support is ubiquitous, using fallback code to support them on older browsers. This helps avoid the chicken and egg problem that new specs often suffer from - content creators don't use them until the browsers support them, and the browsers don't support them until there's content that needs them.

--
I am TheRaven on Soylent News
Re:Thanks, no by afabbro · 2010-07-12 07:21 · Score: 1

I've learned long ago that developing against standards that are not yet official is the road to pain. This is demonstrated even in the summary itself. So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"? Soo... now I'm already having to code workarounds before the standard is even official? Again - thanks, no. I'll wait until it's ratified as a standard, and the first revision of major browsers offers compliance.
Well then you can enjoy the wait until 2022, because that's when it will reach W3C Recommendation, which is the current status of HTML4.
Of course, by that time the rest of us will all be enjoying HTML9.
The real standard is "what do 80% of browsers support?" Browser support for HTML5 will be added piecemeal, just like they did with HTML4.

--
Advice: on VPS providers
Re:Thanks, no by thePowerOfGrayskull · 2010-07-12 13:04 · Score: 1

ANd until then, I have to keep coding browser-based workarounds for a given feature that is implemented on platform "A" and not platform "B". This does not seem like a good solution.
I'm ok with using things that are already implemented... but trying to use features that are not implemented completely across all platforms is a major step backwards.
Re:Thanks, no by thePowerOfGrayskull · 2010-07-12 13:51 · Score: 1

Things like HTML 5 Shiv are part of the design of HTML 5. It is intentionally designed in such a way that it can be implemented in legacy browsers using a combination of plugins and JavaScript. This is not a workaround, it's a migration path
I have read about that -- but it still reads like a workaround. You're still doing twice the work to implement the same feature for different platforms; there's no way around that.
Re:Thanks, no by thePowerOfGrayskull · 2010-07-14 05:04 · Score: 1

This is something of a straw man. No one recommends you implement the features that aren't readily available in all major browsers. It just goes through a list of features that seem likely to soon be available in all browsers. You're the only one saying you should implement those particular items.
You must haev read a different article. The one I read said:

There's clearly a core of HTML5 features that all the major non-IE browsers do support, which could allow "draft HTML5" websites to be deployed to a large segment of the Web-using population.
The problem with that statement is that - as much as we might like to have it otherwise - IE is still a major browser; and in some parts of the world is still the dominant browser. Your own statement confirms that you're aware of this too:

Yes, since everyone in their right mind can see IE does not now and is unlikely to soon implement standards compliance. You implement work arounds for IE now in all your pages don't you, just like all the rest of the world that does Web development? Why would you think that is going to change?
That's kind of the point, isn't it? If it's not going to change soon (and all indications are that it's not), why would I want to make four versions of my site when I could do the same thing today with one or two? Using many common JS libraries hides the incompatibilities, so why not go with "HTML 5 Shiv" and skip HTML 5 entirely until it's more widely available? My alternative is implementing "draft HTML5" sites - I need to code those sites twice or more: once for IE, once for the common HTML5 functionality supported by other browsers; and once for the people not using the cutting edge browser builds (which is often the majority of people). .

By all means feel free to ignore HTML5 and not implement any of it. It just means your site will be crappier than sites being reworked with support for some of the nice new standards. The game is changing, but there's no reason you have to get on board. By all means, sit on the sidelines until you feel comfortable.
Have you looked around lately at what's possible under existing standards? Change happens, but it's not like we're hurting that badly for lack of it right now - using some of the ubiquitous JS libraries it's possible to make very interactive and flexible web sites today. HTML5 will make that easier, but not so drastically easier that it's worth the hassle of doubling or trebling my work.
The entire thing is as frustrating to me as handheld development is proving to be: a vast user base has a huge array of device/platform combinations. You want to use the latest features from the newest, but you also have to support those running the older. This means doing two, three or more times as much work in order to ensure compatibility and seamless degradation across platforms.
At least in the case of handhelds you're not aiming for a moving target - you know for a fact exactly what capabilities you have available to you for a given platform version. In HTML5, we aren't even given that much yet.
Re:Thanks, no by 99BottlesOfBeerInMyF · 2010-07-20 02:11 · Score: 1

Sorry it took me so long to reply to this.

...why would I want to make four versions of my site when I could do the same thing today with one or two? Using many common JS libraries hides the incompatibilities, so why not go with "HTML 5 Shiv" and skip HTML 5 entirely until it's more widely available?
You seem to be misunderstanding what HTML5 shiv is. It's a library that lets IE interpret HTML 5 features coded in HTML5 (with a few caveats). Your choice isn't to use HTML 5 or HTML 5 Shiv, but rather to not use HTML 5, or to use HTML5 and include HTML 5 shiv to work around IE. Just using the shiv does nothing.

My alternative is implementing "draft HTML5" sites - I need to code those sites twice or more: once for IE, once for the common HTML5 functionality supported by other browsers; and once for the people not using the cutting edge browser builds (which is often the majority of people).
Your alternative is to implement the site once, using only the features of HTML 5 that are well supported either natively by all the browsers you care about, or via HTML 5 Shiv. That's one version of the site that should degrade gracefully for old browsers.

Have you looked around lately at what's possible under existing standards? Change happens, but it's not like we're hurting that badly for lack of it right now...
I very strongly disagree. We're advancing in our ability to use ever more clever hacks to work around a core lack of increased functionality and, frankly, it is painful for Web developers and greatly slows progress.

The entire thing is as frustrating to me as handheld development is proving to be: a vast user base has a huge array of device/platform combinations. You want to use the latest features from the newest, but you also have to support those running the older. This means doing two, three or more times as much work in order to ensure compatibility and seamless degradation across platforms.
Which is one of the things HTML5 is addressing. Rather than figuring out a hack to get GPS data from your handheld to your Web site, you now have a single standard all the phones are moving to support. The sooner it happens, the less pain in the long term.

At least in the case of handhelds you're not aiming for a moving target - you know for a fact exactly what capabilities you have available to you for a given platform version. In HTML5, we aren't even given that much yet.
I think you're overloading the term "platform" here. Cell phones are always updating functionality and each one updates the OS and has differing levels of support for the OS incrementally. HTML 5 is, ironically, one of the closest things we have to a platform for all cell phones, where the subset of browsers is limited, the inputs are handled for you, and we can create write once run everywhere apps going forward.

Re:Flash has gotta go by Runaway1956 · 2010-07-12 04:51 · Score: 1

Ever thought about sending a report to the owners of the pages that crash your browser? Tell 'em Flash sucks, and tell 'em why.

--
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br

Re:All well and good... by thePowerOfGrayskull · 2010-07-12 04:52 · Score: 1

At this point IE is a minority browser. I haven't tested any web site I've developed in the last 5 years in IE. It's just not worth the time to develop for a broken and ancient browser like IE.

Just because you're not testing ofr it doesn't mean that people aren't using it. It looks like it largely depends on the type of site -- more technically-oriented sites will typically have it as a minority; while mainstream and ecommerce sites will more often show it at the majority (in the US) or close to majority.

Multi-column! Multi-column!! by mozumder · 2010-07-12 05:15 · Score: 2, Insightful

Multi-column (even with basic support), and full support of font-face, is going to go finally enable real layout.

Can you imagine inDesign, or Quark (or Pagemaker, etc..) without multi-column support?

Are there ANY newspapers that don't support multi-column layout?

Meanwhile, I'd like to see varying width/varying shape columns, with reflows, and proper column break hints.

The current support in Firefox/Safari/Chrome is much appreciated, though. (IE doesn't have it at all!)

Example multi-column layout with font-faces: http://www.futureclaw.com/articles/visionary-futurist-syd-mead.html

Re:All well and good... by shutdown+-p+now · 2010-07-12 05:30 · Score: 1

At this point IE is a minority browser.

You have a curious definition of "minority" if it matches "65% of the market".

Sure, it may well be a minority browser for your audience, it it's an overly technical one, or if you live in Eastern Europe. But most people aren't so lucky.

Re:Multi-column! Multi-column!! by Anonymous Coward · 2010-07-12 05:31 · Score: 1, Insightful

I don't understand the point of having multi-column as part of HTML. Multi-column layouts exist because of a number of properties of print layout that do not apply to the web. Web pages are not fixed size. They are not restricted in any direction, but they are commonly expected to not have a limited vertical dimension. Assumptions of fixed sizes have a tendency to get broken on web pages. And multiple pieces of complete content rarely appear on a single page. Multi-column is a print concept, but the web is not print.

Re:Flash has gotta go by AltairDusk · 2010-07-12 05:34 · Score: 1

I can't even remember the last time Flash crashed Firefox on me. In fact the last time it crashed was on an AJAX site. While I don't doubt Flash can cause issues too laying blanket blame on Adobe doesn't seem correct.

Re:Multi-column! Multi-column!! by mozumder · 2010-07-12 05:36 · Score: 4, Insightful

It's because page-width is variable that multi-columns are needed. There is a visual usability limit to column sizes, about 5-10 words or so.

It is a mistake to think that print properties do not apply to web. The same visual rules apply to web, or anywhere.

Re:All well and good... by DragonWriter · 2010-07-12 05:44 · Score: 5, Insightful

IE8 is a lot further along than IE7; and IE9, which should hit beta later this year, supports all HTML5 elements.

No, IE9 passes all of Microsoft's HTML5 tests.

Which is very different than supporting all HTML5 elements. (And even more different than meaningfully supporting all HTML5 elements.)

Re:All well and good... by religious+freak · 2010-07-12 05:51 · Score: 2, Informative

Agreed. Right in TFA, it clearly shows IE is running WAAAY behind every other browser by far.

--
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011

How To Use HTML5 Today (The Idiots Guide) by pizzach · 2010-07-12 06:06 · Score: 1

It is quite simple and always error free! Ideal for blogs and flash pages where content is not paramount.

<!doctype html>
<html />

--
Once you start despising the jerks, you become one.

Re:How To Use HTML5 Today (The Idiots Guide) by afabbro · 2010-07-12 07:22 · Score: 1

It is quite simple and always error free! Ideal for blogs and flash pages where content is not paramount.
Yeah, for most blogs I've seen, "content is not paramount" is an understatement...

--
Advice: on VPS providers

Re:Multi-column! Multi-column!! by Anonymous Coward · 2010-07-12 06:16 · Score: 1, Insightful

Ugh... wall of text with two columns? That means the user has to scroll down a dozen screens, then back up, then down a second time. It works when you're reading a magazine or your monitor is tall enough to have all the text on one screen, but neither is the case for most web sites.

Font issues. by Animats · 2010-07-12 06:30 · Score: 1

Actually, that page is an excellent example of why you shouldn't use a display font for normal text.

With a system that does anti-aliasing of text (Windows 7, Vista(?), newer MacOS, newer Linux, etc.) it's not too bad. If your system doesn't, it looks awful. It looks terrible in Windows XP and earlier, even if you have a current browser. It's definitely not something ready for wide scale deployment given the current state of client platforms. I'm trying it for the amusement of the steampunk community.

Those are actual 19th century fonts, scanned in from a book of type styles circa 1900 and vectorized.

Re:Font issues. by Archon-X · 2010-07-12 08:30 · Score: 1

Looks terrible on windows 7 64bit, in chrome, FF and opera here.
I'm not being a troll, I'm just telling you how it is :)

Video gallery by rwa2 · 2010-07-12 06:37 · Score: 1

Are there any good photo / video web albums that use HTML5 to good effect yet?

I'm kinda hooked on http://marginalhacks.com/Hacks/album/ , which has the simplest, most straightforward interface of all the other things I've tried. And it makes a good attempt at handling video. I have a simple shell script that imports pics from my Canon camera, converts the mjpegs to .mp4, and tosses it into my ~/public_html/pictures directory indexed by Album.

http://gallery.menalto.com/ is also one of my favorites, but it's a bit too labor intensive for a photo archive... I do try to load some of the nicest shots in it, though, for all the comments and other features..

Re:Multi-column! Multi-column!! by demonbug · 2010-07-12 06:39 · Score: 2, Informative

Have you actually tried reading multi-column pages on the web? It is a pain in the ass. Instead of just scrolling down as you read, you scroll down to the bottom of the first column, then scroll back up to the top, then scroll down again to read the next column, etc. It is pointless, and offers zero advantages to the reader. The only people clamoring for it seem to be layout artists raised on print layout; I can't think of a single case as a reader where I would prefer multi-column over single-column layout for an article. Yes, there may be a usability limit to column width - but on the web there is no limit to the vertical dimension, so this really doesn't matter.

The one place multiple columns in an electronic medium makes sense is where you can fit everything on a single page by doing so, and in order to be readable that means knowing the size of the screen your readers will be using - if you can't guarantee that, just use a single column. Pretty much everyone is used to scrolling down as they read, it is quite easy and seamless.

Multi-column has nothing to do with page width - yes, there will be significant space "wasted" in a single-column layout, but so what? It is much better than the alternative of having to scroll up and down as you read.

Re:Multi-column! Multi-column!! by bigrockpeltr · 2010-07-12 06:46 · Score: 1

if you want multi column that bad its just an extra 42 chars for two columns and additional 9 per column.

--
$ unzip, strip, touch, finger, grep, mount, fsck, more, yes,fsck,fsck,fsck,umount, sleep

Re:Multi-column! Multi-column!! by mozumder · 2010-07-12 07:10 · Score: 1

Multi-column can actually prevent scrolling entirely, by using the horizontal space instead of forcing you to scroll vertically.

Don't! by Yvan256 · 2010-07-12 07:14 · Score: 4, Funny

Don't blink. Blink and you're dead. They are fast, faster than you could believe, don't turn your back, don't look away, and don't blink. Good luck.

Re:Don't! by Flossymike · 2010-07-12 07:44 · Score: 1

:-)
Re:Don't! by jesset77 · 2010-07-12 20:30 · Score: 1

Don't blink. Blink and you're dead. They are fast, faster than you could believe, don't turn your back, don't look away, and don't..............
LET ME EAT PEARS 8I

--
People willing to trade their freedom of expression for temporary entertainment deserve neither and will lose both.

Re:Multi-column! Multi-column!! by Hatta · 2010-07-12 08:26 · Score: 1

Well ain't that a big fuck you to the user. No web design should ever disable features the user finds useful.

--
Give me Classic Slashdot or give me death!

Re:Multi-column! Multi-column!! by Hatta · 2010-07-12 08:30 · Score: 1

It's because page-width is variable that multi-columns are needed. There is a visual usability limit to column sizes, about 5-10 words or so.

That does not follow. Yes, a 60 character column is optimal, but that doesn't mean you have to shove a bunch of columns right next to each other. One article should be one long column. Scrolling is easy, and it doesn't force us to keep moving our eyes from top to bottom like multi-column does. A single column would leave lots of whitespace, but so what? I'm not looking at the whitespace, I'm looking at the column. If anything, having more than one column is distracting.

--
Give me Classic Slashdot or give me death!

still only makes sense for backends 90% of time by systematical · 2010-07-12 08:43 · Score: 1

HTML 5 really only makes sense for backends where I/T can dictate browser policies. For instance at my last two jobs I/T has dictated the use of the latest version of FireFox, its been pretty sweet. Unfortunately, most web designers and developers still need to do things the IE 6 way on frontends.

Working draft by Alien1024 · 2010-07-12 09:01 · Score: 1

Isn't HTML5 a freaking working draft...? Wake me up when we have a real spec

Re:All well and good... by Simetrical · 2010-07-12 09:04 · Score: 1

IE9, which should hit beta later this year, supports all HTML5 elements.

Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.

--
MediaWiki developer, Total War Center sysadmin

Re:Multi-column! Multi-column!! by mozumder · 2010-07-12 09:12 · Score: 1

Indeed.

Users are the least capable of determining the quality of their own experience.

Re:Multi-column! Multi-column!! by mozumder · 2010-07-12 09:14 · Score: 1

If what you said is true, newspapers would all end up being one long scroll.

It is easier to scan across several short columns, than to go down one long column.

Re:Multi-column! Multi-column!! by Hatta · 2010-07-12 10:18 · Score: 2, Insightful

Newspapers have physical limitations that web pages do not. Ideally a newspaper would be several long scrolls, one per article. We have the freedom to do that on the web and we should.

--
Give me Classic Slashdot or give me death!

Re:Multi-column! Multi-column!! by Hatta · 2010-07-12 10:22 · Score: 1

Please go work on Gnome or something. The rest of us will be enjoying features we like.

--
Give me Classic Slashdot or give me death!

Re:Multi-column! Multi-column!! by RJFerret · 2010-07-12 13:50 · Score: 3, Insightful

Huh? That would be a scrolling nightmare.

Sure enough, looking at the link provided, it's totally unreadable. The information on the page is out of context with the rest of the information on the page, the text providing context is off screen below. Instead of being able to quickly read or skim any of it, I gave up and closed the tab, returned here to report.

You might only have a hammer in your toolbox, and believe everything you see is a nail, but it's not. Newspapers needed the crutch of multiple columns because their format was hopelessly wide. Web pages have the opposite problem, they are infinitely tall. (One of the wonderful attributes of the Readability tool is to increase a web pages width to fill the screen.)

Worse, more web access is being done on mobile devices, thankfully that site was one column in Opera mini, I suppose we'll have to spoof to make it readable on other browsers?

It's not a mistake to think that print properties do not apply to the web, it's a mistake to misapply properties designed to overcome one liability, to media that has the opposite liability!

PS: Below you claim, "Multi-column can actually prevent scrolling entirely, by using the horizontal space instead of forcing you to scroll vertically." Seemingly to overlook the obvious extra white space required between multiple columns that isn't normally wasted--multiple columns add length.

Valid HTML5 is not valid SGML... by Sits · 2010-07-12 19:34 · Score: 1

...at least not in its non-XML form (check out the doctype for starters). If you've wanted to cope with your typical "in the wild" web page over at least the past 10 years, you've needed a special HTML parser anyway - SGML wasn't enough.

What HTML5 has tried to do is codify how to recover from errors so hopefully if you do choose to make non-validating HTML5 pages there is a greater chance that all browsers will recover the same way.

weblog - webkit ? by Sits · 2010-07-12 19:44 · Score: 1

WOFF is in Chromium's webkit but seemingly not mainline webkit.

Re:All well and good... by tenco · 2010-07-13 01:10 · Score: 1

Unless you go domestic: http://gs.statcounter.com/#browser-PL-monthly-200906-201007 http://gs.statcounter.com/#browser-DE-monthly-200906-201007 http://gs.statcounter.com/#browser-AT-monthly-200906-201007 http://gs.statcounter.com/#browser-BG-monthly-200906-201007 http://gs.statcounter.com/#browser-CZ-monthly-200906-201007 http://gs.statcounter.com/#browser-FI-monthly-200906-201007 http://gs.statcounter.com/#browser-HU-monthly-200906-201007

But globally, you're right. Unfortunately. I guess most of us want to go "North Korea" on IE: http://gs.statcounter.com/#browser-KP-monthly-200906-201007 (Kim Jong-il must have stopped using the web in septembre 2009 :)

Re:Multi-column! Multi-column!! by lee1 · 2010-07-13 04:28 · Score: 1

Multi-column (even with basic support), and full support of font-face, is going to go finally enable real layout.

No, it's not. Not until browsers implement a real hyphenation and line-breaking algorithm like that found in TeX. Until then, web typography will continue to look like the crude output of a word processor, no matter how many pretty fonts you make your readers download.

Split-screen! Split-screen! by tepples · 2010-07-13 08:04 · Score: 1

One of the wonderful attributes of the Readability tool is to increase a web pages width to fill the screen.

The eye most easily reads columns that are no longer than 80 characters (width: 40em in CSS). But modern PC monitors are 2560 pixels wide. At the default font-size: 16px, that's 320 characters or 160em, and the eye has a hard time finding the start of the next line of text. That's why on monitors at least 1600 pixels wide, I tend to split the screen down the middle. Windows 7's window manager has the "snap" feature, and Windows XP's has Ctrl+right click other window > Tile Vertically.

Seemingly to overlook the obvious extra white space required between multiple columns that isn't normally wasted--multiple columns add length.

But narrower columns also reduce the amount of leading (space between lines) needed to keep the eye from jumping the track. So even if you do need 2em of space between columns, you might still break even.

Re:Multi-column! Multi-column!! by Simetrical · 2010-07-13 09:38 · Score: 1

The one place multiple columns in an electronic medium makes sense is where you can fit everything on a single page by doing so, and in order to be readable that means knowing the size of the screen your readers will be using - if you can't guarantee that, just use a single column. Pretty much everyone is used to scrolling down as they read, it is quite easy and seamless.

Actually, there's at least one more case: where the user isn't reading sequentially at all. Wikipedia often uses multiple columns for footnotes, and that works excellently. They take up less vertical space, and it's no harder to read (since you're only reading one footnote at a time anyway, and probably not reading any at all).

--
MediaWiki developer, Total War Center sysadmin

Re:Multi-column! Multi-column!! by benhattman · 2010-07-14 10:19 · Score: 1

Seemingly to overlook the obvious extra white space required between multiple columns that isn't normally wasted--multiple columns add length.

FYI, white space is a major boon to reading retention. YesIcouldwriteallmysentenceswithnowhitespace orpunctuationasthatwouldminimizethetotal spacerequiredbutitseemstomelikeitmightbeabadidea.

Just to prove my point, /. would not allow me to type the last sentence with no spaces. So, I had to add two just to pass their filter. For additional fun, try reading ancient Hebrew, where they understood that not only were spaces unnecessary, but so were vowels and punctuation.

134 of 155 comments (clear)