HTML 5: Now or Never?

Tweet

Here at SitePoint, we have started thinking about HTML 5, and whether or not the time is right to publish a book about it. To help us decide, we asked a number of web luminaries what they thought. Their answers were both varied and interesting. Take a look and decide for yourself: is it time you started learning about HTML 5?

Jonathan Snook, co-author of SitePoint’s The Art & Science of CSS is taking the wait-and-see approach. “You can only implement what browsers support and right now, of HTML 5, that’s very little,” he said. In fact, all of the experts we contacted agreed that most of the new features in HTML 5 have yet to be supported by even the very latest web browsers.

Tommy Olsson, co-author of SitePoint’s The Ultimate CSS Reference, is skeptical to say the least: “HTML 5 isn’t of any real interest to me right now. A vast majority of the visitors to the sites for which I’m responsible are using browsers with no support for HTML 5, and that situation is likely to persist for a few more years.”

That said, there are a number of really useful HTML 5 features that you can use today. The canvas element for drawing graphics on-the-fly is a good example; new in HTML 5, it’s already supported by every major browser except Internet Explorer (and there are workarounds for IE too). For respected web designer Dave Shea (best known for building the CSS Zen Garden), canvas is the most exciting feature of HTML 5. “Native vector graphics. Finally! SVG still doesn’t feel like it has arrived on today’s web, especially in mobile browsers; on the other hand, canvas is already available in a handful of mobile and most desktop browsers, and I think it’d be safe to wager the rest will catch up shortly.”

Lesser-known HTML 5 features like offline data storage, cross-document messaging, and access to the back/forward stack, which are mainly of interest to JavaScript developers, are also popping up in the newest browsers, including IE8.

Ian Lloyd, author of SitePoint’s The Ultimate HTML Reference and Build Your Own Web Site The Right Way Using HTML & CSS, points out that you can even use HTML 5 features with little or no current browser support, if you’re prepared to specify your own CSS styles. “If you use an HTML element like section, it can actually be styled with CSS, even if the browser does not understand what the element is (but it requires a JavaScript hack). With the JS doing its thing, it can make adoption of HTML5 more palatable.” Ian has even added HTML 5 support to his Markup Maker tool, which will generate for you the HTML skeleton of a web page based on the structure that you specify.

Designer Andy Clarke, author of Transcending CSS and creator of For A Beautiful Web, doesn’t think it’s worth the effort to use HTML 5 elements just yet, but he is laying the groundwork. “I don’t intend to develop with HTML 5 any time soon, but I do think that it is important to prepare for their new semantics in some way. That’s why I’ve adapted my own naming conventions to include HTML 5 element names (class="header", "section", "article", "aside" etc.).” Nevertheless, Clarke believes it’s worth learning HTML 5 if only to impress prospective clients. “As with any important new technology, designers and developers should aim to understand the nuances of HTML 5 as early as they can, so that they can be fully aware of its advantages. It’s also important for when clients ask about HTML 5 as those in the know surely will.”

Dave Shea recommends you choose an approach that suits the type of work you are doing. “I’d say it’s a good time to start learning and experimenting. Some are going further and launching full sites in HTML 5 already, but I’d say that works best for personal and experimental sites. Would I redesign my blog in HTML 5 now? Sure, I might give it a shot. Would I do client work in HTML 5? Heavens no.”

Tommy Olsson can think of better ways for today’s designers to spend their time. “I think developers should concentrate on learning HTML 4.01 first of all. Too many don’t even understand that properly. By all means, keep an eye on HTML 5, but it’s going to be quite a few years before it’s universally usable.” Even if you do know your HTML 4, Andy Clarke seems to agree there may be better places to focus your attention. “I strongly believe that there are other, more useful and important aspects of web design and development that we should be paying attention to now, especially Microformats. Microformats have a low barrier to entry, build on existing semantics and offer far more useful opportunities today, in 2009, than HTML 5.”

That covers the present, but what do these influential minds think of HTML 5’s future? Andy Clarke doubts HTML 5 will have any real impact on his work. “I wish it well, but I do have the feeling that by the time that HTML 5 becomes a mainstream alternative to what we are using currently, I’ll be little more than a ghost result on a Google search. Page 1865, yes, I’ll be on there.”

Predictably, Tommy Olsson hopes it never sees the light of day. “I think it’s an abomination, but I’m probably in a small minority. I’m seriously considering a change of career if/when HTML 5 becomes prevalent. It mocks everything I consider important on the Web: semantics, accessibility, and the separation of content from presentation. The worst part is that it redefines the semantics of existing element types, so that markup that has been semantically correct for over a decade suddenly becomes meaningless.”

In either case, Jonathan Snook prefers to put a more positive spin on the situation. “While some people are concerned about the direction of HTML5 and that it’s not progressing quickly enough, I’m just happy that any progress is being made and that browsers are implementing at least some of these features.”

