How To Use HTML5 Today 155
snydeq writes "InfoWorld's Dori Smith offers developers a hands-on guide to using HTML5 today. 'Many of the media reports about HTML5 have focused on the politics, the "not until 2022" sound bite, or on HTML5's prospects as a "Flash killer." The reality of HTML5 is simply that it's the long-needed and long-overdue update to HTML4 — and you can start to implement it today,' Smith writes. Video, semantic tags, smart form input validation — Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way. Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."
Meanwhile, back at the ranch ... (Score:3, 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?
Re:All well and good... (Score:5, 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.
Re:Meanwhile, back at the ranch ... (Score:3, 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 ... (Score:5, Insightful)
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 ... (Score:3, 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:All well and good... (Score:3, Insightful)
...and IE9, which should hit beta later this year, supports all HTML5 elements.
Citation?
Thanks, no (Score:4, Insightful)
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.
Multi-column! Multi-column!! (Score:3, 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 [futureclaw.com]
Re:Is HTML 5 still structured as XML? (Score:3, 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:Multi-column! Multi-column!! (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:Multi-column! Multi-column!! (Score:5, 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:Meanwhile, back at the ranch ... (Score:3, Insightful)
Re:All well and good... (Score:5, Insightful)
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:Multi-column! Multi-column!! (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.
Re:Meanwhile, back at the ranch ... (Score:3, Insightful)
Re:Is HTML 5 still structured as XML? (Score:3, 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? (Score:3, 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:Multi-column! Multi-column!! (Score:3, 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.
Re:Multi-column! Multi-column!! (Score:4, 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.
Re:Meanwhile, back at the ranch ... (Score:2, Insightful)