3 ms·

The bit about <pre> ignoring leading newlines is essentially a completely different thing from the rest of the article. It’s specifically HTML syntax parser beh

The bit about <pre> ignoring leading newlines is essentially a completely different thing from the rest of the article. It’s specifically HTML syntax parser behaviour <https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody https://html.spec.whatwg.org/multipage/parsing.html#parsing-...>: > If the next token is a U+000A LINE FEED (LF) character token, then ignore that token and move on to the next one. (Newlines at the start of pre blocks are ignored as an authoring convenience.) This is also applied to <textarea>. Personally, I think it was a mistake, because it complicates things and doesn’t do enough to justify itself. If it also did leading whitespace trimming across all lines, it’d be interesting enough to maybe justify itself as an authoring convenience (… though honestly I suspect that’d end up worse), but as it is it’s just an extra complication. I’ve needed to deal with the nuance of its special behaviour more than once or twice, and I’ve seen others stumble over it too. It’s also part of the fairly small pile of HTML features that make it not-round-trippable: it’s only done in parsing; the serialiser doesn’t insert an extra ␊ if it would emit `<pre>␊`. This is one of the many cases that tempts me in the direction of the XML syntax (which, to many people’s surprise, is absolutely still a thing—save a local file with extension .xhtml, or serve over HTTP with MIME type application/xhtml+xml). The fact that XML doesn’t have a parser that guesses what you meant is generally a nice feature. (XML also has whitespace collapsing, xml:space. Honestly it’s interesting in this context, conveying whitespace-handling intent, but I’ll ignore it. Because it’s never coming to HTML.) But we’re stuck with this behaviour, because it would break compatibility. And that’s where a lot of the rest of the article baffles me, because I get the general sense, from the way he presents information, that this guy doesn’t understand a lot of HTML’s history and philosophy, things I’d expect to be understood by a memory of the Angular team. The suggestions made are generally just obviously not suitable for HTML, not just because of compatibility, but also because of philosophy. You think should be different from SPACE? Sorry, I think we’re up to about forty years since that ship sailed; entities/character references are strictly shorthand, and numbered entities are strictly code points. And do you know how confusing it would be if it worked differently? It would be a one-off special case. You think you can add a new entity to handle this? In XML I think you might be able to do that (way too long since I’ve written a DTD to remember clearly), but in HTML they’re called character references, because that’s all they can be, and your non-collapsing space would need to be either something entirely new in the document model, or shorthand for something like <span style=white-space:pre-wrap> </span>. > You'd think the CMS should be able to solve this problem, but it really can't. Uh, yes it can, and they all do, where they accept plain text, by either chunking the text into HTML paragraphs (e.g. "<p>" + s/\n\n/<\/p><p>/ + "</p>"), or by turning your text line breaks into HTML line breaks (e.g. s/\n/<br>/). CMSes do a lot of dodgy stuff like this. If you want to have nightmares, look at WordPress’s wpautop function, and think through the implications of it all. It’s a radioactive wasteland of bad ideas. It’s also rather important to remember that two line breaks in HTML (e.g. <p>A<br><br>B</p>) is not the same as a paragraph break (e.g. <p>A</p><p>B</p>). Consider margins and text-indent, for a start. > How Could we Fix This? The offered solution, “quote your strings”, is what almost all programming languages tend to do. Document languages practically never quote their strings (I can’t immediately think of any even vaguely popular ones that do). Document languages consistently default to text mode, with only markup elements requiring special syntax. As is later noted, there is, of course, absolutely no chance of HTML ever doing anything even vaguely like this. And honestly, if such a breaking change were on the cards, you’d be making far more invasive changes to HTML’s syntax. > 3. HTML already breaks the rules of common text formatting. > • The idea that you can write HTML today by just typing the text you want is a lie. No it isn’t: no one ever suggested that was a feature; there was no dishonesty. HTML is a markup language. —⁂— The remark on template language whitespace control is incorrect: Say hello to {%- username -%} and welcome them to the team! You’ll actually get “Say hello toDeveland welcome them to the team!” which is clearly not what’s wanted. —⁂— For my own part, I have at times seriously considered producing HTML with only the whitespace I mean, and applying something along the lines of `:root { white-space: pre-wrap }`. But then I remember that there’s a lot more that’s dodgy around segmentation, both in the directions of extraneous and missing breaks. For example, this URL and its rendering: data:text/html,<body style=font-family:monospace;width:5ch>Look at C++!<br>X </a> Look at C+ +! X </ a> Viewing on my phone (which, due to narrower column width, is more likely to demonstrate such problems), I think I’ve come across three articles on HN in the last week or so exhibiting this sort of problem. If I were writing much that referred to C++, I would genuinely make something to change it to <nobr>C++</nobr>, and I do sometimes tweak breaking behaviour inside <code> elements to control where breaks can occur. (I’m also the kind of guy who types actual no-break spaces in Bible references where the book has an ordinal, e.g. “1 John 2:3” will have one NBSP and one SPACE.) And in the end… HTML collapsing whitespace has done a lot to quell the two-spaces-between-sentences convention some hold, so it’s not all bad. ;-)

