Slashdot Mirror


W3C Considering An HTML 5

An anonymous reader writes "When the decision was initially made to move in the direction of XHTML, instead of a new version of HTML proper, it seemed like a good idea. Years later and the widespread adoption of CSS (among other things) has proven that things don't always develop the way we expect. As a result, HTML 5 has been revived by the W3C. After some lobbying and continued work by the Web Hypertext Application Technology Working Group, the old web markup language is getting an official face-lift. A post to the Webforefront blog explains the history behind the initial decision to move to XHTML, and why things are so different in the here and now."

82 of 414 comments (clear)

  1. Absolutely right by jimicus · · Score: 5, Insightful

    Because what the world really needs right now is another version of a web standard which has had hardly any full, correct implementations in any version that's ever existed.

    Or are the W3C just trying to justify their existence?

    1. Re:Absolutely right by Valacosa · · Score: 4, Funny

      Because this time people will code to it, dammit.

      --
      "Live as if you'll die tomorrow." Ridiculous. You could die later today.
    2. Re:Absolutely right by tolan-b · · Score: 5, Interesting

      Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

    3. Re:Absolutely right by $RANDOMLUSER · · Score: 5, Funny

      Because this time people will code to it, dammit.
      You got coffee on my monitor.
      --
      No folly is more costly than the folly of intolerant idealism. - Winston Churchill
    4. Re:Absolutely right by arivanov · · Score: 3, Insightful

      Yeah, right.

      That shall be coding to a standard defined by a vendor infested committee where each representative has been obsessed to ensure that all of their bugs are standardised as "this is not a bug, it is a feature".

      As a result the implementations will remain as quirky as they are now. At best. At worst...

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    5. Re:Absolutely right by ronadams · · Score: 2, Interesting
      1. It's made of many people, period. Some of them do not work for any tech firms.
      2. If the primary (or even subsidiary) interest in updating standards was to sell more copies of Dreamweaver and other similar products, then why would there be free updates to Dreamweaver extensions to reflect standards changes? Also, the majority of the industry is not coding in Dreamweaver, so there's no chokehold on the business here.
      3. Sorry, no point-and-click HTML generator makes "perfectly good HTML". Many do a decent job, but it will never be as efficient as straight code and thorough knowledge of the standards.
      In closing, if the W3C's purpose was to bolster commercial software sales, they sure are going about it in the most ineffective way possible.
      --
      Appended to the end of comments you post. 120 chars.
    6. Re:Absolutely right by AKAImBatman · · Score: 4, Informative

      Or are the W3C just trying to justify their existence?

      That's a bit cynical, don't you think?

      HTML5 is the result of the hard work done by the Web Hypertext Application Technology Working Group (WHATWG). The WHATWG is composed of members from all browser makers, with the occasional public comment thrown in for good measure. As a result, the group has been removing or reducing the ambiguity about implementing the various standards (especially the parser!) and have added features that bring HTML up to a true application platform. Their work is represented in web browsers every time someone uses the Canvas tag, Audio object, Storage API, and other modern features.

      The WHATWG was formed because the W3C was seen as too slow to execute such new technologies. Now that the WHATWG specs are stablizing, the W3C has taken a dump of the WHATWG HTML 5 standard and proposed it for ratification under W3C bylaws. This has several advantages over the WHATWG standardization, not the least of which is extracting patent waivers from companies like Apple who technically "own" some of the technologies behind the WHATWG standards.

      Note that the HTML5 group at the W3C is a bit different from most. In an attempt to remain as open as the WHATWG, they are accepting just about anyone as an "invited expert" to provide input and comments on the standards process. This is a huge departure from the way that most W3C standards are handled, and is probably a good choice for a standard as comprehensive and complex as HTML5.
    7. Re:Absolutely right by TheRaven64 · · Score: 2, Interesting

      Some of the WHAT-WG's proposals for HTML5 look fun. The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera) lets you draw bitmap images via the DOM, but my favourite is client-side storage. This lets you store several KB of data locally, enough for simple documents in a number of formats.

      --
      I am TheRaven on Soylent News
    8. Re:Absolutely right by tolan-b · · Score: 3, Informative

      No you're wrong I'm afraid, the HTML5 that W3C is talking about *is* based on WhatWG's HTML5. It supports HTML and XHTML syntaxes to the the same serialisation, so MS supporting XHTML isnt' wasted. They're basically merging HTML and XHTML.

    9. Re:Absolutely right by AKAImBatman · · Score: 4, Interesting

      The canvas tag (originally from Mozilla, I believe, but now in WebKit and Opera)

      Actually, it was originally from Apple Safari. Apple invented it for their desktop widget thingys. Opera and Mozilla have both embraced it with open arms. :)

      my favourite is client-side storage.

      I agree. I absolutely love this feature! Unfortunately, it's only implemented by Firefox at the moment. I was hoping that it would show up in Safari 3.0 so that richer iPhone applications could be written, but it was not to be. The feature request is still sitting out there with no assigned implementer. I'm tempted to dive into Webkit and maybe see if I can add it.
    10. Re:Absolutely right by AKAImBatman · · Score: 5, Informative

      Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.

      Don't believe me? Here are the two standards. Compare:

      WHATWG HTML5
      W3C HTML5

      Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.

    11. Re:Absolutely right by Captain+Splendid · · Score: 2, Funny

      if the W3C's purpose was to bolster commercial software sales, they sure are going about it in the most ineffective way possible.

      I dunno, I sure have bought a lot of copies of Notepad in the last ten years!

      --
      Linux, you magnificent bastard, I read the fucking manual!
    12. Re:Absolutely right by suv4x4 · · Score: 2, Interesting

      No you're wrong I'm afraid, the HTML5 that W3C is talking about *is* based on WhatWG's HTML5.

      It's written "WHATWG" by the way, for the same reason you don't write UspTo. But that's not important.

      WHATWG are the group that pitched W3C to consider HTML5. W3C's HTML5 isn't based on anything right now since it doesn't exist yet. It may include in some form some HTML5 features, but don't delude yourself that W3C will beat the heck out of it, until it's a tortured mix of their XHTML2 standard and WHATWG's HTML5.

    13. Re:Absolutely right by fbjon · · Score: 3, Funny
      You jest, but it is actually that simple. HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.


      The result is that browsers will show you the finger if you don't code to the standard.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    14. Re:Absolutely right by WED+Fan · · Score: 5, Insightful

      Actually HTML5 is largely a result of work by the main browser makers, except Microsoft I believe. Hixie from Opera is the project lead of the WhatWG which was created to extend HTML to make it more applicable for web applications. It fixes a lot of the problems with both HTML 4 and XHTML, and its backwards compatible with *both*.

      Excuse me, but it must be pointed out.

      When you start talking standards and you gather a group of browser/client makers to discuss new standards, you really do need to have the giant on the block represented. Otherwise, you get a set of standards that run the real possibility of being ignored, or worse, supplanted by the giant's idea.

      When the combined numbers of the "others" don't even come close to trumping the giant's numbers, you are heading to failure. In this case MS, like it or not, is the giant. The easiest way to stop this crazy, "IE only partially implements html x.0/css x.1/xhtml x.x" crap is to involve them.

      Of course, this is just crazy talk, right. Oh heavens, we might actually run into the problem of MS taking over the standard. You know what, when you have a formation marching down the street, and 70% are on one heel beat, and the other 30% are out of step with the 70% and aren't even in step with themselves, its the 30% that need to get with the beat.

      Failure to accept this is only going to widen the gulf, unless MS, through largesse or coincidence follows the new standard.

      --
      Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
    15. Re:Absolutely right by 1110110001 · · Score: 2, Informative
      I copied both specs to a pure text file and the only difference I found is a mark in the header lines:

      -WHATWG
      +W3C
      -Working Draft -- 28 June 2007
      +W3C Editor's Draft 28 June 2007
      -You can take part in this work. Join the working group's discussion list.
      +This Version:
      + http://www.w3.org/TR/2007/WD-html5-2007MMDD/
      +Lat est Published Version:
      + http://www.w3.org/TR/html5/
      +Latest Editor's Draft:
      + http://www.w3.org/html/wg/html5/
      +Editors:
      + Ian Hickson, Google, Inc.
      + David Hyatt, Apple, Inc.
      -Web designers! We have a FAQ, a forum, and a help mailing list for you!
      +Abstract
      -One-page version:
      - http://www.whatwg.org/specs/web-apps/current-work/
      -Multiple-page version:
      - http://www.whatwg.org/specs/web-apps/current-work/ multipage/
      -Version history:
      - Twitter messages (non-editorial changes only): http://twitter.com/WHATWG
      - Commit-Watchers mailing list: http://lists.whatwg.org/listinfo.cgi/commit-watche rs-whatwg.org
      - Interactive Web interface: http://html5.org/tools/web-apps-tracker
      - Subversion interface: http://svn.whatwg.org/
      -Editor:
      - Ian Hickson, Google, ian@hixie.ch
      +This specification defines the 5th major revision of the core language of the World Wide Web, HTML. In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.
      +Status of this document
      -© Copyright 2004-2007 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA.
      +This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
      -You are granted a license to use, reproduce and create derivative works of this document.
      -Abstract
      +If you wish to make comments regarding this document, please send them to public-html@w3.org (subscribe, archives) or whatwg@whatwg.org (subscribe, archives). All feedback is welcome.
      -This specification introduces features to HTML and the DOM that ease the authoring of Web-based applications. Additions include the context menus, a direct-mode graphics canvas, inline popup windows, and server-sent events.
      -Status of this document
      +Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
      +The latest stable version of the editor's copy of this specification is always available on the W3C CVS server and in the WHATWG Subversion repository. The latest editor's draft (which may contain unfinished text in the process of being prepared) is available on the WHATWG site. Detailed change history can be obtained from the following locations:
      -This is a work in progress! This document is changing on a daily if not hourly basis in response to comments and as a general part of its development process. Comments are very welcome, please send them to whatwg@whatwg.org. Thank you.
      + * Twitter messages (non-editorial changes only): http://twitter.com/WHATWG
      + * Interactive Web interface: http://html5.org/tools/web-apps-tracker
      + * Commit-Watchers mailing list: http://lists.whatwg.org/listinfo.cgi/commit-watche rs-whatwg.org
      + * Subversion interface: http://svn.whatwg.org/
      + * CVS log: http://dev.w3.org/cvsweb/html5/spec/Overview.html
      -Implementors should be a

    16. Re:Absolutely right by tolan-b · · Score: 4, Informative

      WHATWG are the group that pitched W3C to consider HTML5. W3C's HTML5 isn't based on anything right now since it doesn't exist yet.
      From the WHATWG list:

      The W3C's HTML working group today resolved to start from the current WHATWG work. Specifically, the group resolved to review our work, and will probably build on it. They also resolved to call this work HTML5. Thus, the "Web Applications 1.0" spec is now officially named "HTML5"! I have also checked a copy of the two main WHATWG specs (but with the W3C boilerplate) into the W3C CVS server. Going forward, any changes will be committed to both the WHATWG and the W3C repositories simultaneously.


      It may include in some form some HTML5 features, but don't delude yourself that W3C will beat the heck out of it, until it's a tortured mix of their XHTML2 standard and WHATWG's HTML5.

      Well seeing as it's starting from their work I rather suspect it will include the bulk of it, because it's highly interdependent.

      Then again you seem to have an axe to grind with the W3c, so don't let me stop you..
    17. Re:Absolutely right by fbjon · · Score: 4, Interesting

      Yes there is, the browsers would be checking to ensure it's valid. If no browser accepts it, the developer will have to fix it or get fired.

      --
      True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
    18. Re:Absolutely right by Excors · · Score: 4, Informative

      HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

      That is incorrect: the HTML5 parsing algorithm never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).

      Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.

    19. Re:Absolutely right by jalefkowit · · Score: 5, Informative

      You jest, but it is actually that simple. HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

      The result is that browsers will show you the finger if you don't code to the standard.

      I'm a participant in the HTML Working Group and I can tell you that this is incorrect. You're thinking of XHTML2, not HTML 5. XHTML2 has the XML parser strictness and pages will fail to display if they're not well-formed. HTML 5 is going the complete opposite direction, assuming that people will code poorly and defining failure modes for browser vendors to follow when that happens.

    20. Re:Absolutely right by jalefkowit · · Score: 2, Informative

      Microsoft has several people participating in the HTML Working Group, and Chris Wilson, the leader of the IE team, is the chair of the group. So you don't have to worry about Microsoft being left out.

    21. Re:Absolutely right by rikkus-x · · Score: 2, Insightful

      a specification that describes how to handle invalid content

      Perhaps you'd like to write it? I'd like to see such a thing. It would be quite amazing if it was done well.

    22. Re:Absolutely right by Excors · · Score: 4, Insightful

      If no browser accepts it, the developer will have to fix it or get fired.

      More likely, the developer will stop using technology that makes their life harder, and will stick with invalid HTML4 and Flash and Silverlight and all the other possibilities, which defeats the aim of improving interoperability on the web.

      Also, browsers have bugs. What happens when a user tests in one browser which accidentally accepts their invalid code, without noticing that other browsers don't? (Possible answer: other browsers will have to start accepting that invalid code too, else their users will stop using that browser and start using the one that can actually display the web. And since the specification would only say how to handle valid code, the other browsers will have to reverse-engineer each other to get mostly-compatible behaviour for invalid code, which results in a mess of incompatibilities - that is what has happened for HTML4, and is what HTML5 is trying to fix by defining how all invalid content must be handled in a way that is sufficiently compatible with the existing behaviour (and existing bugs) of browsers.)

      Also, most content is generated dynamically, so you can't simply test the page before you upload it. Server-side code has bugs, and draconian error handling does not make things easy to fix.

    23. Re:Absolutely right by thrillseeker · · Score: 2, Funny

      a specification that describes how to handle invalid content

      Perhaps you'd like to write it? I'd like to see such a thing. It would be quite amazing if it was done well.


      I'd recommend a nice blue colored background with lots of white text and numbers when anything goes wrong - I kind of miss it not being in the web world ...

    24. Re:Absolutely right by Trails · · Score: 4, Informative

      Chris Wilson is a guy with his heart in the right place working for people who, in the past, put business strategy over standards support (I'm not editorializing, that's what they did). This is why MS's standard support is lame.

      That being said, Chris Wilson (at least) talks the talk, and IE 7 was a (small) step in the right direction.

      The more important, and encouraging, signal imo is MS hiring Standardista Molly Holzschlag. Given her history, I think we can expect more and better from MS on this front in the future.

    25. Re:Absolutely right by Anonymous Coward · · Score: 5, Insightful

      I'm very troubled by the implication that HTML5 will focus on the assumption that people will code poorly and the proper solution is to provide better failure modes for browsers. This is more likely to have the effect of lowering the standard than improving it as humans will simply take the easy road.

      I would plead for a higher standard that would require strict compliance to well-formed rules that would lead to better overall web governance, security, and standards that benefit the authors and readers. I'm really fed up with not being able to use my favorite browser for everything because the code is broken on one browser brand or version, or because one browser vendor simply wants to make their own rules.

      Let's do this generation of standards right. Make the coders comply with strict, well-formed rules or make them pay the price.

    26. Re:Absolutely right by jalefkowit · · Score: 4, Informative

      Wow. I hate you.

      The working group is open to the public and costs nothing to join. If you don't like the state of HTML, come over and help make it better.

    27. Re:Absolutely right by Blakey+Rat · · Score: 3, Insightful

      The problem seems to be that a significant percentage of web site developers lack the discipline or interest to follow rules.

      The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0? Is it even possible? Yet I can "break" the rules, use table cells as layout, and accomplish the same thing in seconds.

      Web developers would use the standards if the standards reflected the reality of their job and *made it easier*. In the same way software developers use APIs because the APIs *make their job easier*. (You don't have to worry about what monitor a window is on, you just call 'RefreshWindow' or whatever and it happens. CSS *should* have had a "style='3 column'" from the start.)

    28. Re:Absolutely right by FireFury03 · · Score: 3, Interesting

      Some of the WHAT-WG's proposals for HTML5 look fun.

      Unfortunately there seems to be a lot of crazyness in there too. XHTML 1.1 went some way towards reducing the redundency of some tags. For example, the object tag replaces embed, iframe, etc with a single unified tag to handle all embedded objects (not sure why they didn't ditch img at the same time.

      HTML 5, on the other hand, seems to be keeping object but also reviving iframe and embed. Meanwhile they are introducing a load of tags to do the same job - video, audio, etc. This is crazyness since it means you have to revise the markup language every time someone invents a new type of embedded object, whereas just using a single object tag for everything means your browser can determine the type of content from the MIME content type of the object and render it if supported.

      I would prefer to see new features going into XHTML rather than HTML. However, XHTML does need a modification IMHO: the spec states that XHTML which isn't well formed must not be rendered - I think it would be better to require the browser display a page saying something along the lines of "this page is broken, click this button to try and fix it - it may not render correctly". Forcing web developers into writing well formed code is a Good Thing, but the end user needs a way of trying to render the page anyway if the developer did muppet it up.

      The trick to making bad web developers write good code is to make sure the people who are paying them know that they are bad developers - presenting a page stating that fact is a good way to do that.

      I don't believe the spec can (or should) define how to handle broken code in the specific sense - defining the handling for every corner case is impossible and would make the spec far too complex. Much better to just say "you present an error, give the user the option to fix it and then fix it up as best you can (how to do this is outside the scope of the spec)".

    29. Re:Absolutely right by CoughDropAddict · · Score: 4, Insightful

      Imagine if C++ compilers could take the same liberties that web browsers could with the input!

      Imagine if web browsers were anal retentive and refused to display anything with the slightest syntax error. Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it. Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable.

      I know it's not satisfying, but being permissive on the web really is the best policy, as long as the results of the permissiveness are well-defined (which is what HTML5 does).

    30. Re:Absolutely right by metamatic · · Score: 2, Insightful

      The "rules" are stupid. Do you know how hard it is to make a 3-column or 4-column content site using CSS 1.0?

      Nice strawman. CSS 1.0 was 11 years ago. Do you know how hard it is to make a 4-column table using HTML 2.0, which was the HTML standard 11 years ago?

      (Hint: HTML 2.0 didn't have tables.)

      4 columns in CSS is trivial, if you don't limit yourself to what CSS was like 11 years ago.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    31. Re:Absolutely right by Tony+Hoyle · · Score: 3, Insightful

      Yeah like they do now for XHTML and HTML4.

      Oh, wait. They don't.

    32. Re:Absolutely right by Excors · · Score: 2, Interesting

      You can create DOMs that cannot be serialised to well-formed XML, like with document.createComment('--'). I don't really know anything about XSLT, but it doesn't appear to have had much success as a web templating language. Tools like Genshi seem to do much better at that, but anything outputting XHTML has to be very careful about avoiding all the little errors that might creep in and kill the document, so it's still safer to serialise to HTML at the output end of an XML toolchain - the browsers of your web site's users are rarely the best place to detect bugs in your server code, since those users are not in a position to do anything except leave your site.

    33. Re:Absolutely right by Blakey+Rat · · Score: 3, Insightful

      That's because it's a label, wired up to jump to the text field it is associated with as soon as you click.

      And therefore copy and paste doesn't work. This kind of crap is exactly why I hate the web!

    34. Re:Absolutely right by SmokedS · · Score: 2, Insightful

      Eh, No.
      It means you get to use a validation component on the included content before sending it to a browser.

      You can bet your butt that there will be such components available before HTML 5 reaches any notable market penetration. Open source coders will Likely get them out there before the standard is even finalized.

    35. Re:Absolutely right by Allador · · Score: 5, Insightful

      Did you read the proposal, or anything around WHAT-WG's HTML5?

      It's actually incredibly sensible, and is a very practical and natural extension of what we're doing with HTML now.

      It has very little to do with browser bugs, or even web sites per-se. It's more about adding features to more naturally support web 'apps'.

      Read up on it, it actually makes a lot of sense.

      I just hope it can make some progress, but given that it was started by Mozilla, Apple and Opera, the people making the best browsers out there, it may actually have a chance of being supported.

    36. Re:Absolutely right by ptaff · · Score: 2, Insightful

      Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML, and your not-quite-perfect blog software didn't quite know how to launder it [...] could make your site completely unavailable.

      Well, it would be a shame to use any software that'd break like that! How come that the web is the sole programming environment where it's impossible to get an error, where programmers are thus encouraged to make errors, where coders can ignore string validation (and supposing a strict HTML parser, they'd blame the parser just like a clueless newbie would blame a compiler)? Please, we're not talking about complicated markup nor about string validation done in assembly or C -- web languages have easy built-in routines that do just that.

      HTML monkeys rely on that great "error-recovery" misfeature and that alone explains why browsers are so big and slow. Every tag-soup-recovery method used by MSIE must be reproduced, so the standard shifts to how-does-MSIE-handle-that. Had Netscape won the browsers war, the same situation would prevail.

      And there is no reasonable explanation nor incentive to base the web on human error recovery! Come on now. The web would still exist if it required strict conformance to standards. Javascript syntax errors are fatal, how come people who can't code HTML properly are able to code syntax-error-free javascript?

    37. Re:Absolutely right by Doctor+Memory · · Score: 2, Insightful

      magine if web browsers were anal retentive and refused to display anything with the slightest syntax error If they'd been this way from the start, then there wouldn't be any problem. HTML would be just like a programming language: break the rules, pay the price.

      Imagine if your blog suddenly became undisplayable because commenter number 32 input some broken HTML Commenter #32 wouldn't have been able to input some broken HTML. If it was really important to keep HTML valid, then blog software would have correctness-checking, and submitting borked HTML would result in "The comment you entered did not pass HTML validation. Please check any HTML tags you may have entered and correct any errors."

      Imagine that the slightest syntax error from Google Analytics, Google AdWords, or anything else you embed into your site could make your site completely unavailable. I imagine that anybody supplying ads would make damn sure their HTML was valid, since the clients don't care whose fault it is, they just want their ads to show up.

      Sure, I know we can't suddenly flip a switch and declare that all HTML must be valid and well-formed from now on, I'm just saying that if we'd treated HTML the way we treat programming languages, we'd be in much better shape today. Too bad HTML tags weren't defined as a bunch of PostScript macros....
      --
      Just junk food for thought...
    38. Re:Absolutely right by porneL · · Score: 2, Informative

      HTML 5 revived <embed>, <iframe> and added <video> precisely because <object> has failed. It turned out to be too difficult to implement interoperably -- you have one element, that might be an image, a page, a video, an applet or any plugin content, but you can never be sure what it is, because it's dependent on a remote resource and can even change dynamically. It must have DOM API for all of possible content types. It sometimes has intrinsic dimensions, sometimes it hasn't. And on top of it all, Eolas has been given patent for its most obvious implementation.

      HTML 5 has fully documented parsing, including error handling. So you have unambiguousness of XML (handling of every possible input is covered by the spec) with fail-safety of real-world HTML (because users prefer browsers that don't show Yellow Screen of Death, ever).

    39. Re:Absolutely right by metamatic · · Score: 2, Insightful

      Nobody in the HTML group thought columns would be useful either, apparently. As I said, HTML 1.0 and HTML 2.0 lacked any kind of columns or tables.

      No, the idea was to build up the standards gradually. Start with the simple stuff and then move on to the more complicated problems. You know, good software engineering. Plus HTML was never intended to be a page description language. Computers at the time didn't have the kind of huge high-resolution screen that would make multiple columns a good idea.

      (In fact, plenty of us still don't think they're a good idea on screens.)

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  2. Regress is the New Standard for Progress by ronadams · · Score: 4, Insightful

    TFA makes several great points about how this seeming sentiment of "we'll stick with the HTML we know and love" is more an unwillingness to change than it is to update a standard. The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. This really seems a regression more than anything. What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?

    --
    Appended to the end of comments you post. 120 chars.
    1. Re:Regress is the New Standard for Progress by Anonymous Coward · · Score: 4, Insightful

      Ill tell you why web developers do not adopt XHTML, its not because of reluctance to change, its because XHTML OFFERS NO BENEFITS TO HTML 4.

      Why would anyone in their right mind spend time updating from HTML 4 to XHTML 1.1 when there is no visible benefit and a LOT of pain.

      HTML 5 FINALLY introduces features that web developers NEED. Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es. If they had introduced these features into XHTML then I am sure it would have been adopted by browsers and developers alike.

      The lack of support from a certain vendor would not have mattered because they would have been pressurized into supporting the standard by the >10% share of browsers that would support it.

      P.S. Posting in good 'ol plain text :)

    2. Re:Regress is the New Standard for Progress by LingNoi · · Score: 2, Insightful

      Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es.


      Even with client side validation you would still have to validate it server side anyway unless you are a crap developer.

      I would rather have xhtml then go back to the mess that html was with its styling embedding directly into the tags and I know that if its allowed its going to happen. Some day I am going to get the tag soup code from the developer working with me, I can feel it.

      Give me clean code and forced usage of CSS any day.
    3. Re:Regress is the New Standard for Progress by tknd · · Score: 2, Insightful

      Ill tell you why web developers do not adopt XHTML, its not because of reluctance to change, its because XHTML OFFERS NO BENEFITS TO HTML 4.

      Incorrect. Web developers don't adopt it because they're not required to. XHTML offers one big benefit that many bad web developers, like yourself, fail to see. That is strict parsing and failures associated with parse errors. When you write a program, the compiler/interpreter expects you to write code that adheres to the syntax defined by the language. Failure to do so results in an error. There is exists no such thing for HTML4 markup, therefore you can gloss over several parser errors and never notice them. XHTML was out to fix that, but because the W3C has such a shitty track record with the other half of defining standards (which is testing, quality assurance, and certifcations), nobody bothers.

      The parser should be anal. We've already developed and studied parser technology to the point where it is pretty standard or even automated to write a parser as long as you have a grammar. Having an anal parser is almost "free" testing--something many web developers need more training on.

      Why would anyone in their right mind spend time updating from HTML 4 to XHTML 1.1 when there is no visible benefit and a LOT of pain.

      It's only painful because you've been doing it wrong the entire time and you were allowed to get away with it.

      HTML 5 FINALLY introduces features that web developers NEED. Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es. If they had introduced these features into XHTML then I am sure it would have been adopted by browsers and developers alike.

      No, you don't need those things. You think you do, but you don't. The internet was intended to spread information. Text and hyperlinks are a great way to get that across. But somewhere, someone(s) started playing with other types of content like images, animated images, built-in programmability (Javascript/ECMA script), and embedded programs and other types of media (flash, video, audio). Now we have bloated pages, pages that mess with your computer, and a complete mess called the world wide web.

      I don't disagree that there are some benefits to having these things, but there's been an awful lot of hurt and pain caused by having them. Therefore, I believe it is much better to take a conservative approach to adopting standards that go beyond basic text. Once we've finally gotten that first step right, then maybe we'll get the others implemented better. But everyone's always quick to define the solution but never the problem that the solution is to solve. Because of that we end up with standards and solutions that have issues and are fairly limited in their lifespan or application.

    4. Re:Regress is the New Standard for Progress by RAMMS+EIN · · Score: 2, Insightful

      I about couldn't disagree more.

      ``Ill tell you why web developers do not adopt XHTML, its not because of reluctance to change, its because XHTML OFFERS NO BENEFITS TO HTML 4.''

      On the contrary. XHTML, contrary to HTML, is easy to parse. There is a whole slew of tools available for parsing and processing XML documents, which can be used with XHTML straightforwardly (by virtue of XHTML being XML). Now, these benefits might be external to web developers, but, eventually, they should (and have) come back to them. Some XML tools can be put to good use by webmasters. If the webmaster outputs valid XML, that is.

      ``Why would anyone in their right mind spend time updating from HTML 4 to XHTML 1.1 when there is no visible benefit and a LOT of pain.''

      If your HTML was good, there is very little pain. If the HTML was crap, then, perhaps, you shouldn't bother with updating indeed.

      ``HTML 5 FINALLY introduces features that web developers NEED.''

      One of the key benefits of XHTML is that other XML formats can be used together with it. This allows an infinite number of useful formats to be developed orthogonally, and then put together as the need arises.

      ``Things like native client side validation, canvas and menu elements. These are things that we have been crying out for years but W3C disappeared up their own self-validating a**es. If they had introduced these features into XHTML then I am sure it would have been adopted by browsers and developers alike.''

      The trick is, of course, that with HTML, you do indeed need to put the features in the spec. With XML, you can keep things modular. MathML doesn't have to be in the XHTML spec to make it valid to embed MathML in an XHTML document. Of course, as long as user agents don't implement the necessary support, you're stuck no matter if the spec includes your favorite feature or leaves it up to a separate spec. And that's where the real issue is as far as features are concerned. The browser vendors don't have to wait for W3C to cook up something before they implement it, and, conversely, just because the W3C has cooked up something doesn't mean the browser vendors will implement it.

      ``The lack of support from a certain vendor would not have mattered because they would have been pressurized into supporting the standard by the >10% share of browsers that would support it.''

      In what reality?

      --
      Please correct me if I got my facts wrong.
  3. hmm. by apodyopsis · · Score: 3, Interesting

    are they going to enforce all the current browsers to support it fully and correctly as well?

    or will some browsers go their own way with "extensions" and "implementations" specific to their own system like last time.

    1. Re:hmm. by ronadams · · Score: 2, Funny

      are they going to enforce all the current browsers to support it fully and correctly as well? or will some browsers go their own way with "extensions" and "implementations" specific to their own system like every time. Fixed.

      No, the W3C has no authority or ability to enforce it. Browsers will do what they do. Hopefully, what they do is at least in the general neighborhood of the standards. Rules were made to be broken, and Web Standards were made to be bastardized by incompatible browsers.
      --
      Appended to the end of comments you post. 120 chars.
  4. The Author is Not Completely Wrong by ronadams · · Score: 4, Informative
    There was an interesting discussion about this in the xml-dev mailing list. Rick Jelliffe had this to say:

    XML was developed as a subset of SGML. Most of the ISO working group which looked after SGML were also involved with the creation of XML (Clark, Kimber, Bosak, also Goldfarb, Peterson, me, and others). The correction for SGML came out before XML was finally put as a recommendation (AFAIR) so there never was a time when XML was not a true subset of SGML. Where there were differences, ISO8879 was corrected specifically to make sure that XML was indeed a subset. In fact, Charles Goldfarb even said at one stage "XML *is* the revision of SGML" (debate on the revision of ISO 8879 had started years before: XML was the embodyment of that). XML can be argued as both the revision to and a subset of SGML. Hence my disappointment in anything new that seems to shy away from this path, like HTML 5 instead of XHTML.
    --
    Appended to the end of comments you post. 120 chars.
    1. Re:The Author is Not Completely Wrong by tolan-b · · Score: 5, Informative

      HTML 5 is also 'XHTML 5'. You can use well-formed XHTML style syntax, and deliver it with an application/xml or application/xhtml+xml mimetype, *or* you can format it HTML style and deliver it with a standard HTML mimetype.

      http://blog.whatwg.org/html-vs-xhtml

    2. Re:The Author is Not Completely Wrong by ronadams · · Score: 2, Interesting

      Intersting! That makes me a bit more hopeful for the standard. The whole idea is to move towards the "semantic web": say what you want, and render it in the most accessible ways possible. More and more sites and services are being presented in both a standard and mobile format, as well as several handicapped-accessible formats. More choices is a good thing.

      What I'm not seeing (perhaps because I haven't read the standard yet, or thought it through enough) is what HTML brings to the table that XHTML can't. Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?

      --
      Appended to the end of comments you post. 120 chars.
    3. Re:The Author is Not Completely Wrong by julesh · · Score: 2, Insightful

      Why bother with allowing the HTML mimetype, if it has no advantages other than it's what was done in the past?

      Because XHTML adoption has been slowed by a lack of backwards compatibility: you can't currently deliver XHTML in a standards-compliant way and expect it to work on anything other than a small minority of browsers. Sending the data with content type 'application/xhtml+xml' or whatever confuses the current installed base of internet explorer, making it an extremely bad idea, and probably unusable for general consumption sites for at least the next 5 years. See this excellent article for more reasons why this is a good idea.

  5. Cry for relevency by palladiate · · Score: 3, Insightful

    They can't let HTML die. The W3C would become irrelevant quickly if they stopped tweaking the language. Finally, even nomral users and web surfers have started to use HTML in web forums and MySpace (to usually garish effect, but still. XHTML just doesn't have the portability and ease of use that HTML did for things like forums.

    Take Fark for instance. After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

    Sadly, many useful old tags probably won't work in HTML 5, or not in any useful fashion. The W3C will most certainly mess with the language to bring it in line with XHTML conventions. They've already taken target="_blank" from us, what other useful gizmos are they going to futz with this time, bookmarks? You can pry my octothorpe from my cold, carpel-tunnel hands.

    Sure, CSS is damn useful and nobody generally liked frames. However, everything else about HTML was fine circa 1995. Maybe I'm being an old codger who still writes HTML pages without fancy crap like Frontpage, but I'm getting tired of their self-important crap. Breaking useful conventions just makes trying to communicate on the web that much harder. But, every time I tag font or add target="_blank", I do think about the W3C. Maybe that was just their goal all along.

    1. Re:Cry for relevency by HappyHead · · Score: 4, Informative

      After years and years, a critical mass of people are finally learning a, b, u, i, big, super, img, and other standard tags, most of which just don't work the same or at all under XHTML.

      Um, what? Seriously, the b, u, i and big tags are _exactly the same_ in XHTML. There was never a super element in HTML 4, it's just sup, and it's unchanged. The a tag does everything from HTML 4 the same way in XHTML. The only difference in it is that it's allowed extra attributes.

      Out of all of those things, the only one that's changed at all is the img tag, and that's only in two places - first, in XHTML you are required to provide an alt= attribute (instead of just strongly recommended like in HTML 4), and second, you have to close the tag properly, with a /> at the end.

      Frames are also still part of the XHTML spec.

      The font tag however, is gone and won't be missed any more than the blink tag was, by anyone other than frontpage (which absolutely loves adding thirty or so font tags in a row setting and unsetting the color 'white' from the text.

    2. Re:Cry for relevency by mikael_j · · Score: 3, Informative

      I think a reason that XHTML has not taken off is due to its unforgiving strictness. From what I understand, if you make a single mistake in XHTML the page will not work and for that reason it is not intended to be handwritten. But with HTML you often have different ways of achieving the same effect, such as with centering.

      Actually, one of the reason many people have picked up on XHTML is because it's a lot "cleaner" than "good" ol' HTML 4, the strict rules are one of the reasons for this, in XHTML you're not allowed to do stupid shit like "<i>foo and <b>bar</i> are both words</b>". And writing XHTML by hand is much easier than relying on some horrible WYSIWYG tool's generated code.

      This is the reason for the continuing appeal of HTML: its simplicity. My understanding that XHTML requires is that document formatting be separate from the content of the document. Yet sometimes is so much simpler to use a CENTER tag versus having to mark a section of text with a customized tag and then go into a style sheet to center a single section of text.

      Actually, formatting should be kept separate from the content for several very good reasons. Maintainability is a biggie as anyone who's ever had to redesign a static HTML website riddled with <font> tags. Extra points if it was made using a WYSIWYG tool that uses three or for tags when you only need one...

      Anyway, I for one hope that XHTML is path we stay on. And I think the main problem that XHTML+CSS has had is Internet Explorer and its craptastic handling of CSS (still crappy in IE7 although it's gotten slightly better).

      /Mikael

      --
      Greylisting is to SMTP as NAT is to IPv4
    3. Re:Cry for relevency by Derek+Pomery · · Score: 3, Insightful

      The only advantage font gives over using the style attribute (which gives far greater control) is that forum text sometimes disables CSS due to security concerns.
      This can be solved with moderately smarter CSS munging (whitelist the font-* stuff) or simply not allowing your users to use HTML in form posts in the first place - use bbcode instead.
      That can be munged by the server however it wants.

      Rest of what you were saying was kinda silly so I just focused on the one legitimate one.

      Oh, and target="_blank" - that's fair. The only alternative is javascript, which often is no alternative at all. On the other hand, I do find that target bloody annoying. Let me decide if I want to open a link in a new window, dammit. I'm not exactly sorry it is gone.

      --
      -- perl -e'print pack"H*","6e656d6f406d38792e6f7267"' /. ate my old sig. Bastards.
    4. Re:Cry for relevency by Bogtha · · Score: 2, Informative

      I think a reason that XHTML has not taken off is due to its unforgiving strictness. From what I understand, if you make a single mistake in XHTML the page will not work

      This is not true. There is only one class of errors that causes a fatal error, and that's when the document isn't well-formed. Invalid pages can still be served without tripping the mandatory error-handling.

      for that reason it is not intended to be handwritten.

      No, handwritten is still fine. Handwriting XHTML and then publishing it without any attempt to load it in a browser or check it for errors first is a bad idea though. But then again, it was a bad idea with HTML too.

      My understanding that XHTML requires is that document formatting be separate from the content of the document.

      No, this is also not true. It's considered best practice with both HTML and XHTML, both have document types that enforce this separation, and both have document types that don't enforce this separation. It's your choice.

      Yet sometimes is so much simpler to use a CENTER tag

      XHTML 1.0 has the <center> element type (not "tag").

      --
      Bogtha Bogtha Bogtha
  6. Don't you need power to be hardline? by JordanL · · Score: 3, Insightful

    What does XHTML fail to deliver that would cause WC3 to shy away from the previously hardline (and appropriate, IMHO) stance of "this is the new HTML, get used to it"?
    First, having reviewed some of the things in the draft HTML5 standard Opera and Apple have been working on, I have to say that it is indeed worth standardizing.

    Second, I wonder about this "hardline" approach. Who made the W3C gods of the internet? I mean, things need to be standardized, but they refused to do their job and standardize, and guess what, the industry got together and made another standardization board which was mentioned in the OP. The W3C can't hardline anything... they just format the direction we're going... they don't choose it, the industry does that.

    Go ahead, think I'm wrong, think the W3C should just stick it to all those web developers and browser companies that have spent years working around the group that is supposed to make their lives easier. The W3C is a paper tiger... they are completely at the mercy of everyone else. They can't hardline anything, much less something which was being standardized without them anyway.
  7. Re:W3C is aggrivating sometimes by sveard · · Score: 2, Informative

    Isn't the & character forbidden in XHTML links? You have to use the & entity, if I remember correctly. Sure, it's allowed in HTML 4.01, but not in XHTML (again, if I remember correctly)

  8. As a standard, HTML4 has failed by Nicolas+MONNET · · Score: 3, Interesting

    It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?

    Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS. Compare this to XUL's grid, vbox and hbox (yes, I know there are now CSS selectors in Firefox, Opera and Safari to do that)

    Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application. The idea to separate content and layout is nice, but the thing is, most content in pure-ist HTML+CSS is basically a bunch of div's and span's. It isn't much semantically richer than tablesoup.

    IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.

    1. Re:As a standard, HTML4 has failed by Bogtha · · Score: 2, Insightful

      It's too hard to implement, because there is no default way it should look like. There is no default, standard stylesheet. What height is H1 supposed to look like by default?

      I fail to see the difficulty. Headings aren't supposed to have a particular default height. What makes this difficult? Browser vendors can simply pick one themselves.

      Also look how hard and painful it is to implement a 3 column liquid layout with just HTML and CSS.

      It's trivial. It's a bit more complicated if you are talking about the subset of HTML and CSS that Internet Explorer supports, but there have been established techniques for years.

      Fact is, HTML is based on a page/document model, whereas, nowadays, HTML "pages" are most of the time "screens", part of an application.

      Part of Apple's philosophy is that applications should be based around the concept of documents, and they've been quite successful with it. A document model is not antithetical to applications.

      most content in pure-ist HTML+CSS is basically a bunch of div's and span's.

      This is not true. The idea is to use the most appropriate element type. <div> and <span> elements should only be used when there isn't something more suitable.

      IMHO, if I were to redesign HTML today, it would look a lot like Xul, with XBL2 and microformats on top.

      Please refer to the Rule of Least Power. It has all kinds of implications that make what you are suggesting a much worse idea than a document-based design.

      --
      Bogtha Bogtha Bogtha
  9. Re:W3C is aggrivating sometimes by Anonymous Coward · · Score: 2, Informative

    Quickly, and in the order you mentioned them...

    First, the italic and bold tags don't have semantic replacements either. You have the em tag, which is supposed to represent emphasised text, and the strong tag, which is supposed to represent strongly emphasised text. Following standard typographic conventions, emphasised text is rendered in italics, and strongly emphasised text is rendered in bold. These are not the same thing as the i and b tags. A screen reader would completely ignore those, but might use the em or strong tags to apply emphasis to the spoken version of a page. A non-graphical user agent might represent them in a different way.

    That's why the i, u, and b elements still exist in XHTML 1.1. They're just for italic, bold, and underlined text that has no semantic meaning. When writing something in a foreign language, for example, it's conventional to use italics. That's not the same as emphasised text - a screen reader should not emphasise the italic portion just because it's in italic. So you'd use an i element, or some other element with italic font styling applied to it.

    Of course lists aren't allowed in paragraphs. How could they be? If you're writing a paragraph, and you then start writing a list, have you not in fact finished the paragraph first?

    The HTML entities thing is from SGML.

  10. Get it on yer CV man! by Chrisq · · Score: 2, Funny

    Or as the CV writers would say: "extensive experience with HTML 4, XHTML, where he was responsible for delivering high quality web pages. Has studied the HTML5 standard and is confident that he will be able to maintain the same quality of delivery with this new technology."

  11. Re:W3C is aggrivating sometimes by brunascle · · Score: 2, Funny

    you, sir, are apparently the last person i should be listening to about HTML.

    it's a joke. laugh.

  12. Just what we need by Anonymous Coward · · Score: 4, Funny

    Another web standard for microsoft to ignore.

  13. Client side include please! by apathy+maybe · · Score: 3, Interesting

    Can I have a client side include this time around?

    Server side includes are very nice, except that they require a server!

    Client side includes have the potential to be much nicer! Two quick reasons: the first is when (X)HTML is used on (for example) CDs or similar, there isn't a server, and trying to make each page the same either requires fucking around with templates and software, or else using forms...; the second is it would work the same was as having external CSS, saves on download time, allows parts of the page to be downloaded only once and so on. (This second point would also make it really easy to offer different versions of the same page, include header and footer, and don't for example.)

    I know that JavaScript client side includes exist. They, however, are a kludge. They need JavaScript for one!, they might not work on all browsers, they might not be standard and so on. No thanks.

    A simple client side include that worked on the client side the same way the PHP include does, and I'll be happy.

    --
    I wank in the shower.
    1. Re:Client side include please! by apathy+maybe · · Score: 2, Interesting

      While that is a possibility, you could easily implement have it implemented so that the standard says that only things from the same place could be included (this way you couldn't include local documents in external documents and vis versa). Or you could just build a secure fucking browser that didn't do that sort of thing...

      --
      I wank in the shower.
  14. Re:A clean slate again by CastrTroy · · Score: 2, Insightful

    If the standard is "do whatever IE does" then how would Firefox ever actually be able to implement that standard. There is no published documents on how IE functions, so how is Firefox supposed to keep up with that. If Firefox emulated IE 6 perfectly, and then MS released IE7 and completely changed the markup (like they do all the time with their doc format), then Firefox would have to go through a lot of work, trying to figure out what MS was doing. the W3C standards exist because people want to use operating systems other than windows to access the web. They exist because they want to be able to rely on other vendors to provide a web browser that works. If anything I would blame MS for holding everyone back, when we could be creating beautiful webpages very easily, but instead it ends up taking twice as long because we have to deal with all the quirks in IE. Even if no other browsers existed, it would still take this long, because there is no documentation or definition of what IE will do with any give HTML or CSS code.

    --

    Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
  15. date tag? by ngunton · · Score: 4, Interesting

    I have suggested this before and always got shouted down for it... but as a web developer, I really wish they had simply implemented tags like 'date', which the browser would automatically know about as a date field and have its own built-in popup calendar for browsing dates, rather than having to either rely on plain text, lame dropdown menus, or else implementing yet another date popup javascript library (or including yet another javascript library which slows down the user experience even more).

    There are so many things that could be included in the html language if it weren't for the purists - dates, columns, real collapsable tree controls, counters, AJAXified controls that work without all the crap you have to do today to detect browsers... but no, the purists say "you can do it in this (incredible convoluted) css" or "you can implement this in javascript" (cue long convoluted "obvious" solution).

    Geeks are notorious for generalising and making everything nice and orthogonal, but they often forget that sometimes it's worth having something that makes life easier 90% of the time, even if it's technically possible to reduce it to a set of other constructs that already exist.

    Remember lisp, nobody uses it for real-world programming even though it's incredibly powerful. No, we use other languages that have lots of useless and redundant and inflexible syntax that makes the act of everyday programming easier and more straightforward most of the time. Are these inferior languages as powerful, expressive and all-encompassing as lisp? No. Are they easier for 99% of mere mortals to comprehend and use? Yes. If we had tags for controls that reflected the more dynamic nature of the Web today, even if many of those tags could be implemented in javascript, it would make pages smaller and faster 90% of the time (you could still implement it yourself if you really needed additional functionality).

    But, as usual, the purists are in control. We're not supposed to use tables for arranging pages; no, we have to use CSS to do that. So now we have a bunch of pages that don't render properly. But do they admit that it was a bad idea? No, it's the browsers' faults for crappy implementations. I don't get it, this religious mindset that says "You must do it one way, our way is the only way". "The TABLE tag is for tabular data only, don't use it for arranging the page". What crap. The table tag is amazingly useful, it works in all browsers, and no I don't mind in the least typing TR and TD everywhere. It's simple and it works. Yes, it's more verbose perhaps than the CSS version but at least it works in all browsers and doesn't end up with overlapping crappy text all over the place.

    1. Re:date tag? by jalefkowit · · Score: 3, Interesting

      "The TABLE tag is for tabular data only, don't use it for arranging the page". What crap. The table tag is amazingly useful, it works in all browsers, and no I don't mind in the least typing TR and TD everywhere. It's simple and it works.

      Unless your reader is blind or visually impaired, and using a screen reader, in which case your page will blow up spectacularly. Or if they try to access your page via a mobile phone browser. Etc., etc.

      Attention all web developers: please read this and think about how broad the range of web users truly is.

      (Oh, and if you don't give a flying fark about blind people or phones -- moving your style instructions from the HTML into CSS files will cut down on the total volume of info your users have to download by an order of magnitude, reducing your bandwidth costs.)

    2. Re:date tag? by 'The+'.$L3mm1ng · · Score: 2, Informative
      You got it.

      The input element's type attribute now has the following new values:

      • datetime
      • datetime-local
      • date
      • month
      • week
      • time
      • number
      • range
      • email
      • url
      HTML 5 differences from HTML 4
    3. Re:date tag? by Ancalimar · · Score: 2, Insightful

      Absolutely well-said. I understand all about the principle of separating content from layout, but frankly there's far too much arrogance to go around about HOW to implement that concept.

    4. Re:date tag? by Alomex · · Score: 2, Informative


      The problem comes when languages got religion. Lisp went from a list based language to list based syntax jihad. Ditto for Pascal and his strictly enforced strongly typed functions and Java and its everything-is-an-object global-variables-are-forbidden jihad.

      SGML as well as the newer versions of HTML are in a format-is-100%-orthogonal-to-content jihad.

      Notice that all of the principles listed above are good and correct. The problem comes from emforcing them too strictly.

  16. Re:A clean slate again by HappyHead · · Score: 3, Insightful

    After Mosaic faded out, Netscape was the dominant browser, . . . Microsoft IE took over as the dominant browser.

    The funny part of that is, Netscape was a re-write of Mosaic by the people who made it in the first place. They did Mosaic as a school project, and then said to themselves, "You know, we could probably make money with this, if we fixed all the things we did wrong!" Mosaic was kept by the University it was written at, then spun off to a company named spyglass, which was bought by Microsoft, and re-named to IE. Thus, Mosaic started the web revolution, Netscape was a side-track, and then Mosaic came back under a different name, with much wealthier owners who could afford more coders to work on it. Netscape of course, tried to keep up with the feature creep, but with less financial backing, and less people working on it, their code soon turned into an un-manageable mess (which is why it was completely scrapped and re-written from scratch for Firefox) - just goes to show that for large projects, maybe those project managers really do serve a purpose.

    That of course, is where the problem with browser compatibility really came in - Microsoft wanted more more more features, and they wanted them now now now! So they pushed their developers for speed instead of sanity/security/stability, and that resulted in dumbness like allowing ActiveX to be embedded inside of web pages, and the completely screwball syntax for adding filters to CSS code. Admittedly, some of the things that were added were good, and some were useful (the BGSOUND tag for example, is much easier to control from javascript than the EMBED tag), but the vast majority of the "new features" introduced to IE this way were either pointless, needlessly convoluted for the developer, or just plain harmful. (As the many people who had their bank accounts raided by ActiveX malware, or their computer's power turned off by visiting a prank site will agree.)

    Since IE was windows-only for the most part, Microsoft was free to include as many proprietary things as they wanted, slap copywrites, patents, and all sorts of other protections on them, and basically make it impossible for people on other platforms to add those features to their browsers. It's important to remember that in the early days of the internet (when Mosaic and Netscape first came out, and thus when the actual mindset regarding their feature paths was determined), Windows only barely supported internet access at all, and was in the extreme minority of systems on the internet, which were mostly Unix based. (Yes, Microsoft's browser did technically originate on a Unix system, I've used the original first version of Mosaic when it was first released, on a black-and-white X Terminal attached to an SGI Challenge system.) That meant that while Microsoft was free to make things that worked only on their system and call it good, nobody else could get away with it, as most of their userbase would be left behind.

    Besides, adding a new spec like HTML 5 will not fix the browser gap - even now, as new technologies are coming out and new standards and specs are being released, the browser developers are still putting their own unique and incompatible spins on how things work. Ever tried to embed video in a web page and have it be completely XHTML compliant? You can do it in Firefox. You can do it in IE too. You just can't do it in both with the same code, because they interpret the specs differently. That has nothing to do with IE needing to support backwards compatibility at all, since backwards compatibility relies on a different set of tags completely. It also has nothing to do with Firefox's developers being immature and combative, since they took the simpler and saner route of the two, which didn't involve ActiveX, or embedding the Microsoft Media Player. (Yes, ActiveX in web pages is still bad, even if it can't get at your bank software or power off register anymore.)

  17. Re:Great by ajs318 · · Score: 3, Insightful

    Why do you Brits always insist on using French spellings?
    Because some of our language is borrowed from French, and we retain the spelling and pluralisation rules of the donor language until the word earns a new meaning; in which case, when used in the new sense, it's considered to be an English word which happens to share its spelling with a Foreign word, so the usual English pluralisation rules apply. Hence beetles have antennae, but radios have antennas. Unless they're small, covert transmitters ..... because then they would be bugs. ( Chad image, caption "What no rimshot?")

    Anyway, the fact remains that it was us who stole ..... er ..... borr ..... er ..... invented it. You septics were the ones who had to change it. I'll grant that there might have been more pressing concerns than a copy of the O.E.D. when the Mayflower first set sail out of Plymouth -- and the passengers' apparent inability to think of a better name for the place where they had just landed than the place where they had just come from is evidence for that. But there's no excuse for that sort of behaviour nowadays.
    --
    Je fume. Tu fumes. Nous fûmes!
  18. Re:I hate ACs by Xest · · Score: 2, Insightful
    Hate to say it but the AC is right, most your comments seem to be based on a lack of understanding about XHTML and what HTML is.

    "Indeed they do, but in 10 years if every web board declares XHTML strict convention, there's plenty of handy stuff that no longer works, and has no replacement."

    Got any examples of what you can't do in XHTML that you can do in HTML? At the end of the day you can always embed CSS directly into your code when using something like a form on a forum using the style attribute, for example:

    Blah blah



    It ain't good practice, but backwards compatibility isn't necessarily about good practice because sometimes the things you're being backwards compatible with weren't good practice to start with.

    Furthermore, you talk about additional functionality being missing from XHTML that's available in HTML but again, this misses one of the core points as to what XHTML is about, the X in XHTML means extensible, XHTML is designed to be a solid core of HTML markup that's embedded in the XML rules, so that any application can define a new doctype with new tags to do new things as needed. HTML doesn't have this option without simply breaking the standard.

    Many of your comments also suggest you don't understand the concept and importance of separation of code, content and presentation and what this means. The W3Cs recommendations aren't about creating new standards to stay relevant, they're about pushing standards that improve:

    - Accessibility
    - Extensibility
    - Compatibility

    I can't see how this is in any way a bad thing for anyone other than those who simply can't be arsed to spend 10 minutes finding out what's different!
  19. Adoption more important than technology by Geof · · Score: 2, Interesting

    The whole idea of XHTML was to provide a segueway into an altogether new way of distributing content. . . . What does XHTML fail to deliver . . . ?

    It has failed to deliver adoption. We can argue about why (IE's lack of support, no compelling features), but the fact remains that a standard is worthless unless it actually becomes, you know, standard. Standardization is less a technical matter than a social one. Most of HTML's value derives not from its technical strengths, but from its ubiquity.

    To date, the new way of distributing content that you cite has not succeeded. XML was advertised as a solution to interoperability, but in reality it solved the easy problems - e.g. syntax, not the hard ones - e.g. agreement about meaning. XHTML's ambition to mix multiple XML vocabularies in a single document is worthy (and in the longer term worth pursuing), but the subset of vocabularies that would be widespread enough to matter would be small.

    What HTML 5 offers, and what XHTML did not deliver, is further agreement about meaning. It provides standard ways to do what people are already doing. For example, it specifies unambiguous ways to mark up navigation menus and time. These are small things, but small things matter. Look at HTML's declarative links - also a small thing: they have made possible applications like Google (imagine if links were all scripted instead!).

    Meanwhile, HTML 5 can be serialized as XML. Why not simply make it XHTML 5? Again, we can argue about the relative benefits, but the best answer is that it would be a barrier to adoption - and thus to the central benefit of standardization.

    Despite all of this, I certainly wouldn't call XHTML a failure. If you consider it outside the browser it is very useful (for server processing, embedding in Atom, etc.). In the medium to long term, it seems likely to gain in popularity. At this point, though, it is clear that non-XML HTML serialization is not going to go away. I think there are good (social) reasons for that; regardless, making that HTML better is a good thing.

  20. HTML 5 Won't Matter... by Nom+du+Keyboard · · Score: 2, Informative

    HTML 5 won't matter until Microsoft almost handles it in Internet Explorer. I'd guess that might happen 5 years after the standard is adopted.

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
  21. Instead of HTML 5, we need XHTML design process v2 by mikelang · · Score: 2, Interesting

    I see this a step back.
    I've already gained immense advantages by using XHTML in my apps,
    and I see it XHTML+CSS combo is much better supported than HTML+CSS.

    The only problem is with XHTML design process, that is painfully slow,
    with unnecessary emphasis on 'modularity'.

    Just give me a concise specs of XHTML 2.0, CSS 3.0 so that they'll include
    editing. But to do this, W3C would have say bluntly that the problem with XHTML
    was with the process and people, not with the technical side. (The same happened
    with never-completed CSS 3.0 and rarely-fully-implemented XForms.)

  22. Or "Browser makers ignore standard; make own" by leighklotz · · Score: 2, Interesting

    W3C was formed to create a "consortium" not only of browser makers, but also tool vendors and other major HTML users. The W3C explicitly differed from IETF in having members pay dues (and hefty ones for big companies), and in having more structure, though still less than real standards bodies such as ISO.

    One of the goals was to make sure that all the players had a voice, not just the browser vendors.

    Well, everybody got together and decided to design something that had clear semantics, well-defined behavior, and was modular. CSS came out of this, and XHTML came out of this. Netscape didn't like CSS, so Microsoft did. Then Netscape capitulated on CSS, then it folded.

    Then nothing happened. For a long, long time. (You may recall this period.)

    Opera was founded by Hakon Lie Waum, and it found a great niche market in embedded browsers, but getting there required it to be "IE5 bug compatible," at a tremendous engineering effort.

    Then a bunch of other companies came along and started making browsers and tools and middleware and all sorts of stuff that implemented the plethora of W3C modules, and started to target enterprise customers and mobile phone vendors with products implementing XHTML Basic (which replaced WAP/WML in short order), SVG (which made Flash be stillborn in the phone market), XForms (which appeals mostly now to vendors who can control the middleware, but gives them the AJAX advantage without browser dependence). It became clear to the now old-guard browser vendors that if they didn't do something to enshrine "IE5 bug compatibility" in HTML, it was going to be subsumed by new, easier to implement standards, probably starting from the cell phone and enterprise markets, but pushing out into full consumer/open web markets from there.

    So, they created a crisis by starting their own parallel standards group and threatening W3C. The keep this threat up, and use the same kind of populist appeal and divisiveness we see in US politics to stir up hatred and polarization, all the while keeping the parallel work on the forefront.

    All I can say at this point is that you should be prepared for JavaScript to become the language of expression on the web, with markup languages being reduced to a graphics library for scribbling on screens.

  23. Re:It's CSS thats the problem by porneL · · Score: 2, Informative

    What CSS needs is a way of defining columns, or a way of gluing DIVs together to it's easier to stack them side by side without running into all the problems you get if you float them.

    You mean like display:table-cell that's part of CSS since 1996, and works reliably in every browser except IE?

    It also REALLY REALLY needs variables.

    For constants use server-side processing (color:%foo% is trivial to implement). For really variable-variables you have DHTML and W3C DOM2 Style.

  24. Re:I think you'll find by FoamingToad · · Score: 2, Insightful

    That's "bastardised", dear boy :-)

  25. English doesn't borrow from other languages... by DragonHawk · · Score: 2, Funny

    Because some of our language is borrowed from French...

    Obligatory: "English doesn't borrow from other languages. English follows other languages down dark alleys, knocks them over, and goes through their pockets for loose grammar." -- Author unknown

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.