5 ms·

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 abs

by 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
  Thanks for the great feedback. I agree with what you said, though there are details I'd like to respond to. > XHTML is dead / retired the XHTML name / XML syntax for HTML It's complicated. XHTML 1.0 certainly existed, I coded to that standard, and I used W3C's validator. XHTML 1.0 is basically HTML 4.01 modified to fit XML syntax. XHTML 2 was drafted but never implemented as far as I knew. XHTML 1.0 code is still forward compatible with the current so-called XHTML5. In that sense, XHTML is not dead in name or in implementation, and it's just the trunk of history whereas XHTML 2 is a dead branch. I would prefer to continue using the XHTML name, despite what you legitimately pointed out regarding "XML syntax for HTML". > boolean attributes I never knew about that complicated behavior. Thanks for the introduction; I'll have to look further into it. > <noscript> doesn’t work in XML syntax It works perfectly fine and some of my pages have examples. I'm not even using CSS to hide the element; I'm solely relying on the browser's default behavior. https://www.nayuki.io/page/calculate-gcd-javascript https://www.nayuki.io/page/calculate-gcd-javascript > <template> tag needs special-casing in the parser I didn't know this and it saddens me that the <template> DocumentFragment behavior breaks the uniformity of the XML DOM. > SGML is weird It is indeed, just from my cursory study of it. I only know enough SGML to point out that it's weird and then give a few links to more information. I only mentioned SGML in my article to explain where the weirdness of HTML came from. > It’s not omitting the attribute value like any sane person would expect, but rather the attribute value. Looks like you misspelled something there, having repeated the same phrase. > the minimised form of <alpha beta="gamma"> is <alpha gamma>; <alpha beta> would be invalid I did not expect that, and it doesn't seem to match the behavior of HTML. > why <nobr> was non-conforming To me it seems to have a presentation quality like <b>, <i>, <u>, <tt>, <center>, etc. > exactly as much as <wbr> I think there's no way to design <wbr/> to be expressed CSS because it really is a single point in the text rather than a span.
  - chrismorgan 2y ago
    • <noscript> doesn’t work in XML syntax. From the spec comes this description of why <https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element https://html.spec.whatwg.org/multipage/scripting.html#the-no...>: > The noscript element is only effective in the HTML syntax, it has no effect in the XML syntax. This is because the way it works is by essentially "turning off" the parser when scripts are enabled, so that the contents of the element are treated as pure text and not as real elements. XML does not define a mechanism by which to do this. That’s the sense in which I say it doesn’t work. In the way people most commonly use it, to add a “JS disabled so this won’t work” message in the body, you’re saved by the user agent stylesheet including `@media (scripting) { noscript { display: none !important; } }`. But if you try doing things like varying styles via <noscript>, that won’t work. And that’s why <noscript> is (nominally, as ever) disallowed in XML syntax. • As for <nobr> seeming presentational: it can be used presentationally, but so can <strong>, and often is. If I think to places where I’ve used it, most of the time perception of the content would have been materially harmed by line breaks. And that’s the real test of whether something is presentation; framed another way, in a Reader Mode, should it remain or disappear? I expect inline styles and spans may be stripped by a Reader Mode, including <span style="white-space:nowrap">, but I say <nobr> should remain. Drawing connections to Unicode may be helpful too; most things there are Unicode characters for, if there are HTML things for they should be preserved as likely content semantics: I wouldn’t expect a Reader Mode to mangle my Unicode NO-BREAK SPACE to SPACE or my NARROW NO-BREAK SPACE to THIN SPACE or SPACE—they can be presentational (or even stenographic!), but they’re used for content semantics. And <nobr> is content semantics. • <wbr> can be expressed in CSS easily: <span style="display:inline-block"></span>.

by nayuki 2y ago

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
Thanks for the great feedback. I agree with what you said, though there are details I'd like to respond to. > XHTML is dead / retired the XHTML name / XML syntax for HTML It's complicated. XHTML 1.0 certainly existed, I coded to that standard, and I used W3C's validator. XHTML 1.0 is basically HTML 4.01 modified to fit XML syntax. XHTML 2 was drafted but never implemented as far as I knew. XHTML 1.0 code is still forward compatible with the current so-called XHTML5. In that sense, XHTML is not dead in name or in implementation, and it's just the trunk of history whereas XHTML 2 is a dead branch. I would prefer to continue using the XHTML name, despite what you legitimately pointed out regarding "XML syntax for HTML". > boolean attributes I never knew about that complicated behavior. Thanks for the introduction; I'll have to look further into it. > <noscript> doesn’t work in XML syntax It works perfectly fine and some of my pages have examples. I'm not even using CSS to hide the element; I'm solely relying on the browser's default behavior. https://www.nayuki.io/page/calculate-gcd-javascript https://www.nayuki.io/page/calculate-gcd-javascript > <template> tag needs special-casing in the parser I didn't know this and it saddens me that the <template> DocumentFragment behavior breaks the uniformity of the XML DOM. > SGML is weird It is indeed, just from my cursory study of it. I only know enough SGML to point out that it's weird and then give a few links to more information. I only mentioned SGML in my article to explain where the weirdness of HTML came from. > It’s not omitting the attribute value like any sane person would expect, but rather the attribute value. Looks like you misspelled something there, having repeated the same phrase. > the minimised form of <alpha beta="gamma"> is <alpha gamma>; <alpha beta> would be invalid I did not expect that, and it doesn't seem to match the behavior of HTML. > why <nobr> was non-conforming To me it seems to have a presentation quality like <b>, <i>, <u>, <tt>, <center>, etc. > exactly as much as <wbr> I think there's no way to design <wbr/> to be expressed CSS because it really is a single point in the text rather than a span.
- chrismorgan 2y ago
  • <noscript> doesn’t work in XML syntax. From the spec comes this description of why <https://html.spec.whatwg.org/multipage/scripting.html#the-noscript-element https://html.spec.whatwg.org/multipage/scripting.html#the-no...>: > The noscript element is only effective in the HTML syntax, it has no effect in the XML syntax. This is because the way it works is by essentially "turning off" the parser when scripts are enabled, so that the contents of the element are treated as pure text and not as real elements. XML does not define a mechanism by which to do this. That’s the sense in which I say it doesn’t work. In the way people most commonly use it, to add a “JS disabled so this won’t work” message in the body, you’re saved by the user agent stylesheet including `@media (scripting) { noscript { display: none !important; } }`. But if you try doing things like varying styles via <noscript>, that won’t work. And that’s why <noscript> is (nominally, as ever) disallowed in XML syntax. • As for <nobr> seeming presentational: it can be used presentationally, but so can <strong>, and often is. If I think to places where I’ve used it, most of the time perception of the content would have been materially harmed by line breaks. And that’s the real test of whether something is presentation; framed another way, in a Reader Mode, should it remain or disappear? I expect inline styles and spans may be stripped by a Reader Mode, including <span style="white-space:nowrap">, but I say <nobr> should remain. Drawing connections to Unicode may be helpful too; most things there are Unicode characters for, if there are HTML things for they should be preserved as likely content semantics: I wouldn’t expect a Reader Mode to mangle my Unicode NO-BREAK SPACE to SPACE or my NARROW NO-BREAK SPACE to THIN SPACE or SPACE—they can be presentational (or even stenographic!), but they’re used for content semantics. And <nobr> is content semantics. • <wbr> can be expressed in CSS easily: <span style="display:inline-block"></span>.