nayuki 2y ago
Awesome comment, thanks. I agree with pretty much everything you said. > tempts me in the direction of the XML syntax (which, to many people’s surprise, is absolutely still a thing—save a local file with extension .xhtml, or serve over HTTP with MIME type application/xhtml+xml) I am one of the very few people who serves content in XHTML mode in practice, and also wrote a detailed guide on what it entails: https://www.nayuki.io/page/practical-guide-to-xhtml https://www.nayuki.io/page/practical-guide-to-xhtml > The offered solution, “quote your strings”, is what almost all programming languages tend to do. Correct, except for shell scripts. In shell, by default everything is a literal string passed into the program, unless it has designators such as a prefix dollar sign. As you can imagine, this causes all sorts of escaping nightmares. And don't get me started about array handling. That's why I find myself reaching for Python instead of Bash, because it's so much easier to build sane, composable, debuggable programs in the former. > I would genuinely make something to change it to <nobr>C++</nobr> I didn't know about the <nobr> element. I looked it up and it's deprecated. However, it can be simulated with CSS white-space:no-wrap. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nobr https://developer.mozilla.org/en-US/docs/Web/HTML/Element/no... > I’m also the kind of guy who types actual no-break spaces in Bible references where the book has an ordinal, e.g. “1 John 2:3” will have one NBSP and one SPACE. Similarly, I am one of the few people who uses NBSP between a number and a unit symbol: 10 kg.
- chrismorgan 2y ago
  A few comments on your practical guide to XHTML, which is otherwise an entirely excellent document: Firstly, you don’t make it clear that XHTML is dead, dead, dead. The HTML Standard superseded it, and although it originally contained a thing still called XHTML, it eventually retired the XHTML name due in part to confusion with XHTML 1 <https://github.com/whatwg/html/pull/2062 https://github.com/whatwg/html/pull/2062>. And so what we have instead is XML syntax for HTML (arguably also a tad misleading due to processing differences like document.write’s absence, tagName case differences and missing features like <noscript>, which feel a bit beyond syntax differences). Honestly, browsers never truly even implemented XHTML; what they implemented was strictly more accurately an XML syntax for HTML. They only validated the XML part, never the XHTML part, and allowed HTML features absent from XHTML. By now, I’d call even XHTML 1.0 or 1.1 validation fairly worthless, given the further divergences in the HTML Standard—though I don’t know what there may be in the way of XML-syntax HTML validation to replace it. Anyway, I’d suggest talking about HTML and XML syntax instead, since that’s been the accepted terminology for the last eight years; or at the very least a note to some such effect at the beginning of the article. Secondly, about boolean attributes there’s another option you don’t mention: setting the attribute to an empty string, e.g. checked="", which is what empty attribute syntax is equivalent to these days. The HTML 4 and XHTML 1 DTDs specified `checked (checked) #IMPLIED`, meaning `checked="checked"` was the only valid value, with the minimised form `checked` as equivalent¹, and `checked=""` invalid, I believe. But in practice, I believe literally no one implemented it the SGML way, and so `.getAttribute("checked")` gave you an empty string on <input checked>… though serialising the element (.innerHTML of parent) in at least Firefox 4.0² turns checked="" into checked="checked". Thirdly, it’s possibly worth noting that <noscript> doesn’t work in XML syntax. Fourthly, maybe not really worth noting, but XML syntax isn’t actually proper XML any more: the <template> tag needs special-casing in the parser <https://html.spec.whatwg.org/multipage/xhtml.html#templateTagXML https://html.spec.whatwg.org/multipage/xhtml.html#templateTa...>. ¹ SGML is weird. It’s not omitting the attribute value like any sane person would expect, but rather the attribute value. Given <!ATTLIST alpha beta (gamma) #IMPLIED> (“element alpha has an optional attribute named beta which has only one legal value, gamma”), the minimised form of <alpha beta="gamma"> is <alpha gamma>; <alpha beta> would be invalid. So I guess XHTML was mildly backed into a corner on the syntax. I doubt even a single user agent ever actually implemented it the SGML way, rather special-casing it; it’s documented that many HTML user agents didn’t actually support <input checked="checked">, only <input checked>. ² Downloaded from https://ftp.mozilla.org/pub/firefox/releases/ https://ftp.mozilla.org/pub/firefox/releases/ and it Just Worked. Unfortunately, I’m on x86_64 Linux without multitarch i686 set up, and 4.0 was the oldest with x86_64 builds. Shouldn’t be hard to get 1.0 running, but my curiosity wasn’t quite great enough for the effort. I was worried 4.0 would be too new, but this "" → "checked" serialisation suggests it was still weird, so ancient browsers probably do much the same. —⁂— Responses to other parts of your comment: • Shell scripting was the main exception I had in mind, for unquoted strings; and they’re something you have to be careful with. Perl has barewords; and they’re typically mostly disabled as a footgun. • I had completely forgotten <nobr> was deemed non-conforming! One of these days I should investigate more thoroughly why, and probably appeal for it to be revived and formalised. It’s a useful and semantically-valuable thing, exactly as much as <wbr>, which I think had exactly the same “this wasn’t even in any W3C HTML spec” problem as <nobr>. In the mean time, I will continue to use it from time to time, as appropriate. • I like to type NARROW NO-BREAK SPACE between a number and a unit, if I reckon a little spacing is called for (normally I don’t).

