I'm also not a fan of any aesthetic style where changing something small means you have to change something else.
In this case, any time you have more than one word or have an html character like "<" in your text, you need to go back and add quotes, or remove them when you delete that "<".
Also, all of this is stringly-typed anyways, I kinda like how it's uniformly inside quotes, not only sometimes in quotes when the conditions are just right (notice how his html sample only has his case in mind).
I would also wonder if this messes with any tooling that parses html whether it's linters or various editors.
Finally, I think people should stop using "stop using X" as blog posts. It immediately strikes me as condescending and I think it puts people instantly on the defense. Why not just "You don't need to quote your html attributes" or something? -- Frankly, that was news to me, and I like learning new things, yet here I am in the comments sharing how I disagree with them.
"I'd rather do busywork maintaining my code to conform to an ideal of quoted uniformity than be forced to think whether those quotes are of any benefit to me or to the reader."
Seems reasonable. Eliminating decision making for trivial things is pretty empowering. Likewise I don't indent my code myself. I just always accept IDE indent specified in config file which isn't always optimal.
1. HTML is read by parsers 99.9% of the time. Rare is the human who cares to “View Source” on a site.
2. If you have a decent editor, those quotes are inserted automatically, so no busywork required.
1. Parsers don't care. Humans do. 99.9% of time spent reading the html source is spent by humans, because they are so much slower than browsers. 2. I don't know what "decent" means in this context. Automatic code/quote insertion is wrong when I do not want them. It leads to less readable code.
This is flatly false. Read the specs, attributes are not required to have quotes. (If a bit more familiar with the spec you might then say “yeah, but it defines how all inputs should be parsed, including incorrect input”. If still more familiar with the spec you would then realise that attributes without quotes are a conforming feature.)
Autocorrected XML? I don’t think any browsers have ever been willing to render invalid XML or XHTML that was invalid XML, though I wouldn’t write an affidavit to that effect. I can speak confidently that Firefox would always complain of any XML invalidity in your XML or XHTML document, rather than rendering it.
I misremembered that the quotes where mandatory in html. They're only mandatory in XML.
Initially, html was also valid XML. It's been quite a long time since then, so I accepted that Quotes definitely aren't mandatory anymore.
it's not like I wrote a lot...
Or are you somehow mixing up my comment about chrome adding quotes to html attributes before it renders the DOM?
And heck, I'm not even sure if that's even still the case. I just roughly remember looking at KHTML Code Back around 2008 and thinking "that's smart, you just make certain the data is how you want it to be for easier handling"
Nah, HTML was never valid XML. It started from SGML and didn’t close (most?) tags. Plenty of years later, XHTML rebased HTML atop XML, but failed in its efforts to convince people that this was worthwhile.
Explicit is better than implicit. I've had too many things break in the past because I trusted the parser to "do what I want". Now I trust explicit quotes to keep ambiguity away.
This comment would be more substantive if you justified your position rather than just making a statement. The source article makes some claims for why the quotes are useless, and the burden lies upon you to refute or explain them away, or provide stronger counter-reasons.
So other than 'makes the html less readable', the other content of the article is "I was devastated to have to update my src" back in 2000, and "by the way, run your html through a validator, see lots of stuff isn't valid!"
Because of the lack of content and compelling argument in the 'article', I feel like my assertion that it wasn't useless was just as substantive as "I don't like it" that the article proposed.
I wouldn't have much to add that the original author didn't already say with this sentence:
> I write <div class="multiple words"> if I have to in HTML
The argument for using invalid HTML because many other websites implement invalid HTML is not a strong argument imo. Modern browsers are very forgiving in this regard but we and developers should still strive for consistency through explicitly defined values.
Just checked for myself, and you're correct. OP could have shortened the post by 90% if they just pointed to this fact. But while technically valid, for any reasonable HTML document, you'll run into cases where quotes are required. Example:
<div class=foo bar>
At which point, if you use quotes once in your document, you should really use them throughout.
I don't know. I feel like the difference between quoted and not-quoted is the difference between a keyword and a string. In HTML quotes let me know unambiguously what is a value and what isn't. I'd also wager an insignificant speedup in parsing from not having to intuit where the value ends or what tokens are part of the value.
Looking at an expanded example:
`<div id=foo class=bar>`
- `div` is a keyword.
- `id` is a keyword.
- `foo` is meant to be a string value but it's ambiguous.
- `class` is meant to be a keyword but it's ambiguous. Since `foo` isn't quoted how much extra work does the parser have to perform to know this?
Not using quotes relies on browsers that have always made a best-effort attempt to parse even the most badly broken HTML. This was particularly bad back in the late 90's early 00's.
I think I prefer consistent HTML rather than quotes that change based on the value.
Sounds like you’re unfamiliar with how the HTML parser is defined. There’s no guessing; it’s all simple, hard rules that never look backwards, defined as a state machine, and has been since HTML 5. (And even before then, I would never have characterised browsers as making a best-effort attempt to parse; they all followed rules, just messy and complex and unspecified rules that involved reverse engineering one another.) I wouldn’t care to guess which of attribute values being quoted and unquoted would perform better, and it may vary by engine depending on how they access memory and perform comparisons, but the difference will be negligible either way, though… probably measurable.
Here's where I was coming from. (Warning I don't know browser internals but I have written a a lexer and parser before).
Assuming the browsers run a lexer to take the HTML and convert it into an AST of some kind they would walk the text per-character (or UTF code-point potentially). If the rules were enforced loosely but in a purely forward looking way then `<div class=pants shirts id=small>` would parse as Div token with a class value of `pants shirts id=small`. However I doubt that they're parsed purely forward looking since it's not possible to know from the character position at the `i` in `id` that `id` is a keyword for an argument rather than part of the class value.
So how does the browser know that the class value ends at `id`? Because there are additional heuristics over and above the quote requirement. What probably happens is that it looks forward until it finds some value that's not allowed in the `class` attribute (spaces are allowed for multiple class names), I'd guess in this case the assignment operator after `id`. Once it finds this it says to itself "Hey, `id` is an attribute." So it ends the Div token before `id`, probably stripping the trailing white-space since it's inside an HTML tag, and then starts parsing the `id` attribute.
This behavior of accepting non-compliant HTML is additional complexity over and above strictly parsing the standard. Having to take the "slow" path of waiting until it gets to another attribute doesn't take much, maybe a few dozen actual instructions, the data is probably still in the same cache line. But repeat that 100,000 times for each attribute in a real-world HTML document and it adds up.
Yeah, that’s not how it works at all (or has ever worked). It’s defined as a state machine and parses it code point by code point. And since HTML5, it defines how all inputs must be parsed: if two browsers ever parse any HTML document differently, there’s a bug in at least one of them. You can write non-conformant documents, but browsers will still all parse them identically.
Your example is equivalent to <div class="pants" shirts="" id="small">. This may show your error in expecting that it look backwards: no attribute names are considered special, an attribute value is concluded by its closing quote or by characters like space, and attributes don’t have to have values (there are plenty of boolean attributes, which are the most common cases where people omit the ="").
The HTML grammar really isn’t conducive to lexing.
If you’re interested in how it all actually works, I find how the HTML spec defines its parser very approachable.
> Not using quotes relies on browsers that have always made a best-effort attempt to parse even the most badly broken HTML.
Not using quotes is actually fully permitted by the HTML5 spec, although use of quotes is recommended. The HTML5 spec formalises this.
The HTML5 spec is somewhat noteworthy in that it was actually put together and agreed upon by the browser vendors/developers, and then became a W3C spec (previously, this has occurred the other way around). HTML5 parsing formalises much of the previous leniency / workarounds.
When writing my code for myself only, I don’t quote my attribute values unless necessary. If writing in a shared project, I will match the existing style, which is almost always to use quotes.
But things that bother me much more are:
• Putting type="text/javascript" on <script> and type="text/css" on <link rel=stylesheet>. These are 100% useless and I can’t think of any justification for people choosing to write them that way, whereas I can easily for quotes on attribute values.
• Trailing slashes on HTML tags. As far as the parser is concerned, these are completely useless in HTML (though not SVG or MathML). The spec basically says “oh, there’s a trailing slash on the tag? Sigh, don’t they know XHTML died? Skip it.” Worse, I think they’re actively slightly harmful because they may make people think that you can close tags that way, like in XML. You can’t. The trailing slash is only valid on void tags like <img>, where there is no closing tag, and the parser only special-cases ignoring it for convenient compatibility with XHTML/XML documents.
Parsing HTML is anything but a minefield. It’s far and away the best format in this regard that I’ve ever encountered, because its parser is defined exhaustively, and all the tools people use obey.¹ Few other things boast that, and even fewer are consistently implemented correctly (which is to say: I don’t know of any examples, though I haven’t hunted).
(I’m speaking specifically of parsing HTML. Other tasks that you may perform on documents are a good deal less robust.)
—
¹ OK, so developers often still use bad HTML parsers in their own apps. But browsers and all good HTML tooling gets it right.
43 comments
[ 39.3 ms ] story [ 293 ms ] threadAnd if other people following the specs bother you so much, maybe seek OCD treatment.
In this case, any time you have more than one word or have an html character like "<" in your text, you need to go back and add quotes, or remove them when you delete that "<".
Also, all of this is stringly-typed anyways, I kinda like how it's uniformly inside quotes, not only sometimes in quotes when the conditions are just right (notice how his html sample only has his case in mind).
I would also wonder if this messes with any tooling that parses html whether it's linters or various editors.
Finally, I think people should stop using "stop using X" as blog posts. It immediately strikes me as condescending and I think it puts people instantly on the defense. Why not just "You don't need to quote your html attributes" or something? -- Frankly, that was news to me, and I like learning new things, yet here I am in the comments sharing how I disagree with them.
Plus if you have a good editor, you don’t generally need to type the quotes yourself.
And +1 on the “stop using”. Ordering people around is not a good way to convince anyone.
Fwiw, at least chrome autocorrected it before rendering... Though that might be out of date as well? Idk
I misremembered that the quotes where mandatory in html. They're only mandatory in XML.
Initially, html was also valid XML. It's been quite a long time since then, so I accepted that Quotes definitely aren't mandatory anymore.
it's not like I wrote a lot...
Or are you somehow mixing up my comment about chrome adding quotes to html attributes before it renders the DOM?
And heck, I'm not even sure if that's even still the case. I just roughly remember looking at KHTML Code Back around 2008 and thinking "that's smart, you just make certain the data is how you want it to be for easier handling"
Oh. And: Stop Using Medium. TYVM
> It “makes” “the” “html” “that” “is” “already” “cluttered” “enough” “even” “less” “readable”.
So other than 'makes the html less readable', the other content of the article is "I was devastated to have to update my src" back in 2000, and "by the way, run your html through a validator, see lots of stuff isn't valid!"
Because of the lack of content and compelling argument in the 'article', I feel like my assertion that it wasn't useless was just as substantive as "I don't like it" that the article proposed.
I wouldn't have much to add that the original author didn't already say with this sentence:
> I write <div class="multiple words"> if I have to in HTML
This stinks of IE6 privileges.
Looking at an expanded example:
`<div id=foo class=bar>`
- `div` is a keyword.
- `id` is a keyword.
- `foo` is meant to be a string value but it's ambiguous.
- `class` is meant to be a keyword but it's ambiguous. Since `foo` isn't quoted how much extra work does the parser have to perform to know this?
Not using quotes relies on browsers that have always made a best-effort attempt to parse even the most badly broken HTML. This was particularly bad back in the late 90's early 00's.
I think I prefer consistent HTML rather than quotes that change based on the value.
Assuming the browsers run a lexer to take the HTML and convert it into an AST of some kind they would walk the text per-character (or UTF code-point potentially). If the rules were enforced loosely but in a purely forward looking way then `<div class=pants shirts id=small>` would parse as Div token with a class value of `pants shirts id=small`. However I doubt that they're parsed purely forward looking since it's not possible to know from the character position at the `i` in `id` that `id` is a keyword for an argument rather than part of the class value.
So how does the browser know that the class value ends at `id`? Because there are additional heuristics over and above the quote requirement. What probably happens is that it looks forward until it finds some value that's not allowed in the `class` attribute (spaces are allowed for multiple class names), I'd guess in this case the assignment operator after `id`. Once it finds this it says to itself "Hey, `id` is an attribute." So it ends the Div token before `id`, probably stripping the trailing white-space since it's inside an HTML tag, and then starts parsing the `id` attribute.
This behavior of accepting non-compliant HTML is additional complexity over and above strictly parsing the standard. Having to take the "slow" path of waiting until it gets to another attribute doesn't take much, maybe a few dozen actual instructions, the data is probably still in the same cache line. But repeat that 100,000 times for each attribute in a real-world HTML document and it adds up.
Your example is equivalent to <div class="pants" shirts="" id="small">. This may show your error in expecting that it look backwards: no attribute names are considered special, an attribute value is concluded by its closing quote or by characters like space, and attributes don’t have to have values (there are plenty of boolean attributes, which are the most common cases where people omit the ="").
The HTML grammar really isn’t conducive to lexing.
If you’re interested in how it all actually works, I find how the HTML spec defines its parser very approachable.
Not using quotes is actually fully permitted by the HTML5 spec, although use of quotes is recommended. The HTML5 spec formalises this.
The HTML5 spec is somewhat noteworthy in that it was actually put together and agreed upon by the browser vendors/developers, and then became a W3C spec (previously, this has occurred the other way around). HTML5 parsing formalises much of the previous leniency / workarounds.
But things that bother me much more are:
• Putting type="text/javascript" on <script> and type="text/css" on <link rel=stylesheet>. These are 100% useless and I can’t think of any justification for people choosing to write them that way, whereas I can easily for quotes on attribute values.
• Trailing slashes on HTML tags. As far as the parser is concerned, these are completely useless in HTML (though not SVG or MathML). The spec basically says “oh, there’s a trailing slash on the tag? Sigh, don’t they know XHTML died? Skip it.” Worse, I think they’re actively slightly harmful because they may make people think that you can close tags that way, like in XML. You can’t. The trailing slash is only valid on void tags like <img>, where there is no closing tag, and the parser only special-cases ignoring it for convenient compatibility with XHTML/XML documents.
My editor does that, not me.
(I’m speaking specifically of parsing HTML. Other tasks that you may perform on documents are a good deal less robust.)
—
¹ OK, so developers often still use bad HTML parsers in their own apps. But browsers and all good HTML tooling gets it right.
Say I have
then anywhere on that line I can go ci" and vim will jump to the right spot and change what's inside the double quotes. Quotes aren't useless.