12 ms·

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 unambiguousl

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 6y ago
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 6y ago
  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 6y ago
    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.
jimsmart 6y ago
> 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.

chrismorgan 6y ago

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 6y ago
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 6y ago
  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.

jimsmart 6y ago

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