By Louis Simoneau

Is HTML5 Dirty?

By Louis Simoneau

Last week, I wrote about Google’s mod_pagespeed. Some of the module’s features brought out some negative reactions in the comments; notably, the fact that mod_pagespeed can be set to remove quotes from around attributes in your markup, and remove unnecessary attributes (such as type="text" on an input element).

The commenters noted that they were uncomfortable having the server output invalid markup, or “destroying their good intentions.”

Ah, but it’s not invalid! Or at least, it doesn’t need to be.

One of the more interesting (and at least a little controversial) aspects of the HTML5 specification is its relaxing of several constraints on the exact syntax of your markup. The idea was to reduce as much of the complexity of an HTML document as possible, while maintaining backwards compatibility. As it turns out, browsers have always supported unquoted attributes, and they’ve always defaulted to an input type of text in the absence of a type attribute (or in the presence of a type attribute they don’t understand; this is why the new input types like "number" or "email" are backwards compatible). As a result, the simplest input attribute that’s fully backwards compatible is:


This works in every browser, and correctly displays a text input box. This is why the authors of the HTML5 spec went ahead and made that the minimum required by the specification to create that element. Quotes around attribute values are only required if there’s a space in the value; element and attribute names are case-insensitive, and many attributes have a default value that will be assumed if the attribute is absent (this is the case with the type attribute of the input element). That’s the whole idea behind the spartan HTML5 doctype: it was the minimum number of characters required to trigger standards mode in older browsers.

Even once you understand that, markup like <INPUT type=text> still looks wrong, doesn’t it? But, as Jeremy Keith argues extremely well in his Fronteers 2010 keynote, that’s a question of coding style, and the specification should be style-agnostic.

So, coming back to mod_pagespeed. If it can improve your performance by stripping out a bunch of needless bulk from your code in a way that every browser ever made will be able to parse without problem—then I say let’s do it. The good news is that the HTML5 spec has been built with this in mind, so those of us who care about doing things “the right way” can gain some peace of mind.

note:Want more?

