As a client- and server-side developer I'm extremely excited about HTML5. For the first time in a decade, browsers are getting new capabilities! HTML 5 is much more than just new tags - we're talking offline support, concurrency with web workers, canvas, geolocation, native audio and video, WebSockets, a supported method of making cross-domain API calls...
HTML 5 is clearly aiming to bring the open web platform up to par with desktop APIs. I expect many desktop applications to be developed using HTML5+CSS+JavaScript within just a few years.
And even if that doesn't spike your interest, there's the critically important role the HTML 5 spec pays in standardising what we already have. It's ridiculous that XMLHttpRequest, one of the most useful modern browser APIs, has no spec - every browser implements it by reverse engineering the others, who in turn reverse engineered IE (which is closed source, so who knows if they got it right?). HTML5 fixes that. It also specifies things like innerHTML, ContentEditable, the execution order for script files, all that DOM level 0 stuff that never made it in to an official spec.
Finally, HTML5 specifies a formal error model for HTML for the first time. This means it will actually be possible to implement a new browser from scratch without having to spend years reverse engineering the behaviour of IE and friends when faced with invalid markup.
I'm amazed to see so many web developers unexcited by HTML 5. This is the first time our core platform has seen any serious evolution since HTML4.01 was published in 1999!
As for browser support, it's happening right now. If you develop for the iPhone / mobile WebKit stuff most of the above features are sitting there waiting for you to use them. Try this page in your iPhone for example:
Even IE is catching up - IE8 supported a bunch of HTML5 concepts (key/value based storage, cross document messaging, hashchange event and more) and IE9 is set to support even more.
HTML 5 is the most exciting thing to happen to web development in a very long time.
None of these things require HTML 5, and all of the worthwhile things had workable implementations before HTML 5.
Formal specifications for things that had de facto cross-browser support for multiple browser generations are nice, but not amazing.
"This is the first time our core platform has seen any serious evolution since HTML4.01 was published in 1999!"
And that's just simply untrue, but oh, well.
"I'm amazed to see so many web developers unexcited by HTML 5. This is the first time our core platform has seen any serious evolution since HTML4.01 was published in 1999!"
And I'm boggled to see such giddy fanboyism modded up so high.
Can you list _worthwhile things had workable implementations before HTML 5_ and the stuff they implemented before HTML5?
<canvas>? <video>? local storage?
With Canvas, you might have a point, though it makes a poor justification for the rest of HTML 5. I've yet to need Canvas for anything, though. Video is silly to even ask about. Google Gears rather predated HTML 5 local storage.
Now, give me something I couldn't do before with nearly-universal plugins.
Front End developer and graphic designer (xHTML/CSS/Design)
HTML5 makes me cry inside, part of me died when HTML5 gained browser support. To me, HTML5 is all about GIT'R'DONE; it's an evolution, an odd growth on the body of HTML4, rather than setting a newer, better foundation. :(
The only plausible alternative that anyone ever set forward is complete stagnation.... I’m hard pressed to call that preferable, especially if we’re talking about “foundations”. Be sure to notice that browsers still haven’t finished implementing HTML 4 and CSS 2, more than a decade after their specification. Also notice that when you say you write "XHTML", your code is almost certainly not being treated as XML by browsers.
Did you ever actually try running a site using proper XHTML? I ran my blog like that (serving the correct content type to non-IE browsers) for a few years and found it to be a ton of hassle for absolutely no benefit.
I'm excited... but it's not enough. What we should really have is a standardized low-level byte code interpreter, allowing a variety of languages and great performance. Basically what Java promised but didn't really deliver.
Programmer here. Canvas tag excites me because for years the desktop programmer in me has wanted simple pixel addressing so that I could implement my own full-featured input/form controls, such as a grid control.
Almost all of the HTML features in HTML5 are boring and barely useful. The rest, basically, <video> and <audio> are crippled.
The useful parts of HTML5 are the new JavaScript APIs (which arguably don't really belong). Unfortunately many important ones are missing, and of the ones which are present many are incomplete or broken.
Mostly a programmer, and not really. To be honest I would be much happier with better CSS capabilities (better syntax, variables) than video tags and whatnot. I'm not against it obviously, but probably won't be rushing out to learn all the new features.
Sure, that's exciting. But imagine designers not having to test in every browser for rendering bugs. Imagine testing in one browser and being sure it was going to work for everybody, just as fast, and look just as good. I think it'd be a huge, huge step forward. After that, HTML5 all the way!
No, I don't mean that. If you want to have a design work across different browsers, one of the first things you have to do is find a common baseline. This is where things like reset.css come in, which overrides many predefined styles.
I'll try re-wording my post:
I suspect <aside> and <article> will have the same styling possibilities as any other block level element for a particular version of CSS.
Programmer. I think it's great that we're extending the semantics of what we have now, but we're going in the wrong direction. I agree really strongly with John Allsopp that we shouldn't be extending the number of elements available - we should be creating a framework for extensible semantics (using attributes or the like):
I have to disagree here. It is the common document elements that represent the greatest improvement, in that they will provide accessibility cues that classed divs never can. It's all well and good for us to gripe (or crow) about what can and cannot be done with the element collection already in hand (in HTML 4.01 and in XHTML), but when it comes right down to it, we have no way of semantically differentiating the various parts of a document. Attributes within HTML or the implied extensibility of XHTML are not really solutions here, since even with namespaces and custom DTDs there is no way to indicate to a user agent the ACTUAL significance of any given class of span or div within the document context. A convention is NOT a standard.
HTML 5 (and its X counterpart) should mark an enormous shift in the usability and discoverability of web pages for users of assistive technologies, for indexers and cataloggers, and so forth. <canvas> doesn't turn me on nearly as much as <header>, <section>, <aside> and <footer> do.
Programmer here. HTML 5 is dominated by scripting, which I think we will regret. Marked up data is easily manipulated and repurposed, but arbitrary code has very few uses other than executing it, which is mostly why script-heavy documents tend to be trainwrecks in accessibility and search.
And I desperately hope there's going to be a more usable and declarative schema for HTML 5 than "anything is valid if you carry out this long parsing procedure and it says it's valid".
I haven't seen anything exciting about it. It doesn't let me do anything significant that I couldn't with existing technology. It's just the New Style.
When I first started thinking about it and studying it, I found it downright exciting. So much potential. But as with most thing the devil is in the details. And we just don't have enough details yet. So much could change between now and when it actually gets implemented that it may turn out to be a big disappointment.
Developer here - it definitely excites me. But I'd much rather see full, compatible CSS2.1 support first - and then CSS3!
I just can't help but think that this will fragment things a little bit further. I hope it won't, but I don't know whether we can expect all browsers to implement HTML5 at the same time.
I'm excited about many of the new features. However, the move away from XML syntax is a disastrous and utterly pointless decision.
Also, I wish they had taken the opportunity to rid the world of the massive failure that is CSS and replace it with a layout system that makes simple things simple.
1) Nobody moved away from XML syntax. You can still use it if you want.
2) In most cases XML syntax is pointelss.
3) HTML5 has nothing to do with CSS, and CSS is doing fine, far from being "massive failure".
It doesn't matter whether I can use XML. What matters is that some people will use a new syntax and all the integration hassles and incompatibilities will start once again.
Why is it a good idea to invent yet another syntax that is almost the same but not quite compatible?
Looking at the ridiculous guru culture that has formed around minor obscure CSS features is very telling. When that happens to a technology I call it a massive failure.
"HTML 5 is being written in two syntaxes: html and XML. Because SGML has never been deployed in browsers and many html authoring tools, HTML 5 defines a new serialization called html, which looks a lot like the previous known SGML."
I still have to use javascript as my programming language. I know there are cross-compilers to javascript, but it is really disappointing that we sorta standardized on a language instead of a bytecode.
IMHO, a single, simple, and flexible language has greatly helped the web become ubiquitous. I think that javascript has been a key ingredient to the web's growth and it might not have been the same if a more "powerful" or "standard" language/jvm was shoehorned in.
Although I love the idea of prototype-based languages (NewtonScript was fun), it is a language and not a standard bytecode. We spent a lot of time learning to optimize it and we are stuck with it. Cross compilers are a poor substitute for a standard vm and bytecode.
Why not, it is a standard and a "bytecode" (Javascript sources being the bytes). Not a very efficient bytecode maybe, but still. You could write a scheme interpreter in JavaScript and have it execute your scheme programs in the browser.
Because it a kludge and not very efficient. I just can't believe the huge step backwards we take when we go to do "web programming". I guess I'm just wishing the web browser had evolved into an open cross platform thin client that is not dependent on one language.
Nope. It just bloats what we already have in xHTML 1.1. Sure, I can throw a header or section tag around a block, but I still have to use divs. It's just another level I need to indent at this point in time.
Sorry, which new features do you imagine available in XHTML 1.1 that aren't there in HTML 4.01?
Let me help you count: Zero.
HTML5 is very little about e.g. the HEADER element, and much more about the underlying support for other features, such as geolocation, native sound and video, crossdomain XMLHTTPRequest, offline support and (yes,) much more.
xHTML encourages well written, consistently formatted, code which is probably its most important feature.
Many of the HTML5 features you mentioned I don't see as being features that belong within a document structure language. Geolocation and Crossdomain XMLHTTPRequest are browser issues they have nothing to do with a document and don't belong in a spec for a document definition.
Native sound/video and offline support, of course, I agree with. But, if your application doesn't have the need for either of these features - what does HTML5 offer?
I was excited about standards on the audio and video formats. Since that has been cancelled HTML5 has no advantages over my current love XHTML. Both programmer and designer but both are just hobbies and my sites are mostly static (and I hate Javascript).
It doesn't excite me in the least because, since I can't afford to alienate big chunks of my audience, it might have enough penetration to use in, oh, 3-5 years? Meh.
While it might not be ready for general-audience web projects, I'm already using HTML5 and CSS3 features (including app cache and database storage) for some upcoming Android- and iPhone-specific mobile sites, and for a product that embeds WebKit in a non-browser application. Many of the features are also useful for building Flex/AIR/Silverlight-style "rich" apps, for which you could distribute Prism or another site-specific browser.
My gut feeling is that the mobile arena might be where html5 takes off first, with the number of webkit-based browsers out there now (iphone, android).
How does that affect you? Your HTML markup will work in HTML5, too. In any case, I keep reading no one will use it for years yet most of the leading developers and designers I know are using it today. And I'm joining them since all my markup is now HTML5 as of six months ago.
When you say that your markup is HTML5, do you just mean that you changed the doctype at the top (That's trivial, and its only real effect is saving a few bytes, though I suppose it's a nice symbolic gesture), or that you are now using all of the new semantic elements like <article> and <section> and <footer>, using <video> instead of plugin-based video, including features like drag-and-drop, or offline use of data-heavy apps, &c. &c.?
Corporate users would still need their administrators to install the plugin. But Chrome Frame could let change-fearing companies keep their users on IE6 (no retraining users or retesting existing sites), and use the Chrome engine only for sites that opt in to it.
I think part of the problem is MS encouraged people to write a bunch of ie6 specific sites. Thus, since ie doesn't AFAIK do side-by-side installs, the need to stay on ie6 for line of business apps.
Probably. On one hand, People Still Use IE6. And the people who still use IE6 aren't people who install things like Google Chrome Frame, or the latest updates from Microsoft (obviously). So for the time being, more features, along with cleaner syntax and the rest, means more work for web developers who want to use those features and whose audiences aren't particularly ahead of the curve.
On the other hand, those developers whose audiences are ahead of the curve, or who don't mind the blasphemous "Please update your browser. Here are some good ones:" link, will push the industry forward until the number of people still using IE6, or FF1.5, or Mosaic or whatever, approaches zero. It will happen because people will get annoyed, or viruses, or new computers running new operating systems and browsers. In that way html5 is the best thing that could happen to the web. A backwards-incompatible version will (hopefully) throw the few stragglers, who spend money on the web but still don't need css2, into the 21st century.
My grandmother was, until very recently, using MacOS 9 with IE4. She did not care that her homepage (apple.com, as it had been since she bought the computer) was impossible to read. People still using IE6 and even IE7 in five years will not be the kind of person who spends a lot of time or money online.
HTML 5 is clearly aiming to bring the open web platform up to par with desktop APIs. I expect many desktop applications to be developed using HTML5+CSS+JavaScript within just a few years.
And even if that doesn't spike your interest, there's the critically important role the HTML 5 spec pays in standardising what we already have. It's ridiculous that XMLHttpRequest, one of the most useful modern browser APIs, has no spec - every browser implements it by reverse engineering the others, who in turn reverse engineered IE (which is closed source, so who knows if they got it right?). HTML5 fixes that. It also specifies things like innerHTML, ContentEditable, the execution order for script files, all that DOM level 0 stuff that never made it in to an official spec.
Finally, HTML5 specifies a formal error model for HTML for the first time. This means it will actually be possible to implement a new browser from scratch without having to spend years reverse engineering the behaviour of IE and friends when faced with invalid markup.
I'm amazed to see so many web developers unexcited by HTML 5. This is the first time our core platform has seen any serious evolution since HTML4.01 was published in 1999!
As for browser support, it's happening right now. If you develop for the iPhone / mobile WebKit stuff most of the above features are sitting there waiting for you to use them. Try this page in your iPhone for example:
http://simonwillison.net/static/2009/navigator.geolocation.h...
Even IE is catching up - IE8 supported a bunch of HTML5 concepts (key/value based storage, cross document messaging, hashchange event and more) and IE9 is set to support even more.
HTML 5 is the most exciting thing to happen to web development in a very long time.