Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

W3C Publishes First Public Working Draft of HTML 5 310

Posted by Zonk 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."
This discussion has been archived. No new comments can be posted.

W3C Publishes First Public Working Draft of HTML 5 More

W3C Publishes First Public Working Draft of HTML 5

Comments Filter:
  • Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
    How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

    Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.

    • Someone hire this guy! (Score:5, Insightful)

      by nacturation ( 646836 ) <nacturation@gmAUDENail.com minus poet> on Tuesday January 22, 2008 @01:40PM (#22140890) Journal

      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.
       

    • How long that takes, noone really knows.
      About a month less than it will take for them to roll out HTML 6, at a guess...

    • Re: (Score:2)

      by Tacvek ( 948259 )

      Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
      How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

      Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.

      No, a user agent need not support scripting at all. If it does support an ECMAScript-based scripting language then it would likely be using the third edition or later, as the specification includes an exception system, and try catch blocks were not introduced until the third edition. However, that is no guarantee that that version will be used, as older versions with support for exception added would work as well.

  • The treadmill.... (Score:5, Insightful)

    by gandhi_2 ( 1108023 ) on Tuesday January 22, 2008 @01:34PM (#22140786) Homepage
    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".

    • Re:The treadmill.... (Score:4, Insightful)

      by keytoe ( 91531 ) on Tuesday January 22, 2008 @01:43PM (#22140968) Homepage
      It's not a treadmill if you actually cover ground.

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

        Not necessarily. To extend your analogy, I can still cover 2-3 feet on a treadmill while making it look like I'm running. That's what we're dealing with here.

      • Re: (Score:3, Funny)

        by STrinity ( 723872 )
        But what if W3C is an airplane and you put it on the treadmill -- does it stay still or take off?

    • Re: (Score:2)

      by cromar ( 1103585 )
      Yeah. It's not like the W3C has contributed anything to the internet at all. Sheesh. Who do they think they are?
    • Upgrade treadmill my ass... a lot of the changes in HTML 5 are very welcome, and I wish they were implemented yesterday. This is not Microsoft shoving Vista down your throat.
    • I would agree with you... if requirements never changed.

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

      Right. Because the current standards are so flawless and slopping over with intuitiveness that they can't be improved upon, and the needs of developers, content providers, and end users never ever change. If there's anything to love about the web game, it's how it's reliable and rock solid and fantastically

    • Re:The treadmill.... (Score:5, Informative)

      by hixie ( 116369 ) <ian@hixie.ch> on Tuesday January 22, 2008 @03:50PM (#22143392) Homepage
      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. :-)
    • HTML4 was released in 1997!!! CSS2 (the one STILL not supported) in 1998!!! The web has stood still on ancient tech because of 1 big company a REALLY long time. It's time to push HTML5 (XHTML5?) CSS3 & other new things and push those who don't keep up into the cold.

  • First thoughts (Score:3, Interesting)

    by apathy maybe ( 922212 ) on Tuesday January 22, 2008 @01:37PM (#22140828) Homepage Journal
    Still no client side include (no, object doesn't cut it...).
    People are talking about browser support, it seems to be written in such a way as they should already be able to support it if they support either HTML 4 or XHTML.
    It removes lots of sylistic tags, CSS way to go.

    New section tag is good.

    Overall, looks interesting, cleaning up HTML a bit more, forcing it to be more of a structure rather then presentation language.

    Anyway, I'll start using it, when and if, it becomes useful for my work. Otherwise, XHTML and HTML 4 are it.

    • Re: (Score:2)

      by onion2k ( 203094 )
      I can see advantages for most things they're proposing ... except for dropping the target attribute in anchor tags. I don't get that one. That's really useful for making external links open in new windows/tabs. Unless there's an alternative I've missed I think that could be a big mistake.

      • Re: (Score:2)

        by aftk2 ( 556992 )
        I would imagine they would simply advocate JavaScript for this sort of thing (not that I agree, necessarily). I could also see CSS to some degree controlling this; it's not necessarily presentational, but I could see different stylesheets making use of different target attributes for links.
      • it's because the end-user is supposed to decide whether or not to open a link in a new window/tab, not the site.

    • Re: (Score:2)

      by cromar ( 1103585 )
      What do you want to do with client side include?? With all the security flaws around these days, I'm happy my browser isn't going to be executing external code. Or do you mean something else by that phrase?

  • Read the diff (Score:2, Insightful)

    by DeltaSigma ( 583342 )
    And I must say, I like where this is going so far. It feels like a very natural progression from HTML4's ideology, while respecting authors' collective recent interests, such as media embedding, and <canvas>.

  • Still sloppy (Score:5, Insightful)

    by nagora ( 177841 ) on Tuesday January 22, 2008 @01:39PM (#22140882)

    "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

    • Is that such a difficult concept?

      I'll make you a deal: you talk to the W3C and get them to drop this completely and utterly bass-ackward broken idea of creating new non-XML flavors of HTML, and I'll talk to the XML folks about dropping the DOCTYPE requirement.

    • The problem is that most non-IE browsers rely on the presence of a DOCTYPE to signal whether the document should be parsed in a strict standards-compliance mode or a loose "quirks" mode. So if you ditch the DOCTYPE you're taking away authors' ability to "opt in" to stricter parsing.

    • Re:Still sloppy (Score:5, Interesting)

      by hixie ( 116369 ) <ian@hixie.ch> on Tuesday January 22, 2008 @03:19PM (#22142734) Homepage
      Actually originally we wanted to remove the DOCTYPE altogether, and since the <html> start tag is optional that would have made the boilerplate "" (the empty string), or "<html>" if you want to include the <html> 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 "<!DOCTYPE HTML>".

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

  • Includes? (Score:3, Insightful)

    by pr0nbot ( 313417 ) on Tuesday January 22, 2008 @01:40PM (#22140906)
    Good to see they're binning frames.

    But - why has there never been an include mechanism in HTML?

    • But - why has there never been an include mechanism in HTML?
      I don't know the answer, but I suspect two things:
      • Not that much demand from developers... this is simple to solve server-side.
      • Potential for abuse/mistakes. You'd have to protect browsers against nested includes/circular references which could get tricky.

      • Re: (Score:2)

        by pr0nbot ( 313417 )
        But all that is true of CSS, and yet we have the ability to include external CSS in both HTML and in CSS itself.
        • With CSS you are sold on external sheets because they cache and thus shorten load time. You might be able to make the same argument about certain types of html - say a navigation sidebar... but I bet the html that makes up even a complex sidebar is in the 1kb range once zipped. For instance, the whitespace-heavy Slashdot sidebar is 3.4k and compresses to 1.2k. I'm not sure that it is worth caching that. Their CSS, on the other hand is 56k (12k zipped).

    • Re: (Score:2)

      by porneL ( 674499 )
      There has been - frames - and it didn't work out very well. It's because the web has deep-rooted assumption that every document has its own URL.

  • Absent Elements
    font, although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors.

    I know this is for ease of use, but seriously: if the people at W3C really want a "standard", doing stuff like this does nothing but make it ok to ignore the standard. So which is it, CSS or font? Pick one!

    • Re: (Score:2)

      by Tacvek ( 948259 )
      They are planning on dropping this. What they will recommend dumb WYSIWYG ediotrs to use is unclear, but it may just be simple style attributes containing inline CSS. (That is certainly better than the font tag).

    • Re: (Score:2)

      by porneL ( 674499 )
      This part isn't ignored. In fact, it's pretty much the opposite: all current implementations of WYSIWYG editor insert <font> and browser vendors refuse to change that, because websites rely on that behavior.

      If W3C demanded CSS, then it would get ignored or at best implemented as <span style="color:red">, which is just as bad as <font color="red">.

  • title says it all really. basically they are not going for a default of ogg for audio and video by the looks of it...
    • Why? Ogg was supposed to be a free version of MP3. We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video. Barely anything out there supports Ogg except for a VLC and maybe one handful of apps and one or two iRiver players.

      • Re: (Score:2, Informative)

        by nickptar ( 885669 )
        "We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video"... both of which are patent-encumbered.
      • And a bunch of other MP3 players and every single MP4 player manufactured in China.

  • Finally (Score:2, Insightful)

    by Wiseman1024 ( 993899 )
    XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

    On top of that, we get decent application controls such as grids, trees, better lists, and meters.

    Though audio and video I can live without. I'll be the first to get rid of it in my user CSS.

    Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2). (And
    • You want to center a block? Set it's width, and set left and right margins to 'auto'. That's CSS for 'center block relative to enclosing block.' (And yes, that behaviour is in the spec.)

      Otherwise, what are you looking to do that you can't?
      • And if your block isn't fixed-width? Seriously, I've never understood why you need to tinker with an object's margins to changes its alignment. A whole stack of CSS stuff like this seems terribly clunky and unintuitive.

        Of course, my mine gripe with the centering methods in CSS is that IE6 doesn't support them, but that's not W3Cs fault.

        • Setting the left and right margins to auto works just fine in IE6, although I wouldn't have been surprised if it didn't.

          Also, as long as your element is set to a width smaller than the parent element then it should work, and if you want everything inside a <div> to be centered then you set "text-align: center;".

          /Mikael

        • If it's not fixed width, it will be as wide as it's parent and thus centering it would not make sense. What is it you are trying to do but can't do?

        • Your block will either be fixed-width or have some width relative to it's enclosing block, otherwise you wouldn't be centering it. (The only other option is completely unknown width, and if the width is completely unknown the browser can't center it. It won't know the width either.)

          And the margins thing makes sense, if you think about it: to center it, you tell it to distribute all extra space into the margins, equally. So it's logical, if a little unintuitive.

          CSS isn't always the most intuitive, I'll ad
    • XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

      I'd say that XHTML (which is what we should be talking about) is actually quite nice and lowercase is a lot nicer than uppercase, or are you one of those people who think COBOL was fun to write?

      Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2).

      • Re: (Score:3, Insightful)

        by hixie ( 116369 )
        With HTML5 we are doing a few things to address the fact that authors write invalid content. One is that we are relaxing a lot of the content model requirements. Another is that we are allowing the "/>" style on elements that have no end tag (like <img> can be written <img/>). We're also simplifying some things like making the type="" attribute optional on the <script> and <style> elements.

        There's also work to make validators for HTML5 that are far more detailed and friendly than

    • XML's syntax sucks. It's annoyingly verbose,

      ...and delightfully extensible and powerful...

      and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text).

      ...which is why I used one of the many open source and/or freeware text editors out there that support syntax highlighting. I can honestly say that I've never had a problem telling my tags and attributes from my content, and even when I'm not using case-sensitive markup, I never use asinine CAPITAL LETTERS to denote su

  • Still no value on select tags? (Score:4, Insightful)

    by dumbo11 ( 798489 ) on Tuesday January 22, 2008 @02:45PM (#22142072)
    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".

    • Re: (Score:2)

      by hixie ( 116369 )
      That's an interesting idea. I'll file it away for consideration. You can also send feedback to the lists (see e.g. http://www.whatwg.org/mailing-list#specs) or to me directly (ian@hixie.ch).
    • I also think that selected="selected" is pretty redundant. selected="true" would convey as much information, but look less, wel, redundant. Granted, it's just a few bytes, but it does look kind of stupid...

  • HTML5 is the wrong path (Score:5, Insightful)

    by Dracos ( 107777 ) on Tuesday January 22, 2008 @03:12PM (#22142616)

    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.

    • Re: (Score:3, Informative)

      by hixie ( 116369 )
      XHTML failed: hardly anyone uses it. According to studies I did at Google, using a sample of several billion pages, about 0.0044% of pages use XHTML with the XML MIME type, and about 15% of people try to use XHTML, by giving the XHTML namespace, but actually use HTML, by sending it with the text/html MIME type.

      I'd rather work on a spec that is considered drivel but that everyone ends up using, than work on a spec that is theoretically perfect but which makes zero impact on the world at large.

      • Re: (Score:2)

        by Nimey ( 114278 )
        So far as I know, Internet Explorer doesn't support XHTML. Since it's the majority browser, there you go.
      • Why should anyone use XHTML when IE still the majority browser - will treat it as regular HTML anyway? If you want to avoid weird bugs that arise from one browser being in XML mode and one being in HTML mode you write everything as HTML from the start.

        XHTML is kind of nice, but Microsoft has rendered it irrelevant by ignoring it. So we use HTML 5, which maybe has a better chance of supplanting HTML 4.01.

      • Re: (Score:3, Informative)

        by Dracos ( 107777 )

        No version of IE supports XHTML's correct mime type. XHTML "failed" not because people didn't want to use it, or didn't understand it, but because the majority browser didn't support it. So XHTML is served with the mime type IE does understand, and this is a practical, if far from ideal, compromise. The problem lies with the browser(s), not the users or developers.

        I'd rather have a spec that is perfect and correctly implemented than a perverted one that still won't be correctly implemented.

    • Re:HTML5 is the wrong path (Score:5, Interesting)

      by Xest ( 935314 ) on Tuesday January 22, 2008 @03:46PM (#22143316)
      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?

      • Re:HTML5 is the wrong path (Score:5, Insightful)

        by hankwang ( 413283 ) * on Tuesday January 22, 2008 @04:28PM (#22144184) Homepage

        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.

    • Re: (Score:2)

      by dargaud ( 518470 )
      Yes, my site is amateurish and has been like that since, oh, 1996. When I looked at the XHTML+CSS specs my only thought was "WTF, this can only be written by a code generator". I write my HTML by hand as the original web intended. Yes, I forget to close some tags and the presentation is kind of sucky. So what, I still get 10000 visitors a day. At least with HTML4/5, I know what the tags mean. Not so with XHTML. And XHTML never validates, period. I'd say HTML5 is a realistic implementation for old-style web

  • No more style attribute?!?!?! (Score:4, Interesting)

    by TrebleJunkie ( 208060 ) <ezahurak.atlanticbb@net> on Tuesday January 22, 2008 @03:29PM (#22142932) Homepage Journal
    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.

  • Uploading Files (Score:2, Insightful)

    by Blobule ( 913778 )
    I didn't see anything new for uploading files. It would be great if improved support for uploads could be considered. Currently uploading 10 files requires 10 file widgets and performing the browse/select process for each one. It would be nice if the kind of interface found on sites like facebook for uploading multiple images/files could be achieved without the need for Flash or Java.

  • Fix : text, sizing, rendering (Score:4, Insightful)

    by victim ( 30647 ) on Tuesday January 22, 2008 @03:38PM (#22143136)
    Having used <canvas> 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.

  • The standards are just not very good (Score:3, Interesting)

    by groomed ( 202061 ) on Tuesday January 22, 2008 @08:38PM (#22147850)
    Every discussion around HTML and related W3C standards always seems to end up in a blamefest. Microsoft is to blame for their poor standards compliance, lazy web developers are to blame for sloppy code, Al Gore is to blame for inventing the Internet.

    All of that is true. But I have come to believe that perhaps the blame lies primarily with the standards themselves. They are just not very good.

    I know this is not a popular opinion. Let me qualify it and try to explain briefly what I mean. There is of course a lot of theoretical and historical background to consider, but frankly it is a waste of time to drag all that into a Slashdot comment.

    The first problem is with HTML. HTML abstracts at the wrong level. It should be a presentation language, not a structural markup language. There is no need for HTML as a structural markup language and frankly I am baffled by the religious zeal with which some people defend this notion. As a structural markup language, HTML is very poor. Structural markup is most useful for well-defined, domain-specific applications. That is not what HTML is used for and this causes numerous problems: ill-defined rendering behavior, poor querying and indexing abilities, poor feature set, relatively slow performance, not to mention poor reusability.

    The second problem is with CSS. Although at its core a good idea, it is poorly implemented, with a pointlessly weird, C-inspired syntax. It is too feeble to express presentational structure and lacks a method to express generalized context-dependent relationships. The selector language is so baroque that it is poorly understood by authors and implementors alike. Most importantly, CSS simply does not solve many common layout and styling problems, except at the most trivial level. Efforts to address this have mostly just made CSS more complicated rather than more powerful.

    The third problem is with Javascript. The language itself is not bad, but it exists in an environment that is so primitive and crude, that often the easiest way to accomplish anything is still to just stuff precalculated strings into a node's innerHTML. The web is littered with the corpses of Javascript libraries to provide simple services like data binding, templating, input validation and widget sets. None of which build on eachother, because there are no tools to enable this kind of workflow, and most of which fail on either correctness, performance or standards-compliance.

    Why are there so many problems with these standards? Is it normal for standards to be so problematic? It is certainly true that numerous standards failed. But on the other hand, many other standards succeeded. PostScript and PDF are very successful standards that have been implemented dozens of times with minimal interoperability issues. The same goes for countless file format standards, such as GIF, PNG, JPG and ZIP, or standards such as ASCII or Unicode.

    Of course the comparison between HTML (and all related tech) and, say, GIF, is not valid. In the case of HTML there are many reasons, some socio-economic, which have brought us to the point where we are today. But despite that, I believe it is possible to identify 2 key issues with the W3C family of tech:

    1. The wrong abstraction level. The W3C people have been chasing a nebulous vision of a "semantic web" which is accessible for everyone on any kind of device. This has resulted in intentionally vague, abstract specifications. But people who have not done a lot of work building GUIs for production systems do not really understand how to abstract layout and presentation. This was a key failing in the original Java GUI toolkit called AWT (Abstract Window Toolkit).
    2. The wrong people. The HTML/CSS/Javascript/XSL standards have been developed by people who are primarily interested in information technology and theory. They have little understanding of and less experience with graphic design and application front-end development. They really do not understand what distinguishes good from bad in this area

Slashdot Top Deals

It is better to live rich than to die rich. -- Samuel Johnson

Close