If you want to read more from Louis, subscribe to our weekly tech geek newsletter, Tech Times.

  • XMLuvr

    I probably get flamed for this, but the more I read about HTML5, the worse it gets. Seriously, if XHTML is too “complex or difficult” then please use Markdown. So far, the only decent things in the HTML5 tagsoup are canvas, video and audio. Everything else in that specification just seems to be superfluous junk targeted at bloggers and webdesigners that cannot get their head around the few rules a proper XHTML format would require. Namespace will likely stay a pipe dream forever.

    • ShinoKage

      I have to agree with this guy here 200%. I couldn’t really say it better myself….

    • David Martin

      I also agree, i’m not finding many other posatives to Html 5. Also a massive issue for me is the lack of support that IE is offering for Html 5 & CSS3.

    • momos

      Same here, XHTML 2 had more BLING in my book

    • Exactly my thoughts.

  • Cezary Tomczak

    That’s great to hear. I didn’t know that without quotes around it is still valid html5. Hate those quotes around, and my keyboard is thankful! Less typing, less lines of code, better readability, just awesome!

  • Andy M

    so is html 5 not considered xml then?

    • Q.E.D.

      No. HTML5 is an SGML (Standardized General Markup Language) like all the other HTMLs including 4.01, which means that there aren’t many rules governing well-formedness on mark-up. In fact HTML 4.01 isn’t valid XML either. XHTML is the only valid XML implementation of HTML, but there is hope with the so-called XHTML5.

      • Paul McKeown

        HTML ditched its link with SGML. They were never paid anything more than lip service, how many SMGL/HTML web browsers have you ever come across? Have you ever seen style comments for example? You are right that html’s ugly markup testifies to it descent from SGML, but it certainly wrong to say that html5 is an SGML. Of course XHTML5 exists, for those that despise ugly markup.

      • EPB

        Not quite SGML, but the syntax is very similar and still inspired by SGML.

        HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1 documents published on the Web, but is not compatible with the more esoteric SGML features of HTML4, such as processing instructions and shorthand markup as these are not supported by most user agents.

    • Louis Simoneau

      You actually can serve up HTML5 as XML if you like. All that means is you need to include an xml namespace declaration at the top, adhere to XML syntax requirements, and serve the file up as application/xhtml+xml. Of course, that means IE will choke and die, but the option is there if you want it :)

      • bemo56

        >Of course, that means IE will choke and die, but the option is there if you want it :)

        And if there are any typos in your syntax (forget to close an element, etc), users get a scary message to look at and the entire page refuses to show!

  • Gah. This is why HTML5 is a mess.
    Less strict makes it harder for the browser vendors to be consistent. The stricter the specification, the less guesswork the browser needs to do and we get both faster browser rendering due to following a set of strict rules without guessing what the developer “really” means and less headaches as developers as it’s either right/wrong and tools like validators can easily pick up on that. Giving people “shortcuts” is no good long term.

    • Cezary Tomczak

      Yeah, omitting quotes will definitely slow down the browser, because detecting attributes value without quotes is a real science.
      Now that I’ve read about how parsers work, I know that:
      <input type=”text” name=”” value=”” />
      Is a lot easier to parse, takes less time, than parsing an empty input:
      Thanks for enlightening us.

      • Bouke Versteegh

        sorry, this is just not true. just a single character determines the boundaries of the value.
        suppose you have parsed (type=) — without parentheses of course — then if the next character is a quote (“) it should read until the next quote. otherwise it should read until the next space. the only difference is a branch-off at the first character. easy.
        the same goes for ’empty input’. if the first non-space character after (, then stop reading. use some defaults. otherwise keep parsing attributes. this is technically “harder” because you need to do more parsing.
        in regular expressions:

    • Anonymous

      I fully agree!
      I get tired with ridiculous changes like that. Make up your minds at W3C, please! You jump up and down like a yo-yo.

    • Louis Simoneau

      Actually that’s not true. HTML5 makes it easier for browser makers to be consistent because, unlike previous specifications, it defines error-handling procedures for dealing with poorly formed markup.

      As for the looser syntax I outlined above, all browsers already deal with those examples in a consistent way, so what’s the worry?

    • config

      Number of browser vendors: a handful
      Number of web developers: innumerable

      This has always been my argument for making things simpler, and more lightweight for the average web master/developer/engineer/monkey.

      I was dragged (I may have kicked and screamed a little) into the world of adding closing slashes to tags that were by definition singletons, and other XHTML nonsense. I’m screaming headlong back to rational world.

  • Elmor

    Well as it was said in this article – you can say HTML 5 is a “spartan” style coding…

    really i used from time to time attributes without ” ” or no “type=text” … but somehow it feels really dirty… or is it just nonsense?

  • aramando

    I’ve got used to the idea of no quotes when attribute values don’t contain spaces, this actually seems perfectly sensible, but not needing to close tags that contain text or other elements is a horrible idea.

  • A. Nonymous

    How do you assign multiple classes… or use a sentence with spaces in alt or title attribute? The structure of xhtml was not difficult to grasp. This is a hot mess.

    • Andy M

      if you are going to use spaces in your attributes then you have to enclose them with quotation marks, but if the attribute value pair dont have a space then you can do the lazy syntax. Id say it makes sense as far as sending super dooper small html files, but the savings are going to be out weighed by so many other factors.

  • Quilo’s sort of the right kind of dirty….

    And I agree with XMLuvr, stricter is better and more eficient. Since I prefer my designers prettier than smarter(ie:. can barely do 2+2, but their designs blow my mind). I don’t mind doing all the coding, even including css, if the design is alright

  • anon

    “style-agnostic” nice!

  • Marc

    Absolutely agree Tom. I thought that websites were finally tidying themselves up and “coding styles” as referred to in the article, can mean real headaches for someone maintaining a site they didn’t build in their own “coding style”. Coding in a strict and standardised way means that everyone always knows what they’re looking at.

  • john doe

    Douglas Crockford has some concerns about the security problems in html5. Fix them first please. HTML4 will be here a long time still I think. Web Standards are half-bullshit.

  • I was really pleased when developers finally moved away from the mess of early HTML to become ‘strict’. It introduced a degree of conformity which made it far easier to work with other people and their code. And, it just looked neater.

    Now it seems like we’re moving back to anything goes, and we’re all going to be presented with a mess of different styles, often within a single document. I am not looking forward to this at all. Yes, it may work. But it’s not going to make things easier in the long run, and it’ll only confuse beginners, who learn from looking at code.

    I wish HTML5 had chosen one style to be canonical and stuck with it.

    Other than that, HTML5 looks pretty good (still figuring out some of the subtleties, but I’m looking forward to using it soon).

  • BrenFM

    I’d prefer to stick with my quotes, cheers muchly anyways, mainly for cases when you’re creating a div with multiple classes that require a space between them – thus requiring quotes. I don’t want to have to consciously think about when I have to put quotes and when I don’t, to me THAT is what a standard is all about.

    On the flip side, I’m all for mod_pagespeed doing anything like this on the fly to speed up page load times – so long as it’s not at the expense of the functionality of the page.

    • @BrenFM “I don’t want to have to consciously think about when I have to put quotes and when I don’t, to me THAT is what a standard is all about. ”

      I couldn’t have put it better myself.

      And possibly someone m ay have said this further down – you can write HTML5 in whichever existing “flavour” of HTML-like syntax you wish.

      Personaly, I will be writing it in the XHTML style that I have been doing since 2002.

  • Those people who say “HTML5 is a mess” are forgetting that no one is forcing them to stop using double quotes or omit the “type” attribute. Like Mr Keith indicates, it’s a matter of style. How could it possibly not make sense for HTML5 to not support this style? It’s an integral part of HTML at the moment. It would be silly to not make it backwards compatible, and it doesn’t hurt those who are writing with a consistently XML-ish style.

    And just because it isn’t pretty doesn’t make it unstrict. There is no room for misinterpretation with, for example, unquoted attributes. If the attribute’s value is going to be multiple items (i.e. with spaces) then it must be quoted. However, I would certainly agree that using quotes and the “type” attribute always should be encouraged.

    • The mess stems not from that it stops you from using them; it stems from not forcing you to use them. “Have to” is simpler, clearer, cleaner and more consistent than “you may omit them for this, but not for this”.

      Sure, you can vomit up damned near any mix of HTML 3.2, 4 and XHTML 1 in the HTML 5 doctype — that’s the PROBLEM and why I compare HTML5 to HTML 4 tranny pre-validation.

      The loose rules in fact even negating the advantages of validation… which as I’ve said several times is why HTML 5 seems to be for the people who never embraced or understood STRICT, and just want to vomit up HTML 3.2 with even more goofy redundant tags while slapping a HTML 4 transitional doctype on it.

      Said new tags being just as bad as all the proprietary crap from the peak of the browser wars. See Marquee, Blink, Applet, Embed, plaintext, xmp, basefont, listing and the dozen other proprietary tags and attributes that really should have no place on a modern website. These new tags are no better than any of that garbage. I think there’s like one or two new tags in the entire specification that even seem to have a legitimate point!

  • basvanmeurs

    I totally disagree with the writer of this article.

    “If it can improve your performance by stripping out a bunch of needless bulk from your code in a way that every browser ever made will be able to parse without problem—then I say let’s do it.”

    This is just a stupid quote. Allowing ‘messy’ code will have the effect that browser codes will become more complex. If ‘old’ syntax will be included in new standards it will hold back the development of new features and new browsers. I am shocked to learn that HTML5 doesn’t follow the XML standards. This means that in 10 years we will (still) not be able to parse a page in an XML parser and get interesting information out of it. A missed opportunity! And for what? Just to allow us to type <input> instead of <input type=”text” .. />? I wonder who did the cost/benefit analysis on that one!

    In general, having a clear and rigid standard makes code much more readable and less prone to ‘forgetting’ things. If some developer wrote a page in which there is some input element in which the ‘type’ has not been defined, would this be because he ‘forgot’ it or because he wanted it to be of type text? And the omitting of quotes; this might cause weird errors in a dynamic page context. Take the next situation for instance: <input value=$value>, might produce on some page <input value=respect for the disabled>, and suddenly our textbox would be disabled (at least in some browsers). And those couple of bytes it saves from being sent over the Internet? They have no noticable effect on either the server load nor the page load time.

    Still hoping and keeping my fingers crossed that XHTML5 will be adopted more generally..

  • The years of change in html/xhtml specifications have been like climbing a huge mountain. Slowly we were getting higher and higher, Xhtml Transitional – the peak is in sight, Xhtml strict – almost there, eventually all browsers enforcing and recocgnising that it had to be valid xml – I’m getting the flag out of my bag to plant it. Html5 – the ice has broken beneath us and we are tumbling down amidst an avalanche of our own making.

  • Geoff

    ” If it can improve your performance by stripping out a bunch of needless bulk from your code in a way that every browser ever made will be able to parse without problem—then I say let’s do it. ”

    The question for me is ‘how much of a performance improvement’ vs ‘how hard is it to debug the product’ or ‘how much longer will it take to implement a new feature because of this’

    If the performance gain is not noticable to the end user, say 5 ms and it makes it harder to understand the source of the page when I am trying to add a feature, then I say let’s NOT do it. The end user would rather see the new feature quicker, since they do not notice the page loading any faster

  • Alex

    Jeremy Keith is right, this is only code style and everyone, who wants to use a XML-like strict style, but can’t use true XHTML (for IEs below 9), can use polyglot markup ( But we need something more special like an HTMLLint/Code style checker. (configurable Style-Checks)

  • I don’t think I’m have the depth of understanding of the XML/HTML trade-offs that other posters here seem to be, but I’m happier with HTML. I used to use XHTML but moved to HTML4 strict when we were still stuck with IE6.

    I can’t actually remember my precise reasons now but I found I was happier with HTML strict when building highly dynamic javascript / ajax pages and I couldn’t really perceive any distinguishing benefit from XHTML.

    Again, I’m not sure if I’m totally correct here but I am now even happier to move to HTML 5 since I want some of the features I’ve been seeing. This is the first I’ve heard of XHTML 5 coming up so I guess it’s not ready for use.

  • twenty205

    I may be wrong but I thought quotes around an attributes value denote it being a string [ attribute=”my string” ] as opposed to a number [ attribute=5 ] or a boolean [ attribute=true ]

    If I need performance gains I’ll look elsewhere before thinking about dropping quotes on STRING attribute values.

    But I can see why Google thinks it’s a good idea, for them, considering the amount of crawling they need to do these days.

  • gregbair

    Maybe people who have a problem with it should get together and put out something like Python’s PEP 8, which is a document concerning coding style. You can code Python in any style you like (within the syntax rules) but there are some accepted conventions.
    HTML5 is like Ruby. There’s many ways to do the same thing syntactically, but there are some conventions.

    I think the the best thing to do is to use quotes when developing, but maybe someone could make a minimizer to reduce whitespace and quotes (when appropriate).

  • DeveloperMan!

    I’m sick of this crap. We spend most of the last decade moving toward XML compliance for the web, and the new HTML standard deliberately drags us back to 1998.

    This is how the world ends. Not with a bang, but with a non-terminated blink tag.

  • gtipete

    For the past years the industry has been moving ever so slowly away from bedroom designers/developers knocking up shoddy websites for a fraction of the cost that a true professional would charge.

    Basically targeting HTML 5 at novices and beginners will mark a return to unreadable, hard to maintain and sloppy code which paints out whole profession in a bad light.

  • thecatspaw

    I just don’t get it. We were told for years that adherance to standards and well-formedness was the way to go for web sites of the future. Eliminate all the error-handling, optimise interoperability and boost SEO. Why reintroduce all the problems back into html5? The author reckons that all older browsers will be able to handle all the errors, but what about other user-agents, things like mobile phones, screen readers, braille machines, etc? And leaving a few quotes out and default values is going to maximise download speed?? Sounds laughable, surely any millisecs improvement will be outweighed by all the extra error-handling routines?
    If this approach is so good, why does XML bother with standards?

    There are all sorts of other problems with html5. They’re reintroducing behavioural and presentational elements back into the standard, wouldn’t it be more efficient to keep this stuff separate? We’re not talking about little things here, take the form validation routines as an example, when was that structural? An earlier article at Sitepoint pointed out that all the main software vendors are involved in this new spec, and voila! we have a raft of additions provided by these companies. I suspect it’s an attempt at dumbing-down the whole activity, get any Tom Dick or Harry to become reliant on your software and don’t bother too much about standards. Web design could be religated from an art form to any old rubbish you can post, as long as the big commercials are involved.

  • Buzu

    This is why HTML5 is no the right way. HTML5 is a huge step, unfortunately it is in the wrong direction: backwards.
    Didn’t the web became too chaotic with all those malformed HTML documents? Wasn’t that the primary reason for the creation of XHTML? Do the guys behind the HTML5 project really think we are all bloggers?

    There is some cool stuff on HTML5, but there is a lot of bad stuff in it too. Sometimes I get too tired of companies like apple or google telling us what “the right thing” is. Do I really want a few milliseconds of speed improvements? How far is too far on your quest for better performance? I suppose you can argue that there is no such thing as “enough” when you are talking about performance. But there are trade-offs on everything, so every time you gain on performance, you loose somewhere else. Is that performance improvement worth the price?

    Every site is different. How much benefit do I gain from mod_pagespeed on a site that basically writes itself? what about a highly dynamic website with content being generated on the fly?

    We, perhaps, should remind ourselves that Google is not always right, and most important, that what works for a site as big as google, not necessarily works for a site with 1K views per month.

  • I can’t believe we are arguing over a double quote! There are such better things to argue about, like should you use tabs or spaces to indent your JavaScript, much more exciting topic!

    • jim

      u said it bro

    • The main issue here is agreeing on how many spaces a tab replaces. While the conventional rate is 8 spaces per tab this is usually too many for common coding practice. Most coders use 3 or 4 spaces per tab, but it is not predictable and open to personal preference.

      For this reason spaces are certainly preferable for indenting instead of tabs, since most editors can be set up to insert a particular number of spaces when pressing the tab key.

      This eliminates the problem of viewing the file when different viewers have their editor set up for a different amount of spaces per tab.

  • jim

    Raffles has the right idea … for those of you with lots of time and tools on hand, keep right on adding all the superfluous code you like. For those of us who just want to get pages on the web without having to resort to mega buck software packages and 100K+/page HTML files, HTML5 is making perfect sense … BECAUSE it works with both of us! And that is the whole point.

    And quite whining about XML. That format was only intended for business use with server farms and $100/hour programmers to crunch out database-driven pages for the likes of bloggers, Amazon and Facebook. It is total nonsense for the rest of us (aka, 90% of the net).

    And, Buzu, catspaw, et al … y’all have to get a grip. If you want to keep using code generators to produce nice huge complicated code full of quotes and whatnot, keep doing that! It will be okay. HTML5 happily allows you to do that.

    And, basvanmeurs, don’t be shocked that not everyone wants to join the locked-down white-washed world of XML. Not everyone is a devotee of George Orwell’s vision of the future where Big Brothers [the XML police] control the world [‘Net].

    Sit back and enjoy the new features; and don’t use any of them you don’t like or understand. In other words, K.I.S.S..

    • momos

      XML only intended for business use, come on… If I had my way, HTML would be deprecated, and people who don’t have the skills to learn XHTML would only be able to build sites with tools, that way we should evolve to a cleaner web. Too much people without any web background are creating sites by writing HTML, and since HTML is very forgiving when it comes to mistakes, the web is full of them.

      • Paul McKeown

        I would agree with that!

        I thought the tag soup days were gone, but they’re back with a vengeance.

    • Paul McKeown

      “For those of us who just want to get pages on the web without having to resort to mega buck software packages and 100K+/page HTML files”

      Rubbish. No one needs Dreamweaver to write compliant code. MS Notepad will do at a pinch, but there are many excellent but free text editors available. That is all you need. 100 kilobyte html files? Certainly not from using self closing tags.

      “nice huge complicated code full of quotes and whatnot”

      Is that satire? Or ignorance?

      The code only gets complicated when you omit the “quotes and whatnot”. You have to understand how the browsers work internally to be sure what’s going on if you ignore the “whatnot”. If you use the “whatnot” then you have a guarantee how it will look in any browser and how it will interact with css and javascript.

      “Not everyone is a devotee of George Orwell’s vision of the future where Big Brothers [the XML police] control the world [‘Net].”

      Fine language, but what on Earth are you orating about?

      This is the problem with the Internet, vast seas of total ignorance blasted down everyone lugholes with sublime confidence and overblown language.


      Yes – that’s a structured approach to language, like XHTML, rather than HTML5 tag soup.

  • Tor Valamo

    So if mod_pagespeed makes into , your CSS rule input[type=text] won’t match anymore…

  • Tor Valamo

    So if mod_pagespeed makes “input type=text” into just “input”, your CSS rule input[type=text] won’t match anymore…

  • thecatspaw

    Jim, in the nicest possible way, I’m afraid your argument doesn’t negate all the negatives that come with churning out loose syntax. And I’ve have never used a code generator ;)

  • Designer

    I’m a designer. I love visual simplicity, conformity, clean code and legibility.
    There is nothing wrong with closing every tag, or indeed XML. HTML5 is behind the times. Developers and Designers have moved on from the slip-shod mess of loosely formatted nonsense. JavaScript developers are JSLint-ing their work, Designers are pre-flighting. The only people who don’t want to close an XHTML tag are amateurs and hippies. If you want to be lazy get an IDE with code completion, don’t make the protocol more liberal.
    I hate history repeating itself when it’s junk like this!

  • What really burns me is this absurd notion that having less clear rules and relaxed syntax makes things simpler – that’s pure nonsense.

    In the case of double quotes, it can make assigning values very ambiguous and it will take longer to parse… For example:

    value=click for more information

    The parser has to run ‘for’,’more’ and ‘information’ against the reserved words — if it is a reserved word it will be treated as a separate parameter. It is a lot simpler to write a parser that can simply say ” starts and ends strings than it is to try to make sense of using a white-space and non-white-space character as the delimiters. This is why EVERY major programming language out there uses quotes to mark strings in the first place – GOD FORBID we have HTML work like a real programming language.

    Besides, if stripping out double quotes saves you more than about 1k of markup you need to take a good hard look at what else is wrong with your code.

    Oh, and for those of you who say “it’s more convenient when working in SSI’s like PHP” it’s called single quotes for echo — USE THEM. They’re faster and cleaner. (file that alongside the garbage claims that preserving formatting in the output is ‘pointless’ or ‘too hard’)

    On the whole HTML 5 is just one big giant sloppy HTML mess; It is undoing ALL of the progress of the past decade and making things MORE complicated with ‘gee ain’t it neat’ bull that doesn’t add any actually useful functionality. Literally it undoes the progress of strict — like the original plan to have OBJECT supplant IMG, EMBED, APPLET and BGSOUND… So for the new one do we ride Microsoft’s ass about their implementation working right? Hell no, let’s make EMBED officially part of the spec and add two new tags that are redundant to OBJECT! Yeah, that makes it ‘simpler’.

    Then there’s tags like “nav” or “header” which they make crazy claims on accessibility and getting rid of ‘jumpto’ menus (forgetting how superior jumpto menus are on assigning accesskeys for things like Opera’s accesskey menus), when in fact the only REAL justification for their existence is giving the people who currently slap DIV around semantic elements like H1 and UL for no good reason an excuse for their bloated unnecessary code!

    The majority of people writing HTML ‘professionally’ right now often seem blissfully unaware of the existing tags and certainly don’t seem to know enough to use them properly; see improper heading orders, complete garbage like TD class=”header” or worse, TD class=”header” rowspan=”5″ STRONG… What, never heard of TH? LEGEND? CAPTION? LABEL? FIELDSET? Hell we’re lucky if people figure out how to use BLOCKQUOTE and CITE. If people can’t be bothered to use what we currently have, how is adding MORE tags to it making it ‘simpler’?!?

    The rules of STRICT make things simpler — undoing all of that with a sloppy transitional style rules set with a bunch of new unnecessary elements is not ‘simplification’ — it’s taking a dump in the pool… Which is why IMHO the people behind HTML5 are the ones who continue to just vomit up HTML 3.2 and slap a HTML 4 tranny doctype on it… basically the people who never understood STRICT, the advantages of the formatting rules of XHTML, or how in fact it is SIMPLER and CLEANER the original intent was.

    There’s a reason that six years ago I suggested nuking WhatWG from orbit. It’s the only way to be sure.

    • Bouke Versteegh

      [quote]value=click for more information
      The parser has to run ‘for’,’more’ and ‘information’ against the reserved words — if it is a reserved word it will be treated as a separate parameter. It is a lot simpler to write a parser that can simply say ” starts and ends strings than it is to try to make sense of using a white-space and non- white-space character as the delimiters.[/quote]

      god, please read the article. It doesn’t accept this form of quoteless values. Your example will be parsed as:
      value=”click” for=”true” more=”true” information=”true”

      it will not need to check for each word weather it is a keyword or not. Besides, even if this would be the case, it really wouldn’t make your browser slower, please. You have no idea how fast computers are.

      • thecatspaw


        “it will not need to check for each word weather it is a keyword or not. Besides, even if this would be the case, it really wouldn’t make your browser slower, please. You have no idea how fast computers are.”

        You’ve just contradicted the whole premise of the article, that was by stripping out quotes and other “needless” syntax and keywords, you could somehow speed up code delivery.
        Now you’re saying, don’t worry about error-processing, modern browsers are fast anyway! You can’t have it both ways.

        Ok so deathshadow got a bit carried away with his examples, but his overall argument is right. Yes with modern browsers we don’t need to worry about adding on a few extra millisecs. That’s not the point. The real tragedy with the html5 spec is that the clean standardisation designers fought for for years, which is exemplified by html4 strict, looks set to be thrown away. There were other motives beside speed, how about separating out presentation and behaviour from structure (which Jeremy Keith extolled in his classic “Dom Scripting”), simplifying portability between different “user agents” (and the range of different devices is increasing all the time), and simplifying future maintenance.

        I for one do not want these standards thrown out through lobbying by a few commercial conglomerates like Google. Why accelerate the web into a stratospheric black hole? Who cares about semantically and syntatically correct pages? Well, looks like a lot of us do.

      • Yes, it will be parsed that way — which if it’s incorrect values is wasted processing time — and yet I’ve seen a half dozen different CMS systems accidentally output that exact type of code….

        My point was it’s easier to just say “always do it” than run the risk of having a nube (or even an experienced programmer) miss the subtle nuance.

        As to not having any idea how fast computers are, I’ve been at this for three decades so MAYBE I do still have my head stuck in the 8 bit era, but having written my own lexical compiler (to p-code back in the day) I understand what goes on under the hood, and why programming languages use quotes on string assignments in the first place.

  • kg

    I also agree that html5 isn’t so good as you can read on the web. For those who are protecting looser syntax look at this converter:
    It is joke but very scary.

Get the latest in Front-end, once a week, for free.