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

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

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

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