
Stop ‘Using’ “Useless” ‘“‘Quotes’”’ - todsacerdoti
https://medium.com/lambdax/stop-using-useless-quotes-1bba0a88406a
======
falcolas
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.

Oh. And: Stop Using Medium. TYVM

~~~
kaetemi
"Medium."

------
mikl
Nope. I’d much rather keep my code uniform, than have to think about when to
use quotes or not.

And if other people following the specs bother you so much, maybe seek OCD
treatment.

~~~
posix_me_less
"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."

~~~
mikl
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.

~~~
posix_me_less
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.

------
chrismorgan
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.

~~~
astura
> I can’t think of any justification for people choosing to write them that
> way

My editor does that, not me.

~~~
chrismorgan
Huh. Which editor? I might consider filing a bug report.

------
rad_gruchalski
Looking at his website, the man can't decide himself: view-
source:[https://pocztarski.com/](https://pocztarski.com/)

------
seanhunter
I use quotes so it's easier to use a text object to edit the attributes in
vim.

Say I have

    
    
       <div id="foo">......
    

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.

------
Traster
If I want to write

    
    
        <div id="mydiv"></div>
    

I write

    
    
        <d[tab][leftarrow][space][i][tab]mydiv
    

My text editor can't do that guess work if the existence of the quotes depends
on what I'm going to name my div id.

------
TehCorwiz
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.

~~~
chrismorgan
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.

~~~
TehCorwiz
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.

~~~
chrismorgan
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.

------
wwv25
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.

~~~
7786655
Unquoted attributes _are_ valid HTML.

~~~
wwv25
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.

------
swalls
Any editor made in the last 20 years has syntax highlighting around strings,
to not quote-delim hurts readability in this case.

~~~
chrismorgan
Any editor made in the last 20 years has syntax highlighting around _attribute
values_ , not strings, in HTML. To not quote-delimit makes no difference.

------
exabrial
Good lord, do you really want to die on that hill? I miss the day of well
defined schemas. Parsing HTML is a minefield these days.

~~~
chrismorgan
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.

------
polyacr
I don't think this person knows what he/she/it is talking about.

------
thomasedwards
I guess he can’t use more than one CSS class.

    
    
        <a href=/lovely/ class="button button-primary">Lovely</a>
    

That should trigger him.

This stinks of IE6 privileges.

------
lolsal
Quotes around attribute values in HTML tags are not useless.

~~~
chrismorgan
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.

~~~
lolsal
Sorry, maybe I misunderstood or misread the article. The source article makes
this claim:

> 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

------
411111111111111
The only reason why leaving out the quotes in html actually works is because
browsers autocorrect incorrect html...

~~~
chrismorgan
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.)

~~~
411111111111111
Ah, you're correct, I misremembered that. It's only invalid with XML, but it's
been a long time since valid html was valid XML I guess.

Fwiw, at least chrome autocorrected it before rendering... Though that might
be out of date as well? Idk

~~~
chrismorgan
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.

~~~
411111111111111
Nor have I ever written about autocorrected XML?

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"

~~~
chrismorgan
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.

~~~
jimsmart
No idea why you are downvoted, this is totally accurate.

