6 ms·

> Developers may prefer to strictly parse HTML and any non-compliance results in a "page error". But the websurfers want that page data [...] Note that similar

by dozzie 9y ago

> Developers may prefer to strictly parse HTML and any non-compliance results in a "page error". But the websurfers want that page data [...] Note that similar thing was happening with SSL/TLS connections for a long time: developers may prefer to strictly verify X.509 certificates, but websurfers want that page data. The result of developers bowing to accepting invalid certificates was hurting everybody. Nowadays the situation is much better, because browser developers made visiting sites with self-signed, expired, or incorrectly named certificates significantly harder.

jasode 9y ago
>developers may prefer to strictly verify X.509 certificates, but websurfers want that page data. I categorize that scenario in a different bucket because novice users don't understand the security implications of broken TLS. So, the users don't want that data but they don't know it. The developers in this case are looking out for the user. (Same security situation as developers helping the user by restricting cross-site scripting or address bar hijacking.) To me, that's not the same as the forgiving parsers of HTML and PDF. Whether the HTML is missing closing tags like this: This is paragraph 1. This is paragraph 2. Or is 100% compliant like this: This is paragraph 1. This is paragraph 2. ... the websurfer just wants the page rendered in both cases.
- dozzie 9y ago
 > To me, that's not the same as the forgiving parsers of HTML and PDF. Oh, of course it's not the same. The point is, in both cases users want strictness, but don't know that they want. Users want web pages that are easy for their browsers to parse; "want" to different degree, yes, even an indirect "want", but still. If browsers fail to display web page with invalid markup, developers are forced to fix their sh&t instead of adding another exception to an already big pile of "steaming let's not" in the standard. And we had a precedent of going down this way with X.509 certificates. I think it's a pity that the way is too hard for something not as critical as SSL/TLS.
- inimino 9y ago
 Incidentally, both are 100% compliant, since closing tags on some elements have always been optional in HTML.
- anowicki 9y ago
 Your first example is also probably 100% compliant HTML (it depends on what tag is second immediately followed by): https://www.w3.org/TR/html/syntax.html#optional-tags https://www.w3.org/TR/html/syntax.html#optional-tags

by dozzie 9y ago

jasode 9y ago

>developers may prefer to strictly verify X.509 certificates, but websurfers want that page data. I categorize that scenario in a different bucket because novice users don't understand the security implications of broken TLS. So, the users don't want that data but they don't know it. The developers in this case are looking out for the user. (Same security situation as developers helping the user by restricting cross-site scripting or address bar hijacking.) To me, that's not the same as the forgiving parsers of HTML and PDF. Whether the HTML is missing closing tags like this: This is paragraph 1. This is paragraph 2. Or is 100% compliant like this: This is paragraph 1. This is paragraph 2. ... the websurfer just wants the page rendered in both cases.

dozzie 9y ago
> To me, that's not the same as the forgiving parsers of HTML and PDF. Oh, of course it's not the same. The point is, in both cases users want strictness, but don't know that they want. Users want web pages that are easy for their browsers to parse; "want" to different degree, yes, even an indirect "want", but still. If browsers fail to display web page with invalid markup, developers are forced to fix their sh&t instead of adding another exception to an already big pile of "steaming let's not" in the standard. And we had a precedent of going down this way with X.509 certificates. I think it's a pity that the way is too hard for something not as critical as SSL/TLS.
inimino 9y ago
Incidentally, both are 100% compliant, since closing tags on some elements have always been optional in HTML.
anowicki 9y ago
Your first example is also probably 100% compliant HTML (it depends on what tag is second immediately followed by): https://www.w3.org/TR/html/syntax.html#optional-tags https://www.w3.org/TR/html/syntax.html#optional-tags