Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

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 [infoworld.com] 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.

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.

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.

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.

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

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.

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.

That doesn't work. IE doesn't add the new tags to the DOM properly; tags withing the <article> tag will be added as siblings to the <article>, 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>...

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.

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?

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?

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

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

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.

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.

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.

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.

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.

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?

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. <b><i></b></i>) 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.

The HTML syntax. While it is allowed to do, e.g., <!doctype html><p>foo<p>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.

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.

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 pa

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

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

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

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

* 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 fa

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

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.

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 motiva

(Read the "print" version [infoworld.com] 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" [w3.org] 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 [aetherltd.com]. 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. [sitetruth.com])

The iPad does not require fonts in svg. Like other modern browsers it supports @font-face using standard OTF fonts.

Typophile [typophile.com], TypeKit [typekit.com] and Fast Company [fastcompany.com] 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.

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.

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.

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 i

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.

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.

Actually, that page [aetherltd.com] 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.

The "input type" [w3.org] 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.

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.

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.

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 t

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 m

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.

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 [whatwg.org], 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 [deepbluesky.com] will be added piecemeal, just like they did with HTML4.

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!

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

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 l

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/ [marginalhacks.com] , 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.

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:

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.

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.

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> [whatwg.org], <meter> [whatwg.org], <details> [whatwg.org], <menu> [whatwg.org], and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

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.

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.