Slashdot Mirror

← Back to Stories (view on slashdot.org)

W3C Publishes First Public Working Draft of HTML 5

Posted by Zonk on from the new-coat-of-shellack dept.

Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."

21 of 310 comments (clear)

  1. Re:Not again by nacturation · · Score: 4, Insightful

    Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

    I can't be the only one who thinks the W3C is annoying as hell... So you're advocating holding back progress because a lot of sites authors don't bother to make their HTML compliant? With the new APIs, this hardly qualifies as "no reason at all".
    --
    Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
  2. The treadmill.... by gandhi_2 · · Score: 5, Insightful
    I have this theory...some of you might too....

    Large for-profit software giants must constantly make product to stay in business, pay programmers, and make profit...even if there's nothing REALLY to fix. Just make upgrades...sell new versions.

    Consumers and businesses are constantly put on an upgrade-treadmill as older products are purposely torpedoed...even when they worked fine and did the job they needed to do.

    now replace "for-profit software giants" with "design-by-committee standards organization" and "stay in business, pay programmers, and make profit" with "stay in charge and not have to get real jobs".

    --
    THL phish sticks
    1. Re:The treadmill.... by keytoe · · Score: 3, Insightful

      It's not a treadmill if you actually cover ground.

      --

      Culture is more than commerce

    2. Re:The treadmill.... by hixie · · Score: 4, Informative

      HTML5 is the furthest thing from committee-driven development in the W3C. Basically, I'm a dictator and every piece of feedback goes through me. (This is a point of contention with a lot of people who disagree with my approach, which has basically been to focus on use cases, pragmatic arguments, and research, and to eschew "expert opinions" as the sole guide to what the spec should say.)

      Also, spec writers aren't in charge of anything. This is actually a common fallacy, which leads to people writing specs without paying attention to their users and implementers -- just look at most specs coming out of the W3C. No, spec writers are in fact at the very bottom of the food chain. We can only specify things which the implementers want to implement, otherwise they'll ignore us, and we are only able to control what users do in so far as we tell them to do things that they want to do, otherwise they'll ignore us too. Just look at browser vendors ignoring specs they disagree with. Just look at how many pages have some sort of syntax error (over 93% according to a study of several billion documents I did last year).

      With HTML5 we're specifically trying to avoid torpedoing what implementers and users are doing today. A huge part of the effort is to make the spec relevant, specify what users are doing, specify things that other specs left vague, add features where users are working around holes in the spec, etc.

      As to whether my job is a "real job" or not... I can't speak to that. It's a lot of work, at least. :-)

  3. Still sloppy by nagora · · Score: 4, Insightful

    "The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax."

    So we have

    <!DOCTYPE html><html>

    At the start of every HTML document served with an text/html mime type? That's real rational. Let's get this tidied up once and for all and start html documents with

    <HTML version='xxxx'>

    Is that such a difficult concept?

    TWW

    --
    "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
    1. Re:Still sloppy by hixie · · Score: 5, Interesting

      Actually originally we wanted to remove the DOCTYPE altogether, and since the start tag is optional that would have made the boilerplate "" (the empty string), or "" if you want to include the start tag. Unfortunately, in non-HTML5 browsers, if there's no DOCTYPE, you'll get quirks mode, which we wanted to avoid. That's why we went with the shortest string we could find that triggered standards mode, namely "".

      I agree that it's not ideal, but I couldn't really see a way around it.

    2. Re:Still sloppy by hixie · · Score: 4, Interesting

      Versioning is basically meaningless on the Web. Browser vendors (other than Microsoft, at least) have repeatedly said that they don't want to have multiple code paths for features, which means that they want each version of HTML to work the same as each previous version. Same for CSS, same for the DOM APIs.

      If every version of HTML is going to be identical from the browser's point of view, why bother including any versioning information in there at all?

      As far as validators go: the point of validators is to report errors. When HTML6 comes out, if there are things in HTML6 that are errors that aren't errors in HTML5, that presumably means we found bugs in the HTML5 spec, and so it is more helpful to authors if we report them than if we don't. Therefore validators should always validate against the latest spec (unless manually configured otherwise, of course), and the validators don't need a version number in the format.

      Having version numbers in formats makes people do stupid things, like make behaviour depend on the version flag. Not having a version number in the format makes people notice that kind of mistake more (since then explicit flags have to be invented to make the mistake, instead of just using the version number in the format).

  4. Someone hire this guy! by nacturation · · Score: 4, Insightful

    Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future. I think they should hire you for your keen insight.

    How long that takes, noone really knows. Another stunning peek into the future.

    More importantly, how easy will this be to use and how useful will the semantic bindings be? It'll be as easy to use as a snowboard and as useful as a hammer.

    Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me. A three second scan of the linked article yields:

    "Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings for DOM Specifications specification, as this specification uses that specification's terminology. [EBFD]"

    Their language indicates that ECMAScript isn't a requirement. Essentially, "if you use it, you must implement it in a certain way". They don't mention requirements for implementations that don't use ECMAScript.
    --
    Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
  5. Re:Not again by MightyYar · · Score: 3, Interesting

    I don't really keep up with the politics, but I think that HTML 5 is the W3C caving to exactly the sentiment that you are expressing. People weren't happy with the W3C and their pushing of standards that people weren't following (or at least not uniformly). They responded to outside pressure and HTML5 was born. So cut them some slack - they have seen the light and are attempting to be accommodating.

    Anyway, the situation that you describe won't really be the case in a few years. Safari, Opera, Mozilla, and IE are all fairly standards-compliant these days. When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.

    Getting your site pixel-perfect on all of them is not and never will be trivial, because HTML is not supposed to do that. Certain sites do demand that, and for those sites we have things like Flash.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  6. Re:Of course, it won't matter. by cromar · · Score: 3, Interesting

    Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA). Sounds good to me... the spec can be trimmed if no one is going to implement the full thing (so at least there will be a smaller spec to refer to instead of a complete spec that no one uses). Another good effect is that if MS drags their feet, they will look even more stupid :)

  7. Re:Of course, it won't matter. by AKAImBatman · · Score: 3, Informative

    Of course, it won't matter. At least until some major browsers support it.

    Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.

    And it really won't matter until IE supports it.

    One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)

    The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.

    Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.
    --
    Javascript + Nintendo DSi = DSiCade
  8. Still no value on select tags? by dumbo11 · · Score: 4, Insightful

    If anyone involved in the spec reads this, for the love of god PLEASE include a 'value' on the "select" tag.

    'as an alternative to flagging an option tag with selected="selected", a select tag may have a 'value' attribute. A renderer should select the first child option with a matching value attribute.'

    Please, my servers are getting fed up with rendering an entire country list just to flag one with selected="selected".

  9. HTML5 is the wrong path by Dracos · · Score: 5, Insightful

    To (hopefully) anyone who understands and advocates XHTML and CSS, HTML5 is a tragic mistake. I can't believe TBL is supporting this garbage. It brings back some (but not all: <i> and <b>, but not <u>) presentational tags and gives them worthless definitions. It's full of concessions to lazy/unskilled developers. It makes XML compliance optional. It's full of niche tags which are so narrowly focused (aside, dialog) that they're almost certainly doomed to lousy browser support. It doesn't address the current inadequacies of forms. It has tons of design flaws and inconsistencies.

    Until there are consequences for not following the standards, it doesn't matter what the W3C does: People will continue to make pages and sites that are "just good enough", and browsers will continue to render what they want how they want. In the past, now, and for the foreseeable future, there's no incentive for anyone to do things right other than ego.

    I don't get it. The people designing this stuff are supposed to be experts in the field, yet they seem hell bent on force feeding everyone this drivel. If their true goal is the hurl the web into chaos, then they will certainly succeed.

    1. Re:HTML5 is the wrong path by Xest · · Score: 4, Interesting

      Indeed.

      HTML 5 is probably the worst thing that can happen to the web right now, slowly but surely XHTML compliance was bringing together browsers and sites, you only have to look at the magnificent jump in compatibility of sites from IE6 and Firefox 1 to IE7 and Firefox 2, whilst far from ideal still, developing Standards compliant code for the latest generation of browsers is much less of a headache than it's ever been.

      HTML 5 increases ambiguity, it's a language seemingly designed for the MySpace generation - people who just want to hack together quick and dirty sites without any care or thought for scalability and accessibility. The simplification of XHTML over HTML whereby ambiguity is decreased by fixed rules, and less presentation tags was absolutely fantastic for developing sites that work on a variety of user agents as much more is left for the user agent to figure out so that small handheld devices could finally display compliant sites in a way that best fit the screen. Accessibility software such as screen readers have a much easier time as they could largely ignore CSS and stick to reading out the actual content without worry that some random presentation tags with a non-strict syntax was going to bugger up the parsing.

      The most important concept with XHTML was separation of presentation from content coupled with a strict syntax and HTML 5 goes against these two extremely important points for ensuring we have a clean, standardised, accessible web. It's also quite a problem that HTML 5 says "Oh you don't have to use this or that, you can do it was you want", a standard needs to make up it's fucking mind not sit on the fence because otherwise it's not much of a standard as you get people doing things in many different ways, some of which are undoubtedly going to break in some user agent or another.

      Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further. Instead of dumbing down the underlying language and breaking the web as a result, we should be producing better tools for working with the existing language keeping the web clean without leaving it difficult to publish to.

      Do we really want to prolong the old situation of sites that only work or look differently with some browsers and that are inaccesible to people with special accessibility requirements? Not to mention that aren't scalable as content and presentation get mangled into one and hence really aren't maintainable either?

    2. Re:HTML5 is the wrong path by hankwang · · Score: 4, Insightful

      Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further.

      As far as I understand, HTML 5 specifies exactly how a user agent should deal with formally incorrect code. I have never understood some people's obsession with XHTML, where a compliant browser is supposed to display an error message. With Opera, I encounter "XHTML" pages every now and then that do not display at all because they were dynamically generated from a database and there is a single illegal character in there or a forgotten close tag in a string coming from a database. How is that supposed to help anyone that every scripted page needs to be tested against every possible input condition? It could have been made optional in the user-agent to display a warning for web developers, but no, the spec requires that the browser justs bails out.

      And xhtml also sucks for hand-coded pages since it is full of redundant closing tags, for things like <br>, <tr>, <td>, <li, and so on. It's only more typing and more obfuscating syntactic sugar. There are millions of people who create web content, and only a handful browsers. To me it is obvious that it is a waste of manpower to require of millions of people to learn the exact strict xhtml rules rather than make the browsers more flexible with non-conformant input, in a well-defined cross-browser portable manner. HTML 5 will add new useful features. XHTML adds nothing that wasn't already possible in HTML 4.01-strict (the version without font/frameset/bgcolor/etc. stuff).

      [with xhtml] small handheld devices could finally display compliant sites in a way that best fit the screen.

      I think you are talking about spacer GIFs and table markup. As far as I know, you can still abuse tables for page layout in XHTML. Moreover, to make a page that is really portable between 1024 pixel monitors and devices with a 150 pixel-wide screen requires much more than just xhtml/css; both the CSS and the page structure need to be carefully designed to be portable, in a way that is not enforced by the xhtml spec.

      --
      Avantslash: low-bandwidth mobile slashdot.
    3. Re:HTML5 is the wrong path by hixie · · Score: 3, Informative

      Well, we need tables to be able to represent tabular data. How else would you, for example, represent an invoice? Or a timetable? There are certain things for which tables make sense.

      Naturally, semantic tables should never be used for layout purposes, and that has never been allowed by any of the HTML specs.

  10. No more style attribute?!?!?! by TrebleJunkie · · Score: 3, Interesting

    No more style attributes on any element.

    *blink*

    Idiocy. Abso-fucking-lute idiocy.

    This by itself nearly renders in-browser dhtml applications (ajax or no) non-complaint and broken.

    Somebody really needs to wrench the HTML spec out of the hands of the W3C and place it into the hands of somebody who spends a little time on other side of the ivory towers.

    --

    Ed R.Zahurak

    You know, oblivion keeps looking better every day.

  11. Re:Not again by hixie · · Score: 5, Informative

    Most of HTML5 was actually done outside of the W3C.

    However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

    I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

    http://ln.hixie.ch/
    http://www.webstandards.org/action/acid3

    So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

    http://blog.whatwg.org/w3c-restarts-html-effort

  12. Fix : text, sizing, rendering by victim · · Score: 3, Insightful
    Having used a bit, I say fix it now!
    1. They have still left text out of the <canvas> tag. This is near insanity. The web is littered with people working around this to get labels onto graphs, current solutions are:
      • overlay a transparent div and absolute position some text elements. Works, but no rotating and is fiddly to get the sizing correct.
      • Take a truetype font, render an image of all the glyphs into a grid and know the coordinates of each ones bounding box then paste them in ransom note style to make your text. Most people are used to subpixel rendering and this won't do it. Looks a little bad for small text, ok for large. Big downloads.
      • Be a plotter. Use the Hershey fonts from NIST back in the good old days of pen plotters. (google://hershey&canvas&element). Small, fast, only one font face, antialiasing looks a little blurrier than modern typography at small sizes.

      Hey working group! Use CSS to pick a font. Give a method to get the various metrics of a layed out string and one to draw it. That will cover most uses.

    2. Lack of dynamic resizing: The width and height is specified in the HTML. It would be nice for this to be dynamic so you could use a canvas for DIV backgrounds, like the gradients behind the slashdot article titles. (Yes, obviously those gradients take fewer bytes as images, but you could do something other than repeat a tiny graphic. Use your imagination.)
    3. Address rendering: The canvas uses coordinate transformations to nicely separate the display coordinates from the drawing coordinates. This is good, but if the browser antialiases then you get radically different results for lines that fall on the pixels and ones that fall in the cracks. There should be language in the spec that leads implementors to all make the same decisions about antialiasing so that authors don't have to try to guess which way a client is going to render.
  13. Re:Not again by mhall119 · · Score: 4, Informative

    Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one. I read the spec, and most of the additions are to incorporate what we've all been doing, with CSS/Javascript hacks and plugins, into the spec itself.
    • Menu tag: An actual menu element provided by the render engine, no more CSS/Javascript menu libraries
    • Combo-box input: An actual combo-box form input field, no more CSS/Javascript hacks
    • Datetime input: No more javascript libraries to popup a date chooser, it comes with the browser
    • Number input: No more javascript intervention to stop you from typing "bob" into a field expecting a number.
    • Email input: Not only can it validate email format, but it could let you pull from your email client's addressbook
    • URL input: Again, not only validation, but could let you pull from your browser's favorites, history, etc
    • Input validation: No more onSubmit javascript checks to make sure your required fields have data in them.
    • All Inputs have min/max and pattern (presumably regex) restraints

    (BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)

    • Datagrid: An actual data grid widget, no more hacking Tables to provide the same functionality
    • Audio/Video tags: Just like <img/> tags, only for other media, what a concept!
    --
    http://www.mhall119.com
  14. Re:Of course, it won't matter. by SQL+Error · · Score: 3, Insightful

    The alternative to trial and error when creating a spec is just error.