What do you think? Should SitePoint publish a no-nonsense book about HTML 5, or should we ignore it for now and hope it goes away?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • mhulse

    A Sitepoint book on HTML5? Heck yah! I would buy that book! :)

    I’d say it’s a good time to start learning and experimenting.

    I agree.

    That’s why I’ve adapted my own naming conventions to include HTML 5 element names (class=”header”, “section”, “article”, “aside” etc.).”

    Nice tip!

    “HTML 5 isn’t of any real interest to me right now. A vast majority of the visitors to the sites for which I’m responsible are using browsers with no support for HTML 5, and that situation is likely to persist for a few more years.”

    I also agree… I would only use HTML5 and CSS3 on something experimental/personal/non-critical at this point in time.

    But! Two+ years will go by quick.

    “I think developers should concentrate on learning HTML 4.01 first of all. Too many don’t even understand that properly. By all means, keep an eye on HTML 5, but it’s going to be quite a few years before it’s universally usable.”

    Also agree.

    Hrmm, maybe this is slightly off topic, but… I dunno about the rest of you, but I am a little tired of using content management systems that output strict XHTML markup. The sooner HTML5 becomes “popular” the sooner the CMS apps I use will get on the HTML4+ boat! :D

    @Tommy Olsson: What type of markup (DTD) does he currently prefer? That quote is pretty extreme. Maybe a Sitepoint book will help ease his concerns? ;)

    What do you think? Should SitePoint publish a no-nonsense book about HTML 5, or should we ignore it for now and hope it goes away?

    Yes! Or, maybe, start building-up a dedicated section in the reference section.

    Cheers,
    M

  • SpacePhoenix

    Has the final HTML 5 spec been finalised and confirmed? Until then it is probably too early to do a book. Ditto that for the next version of XHTML. It might perhaps be useful for Sitepoint to have a multi-part article examining and comparing HTML5 and XHTML2 including the pros and cons of each of them.

  • yogomozilla

    Just what the world needs, another version of HTML. Fascinating to see “marquee” will make it into HTML5, can’t wait to implement that in 2013.

    It seems they’ve covered just about everything you can currently do with a library like jquery. The only beneficial part is that it’s a possible standard – meaning those libraries can produce a progress bar to defined set of criteria (which is a good thing).

    Effort should be put into just making the browser viewport a window into any document you wish to serve up and present there (HTML, XML, JSON whatever) rather than restricting it further.

  • http://www.sitepoint.com/ mmj

    Writing anything about HTML5, other than an examination in the name of curiousity, before it is even a “recommendation” is asking for trouble in my opinion. You wouldn’t be writing about HTML5, you’d be writing about “what the HTML5 draft looked like at a certain point in time”. You’d be helping to diverge the standard, especially if there are subsequent changes before it is finalised.

    Add to that the fact that by the time it’s published, it is still unlikely to be a finalised standard, let alone being supported on typical web browsers, for some time further.

    HTML 4.01 is the latest HTML standard that actually exists, which is depressing to those who are eager for change but important to those that actually want to support the latest standard.

  • Jaffa The Cake

    Is canvas really vector graphics? I thought it was more like Flash’s bitmap data, so there’s still need for SVG.

  • WebKarnage

    The single thing that will delay HTML 5 more than anything else for me is what Tommy Olsson points out regarding it redefining existing semantics. This is also bound to cause horrid chaos at some point. Sure it might make some work for some of us, but many of those who don’t understand will also speak badly of the original designers regardless of the age of the design. Why generate the possibility of a huge mess? I suppose they will expect browsers to contain multiple rendering engines for ever now, responding to document type. Now that’s a way to have more divergent sets of standards all in operation together!!!

    I think it could take a good few years for this transition, and anyone involved in deciding HTML 5’s future needs to be careful of what type of mess they are leaving the rest of us who have no say, but have to use it all the same.

    There are many sites still using XHTML transitional, and we talk of HTML 5 before we have certainty! Jumping the gun more than looking forward.

    with best regards,
    Karn.

  • http://www.sitepoint.com/ Kevin Yank

    A reminder: HTML 5 can’t become a finalized W3C recommendation until there are at least two independent implementations in the wild. I think we can all agree that it will be many years before two browsers fully support every feature of HTML 5, and we’ll probably need serious books covering the features that are well supported long before then.

  • http://www.sitepoint.com/ Kevin Yank

    Jaffa The Cake,

    Is canvas really vector graphics? I thought it was more like Flash’s bitmap data, so there’s still need for SVG.

    Canvas is vector graphics. The difference is that after you draw a shape with SVG, you can update/modify that shape (in the same way you can change the content or style of an HTML element on the fly). With canvas, once a shape is drawn, you can only draw new shapes over it.

  • forever4now

    It could be useful to have a book that:
    1. Describes HTML5’s key functionality.
    2. Contrasts current web solutions (Flash, Silverlight, etc.) and HTML5, with pros & cons.
    3. Provides examples where HTML5 may be appropriate and when Flash may be appropriate (e.g. games?).
    4. Describes techniques to prepare websites for HTML5:
    – adapting naming conventions to include HTML5 element names (class=”header”, “section”, “article”, “aside” etc.)
    – using Google Gears (Ian Hickson explains how to code a page for HTML5 & fall back to Gears. http://www.youtube.com/watch?v=xIxDJof7xxQ)

  • wiibart

    No doubt, HTML5 is hot because ..

    iPhone !

  • http://richclarkdesign.com RichClark

    I think Dave Shea hit the nail on the head here:

    Would I redesign my blog in HTML 5 now? Sure, I might give it a shot. Would I do client work in HTML 5? Heavens no.

    The fact is that there are quite a few ‘in the wild implementations’ of html5 here and now so if we’re talking about progressive enchancement with CSS why not the same with html? Pretty much all browsers and devices can be made to understand the basic new elements (albeit with some j/script for IE). So why not give it a go, I have on my site as has Bruce Lawson from Opera and others.

    A book would be an excellent resource the only trouble being that the spec keeps changing, for example only a few weeks ago we had the new <hgroup> element introduced so I’m not sure how you’d keep it up to date unless it was pdf only and updates were freely available to those who have already purchased it?

  • Jaffa The Cake

    Kevin Yank,

    Isn’t that what makes vector graphics different? Once drawn, only a bitmap representation of canvas content is maintained, making it a bitmap.

    You may have told it to draw a circle and a square, but as far as canvas is concerned the result is just an x by y grid of pixels.

  • Jack Osborne

    Although I can see why some people believe writing a book on HTML5 could pose problems, you have to remember that the spec has to signed off later on this year. Perhaps then it and only then, would it be a good idea to get the ball rolling on this subject because at that point the author and the readers will be able to make sense of something which has been signed off.

    Whether or not the spec changes after that point is for a totally different conversation/book.

  • tobyx

    It’s important to get on the train now, rather sooner than later. It doesn’t mean we have to do client work in HTML 5, but being ignorant will just stall the adoption even further. It’s an interesting topic and it’s loooong overdue.

  • Jaffa The Cake

    I’d be more interested in reading a book on the evolution of the spec. Why certain decisions were made, what problems they had to overcome, which bits were scrapped as they were contended etc etc.

    Would be a good insight.

  • http://www.tyssendesign.com.au Tyssen

    @RichClark: I was thinking about doing a HTML5 sites showcase a little while back. Looks like you beat me to it. :)

  • Jake Smith

    Surely the gestation period of a book means that when a solid HTML5 we’re more than likely 9 months in the future from now.

    I don’t want to be scrambling to get a foothold in HTML5 when it becomes mainstream. I need to examine the pros and cons, see whose supporting and when, and be able to advise my clients correctly, without FUD or running with the pack. My clients expect me to know what the future will hold for them online, and count on me to give sound advice.

    Sure, right now I won’t be writing clients’ sites in HTML5, but as others have pointed out, will be trying it for my own projects so I have an understanding of what to expect.

  • Shelley

    Some errors:

    First, the canvas element existed before HTML5. It exists whether you’re using HTML5 or not. Secondly, the canvas element is bitmap, not vector graphics. SVG is vector graphics.

    As for a book, sure…if it’s in digital format, only, and the author is committed to updating it frequently, and providing the updated versions to readers at no charge.

  • http://www.sitepoint.com/ Kevin Yank

    Jaffa The Cake,

    Isn’t that what makes vector graphics different? Once drawn, only a bitmap representation of canvas content is maintained, making it a bitmap.

    Not quite. The difference between vector graphics and raster graphics is that in vector graphics you can tell the browser to draw a circle that, say, fills the canvas. That canvas may be 600×600 pixels on a desktop browser, or 100×100 pixels on a mobile phone. In either case, the browser calculates the pixels needed to draw a perfectly sharp circle within the available pixel dimensions.

    In raster graphics (the good old <img> tag), on the other hand, you feed the browser pre-determined bitmap images. If you want to display a circle, you need to create, say, a PNG file containing that circle. You must decide ahead of time what pixel dimensions that circle will be rendered at. If you create a 100×100 pixel image, it will look blurry if stretched to 600×600 pixels; likewise, if you create a 600×600 image, current browsers will usually do a pretty poor job of squishing it down to 100×100 pixels.

    Vector images are about providing descriptions of shapes that can be rendered to pixels by the browser on the fly. Raster images are about providing pre-rendered images with pre-determined pixel dimensions.

    Both canvas and SVG are ways of displaying vector graphics; the difference is that canvas uses immediate mode rendering, while SVG uses retained mode rendering.

  • http://www.olsenportfolio.com/ nrg_alpha

    I for one will not bother with HTML 5 just yet (and to answer the question of whether sitepoint should publish a book on it, I would wait till it gains a little more traction first).

    The following link is an interview with Ian Hickson, editor of the HTML 5 specifications. In that interview, Ian too thinks it’s too early to start working with HTML 5:

    http://www.webstandards.org/ (it’s the current ‘Recent Buzz’ interview on the home page).

  • http://keryx.se itpastorn

    My fellow countryman (Tommy) is often spot on, but this time I do believe he is exaggerating.

    Separation of concerns is still the way to go. I think he stopped following the development a few years ago when the font tag was being discussed. (It is gone, BTW.) Quite a lot of design-specific markup has been discussed, but only as (a) dismissed suggestions from random people, or as (b) browser requirements, because they must handle legacy content.

    Author requirements vz. browser requirements is the most misunderstood aspect of HTML 5. If a book could help explain that, it would be most welcome.

    Stuff in the spec that is seeing wide implementation can be seen as very unlikely to be changed in any fundamental way, as is stuff that has been part of the spec for a long time. I.e. <aside> is robust, <hgroup> is not.

    @SpacePhoenix: Do not get hung up on the status of the spec! CSS 2.1 is not. Look at CSS 2.1. It took forever to get it into Candidate Recommendation. And even though only minute details are being worked upon (and the test suite!) it is not a proposed recommendation yet.

    HTML 5 stuff can be divided in 3 parts:

    1. Stuff that you can use today and it will work in most browsers (embed, drag and drop, etc)

    2. Stuff that can be made to work with JavaScript and will degrade gracefully (<input type=”date”>, canvas, nav, section, article, etc)

    3. Stuff that is still quite a bit into the future and perhaps also a bit preliminary in nature.

    If a book explains this, and provides details about fallbacks and JavaScript solutions, I think it could come out on the market this fall.

  • Jaffa The Cake

    Kevin Yank,

    (sorry to keep this going)

    If you create a 100*100 canvas element then use CSS to display it at 600*600, you’ll get the same kind of image resizing artefacts as you would if you resized an <img /> by the same amount.

    Canvas Spec

    The canvas element represents a resolution-dependent bitmap canvas…

  • aliceslipped

    I would buy and read a book on HTML 5 now. What better way to learn?
    Plus, you’d get a head start on any rivals you have out there. ;P

  • http://autisticcuckoo.net/ AutisticCuckoo

    @Tommy Olsson: What type of markup (DTD) does he currently prefer? That quote is pretty extreme. Maybe a Sitepoint book will help ease his concerns? ;)

    I prefer HTML 4.01 Strict – the latest W3C recommendation with any support worth mentioning. Yes, it could be improved, but HTML5 doesn’t seem to be the way to do it.

    I’ve written a SitePoint book (plus one for another publisher), so I don’t think such a book would ease my concerns. :)

  • http://www.sitepoint.com/ Kevin Yank

    Jaffa The Cake,

    You are correct that, once vector graphics have been rendered by a canvas element into pixels, resizing the canvas will cause resizing artefacts.

    I suppose you could say that from the web designer’s point of view, canvas lets you draw vector graphics in the same way that Adobe Illustrator lets a designer draw vector graphics and then export them as a (raster) PNG image.

    All current computer displays require graphics to eventually be rendered as a raster image. With the vector graphics support provided by canvas, you can describe the graphics you wish to display using vector primitives (shapes), rather than having to serve potentially large bitmaps in your web application, or write code to set individual pixel color values one at a time. That is the fundamental difference between vector and raster graphics.

  • VodkaFish

    Implementing HTML 5 on any large site now is jumping the gun. Just because we expect a browser to support certain tags in certain ways doesn’t mean they actually will. Like the W3C, I’ll wait for a couple of independent implementations before moving forward with it (if I even do at all).

  • Shelley

    Jaffa and Kevin,

    I realize this discussion is between the two of you, but if I may interject: The HTML5 spec calls the canvas element a “resolution dependent bitmap canvas”, which makes it a raster, not a vector, graphic. Yes, you’re using circles and lines to represent the image, but it is drawn on a resolution dependent “canvas”.

    When I embed SVG in my pages, though, as I do in the background of my various sites (see realtech.burningbird.net), the image isn’t constrained to a specific resolution. This means I can set the size of the graphic to be based on overall page size, not pixel size, and the image will scale based on a person making their browser window larger or smaller.

    Sure you could use percentages with the canvas element, but the drawing is still based on a pixel dependent resolution canvas. SVG, on the other hand, is dependent on shapes, not on pixels.

    Vladimir Vukićević of Mozilla had a presentation on this in 2006, at http://people.mozilla.com/~vladimir/xtech2006/. Click through to the 6th page, with SVG on one side, Canvas on the other. How do they differ? SVG deals with shapes, Canvas with pixels.

  • ionix5891

    why bother?

  • arts-multimedia

    Before html 5 is going to be mainstream, many web applications will become available which can do a much better job of practically anything html 5 can come up with. When you look at what Adobe is cooking up at the moment, I doubt that anybody will want to make use of the new functionality of html 5, except as an experiment.
    I think that html became rather like a foundation block upon which the rest is developed these days. How many tags are we actually still using from html 4 at the moment? Most formatting has been taken over by css and functionality by programming and scripting.
    Correct me if I’m wrong, but I doubt html 5 is going to shake the world, so to speak.
    I will keep an eye on it by reading articles here and there, but I think there is much more important stuff to learn at this time.

  • http://www.terrellharris.net/ funktifyknow

    @Tommy:

    I was kind of thinking the same thing. You are one of the guys I come to on here when I get stuck, and you basically cowrote THE SitePoint book on HTML/CSS, plus the reference, so you must have a valid reason for being leery of the language.

    Personally, I don’t think there is any need to rush into writing a book on the topic. There a numerous sites out there that have info about HTML 5 already, and since it isn’t a recommendation yet, it seems rather moot.

  • arts-multimedia

    Actually, I agree with Jaffa who says:

    I’d be more interested in reading a book on the evolution of the spec. Why certain decisions were made, what problems they had to overcome, which bits were scrapped as they were contended etc etc.
    Would be a good insight.

  • http://panesofglass.org/ aranwe

    I am quite uninterested in HTML5, and I realize I am probably in a very small minority. My thoughts are simple: HTML is a document format. HTML5 is trying to force a document format into an application platform. That doesn’t even make logical sense, though obviously it’s possible.

    When a web app becomes rich enough to be a full-fledged application, what’s wrong with using a technology like Flash/Flex, Silverlight, JavaFX, etc? Host it in an HTML document, make it a resource on the semantic web, etc. HTML5 just seems like a completely bad idea to me.

    Likewise, XHTML2 seems a really bad idea as well. I actually like a lot of the recommendations, but such a drastic change for something that seems to offer only a few helpful features (and also deviates from other standards, e.g. nested <h> tags instead of <h1>, <h2>, etc.) seems misguided as well.

    I like XHTML over HTML4.01 if only because it fits a more rigid structure and leaves behind the potential for “tag soup.” I know there are some TS fans out there, but I am not one. I find great benefit in the strict tagging structures of XHTML (missing from HTML5), especially when parsing and re-using my own existing XHTML docs.

  • telga

    “…[HTML 5] mocks everything I consider important on the Web: semantics, accessibility, and the separation of content from presentation. The worst part is that it redefines the semantics of existing element types, so that markup that has been semantically correct for over a decade suddenly becomes meaningless.”

    Exactly. I’ll continue to use XHTML and RDFa; I have no interest in HTML 5 other than to oppose it and its ‘paving of the cow paths’.

    So, no, Site Point should not bring out a book about HTML 5–unless it wishes to bring into question, at least from some perspectives including mine, its actual support for and commitment to “semantics, accessibility, and the separation of content from presentation”.

  • Jenn

    I would buy! Perhaps is html5 is used, users will upgrade to teh latest browser of there choice. Aren’t newest builds of IE, Opera, Firefox, Safari adding in (some) support?

  • steve

    The worst part is that it redefines the semantics of existing element types, so that markup that has been semantically correct for over a decade suddenly becomes meaningless

    I don’t really agree with that quote. Zillions of nested divs are not semantic. Defining the sections of a page with HTML5 is a good idea and much more semantic.

    The book would be good – but not just yet.

  • forever4now

    It could be useful to have a book that:
    1. Describes HTML5’s key functionality.
    2. Contrasts current web solutions (Flash, Silverlight, etc.) and HTML5, with pros & cons.
    3. Provides examples where HTML5 may be appropriate and where Flash may be appropriate (e.g. games?).
    4. Describes techniques to prepare websites for HTML5:
    – adapting naming conventions to include HTML5 element names (class=”header”, “section”, “article”, “aside” etc.)
    – using Google Gears (Ian Hickson explains how to code a page for HTML5 & fall back to Gears in a YouTube video).

  • Anonymous

    If it doesn’t increase semantics better than xhtml, I can’t see myself wanting to use it. I love how strict xhtml is and how you must close all opening tags properly. Makes things look better for multiple devices as well.

    I say if you’re going to write a book, wait for the technology to come out and give it a test run beforehand. Otherwise it isn’t about what html 5 is, it’s about what you think it’ll be. Never forget that the direction of the object can change in time.

  • Daquan Wright

    If it doesn’t increase semantics better than xhtml, I can’t see myself wanting to use it. I love how strict xhtml is and how you must close all opening tags properly. Makes things look better for multiple devices as well.

    I say if you’re going to write a book, wait for the technology to come out and give it a test run beforehand. Otherwise it isn’t about what html 5 is, it’s about what you think it’ll be. Never forget that the direction of the object can change in time.

  • mattur

    “[HTML 5] mocks everything I consider important on the Web: semantics, accessibility, and the separation of content from presentation. The worst part is that it redefines the semantics of existing element types, so that markup that has been semantically correct for over a decade suddenly becomes meaningless.”

    Pure FUD. HTML5 adds “semantics” (i.e. new structural elements), and adds new accessibility features. HTML doesn’t mark up “meaning”, it marks up presentational structure. I thought we all understood this by now :) I can understand demented standardistas circulating FUD about HTML5, but expected more from you Tommy.

  • Paul

    I agree that an HTML5 book is premature, but a book which focused on building rich interfaces using Canvas and included SVG and VML references for porting code to create cross-browser vector graphics would be very timely. An ECMAScript5 vs ECMAScript4 book is probably more along the lines of being both cutting edge and practical, considering that browser vendors and Adobe update their scripting engines with every major release. In addition, there’s a huge gaping hole in print and online resources on “ActionScript for JavaScript Developers” or vice versa.

  • zfdesign

    Yes such book is needed. on the other hand considering at what stage HTML 5 is may just be an overview of what is new and how much support there is so far. What could be expected. What will be definitely useful is to give more details to this community on what is to come. Surely there will be situations where the better tool to build may be HTML 5 but you can only make a good decision based some knowledge.

    Give it a go I will buy if it is not too big :). I haven’t got the time for everything.

  • Justen

    I don’t see the point. If we want to define our own semantic elements, XHTML supports doctype extensions. Why HTML5 support is more important than XHTML doctype extension support (lacking in IE) I’ll never know. I like some of the new form features, but they’re nothing that can’t be provided via some clever scripting (jQueryUI will handle it for you). The token effort at semantics might actually make the semantics situation worse, rather than better; half the new ‘semantic’ elements are not semantic at all, they’re presentational. The problem is already essentially solved by the microformats community, anyway. A few of the scripting features and DOM changes sound nifty, but I’m not sold on the usefulness. Overall, big waste of effort. I’m pretty confident that HTML5 is stillborn, and all the time spent implementing it should have been spent improving javascript performance, fixing bugs in XHTML and CSS2.1 support, and implementing CSS3 features.

  • http://www.karpie.net Karpie

    At home I write HTML 4.01 Strict code, and at work I write XHTML 1.0 Transitional code. I don’t see either of those changing anytime soon.

  • Justen

    Oh about canvas, forget canvas. get http://www.raphaeljs.com and be happy, great vector graphics support is already here.

  • telga

    “I don’t see the point. If we want to define our own semantic elements, XHTML supports doctype extensions. Why HTML5 support is more important than XHTML doctype extension support (lacking in IE) I’ll never know.”

    @Justen,

    Well said.

    The questions, who/what benefits–most–from paving cow paths and who/what loses–most–by arresting the development and implemtation of XHTML?

  • http://www.fastliondesign.com FastLionDesign

    1. I strongly recommend against writing a book for HTML 5. It is too early for that. Experienced developers probably won’t bother buying it since they know it is too early in the game. And inexperienced web designers may buy it then be extremely disappointed when they discover they can’t use HTML 5 for two or three years.

    2. Sitepoint would be better off writing and updating books on customizing CMSs, especially the popular PHP-based CMSs: WordPress, Joomla and Drupal. This is a hot topic now. Yes, there are a few books for sale now on this topic. But customizing CMSs has become so important that well-written and well organized books that emphasize high-quality design would probably sell for you. You may consider getting ahead of the curve and writing about up-and-coming CMSs such as Silver Stripe, or maybe review the basics of a few new CMSs in one book.

    3. I agree that HTML 5 and XHTML 2 should not change any existing elements. HTML 5 and XHTML 2 should add but not alter existing elements — so that all existing websites will still be able to display in the future the same way old- fashioned table-based sites with font tags can still be displayed today.

  • articles

    What ever happened to writing articles huh? write some articles first please that way you can follow up and we don’t have to pay anything for perhaps miss information ;)

  • http://autisticcuckoo.net/ AutisticCuckoo

    I don’t really agree with that quote. Zillions of nested divs are not semantic. Defining the sections of a page with HTML5 is a good idea and much more semantic.

    What does zillions of nested divs and new element types have to do with redefining existing semantics? Yes, some of the proposed additions in HTML5 are good, I never denied that. But there are also changes for the worse.

    HTML5 adds “semantics” (i.e. new structural elements), and adds new accessibility features.

    I haven’t seen any features that improves accessibility, but I haven’t kept a close eye on development lately. What are they?

    There have been several attempts to remove important accessibility features, though. Some of them have been withdrawn due to massive community criticism, but it’s clear to me that the HTML5 WG do not care very much about accessibility.

    HTML doesn’t mark up “meaning”, it marks up presentational structure.

    That seems to be true for HTML5, but it’s not true for HTML2-HTML4. Yes, clueless authors abuse it that way, but it’s not how HTML is supposed to be used.

  • mhulse

    @AutisticCuckoo:

    Ack! I did not know your real name was Tommy Olson! I would have never questioned an AutisticCuckoo quote!

    Thanks to your helpful forum posts, I too prefer HTML 4.01 strict dtd. :)

    Cheers!
    M

  • http://keryx.se itpastorn

    Perhaps this debate could take a turn for the better if we dropped the 4 vz. 5 war. For a browser there is no such thing as HTML 4 or 5. There is only one HTML. For a browser, the doctype serves but one purpose, and that is to decide the rendering mode.

    The HTML 5 makes this even more clear, since it carefully explains how a browser should treat ambiguous markup. It also explains how to avoid such markup for authors. E.g. a browser must be able to handle badly nested elements, font tags and yes, even marquee. An author should avoid such abominations like the plague.

    Ergo: The HTML 5 spec does not in any way violate the principle of separation of concerns.

    As for accessibility. Ian H. and the core people associated with WHAT-WG do not agree on a few issues, like should the alt attribute be mandatory. I think it should, but I can see their point as well (that badly written alt attributes are indeed more confusing than dropping them, that in a figure element it is redundant, etc). Name calling rarely is an effective way of changing peoples mind, yet this is all to prevalent today.

    The same is true for ARIA. Clearly defining how it should integrate in HTML is not the same thing as being against it at all. E.g. if the HTML attribute says radio button and the ARIA role says checkbox, the browser will display a radio button to all sighted users, but speak a checkbox to blind users – according to the ARIA spec. That is not a good idea!

    Ian H. et al is not so much against accessibility, but they are passionately against ambiguous W3C specs.

  • http://autisticcuckoo.net/ AutisticCuckoo

    @mhulse: LOL! No-one is above questioning, least of all me.

  • Stevie D

    @AutisticCuckoo

    I haven’t seen any features that improves accessibility, but I haven’t kept a close eye on development lately. What are they?

    New sectioning elements such as nav, header, footer etc will allow assistive technologies to parse the page more easily and give users direct access to each section. eg, a screen reader could have a keyboard shortcut or toggle setting to bypass any nav element, and another shortcut to jump straight to the nav element. No more need for skip links, which are a bodge at best.

  • http://www.studio-gecko.com/ XLCowBoy

    *shrugs*

    There’s a lot of speculation and theory-tossing here, but let’s step away and look at the subject at hand for a moment:

    The realistic question is: when and how will Microsoft, with it’s majority browser share, support this? Once we have that answer, then we will know where HTML 5 is headed.

  • http://autisticcuckoo.net/ AutisticCuckoo

    @Stevie D: Yes, that could, eventually, make for improvements in accessibility. I’m not sure they’ll be great improvements, since screen readers already have the ability to skip, e.g., lists, so if your navigation is marked up as a list it can already be done.

    As for eliminating skip links, that’ll have to wait until ‘everyone’ has upgraded to an HTML5-aware screen reader. Considering the price tag of these things, that might take a while.

    Still, those marginal improvements do not offset the disadvantage of proposals such as making the alt attribute optional, removing the headers attribute, etc. At least not in my opinion.

  • http://www.cemerson.co.uk Stormrider

    You can already leave alt empty, and should do a lot of the time, so what is wrong with making it optional? That is just a question of syntax, the meaning is the same.

    You could say that you could tell the difference between someone who intentionally left it empty, and someone who just forgot it, but that is the fault of the author, not the language.

  • http://autisticcuckoo.net/ AutisticCuckoo

    You can already leave alt empty, and should do a lot of the time, so what is wrong with making it optional? That is just a question of syntax, the meaning is the same.

    The difference is that an explicit but empty text equivalent unequivocally says, ‘I declare that this image does not convey any relevant information’. Not everyone can perceive images, so every image should have an explicit text equivalent – which may be empty.

    The title element is required, too. Would you say it should be optional since it’s possible to write <title></title>?

  • http://www.cemerson.co.uk Stormrider

    Yes, if you don’t intend to put a title on a page, I don’t see how putting in helps?

    And I agree that an explicit but empty text equivalent tells something, but then you could say that for alt attributes left out. If the author has left it out for other reasons, then that is the authors fault, not HTML 5’s fault. You can’t say a language is bad just because it can be abused.

  • http://autisticcuckoo.net/ AutisticCuckoo

    An explicitly empty attribute signals ‘I know what I am doing’. An omitted attribute may just as well signal ‘I am clueless’ or ‘I am sloppy’. That’s why I think it should be required.

    What do you gain by omitting it? Unless you’re using a 14.4 kbps dial-up connection the few bytes won’t make any noticeable difference.

  • SpacePhoenix

    One big question for me would be will HTML5 work with AJAX? I’ve yet to learn AJAX yet but once I get a site built I would use AJAX (once I’ve learned it).

  • Arlen

    As usual, there’s a lot of fud, fire and smoke surrounding the topic. As a major participant in a recent forum thread on this, I’d like to chime in on three points.

    1) I don’t think it’s time yet for a book on HTML5. That’s not because the spec hasn’t been approved. Heavens, if that were the standard for publication we couldn’t write a book including CSS2.1 (which according to the W3C also has yet to be approved). Rather it’s not time yet because everything but the basic concepts and skeleton of HTML5 are still fluid. There are new elements being created all the time (hgroup for example) so such a book would be obsolete *before* it ever saw print. A website, yes, but the WHAT-WG has that pretty well taken care of at the moment. If the group stays on track, I’d say revisit this question in 12-18 months; it should be time to at least seriously talk about it, if not publish it, then.

    2) Is it time to write client websites in HTML5? That depends, both upon the client and upon the site’s audience. Some things introduced in HTML5 work for 95% or more of the audience today (last indications I saw said about 5% of the audience turned js off – Javascript is necessary only to help the IE rendering engine see some of the new elements so it can apply css to them – and about 60% of the audience uses IE, which means about 3% can’t see visual stylings on the new elements, give or take an error margin) so they might be useful. At one point I wondered if the javascript requirement could be bypassed with an htc file for Explorer, but I’ve satisfied myself since then that it can’t be done in any useful way. If the audience for the site has a higher than average percentage turning js off, that means it’s less useful, if they have a higher percentage than average with javascript turned on, it’s more useful. (It should be noted that if you can supply IE with another CSS file inside of noscript tags to style the site acceptably, then you’re covering that part of the audience. Of course, then your client has to buy into the idea that those users will see a different look than HTML5-capable users, a possible, but not always easy, sell.)

    Also it depends on your audience’s browser mix. The higher the level of IE use in your audience, the less useful HTML5 will be for you. IE8 doesn’t even give HTML5 much support. It seems odd to me they focused on including some of the APIs of HTML5 inside IE8, but ignored the “low-hanging fruit” of implementing even the simplest of the new elements, like header or footer. (I begin to wonder if there’s a hidden agenda in that; they won’t support XHTML properly, they won’t add support for the next version of HTML elements, either. Do I smell a “the future belongs to Silverlight” policy lurking somewhere?) I don’t know if it’s still the case, but over a year ago one of the prime engineers on IE strenuously objected to the fact that the HTML5 spec told them precisely what the user agent should do to recover from markup errors. Maybe that’s contributing to their foot-dragging.

    Another approach for client sites today is to take the bits and pieces that *will* work across browsers and start using them now. By using the HTML5 DOCTYPE An Event Apart, for example, has blended in the HTML5 concept that links may include what used to be called block elements in other specs something already allowed in most browsers but banned by all (X)HTML specs until HTML5. ((HTML5 revisited the content categories, mainly because the old “block/inline” dichotomy may work for presentation, but never worked cleanly for semantics. Doubt that? Try this thought, based on current specs: Block elements can contain inline or block elements. The paragraph element is a block element. But the paragraph element is the only block element that cannot contain another block element. Ptui.) Clarke’s approach of using divs with HTML5 tag names for classes as a way of starting to think in HTML5 is useful as well for the clients and sites that aren’t suited for more extensive adaptation.

    Bottom line on this point? If your site’s audience contains less IE than normal, and more js than normal, then you’re well positioned to think about using HTML5.

    3) Is it time to experiment with HTML5 in hobby sites or personal sites? Long past time, I think. HTML5’s approach marks a different way of thinking about building for the web (I’ve seen that first hand from experienced developers when I’ve tried to explain HTML5 to them) and even if you don’t use it directly, seeing web building from a different perspective can only improve your practice of your craft. Download a browser with advanced HTML5 support, head over the the whatwg.org HTML5 demos, and start playing around. When you get the hang of them, try some of the more interesting (to you) bits and pieces in your usual browser. See if there’s something there you can profitably use today.

    Oh, and Shelley? Canvas *is* HTML5. It was the first HTML5 element to pick up browser support. They’ve been working on HTML5 since 2004, after all; *some* bits of it were bound to trickle out over the years.

  • http://keryx.se itpastorn

    @AutisticCucko

    The headers attribute has not been removed. Yes it was discussed for quite a while before Ian included it in the spec, but now it is in.

  • Hamranhansenhansen

    I think the key to HTML 5 is that it is happening just as the Web matures from running on PC’s to running on mobiles and other devices, where it really belongs, in the same way that digital music belongs on an iPod or movies on a TV, not in a window on a massive PC workstation. The Web is much, much broader than PC’s.

    The HTML 5 spec is the document that all the IE-authoring Web developers out there will need as they transition from developing content for PC workstations to developing content for the World Wide Web. The stuff you make will change because there is no Microsoft influence at all in mobiles. They have been building a bigger, bigger, and bigger version of IE for the last 10 years and it is now huge and slow, with multiple incompatible browser engines. It requires much more RAM to run than any mobile has, and it needs a whole version of Windows, which also runs all the viruses and malware in the world. The pocket version of IE is based on IE 4 from 1998 and is a joke. It is clearly broken, cannot load “large” Web pages, and nobody uses it. WebKit has 98% of the mobile market by usage.

    At my studio, thanks to HTML 5, we stopped making HTML for Internet Explorer altogether. Rather than have our development split standards/IE as it has been in the past, we split it mobile/PC. For mobiles, we make an HTML 5 website that is very strict, very easy to author, unobtrusive JS and all that, very easy to maintain once it’s built also. Then a Flash developer clones that website as a single Flash 9 presentation that uses all the same media, and which we run at 100% width and height whenever the site sees “MSIE” in the user-agent string. The clone can be made so perfect that the HTML developer can’t tell the difference. And the Flash version runs pixel-perfect in IE 5.5 through 8 on Windows 98 through 7. It took about 10% of the time to support Flash 9 than it typically takes to support MSHTML. We’re not going back.

  • http://autisticcuckoo.net/ AutisticCuckoo

    Block elements can contain inline or block elements. The paragraph element is a block element. But the paragraph element is the only block element that cannot contain another block element.

    Really? What about h1, h2, h3, h4, h5, h6, address and pre?

    Technically, dl, ol, ul and table are also questionable, since they allow only specific element types that are not classified as block-level or inline. And then there’s hr, which is classified as block-level but doesn’t allow any content at all.

    The headers attribute has not been removed.

    It was, then it was put back in after a lot of protests. Who knows, it might be removed again. Anything can happen before HTML5 becomes a stable candidate recommendation.

  • http://keryx.se itpastorn

    For completeness sake, I’m going to reference Google i/o:

    http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html

    http://www.youtube.com/html5

    http://www.webmonkey.com/blog/Google_Throws_Its_Weight_Behind_HTML_5

    People may protest, but HTML 5 is happening.

  • JohnDeHope3

    Do not go where the path may lead, go instead where there is no path and leave a trail.

    Ralph Waldo Emerson

  • Arlen

    “Really? What about h1, h2, h3, h4, h5, h6, address and pre?”

    Good catch. Multiple exceptions make my point even clearer. The new content divisions in HTML5 make a lot more sense to me. The names of the categories take a little getting used to, I admit, but the categories themselves make more sense.

  • Oli

    In most cases you can change a well-written HTML4 page to HTML5 by changing the doctype alone—there’s no requirement to use new elements. As Andy mentioned, you can learn about/prepare for HTML5 by adopting it’s new semantic element names as class/id names, in any flavour of (X)HTML. Here’s a class/id names cheatsheet based on relevant articles from Andy and Jon Tan:
    http://boblet.tumblr.com/post/60552152/html5

    Some benefits of using the above approach with an HTML5 doctype now might be:
    * far more detailed and informative spec, with better code examples
    * additional validation options; Validator.nu, the W3 HTML5 validator and HTML4 Strict validator (with doctype override)
    * very easy migration path to HTML5 with new elements (assuming you have regex)
    * it’s basically a codified way of doing what we’re probably doing in HTML4 strict anyway
    HTH

  • http://www.calcResult.co.uk omnicity

    @SpacePhoenix and others:

    There are at least two points in time when a good reference is needed: at the beginning we all need something to tell us how HTML5 is supposed to work, and there is probably enough material for work to start on that kind of book.
    The next phase is a reference that details the pitfalls and work-arounds of real-life use, and that is clearly a very long way off.
    The other thing to bear in mind, is that unlike with the introduction of XHTML, there has been commitment from all relevant parties, and since this is an evolution of HTML4, there is no reason to think that HTML5 will not get there in the end, the only question is how long HTML4 will remain current.

  • P Ziecina

    I remember similar negative arguments concerning css and xhtml back in the late 90’s (not to mention xml), and as time has proven those who didn’t learn it were ‘left behind’, (or tried to play catch-up).

    I think a book on html5 (and css3), would be one that I would certainly buy, as learning these now would mean that I am at least familiar with the language (even if not conversant).

    P. Ziecina

  • Rick Mason

    I think a smaller book (similar to “Everything You Know About CSS Is Wrong!”) focusing on the basic philosophy of HTML 5, information about topics such as microformats and how they can be used, and code samples that will work with current/near future browsers, would be a good step to take.

    To attempt a definitive book on HTML 5 at this point in time would not work, for reasons that others have explained effectively. An introduction to the ideas behind HTML 5, and ways it can be applied today (and perhaps a taste of what is likely to come) would be something I would order as soon as it was available.

    In addition, the announcement this past week for Google Wave highlights the fact that HTML 5 is going to be a part of cutting-edge web development, and publishing a good introduction to the topic will benefit both SitePoint as a publisher and readers looking for good information.

  • Rick Mason

    I think a smaller book (similar to “Everything You Know About CSS Is Wrong!”) focusing on the basic philosophy of HTML 5, information about topics such as microformats and how they can be used, and code samples that will work with current/near future browsers, would be a good step to take.

    To attempt a definitive book on HTML 5 at this point in time would not work, for reasons that others have explained effectively. An introduction to the ideas behind HTML 5, and ways it can be applied today (and perhaps a taste of what is likely to come) would be something I would order as soon as it was available.

    In addition, the announcement this past week for Google Wave highlights the fact that HTML 5 is going to be a part of cutting-edge web development, and publishing a good introduction to the topic will benefit both SitePoint as a publisher and readers looking for good information.

  • Bob42

    All of us in the computer biz, especially web development, know that products, languages, IDEs and the like come at us at a fast and furious pace. I was reading recently an article talking about the most marketable technologies such as .NET, AJAX, PHP and Ruby on Rails. The author poo-pooed HTML as not worth learning since the IDEs create it automatically. Personnally I have never had an IDE where I did not have to, at some point, go in tweak the HTML. Hopefully HTML 5 will become more popular and a technology worthy of adding to the growing portfolio.

  • BobMarche

    Thanks for the useful info. It’s so interesting