nayuki 2y ago

Awesome comment, thanks. I agree with pretty much everything you said. > tempts me in the direction of the XML syntax (which, to many people’s surprise, is absolutely still a thing—save a local file with extension .xhtml, or serve over HTTP with MIME type application/xhtml+xml) I am one of the very few people who serves content in XHTML mode in practice, and also wrote a detailed guide on what it entails: https://www.nayuki.io/page/practical-guide-to-xhtml https://www.nayuki.io/page/practical-guide-to-xhtml > The offered solution, “quote your strings”, is what almost all programming languages tend to do. Correct, except for shell scripts. In shell, by default everything is a literal string passed into the program, unless it has designators such as a prefix dollar sign. As you can imagine, this causes all sorts of escaping nightmares. And don't get me started about array handling. That's why I find myself reaching for Python instead of Bash, because it's so much easier to build sane, composable, debuggable programs in the former. > I would genuinely make something to change it to <nobr>C++</nobr> I didn't know about the <nobr> element. I looked it up and it's deprecated. However, it can be simulated with CSS white-space:no-wrap. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nobr https://developer.mozilla.org/en-US/docs/Web/HTML/Element/no... > I’m also the kind of guy who types actual no-break spaces in Bible references where the book has an ordinal, e.g. “1 John 2:3” will have one NBSP and one SPACE. Similarly, I am one of the few people who uses NBSP between a number and a unit symbol: 10 kg.

