Forgot your password?
typodupeerror
The Internet

Is It Time for a 'Kinder, Gentler HTML'? 382

Posted by Zonk
from the because-the-current-one-is-pointy dept.
jg21 writes "Via the Web 2.0 Journal, a worthy link to Yahoo! Architect and JSON inventor Douglas Crockford's latest ideas to fix HTML. He's categorically not a fan of HTML 5, which is still just an Editor's Draft and not endorsed by W3C yet. Crock puts forward ten ideas that in his view would provide extensibility without complexity, adding that the simplification of HTML he is proposing would reduce the cost of training of web developers and incorporates the best practices of AJAX development. From the article: 'The problems with HTML will not be solved by making it bigger and more complicated. I think instead we should generalize what it does well, while excising features that are problematic. HTML can be made into a general application delivery format without disrupting its original role as a document format.'"
This discussion has been archived. No new comments can be posted.

Is It Time for a 'Kinder, Gentler HTML'?

Comments Filter:
  • Not Impressed (Score:5, Insightful)

    by AKAImBatman (238306) <akaimbatman@@@gmail...com> on Friday November 30, 2007 @11:04AM (#21532525) Homepage Journal
    You can read his proposal in full over here: http://www.crockford.com/html/ [crockford.com]

    Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end. What you'll probably find is that he hasn't really solved any of the major issues plaguing HTML or even thought through many of the problems and use-cases that HTML 5 is trying to solve. In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."

    Meanwhile, he still leaves the problems of consistent parsing, semantic meaning, multimedia presentation, and a whole host of other issues unaddressed. Which means that his "design" fails to compete with the intended purpose of HTML 5 at even the most basic level.

    I have the highest respect for Mr. Crockford, but my opinion is that he should study the reasons behind HTML 5 a bit more carefully, as well as solicit a bit more feedback from the community before attempting to push a non-solution to their problems. Best of luck to him. :-)
    • Re:Not Impressed (Score:5, Interesting)

      by phoebusQ (539940) on Friday November 30, 2007 @11:10AM (#21532609)
      I think you may be mistaking a page of conceptual ideas for a complete design. Even if the submitted article tries to pass it off as such, these are just a set of proposals that Crockford has been discussing. This particular page is more of a list than anything; it does not contain his entire concept or justification. He does a great job of discussing some of these things in person.
      • Re:Not Impressed (Score:4, Insightful)

        by suv4x4 (956391) on Friday November 30, 2007 @12:52PM (#21533951)
        I think you may be mistaking a page of conceptual ideas for a complete design. Even if the submitted article tries to pass it off as such, these are just a set of proposals that Crockford has been discussing. This particular page is more of a list than anything; it does not contain his entire concept or justification. He does a great job of discussing some of these things in person.

        Yet, if I was involved in the HTML5 drafts I'd be insulted. He does dismiss an actual complete design (HTML5), in favor of few vague niceties and abstract wishes that don't change the big picture even a bit.

        Does it really matter so much if we'll use DOCTYPE or version="5" attribute to specify the document type?

        HTML5 is trying to prepare the web to handle robust web applications, and he's there dissing it and saying "let's instead just drop some legacy features, put some syntactic sugar on it and call it a day".
        • Get rid of all those sharp, pointy brackets around tags! Ouch!
          • by F1re (249002) on Friday November 30, 2007 @05:32PM (#21538131) Homepage Journal
            No way! Those are aerodynamic and make the html travel faster through the pipes!!
    • Re:Not Impressed (Score:5, Interesting)

      by hansamurai (907719) <hansamurai@gmail.com> on Friday November 30, 2007 @11:12AM (#21532637) Homepage Journal
      Seeing as you seem to be involved with the HTML 5 proposal, could you explain this line from the FAQ to me:

      When will HTML 5 be finished?
      It is estimated that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004.

      http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F [whatwg.org]

      That seems like a really long time for something like this to go through, even for something as massive as the web standard.
      • Re:Not Impressed (Score:5, Informative)

        by AKAImBatman (238306) <akaimbatman@@@gmail...com> on Friday November 30, 2007 @11:23AM (#21532771) Homepage Journal

        Seeing as you seem to be involved with the HTML 5 proposal

        If you count arguing on the mailing list a few times and coming up with a new Canvas adapter (still WIP) for IE, then I suppose. :-)

        When will HTML 5 be finished?
        It is estimated that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004.

        Reading that FAQ entry in its entirety helps clarify the issue; at least for me. The WHATWG is being pragmatic about how long it will take them to both get a 100% complete standard (it has continued to evolve, even after being submitted to the W3C) and get everyone on board with it. People don't realize quite how long it took to get the variations of CSS, DOM, and HTML4 standardized and implemented. They've been available for over a decade, but we're only reaping the benefits of these standards now.

        That being said, the W3C does expect parts of the specification to be implemented sooner rather than later:

        The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis. Sections like the Link Types, which is relatively simple, isn't going to take long to become interoperably implemented. In fact, Mozilla is already implementing the new autodiscovery features for Firefox 3.0, and it shouldn't take long for places like Technorati, Bloglines, etc. to implement follow.

        In result, it really doesn't matter when the HTML 5 standard is fully realized. We will be (and already are) reaping the benefits of it long before it's 100% complete.

        Of course, they did get it submitted to the W3C ahead of schedule. And the W3C is taking it more seriously than originally expected. So don't be surprised if they're ahead of schedule on completion. ;-)
      • Re: (Score:3, Insightful)

        by nine-times (778537)
        Is that a typo or joke? I don't get it. If it will really take that long, wouldn't it make sense to set some intermediate goals first? Like whatever they're making HTML 5, call it HTML 8, and set a roadmap for the intervening years?
      • Re: (Score:3, Funny)

        by Randle_Revar (229304) *
        <voice type="Foghorn Leghorn">It's a joke, I say it's a joke, son!</voice>
    • by deniable (76198)
      Pretty much, but he also mentioned making custom tags and attributes first class citizens for CSS. Won't this be fun when text and style-sheets get separated. It's all the fun of xml combined with all the fun of xml.

      OK, here's one. comes before , but if you use then we ignore doctype. OK, a forgiving browser will know what you want, but he then goes on to say that browsers shouldn't be tolerant because it causes too many security problems. It's a bit after midnight and my brain hurts.
      • by snoyberg (787126)

        I think the thing you missed was:

        <html version=5>
        If you see version=5, then treat it as HTML 5. If you see a DOCTYPE, treat it as something else. Seems simple enough to me.
      • by quanticle (843097)

        Could you please rewrite that with extrans mode? It looks like your examples got munched...

    • Re:Not Impressed (Score:4, Interesting)

      by aug24 (38229) on Friday November 30, 2007 @11:17AM (#21532707) Homepage

      Make sure you have about 2 minutes to spare. You're going to need about that long to read it from beginning to end.

      "Let's get rid of HTML features that I believe cause problems."

      Looks to me like you only read for one minute ;-)

      To give the limited amount of credit due, he does go on to some decent sounding suggestions. Nothing in there is actually unreasonable, some things sound like a good idea (UTF-8, browsers stop trying to correct for crap pages if version>=5). I'm still reading the stuff on Modules, or will be when the server responds :(

      Perhaps someone else can try to fix the other things you mention.

      Justin.

    • Re:Not Impressed (Score:4, Interesting)

      by alan_dershowitz (586542) on Friday November 30, 2007 @11:32AM (#21532875)
      I respectfully disagree when it comes to CSS. Items like consistent default styling for CSS are a real problem. Simple tasks like setting a few margins and setting the default font takes ugly CSS that eats up significant processing power doing matching on items. In fact, CSS is junk and should be replaced with something that is actually useful to graphic designers. Something like XHTL-strict plus a separate XSLT and a REAL layout language.
      • by MightyYar (622222)
        I'm mostly a web user, though I've done a few projects. When putting those projects together, I feel your pain - layout is a royal PITA... especially getting things to look nice on various platforms and browsers.

        But as a USER, the things you describe scare me a bit. I like being able to set and change my fonts. I like being able to view websites in a text browser or on my phone (even if the designer didn't plan for those uses). When I'm browsing while connected to my phone, I like to be able to shut off ima
        • Re: (Score:3, Interesting)

          The content is still delivered in XHTML, so you can (or should be able to) style it with your own stylesheet (either XSLT or CSS or whatever you want.) This can be done today, XML can be delivered with an XSLT and the browser will render it. The problem is that the only choices you really get in the browser for output is plain text, HTML, HTML+CSS, or SVG.

          What I am arguing for is a styling language that doesn't suck balls. I've been doing CSS since forever, and I'm finally completely fed up with it. It solv
      • In theory, setting the default font only takes "body { font-family: ... }". Most of the ugly CSS that I've seen comes from having to write something that works in Internet Explorer and everything else.
        • Re: (Score:3, Interesting)

          The two problems are that setting font attributes are done independently for things like table elements, labels, headers than from paras or spans, and also that there is no explicit way to get the browser to start from a default "unstyled" state before you start adding you own style. Implementation differences themselves make styling using CSS that much more miserable.
    • by Anonymous Coward
      HTML is like Captain Hook, He does not understand "Kinder" or "Gentler". This is blasphemy! The Internet needs monsters like this around to fight. What web developer has not shouted "My Kung-Fu is Strong!" when they finally tricked Internet Exploder into properly displaying CSS code after a few days of effort? Only to do it all over again each time Microsoft rolls out a new version of Exploder.

      What would the world be without Captain Hook!

      • by SQLGuru (980662)

        What would the world be without Captain Hook!
        Captain Morgan is a much friendlier captain.

        Layne
    • Re:Not Impressed (Score:5, Interesting)

      by Fozzyuw (950608) on Friday November 30, 2007 @11:47AM (#21533095)

      he hasn't really solved any of the major issues plaguing HTML

      Actually, he's proposing MORE problems. Here's my take...

      No more doctypes

      Why? Adding a "version" attribute it just going to break compatibility. The "web" has enough problems with compatibility, lets not inject MORE. Doctypes work fine. Sure, it's long and doesn't appear to make much sense reading it, but... if it's not broke, don't 'fix' it.

      There is only one scripting language allowed on a page. This is to simplify the addition of new languages to the browser. It also paves the way for replacing JavaScript with a secure programming language.

      I'm sorry but the auther hasn't presented any compelling reason why this is a 'good idea'(tm) and I can think of several reasons this is a 'bad idea'(tm). Do have I have to mention active X, proprietary languages, and 'broken' sites because of it? Then the need for Web.Devs. job skills increase significantly and become much more cumbersome.

      No more framesets, frames, or iframes. The security properties of these were problematic. Instead we'll have modules.

      Hmmm... I don't like frames per say. I don't use them. Though, I don't see how modules are going to make things better or easier but more complex. A frame was simple. A window in a window. That's simple. If Developers abused them, it's the developers fault, not the language for having it. With "AJAX" and Flash video, I'm game to just remove frames all together.

      The default CSS content needs to be standardized.

      It already can be done and this is not the responsibility of HTML. This is as annoying as forcing ones religion on someone else. I'm not going to tell Microsoft they have to use Mozilla's default CSS. Or Apple to stop using their pretty buttons in Safari. Forget it. It's a non-issue. CSS RESET already exists, and developers need to just be educated. Design topics don't have a place in HTML.

      The only character encoding permitted in HTML 5 is UTF-8

      While I want to say "I agree with that" because that's what I do, I think, again, "only" is not the right choice. Can we predict the future? Will UTF-8 be suitable 'forever'? Funny, computers original "only" supported latin characters. That wasn't a good idea. "only" supporting UTF-8 is also a bad idea, but I would like to see it used a default.

      Browsers should not perform heroics to try to make bad content displayable

      I agree with this.

      The tag form is allowed, but not required for
      or .

      I 100% disagree. Standards are standards. If we don't want browsers to "perform heroics" on correcting 'bad code' then lets not give people confusing "standards" of "it's ok to it like this... or like this... or this is 'ok' too!". No.
      and . Tags are tags and they have a function. There are no "special" children. But I do think [script] needs empty tag support.

      CSS can be used to style custom tags.

      Agree.

      mymenubar {display: div; width: 100%;}

      What's wrong with "display:block"? If you want a [div] tag use one. If you want to make your own tag name, then don't try to make it a [div]. Div's are "block" elements. If you want a block element then "display:block".

      Custom Attributes

      I agree. But are we talking about HTML or JavaScript now? And why are you talking about JavaScript when you already said you don't want to support JavaScript? I'm confused as to your intentions.

      That's It

      Kudos for trying, but I think you missed the target.

      Cheers,
      Fozzy

      • by phasm42 (588479)

        Will UTF-8 be suitable 'forever'?
        Yes, it can encode all unicode characters. The only drawback is that some languages are better suited for UTF-16, which may make UTF-8 encoding longer than needed.
        • Re:Not Impressed (Score:4, Interesting)

          by Kadin2048 (468275) * <slashdot DOT kadin AT xoxy DOT net> on Friday November 30, 2007 @12:43PM (#21533827) Homepage Journal
          Not everyone is happy with Unicode.

          In particular, their treatment of some Asian glyphs has some folks absolutely up in arms (cf. Han unification [wikipedia.org]) and it falls short of what I'd call truly 'universal.'

          Start mandating UTF-8 and you're going to have people breaking the standard in favor of national charsets faster than you can say "cultural imperialist."
          • Re:Not Impressed (Score:4, Insightful)

            by m2943 (1140797) on Friday November 30, 2007 @10:00PM (#21540507)
            In particular, their treatment of some Asian glyphs has some folks absolutely up in arms (cf. Han unification) and it falls short of what I'd call truly 'universal.'

            The "controversy" about Han unification is inane nationalistic posturing on the part of those Asian nations; it has no basis in either linguistics or practice. It's as if every European nation wanted their own codes for the Roman alphabet.

            Start mandating UTF-8 and you're going to have people breaking the standard in favor of national charsets faster than you can say "cultural imperialist."

            "Han unification" is not "cultural imperialism", it's simply applying the same design principles to Chinese characters that were applied to other languages. People object to Han unification for a variety of reasons, most of them related to nationalism, arrogance, or simply ignorance. For example, there are lingering animosities between Japan and China. And many traditionalists in Asia think of the West as inferior and would have found grounds for objecting to any character set not designed domestically.

            The technically correct thing to do is to keep Han unification, just like all other scripts are unified, and address problems with specific glyphs as they come up.
        • by suggsjc (726146) on Friday November 30, 2007 @12:45PM (#21533863) Homepage
          Hold on, I know that the web is old, but still. UTF-8? I think most every user that I know has a 32-bit computer, so if we are going to be changing things, go ahead and bump to UTF-32. But even that might now be enough since those fancy 64 bit computers are starting to gain traction. I say let the web be the technology leader and be the first to start using UTF-128. If you combine that with IPv6, every cell on earth can have a unique IP address as well as their own symbol...take THAT "the artist formally known as Prince"
    • Re: (Score:3, Insightful)

      by Hatta (162192)
      In fact, his entire "design" can be summed up with the following sentence: "Let's get rid of HTML features that I believe cause problems."

      What's wrong with that? They shouldn't be trying to shoehorn features into HTML that aren't in line with its purpose, marking up hyper text. If you want a rich, network capable, multimedia enabled application framework, write one! Don't ruin my HTML.
      • Re: (Score:3, Insightful)

        by AKAImBatman (238306)

        What's wrong with that?

        Very simple.

        "Let's get rid of HTML features that I believe cause problems."

        Is not the same as:

        "These HTML features have been empirically shown to cause more problems than they solve. Deprecating them will therefore improve the quality of the standard."
    • Hey, I think we should just mark all our documents the way God intended - Wordstar dot commands.
    • by BlowChunx (168122)
      ... semantic meaning...

      Does that translate into the "meaning of meaning"? I had philosopher friends who kept asking if "There was any there there". Is this something similar?

      No wonder HTML is in trouble.
    • XHTML 2 (Score:3, Informative)

      by booch (4157) *
      In some ways, his proposal sounds a bit like XHTML 2 [wikipedia.org]. Not so much the details, but the idea of breaking from the existing spec, and trying to simplify things. And to put it bluntly, XHMTL 2 has not exactly been taking the world by storm. It seems that nobody really likes it, so it has not gotten much support. It's unlikely that it will ever make it out of draft status.
  • I especially like the "module" concept, which could help to standardize, secure, and simplify a lot of AJAX and similar concepts.
    • Re: (Score:3, Informative)

      by AKAImBatman (238306)

      I especially like the "module" concept

      There is probably some irony in the fact that inter-document communications [whatwg.org] feature in HTML 5 would allow him to implement his "module" concept in an HTML 5 compliant browser. In fact, the HTML 5 proposal is actually superior to his "module" proposal in the method it uses to receive messages. Rather than polling for a JSON packet (which could be costly in both processor time and responsiveness), the HTML 5 solution adapts the existing DOM 2 event model to make the messa

  • I concur, just make it as simple as possible, as non-error-prone as possible. Any of the stuff that "kinda works" should be in a separate spec, i.e. the HTML-KW (kinda works) specification.
  • Yeah: we should make it more like C++, because HTML is just too hard.
    • Re: (Score:2, Funny)

      by Octopus (19153)
      I've said it a million times...

      Tables need pointers!
    • Re: (Score:3, Funny)

      by rucs_hack (784150)
      Nah, what we want to do is enforce the old 'AngelFire' instant web page as a worldwide standard. all backgrounds must be either animated or florescent, Text must be HUGE, all in caps with again, shocking bright colors only (preferably green on a flashing background).

      I'm telling you, enforce this as a standard and the internets will be perfect...
      • Nah, what we want to do is enforce the old 'AngelFire' instant web page as a worldwide standard. all backgrounds must be either animated or florescent, Text must be HUGE, all in caps with again, shocking bright colors only (preferably green on a flashing background).
        You must own stock in MySpace.
  • As an engineer, the words "kinder gentler" don't mean much to me. I mean, they do when you're talking about other things like leaders or puppies but what the hell do those attributes have to do with a communication standard like HTML?

    From the part of the proposal entitled "That's It" I learn:

    These changes significantly improve the reliability, security, and performance of HTML applications. The simplification of the language reduces the cost of training of web developers. It incorporates the best practices of Ajax development. It provides extensibility without complexity. The deltas from HTML 4 are generalizations and reductions, which should make browser implementation more straightforward. This is particularly important for mobile devices that cannot tolerate the power demands of complex platforms. The only new feature here is the module, which is critical for security. Modules makes safe mashups possible.
    So what I'm reading here is you think these changes make it more "straightforward mobile-friendly?"

    I am by no means an expert on this but I do code web applications for a living. I will tell you that these changes do not necessarily "improve reliability, security and performance" of HTML. You are suggesting changes with mobile devices in mind and the developers in mind. Adding another getElementsByTagName method to Javascript will make it easier for developers but over use of that will only make searching the DOM more intensive and lead to worse performance. And remember the original intent of HTML! If you are complaining that mobile devices can't render what a desktop can, perhaps it's time to look at a mobile-HTML standard and either you put a cross translator on the mobile browsers or you entice developers to make two sites. I'm not opposed to these ideas, I just don't see how they're going to really help anything but the specific users this guy has in mind. They certainly wouldn't help me at all or provide a better user experience for my end users.

    This is ridiculous. You are attacking the wrong target here, you should be attacking the browsers that don't behave according to standards like the cowboy Internet Explorer browser that sometimes does whatever it wants. Many nights I have spent hacking code that checks what browser is being run and behaves differently because it's Internet Explorer and not "everybody else."

    Also, a bit offtopic but I Googled "kinder gentler" in an attempt to understand its meaning [google.com] and for some reason the first result was the White House page for George Herbert Walker Bush. What the hell?
    • by ByOhTek (1181381) on Friday November 30, 2007 @11:21AM (#21532755) Journal
      One that eats babies for breakfast, at minimum.

      It strikes me that would be the route to go to get rid of all these crappy, poorly done pages.
    • Re: (Score:3, Insightful)

      by Alzheimers (467217)
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      As an engineer, the words "kinder gentler" don't mean much to me. I mean, they do when you're talking about other things like leaders or puppies but what the hell do those attributes have to do with a communication standard like HTML?

      Easy to use. Forgiving.

      Compare YAML (and JSON) to XML, S-Expressions, or (shudder) HTML. YAML's syntax can be stated clearly in about 20 lines of text. JSON's syntax is a subset of that. And yet, YAML is very forgiving. XML requires dozens (or is it hundreds) of pages. H
    • by Red Flayer (890720) on Friday November 30, 2007 @11:37AM (#21532953) Journal

      Also, a bit offtopic but I Googled "kinder gentler" in an attempt to understand its meaning and for some reason the first result was the White House page for George Herbert Walker Bush. What the hell?
      Wow. You must be young, or I must be old.

      GHWB (not to be confused with GHB, which can be metabolized from certain toy paints) was made fun of a lot for one of his campaign mottos, which was "It's time for a kindler, gentler America." Dana Carvey made gravy from spoofing GHWB on SNL, and the "kindler, gentler America" bit was an instant classic.

      And this brings me around to my point.

      This is ridiculous. You are attacking the wrong target here, you should be attacking the browsers that don't behave according to standards like the cowboy Internet Explorer browser that sometimes does whatever it wants.
      That's a separate problem. Admittedly, I'm not a web developer, but it's rather obvious to me that there are very useful changes in HTML5, and ignoring the possibility of improving web standards in favor of attacking non-compliant browsers is not smart. Far better to address both problems -- besides, how constructive is "attacking" non-compliant browsers? In my experience, attacking others is usually not constructive.

      In short, I feel like you're making a big statement about best policy with a limited understanding of what's going on. I know for certain that I don't have full knowledge here -- but I'd never claim I know the answer.

      But, you know, it's always nice to karma-whore by ripping IE. Sure, IE development may make extra work for you -- but then again, you're being paid for that work. Why not be happy that "that cowboy Internet Explorer" helped you find gainful employment?
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        But, you know, it's always nice to karma-whore by ripping IE. Sure, IE development may make extra work for you -- but then again, you're being paid for that work. Why not be happy that "that cowboy Internet Explorer" helped you find gainful employment?

        Nobody who's ever suffered through the demon that is IE would say that. You know, there's a reason I (and my coworkers) hate it, apparently you just think we hate it because it's fun.

        You know, it's fun to finish a javascript method in Firefox with Firebug there to help you debug and step through it. You think it's fun to watch IE bitch about only God knows what and not work. Or simply not show anything at all if you're trying to evoke a method on a javascript object that isn't valid. No feedback,

        • I have a job to do,

          You have a job because there is work to be done. Less work == fewer jobs available. The markletplace requires unpaid overtime because there are people, such as yourself, willing to supply that labor. I don't undertand what the issue is, we'd all like our jobs to be cookies and roses -- but we all deal with things we'd rather not have to. I'll still maintain that attacking something/someone is less constructive than alternative efforts.

          As for wasting time on IE hacks and rather spendi

      • by gutter (27465)
        Ripping IE is not "karma whoring", it is a simple statement of fact. It is extremely common to generate a layout in Firefox, have it work perfectly in Safari, and have IE screw it all up. When you examine the reason for the broken layout, it is inevitably because IE 6 either didn't implement a feature or mis-implemented it according to the standard.

        No, I am not happy for the extra work. I don't work on salary, and I do have to explain to my boss why a simple feature that should have taken an hour actuall
      • Re: (Score:2, Informative)

        by E++99 (880734)

        GHWB (not to be confused with GHB, which can be metabolized from certain toy paints) was made fun of a lot for one of his campaign mottos, which was "It's time for a kindler, gentler America." Dana Carvey made gravy from spoofing GHWB on SNL, and the "kindler, gentler America" bit was an instant classic.

        IIRC, it was from a state-of-the-union address rather than a campaign motto. I remember thinking, "Kinder gentler? I want a more kick-ass America!" Thank God he had a son!

    • One of his suggestions is for browsers to not be forgiving when it comes to bad HTML. I've been saying this for years and it can definitely help with performance. One reason for browser bloat is the extra flexibility to handle bad HTML. If the parser and display elements were simply strict they'd be smaller and faster. I don't believe a browser should make every possible effort to display every page correctly. Either the document is right or it's wrong.

      Of course the specs themselves need to be less ope
  • by ThinkingInBinary (899485) <thinkinginbinary&gmail,com> on Friday November 30, 2007 @11:09AM (#21532597) Homepage

    This sounds great, but I feel that by turning HTML into a more well-formed document (i.e., XML instead of SGML), the W3C did browser writers and developers a service. Please, let's not go back to the "guess if there's a closing tag" game. I don't mind the script, frame, module, CSS, encoding, and entity changes, but the custom tags/attributes and looser format limits (quoting, ending tags) seem bad.

    • by WebCowboy (196209) on Friday November 30, 2007 @12:55PM (#21534003)
      Honestly are HTML authors really that damn stupid and lazy that they can't manage to write compliant XHTML 1.0? Really, people, it ISN'T THAT BAD. Yes, there is a lot of complex stuff and does namespaces and its all modular and things, but you don't need to use all of that! Putting a forward slash in an empty tag and quotes on your attributes and case sensitivity really aren't HUGE burdens on developers. Perhaps we've all gotten too used to IDEs that auto-complete and auto-adjust case and everything else that we've all turned off our brains. It doesn't help that Microsoft (and even Netscape played along in the bad old days) have encouraged the development of crock-o-crap HTML by adding their own bling to standards and resorting to loosey-goosey tag-soup parsing fro so many years.

      HTML5 seems to be doing a lot to make sure mediocre developers can stay in their comfort zone and to perpetuate many of the more serious problems we still face today. The HTML5 FAQ makes me cringe in many places!

      * "no DOCTYPE. You may include one if you wish, though this is not recommended as they are only relevant when using a validating parser which web browsers do not have." - This is the wrong recommendation and a really stupid rationale. One cannot assume that web browsers will be the only clients to read your document, nor that all clients will lack validating parsers. This saves a small bit of work for lazy HTML authors at the expense of making

      * "HTML 5 is being developed with IE compatibility in mind." - This is a backwards way to move forward with proper standards. You design applications towards standards, not standards towards applications. IE is already mostly compatible with existing standards--the solution is to make sure IE8 tows the line, not to bend over for IE developers. In the automation industry, there is a massive, complicated 8-headed beast of a standard called IEC 61158 that is a good example of what happens when applications drive standards. The IEC was somewhat stuck here however because they got into the game late, when all these battling vendor-developed systems were already established. With the Internet, though the situation is not perfect, existing standards hold a fair and increasing amount of influence. I believe the philosophies behind HTML5 don't do enough to prevent the perpetuation of tag soup and loose vendor-driven application of standards.

      * "The details are still being worked out, but the plan is to indicate the maturity level on a per-section basis." - This puzzles me: They seem to be abandoning the "modules" approach being sought by XHTML in the interests of simplicity, however it is intended that user-agent developers will be implementing the standard "on a per-section basis" as they figure everything out along the way? And they expect this process to take TWICE AS LONG as XHTML did to establish itself as a ratified standard? I sense a lack of vision here--something along the lines of "lets look at what we've got, put Bondo on the dents and holes then spray it with Tremclad to make it look pretty". Not only that, they've decided that they'll work on the right fender and the left door this year, then the rear bumper next year and so on. There's nothing wrong with incrementally ratifying standards, but how about some VISION and PLANNING? Define some modules and their scopes then set teams upon them to tackle them individually and have them ratified as they reach maturity, and do so in a logical fashion (some sort of "core", then forms, then scripting, etc)

      * "Void elements in HTML (the new name for empty elements) do not require a trailing slash...However, due to the widespread attempts to use XHTML 1.0, there are a significant number of pages using the trailing slash"--yet ANOTHER wrong recommendation and faulty reasoning. Lazy HTML authors are annoyed by the slash, but it's been part of XHTML for years so there are a lot of web documents that use it, so HTML5 parsers will have to continue to parse tag soup and do the "guess if there's a closing t
  • by explosivejared (1186049) <hagan.jared@NosPam.gmail.com> on Friday November 30, 2007 @11:16AM (#21532689)
    HTML 5 is strict in the formulation of HTML entities. In the past, some browsers have been too forgiving of malformed entities, exposing users to security exploits. Browsers should not perform heroics to try to make bad content displayable. Such heroics result in security vulnerabilities.

    This will clearly have a negative effect on society. When the script kiddies can't "haxxor" anymore, the only alternative is DRUGS! AND DRUGS ARE EVIL!! CRIME WILL SKYROCKET!
    • Re: (Score:3, Insightful)

      HTML 5 is strict in the formulation of HTML entities. In the past, some browsers have been too forgiving of malformed entities, exposing users to security exploits. Browsers should not perform heroics to try to make bad content displayable.

      It's the browser's fault not the HTML standards fault. And it will never go away unless all of them do away with it at once? Why, because then little Johnny, who messes up a website and only tests it in IE (for example) will see that it works for IE, not FF, not unders

  • Hmph (Score:3, Funny)

    by moogied (1175879) on Friday November 30, 2007 @11:17AM (#21532703)
    Crockford.

    *waits for 5: Awesome at putting words in bold*

  • by Bluesman (104513)
    I like the getElementsByCSSSelector() idea. Better yet would be a way to change css styles dynamically and have the browser respond. Say if I wanted to change the default color of all "a" tags on a page -- in other words, I want javascript access to the css parse tree just like with the DOM. Correct me if I'm wrong, but I don't think there's an easy way to implement this currently.

    Elimination of DOCTYPES in favor of a version attribute to the html tag is just semantics, and kind of silly.

    "There is only o
    • Re: (Score:2, Informative)

      by vaderhelmet (591186)
      This is very possible. Has been for quite a while. http://www.quirksmode.org/dom/classchange.html [quirksmode.org]
    • Re:Hmmm (Score:4, Informative)

      by AKAImBatman (238306) <akaimbatman@@@gmail...com> on Friday November 30, 2007 @11:37AM (#21532951) Homepage Journal

      I like the getElementsByCSSSelector() idea.

      I think it's kind of self-defeating. On one hand he advocates custom-tag creation, then he advocates elements by tag selector. Encouraging one or the other is fine. But offering both will only confuse developers and undermine both options. Going with custom tags is probably the better solution as it encapsulates the semantic information a programmer would be looking for while still being unique enough to style with CSS.

      That being said, if you really want that feature try this script:
      http://simonwillison.net/2003/Mar/25/getElementsBySelector/ [simonwillison.net]

      I want javascript access to the css parse tree just like with the DOM.

      I think you want to read the DOM Level 2 Style Specification [w3.org]. The short answer is: Yes, the CSS is accessible through DOM APIs. The long answer involves lots of shouting and complaining about Microsoft and their stranglehold on the market. :-)
      • by darthflo (1095225)
        Going semantic with custom tags sans some doctype kind of explanation about what they mean sounds like utter bullshit to me. Slimming the standard down to fewer tags (e.g. "html", "head", "body", "script", "block", "inline", "form", "input", "table", "row", "cell" and a generic "object" for images and flash and whatnot), aided by a descriptive "name" attribute for anything would, in my opinion, be a probably better approach.
        Luckily, though, I'm not in charge of either gundam or HTML and find (especially th
    • by nagora (177841)
      Elimination of DOCTYPES in favor of a version attribute to the html tag is just semantics, and kind of silly.

      No, it's a bug-fix.

      Introducting Doctype instead of just adding a version attribute to HTML was more than silly - it was stupid and a sure sign that the W3C committee had been take over by "XML for everything" donkey wabs.

      TWW

      • Re: (Score:3, Informative)

        by Wdomburg (141264)
        Erm, you do realize DOCTYPE was in original HTML draft published in 1993, before the W3C existed and almost five years before XML existed, right?
      • by darthflo (1095225)
        Yep, cause it's utterly stupid to even imagine (or plan for) the development of HTML forking at some point (and different dtds existing peacefully amongst each other).
  • I love it (Score:2, Insightful)

    by pseudorand (603231)
    That sounds like a great idea! I loved everything he said and support it fully. Now all we need to do is formalize it by committee, get Firefox and IE to both support it, get 95% of users to upgrade to the new versions of browsers, and rewrite all of our existing HTML in this new format. Let's get going. :)
  • Seriously, I'm not sure I even care about HTML 5 in anycase. Currently browser makers still do not fully and equally support what we already have what is the point of adding even more complexity by adding new stuff.

    When I can code once ((x)html/javascript-ecma if you like/CSS2) and get exactly the same result in IE 7, FF 2/3, Opera, and Safari then if might be time to talk about adding and changing things.
    • by vux984 (928602)
      When I can code once ((x)html/javascript-ecma if you like/CSS2) and get exactly the same result in IE 7, FF 2/3, Opera, and Safari then if might be time to talk about adding and changing things.

      That right there is the problem. The pixel perfect web that most designers want really was never part of the design. HTML was never intended to get exactly the same result in all browsers. Of course, browsers were supposed to comply to the standard too, and they all have bugs and quirks; they aren't perfect either -
      • The pixel perfect web that most designers want really was never part of the design. HTML was never intended to get exactly the same result in all browsers.

        The first sentence does not jive with the second sentence. You are correct in saying that HTML was never intended to be pixel perfect. You are incorrect in stating that pixel-perfect rendering was never part of the design. CSS is very much designed to provide pixel perfect rendering to nearly any markup via a method that can implement backward-compatibili

  • That's the best solution I can come up with. The web right now is stagnating under a ton of HTML and JavaScript that has been around since the web began, with very, very little improvement apart from some patchwork Ajax stuff.

    Everybody wants to go beyond HTML and create something new and flexible that everyone can feasibly implement, like the early days of the web. Naturally, Microsoft doesn't want to go down this route with IE. Also, people will continue to use what they know will work everywhere - sort
    • That's half of it. Then lets get rid of all the "programmers" who have come to rely on IE's "Yeah, it's malformed, but I know what you mean" behavior. I say if there's even ONE missing (or out of order) </TD> then don't render the page, PERIOD.
    • by dave420 (699308)
      That's not going to happen, so it would be far more prudent to come up with a workable solution than something that can never, ever happen.
  • WYSI... (Score:4, Funny)

    by goldaryn (834427) on Friday November 30, 2007 @11:29AM (#21532841) Homepage
    WTF! [userfriendly.org]
  • Hell no! (Score:5, Funny)

    by sm62704 (957197) on Friday November 30, 2007 @11:30AM (#21532853) Journal
    Kinder and gentler? Jesus, you kids today! We need an HTML that stinks like mace, has sharp barbs all over it, smokes, drinks, hires hookers, opens bottle caps with its teeth and beats the hell out of innocent policemen and then fries them with their own tasers [slashdot.org].

    -mcgrew
  • It's called Gopher.
  • Why not just... (Score:5, Interesting)

    by itsdapead (734413) on Friday November 30, 2007 @11:37AM (#21532957)

    Without breaking Slashdot tradition and reading TFA, why not:

    1. Freeze HTML at V4 and regard as a can of worms to be used for legacy purposes only;
    2. freeze XHTML as a handy kludge that is parseable by XML tools while still rendering as HTML4 (and learn to love "tag soup" as long as it parses);
    3. For new projects, dump the poorly-implemented legacy crap and use "pure" XML + a suitable stylesheet/formatting system.
    4. Develop a diverse, extensible range of DTD/Schema + stylesheet "templates" tailored for various purposes (eBooks; blogs; news; reports etc..) but ensure that new browsers can work with any valid Schema/Stylesheet.
  • Speed (Score:2, Insightful)

    by p0 (740290)
    Don't forget, a compact markup could improve transfer rates too.
    • by sm62704 (957197)
      Just because you have a box full of tools doesn't mean you have to use each and every one of them. You can use the backhoe or the garden spade, it's up to you. Use the right tool for the right job. Just because I only need a hammer today doesn't mean I should throw the screwdriver away.

      fast [mcgrew.info] and slow [kuro5hin.org]; but it's the same article! Yes, the K5 one has comments, but I think the example gets the point across anyway.

      -mcgrew

      PS- yes, I know there's a typo in the "back" link. I'm too lazy to fix it.
  • If people would just write for standards-conforming browsers (e.g. Opera) instead of ones who blatantly break conformity with standards (e.g. Internet Explorer, Firefox), then coding would be a hell of a lot easier to read.
  • More blithering idiots is just what we need. After all, why should you study basics, then move on to intermediate topics a few years later and finally learn to do things properly from experience? Reading To the Moon in 21 hours is so much simpler!
  • by athloi (1075845) on Friday November 30, 2007 @11:56AM (#21533207) Homepage Journal
    HTML was never perfect. Then the standards people took too long to update it.

    Netscape and then Microsoft added custom HTML.

    At this point, the browser became written to execute bad code well...

    Now we've got cross-browser headaches and standards confusion.

    I say bring on HTML 5, and bring on the strict. Make it look good in both browsers. End the sheer boredom of trying to make code display well on FireFox and IE, both of which are bloated pieces of crap, when it works just fine in Opera.

    Simplify, and abstract, but don't expect HTML coders to be coders... it's a language for layout for the rest of us, and its genius has always been its simplicity and adaptability.

  • With all the Amazon 'Kindle' hype, did anyone else read this as a 'Kin-der', Gentler HTML?
  • Ain't broken (Score:3, Insightful)

    by jalefkowit (101585) <jason@jaso[ ]fkowitz.net ['nle' in gap]> on Friday November 30, 2007 @12:06PM (#21533329) Homepage

    I love how the first sentence is:

    HTML needs fixing.

    O RLY? HTML is probably the most widely deployed document format in the entire history of computing (after ASCII plaintext, which I'm not sure counts as a "format"). An unknowably huge number of documents are authored in it every day. All but a tiny fraction are successfully retrieved and rendered by millions of clients ranging from dual-core desktop PCs to mobile phones.

    It's one thing to say "HTML is ugly" (to which I'd agree) or "HTML needs extending" (I'd agree with that too) but "HTML needs fixing"? Really? Is there anybody in the planet who wants to publish something online today but can't because of problems with HTML?

  • by QuietLagoon (813062) on Friday November 30, 2007 @12:15PM (#21533423)
    The Yahoo sites are some of the most unreliable [cnbc.com], slowest and plain old poorly designed sites of any of the major portals.

    Yet the Yahoo developers keep on trying to tell the rest of the world how to create web sites, or how HTML should look, etc.

    The Yahoo developers should first build credibility by getting their own house in order before they try to instruct others how to do their job.

  • The web has desperately needed a foundation asynchronous protocol to build on; I'm thinking of something like BXXP. Request/Response is so archaic and it's forced developers to find all sorts of hacks to get around that problem.
  • security; xml (Score:3, Insightful)

    by bcrowell (177657) on Friday November 30, 2007 @01:20PM (#21534449) Homepage

    I'm baffled by the concept of advocating a new version of html to get rid of security problems. Web browsers aren't going to break compatibility with old versions of html. What good does it do you if your browser supports secure html, but also supports insecure html? The vast majority of the security problems on the web are problems that are specific to IE+Win, because Windows's security model has problems, and security has never been a priority for the IE maintainers. None of that is going to change if you just invent a new version of html. Also, many of the security problems in IE+Win have historically been because of proprietary extensions that MS introduced. If MS shoots itself in the foot by not following standards, then I don't see how a new standard is going to help.

    Another problem with the proposal is that it's a dead end when it comes to new functionality like SVG and MathML. These are xml-based standards, and there is no standards-based way to implement them in html; they have to be implemented in xhtml, or else they have to be implemented in a nonstandard way. Today, if you want to write a web page with mathml in it, and you want it to degrade in a sensible way in versions of IE that don't have the relevant plugin (i.e., 85% of all browsers out there), the choices aren't pretty; basically you either have to serve up multiple versions of your page, or you have to do incredibly kludgy tricks with xslt, or you have to do incredibly complicated stuff with javascript. The fundamental problem is that html has forked into html and xhtml, IE doesn't support application/xhtml+xml and probably never will, and xhtml is the only sensible way to incorporate new technology like SVG and MathML.

  • Hell No (Score:3, Insightful)

    by psykocrime (61037) <mindcrime.cpphacker@co@uk> on Friday November 30, 2007 @01:26PM (#21534575) Homepage Journal
    HTML can be made into a general application delivery format without disrupting its original role as a document format.'"

    Trying to turn HTML into an application delivery format is a brain-dead idea from the get go. Here's a thought: let's use HTML as a document and hypermedia format, and turn to application specific protocols for delivering applications?
  • HTML is DEAD (Score:3, Insightful)

    by OxFF52 (1126819) on Friday November 30, 2007 @01:28PM (#21534613)

    ...or at least will play a much less significant role in the future.

    As a document format, HTML is great... for example, I throw in a few tags in this forum to create bold, italics, links [slashdot.org], etc. Throw in tables and images an you can create a very nice looking article for the web.

    However, there is a huge difference between "documents" which can be read in various different monitor/browser sizes, fonts, and languages and what a majority of paid developers do with HTML within corporations. That being creating pixel perfect applications that work in one particular browser (IE or Firefox).

    To that end, what we need isn't yet another HTML specification which will make the browsers even that much more bloated and incompatible with each other... it is an application framework for the web. In fact, this is what Adobe and Microsoft are creating with Flex/AIR and Silverlight, respectively. Ultimately, the "markup language" of the future will be dynamically created and compiled on the server and sent to the browser in a binary format which is run by a plug-in.

    Therefore, I believe HTML should evolve into what is started out as... a DOCUMENT format. It should really move towards a light-weight Open Document [wikipedia.org] specification, NOT towards something that attempts to embody "Web 2.0" features which are already evolving well beyond dated HTML specifications that are nearly a decade old.

  • Umm, JSON inventor? (Score:3, Interesting)

    by Trailer Trash (60756) on Friday November 30, 2007 @01:32PM (#21534679) Homepage
    That's a little presumptuous, to put it mildly. I've been using JavaScript Object Notation to store data for JavaScript programs for quite a few years now, and I just heard of this guy today. What am I missing? The inventor of JavaScript Object Notation is the guy who created the JavaScript syntax.
    • "JSON" refers to strings of JavaScript source, which are essentially S-expressions, used for marshalling data for transmission. It's promoted as an alternative to XML, because parsing XML in Javascript requires shipping an XML parser in Javascript along with the web page.

      The trouble with this idea is that Javascript has the wrong primitives for this operation. In LISP, there's the "reader", which turns a character string into an S-expression, and "eval", which executes an S-expression. JavaScript combi

  • Or just start over (Score:3, Insightful)

    by maz2331 (1104901) on Friday November 30, 2007 @02:17PM (#21535395)
    Maybe the whole thing needs to be rethought from the ground up. What do we use web browsers for nowadays anyhow? I see the following...

    1. Displaying mixed text/image documents. HTML sucks for laying these out.
    2. Filling in forms and database interaction.
    3. "Online" applications.

    It seems to me that using a "markup" language doesn't meet any of these goals well. The onscreen (and printable) views would be much better in something similar to Postsrcipt, forms would be better as something akin to an MS Access, and online apps require a way to either remotely display the app on the client and interact, or download an applet of some sort that synchronizes with the server.

    I'd say creating a standardized VM that displays Postscript and uses a Java or .NET-type language (maybe even compiled to bytecode) is a better way to go. The key is to integrate this together at all levels, not the current patchwork of embedded client-side or server-side scripts. Make the development process simulate the same steps one goes through to create a native application instead.

    Right now, when making a web app, I have to create PHP scripts that generate SQL queries, crunch the data, and then output HTML and possibly client-side Javascript. What a pain in the ass - there's at least 3 languages involved and really the whole thing is a mother to debug.

The clearest way into the Universe is through a forest wilderness. -- John Muir

Working...