How To Use HTML5 Today

← Back to Stories (view on slashdot.org)

Posted by CmdrTaco on Monday July 12, 2010 @03:46AM from the but-i-wanted-it-yesterday dept.

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."

37 of 155 comments (clear)

Min score:

Reason:

Sort:

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
1. 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!
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!"
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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...
7. 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.
8. 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.
9. 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.
1. 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.
2. 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.
3. 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?
4. 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.'
5. 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.)
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.
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.)
1. 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.
2. 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."
3. 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: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.
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: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
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.
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: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 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.