chrismorgan 2y ago
A few comments on your practical guide to XHTML, which is otherwise an entirely excellent document: Firstly, you don’t make it clear that XHTML is dead, dead, dead. The HTML Standard superseded it, and although it originally contained a thing still called XHTML, it eventually retired the XHTML name due in part to confusion with XHTML 1 <https://github.com/whatwg/html/pull/2062 https://github.com/whatwg/html/pull/2062>. And so what we have instead is XML syntax for HTML (arguably also a tad misleading due to processing differences like document.write’s absence, tagName case differences and missing features like <noscript>, which feel a bit beyond syntax differences). Honestly, browsers never truly even implemented XHTML; what they implemented was strictly more accurately an XML syntax for HTML. They only validated the XML part, never the XHTML part, and allowed HTML features absent from XHTML. By now, I’d call even XHTML 1.0 or 1.1 validation fairly worthless, given the further divergences in the HTML Standard—though I don’t know what there may be in the way of XML-syntax HTML validation to replace it. Anyway, I’d suggest talking about HTML and XML syntax instead, since that’s been the accepted terminology for the last eight years; or at the very least a note to some such effect at the beginning of the article. Secondly, about boolean attributes there’s another option you don’t mention: setting the attribute to an empty string, e.g. checked="", which is what empty attribute syntax is equivalent to these days. The HTML 4 and XHTML 1 DTDs specified `checked (checked) #IMPLIED`, meaning `checked="checked"` was the only valid value, with the minimised form `checked` as equivalent¹, and `checked=""` invalid, I believe. But in practice, I believe literally no one implemented it the SGML way, and so `.getAttribute("checked")` gave you an empty string on <input checked>… though serialising the element (.innerHTML of parent) in at least Firefox 4.0² turns checked="" into checked="checked". Thirdly, it’s possibly worth noting that <noscript> doesn’t work in XML syntax. Fourthly, maybe not really worth noting, but XML syntax isn’t actually proper XML any more: the <template> tag needs special-casing in the parser <https://html.spec.whatwg.org/multipage/xhtml.html#templateTagXML https://html.spec.whatwg.org/multipage/xhtml.html#templateTa...>. ¹ SGML is weird. It’s not omitting the attribute value like any sane person would expect, but rather the attribute value. Given <!ATTLIST alpha beta (gamma) #IMPLIED> (“element alpha has an optional attribute named beta which has only one legal value, gamma”), the minimised form of <alpha beta="gamma"> is <alpha gamma>; <alpha beta> would be invalid. So I guess XHTML was mildly backed into a corner on the syntax. I doubt even a single user agent ever actually implemented it the SGML way, rather special-casing it; it’s documented that many HTML user agents didn’t actually support <input checked="checked">, only <input checked>. ² Downloaded from https://ftp.mozilla.org/pub/firefox/releases/ https://ftp.mozilla.org/pub/firefox/releases/ and it Just Worked. Unfortunately, I’m on x86_64 Linux without multitarch i686 set up, and 4.0 was the oldest with x86_64 builds. Shouldn’t be hard to get 1.0 running, but my curiosity wasn’t quite great enough for the effort. I was worried 4.0 would be too new, but this "" → "checked" serialisation suggests it was still weird, so ancient browsers probably do much the same. —⁂— Responses to other parts of your comment: • Shell scripting was the main exception I had in mind, for unquoted strings; and they’re something you have to be careful with. Perl has barewords; and they’re typically mostly disabled as a footgun. • I had completely forgotten <nobr> was deemed non-conforming! One of these days I should investigate more thoroughly why, and probably appeal for it to be revived and formalised. It’s a useful and semantically-valuable thing, exactly as much as <wbr>, which I think had exactly the same “this wasn’t even in any W3C HTML spec” problem as <nobr>. In the mean time, I will continue to use it from time to time, as appropriate. • I like to type NARROW NO-BREAK SPACE between a number and a unit, if I reckon a little spacing is called for (normally I don’t).