4 ms·

Opening can of worms: did you serve them with any of the available XML MIME types? If not they worked simply because of the bug in the browsers (SHORTTAG means

by rimliu 7y ago

Opening can of worms: did you serve them with any of the available XML MIME types? If not they worked simply because of the bug in the browsers (SHORTTAG means a different thing in HTML compared to XML) and all XHTML code served with HTML MIME type would be littered with ">" if browser treated it right ;)

innocenat 7y ago
I once toyed with the idea of serving XHTML page as application/xhtml+xml, but the fact the browser (back then, not sure about now) will just display XHTML error and doesn't render anything was a deal breaker for me.
- sureaboutthis 7y ago
  By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.
  - ricardobeat 7y ago
    With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.
    - sureaboutthis 7y ago
      Has nothing to do with what I said. IE couldn't handle XHTML until IE9 https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/ https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/
      - ricardobeat 7y ago
        Sorry, but you’re mistaken. The parent never brought up IE - he was referring to the fact that when serving XHTML with the correct mime-type (application/xhtml+xml), any error causes the page not to render at all. This behaviour is intended per spec and was the same across all browsers, not due to lack of support. It’s called “draconian error handling”, consequence of being XML, and was a major factor in the death of XHTML.
        sureaboutthis 7y ago
        The death of XHTML was brought on by the then crop of kids who don't want to understand how computers work and want it all done for them with someone else's code cause computer science is too hard and they'd have to think and thinking is too hard. While I often hear this "draconian error handling" about XML/XHTML by such people who then complain that a language compiler is just as draconian and real programmers complain when it's not and doesn't catch their every little mistake. It's this lack of education and drive for the pursuit of knowledge and understanding that caused XHTML to fall out of favor and no other reason.
        bmn__ 7y ago
        That's all well until you have external content (e.g. blog with comments or blog roll headlines). Many an enthusiastic Web author in the 2000s migrated off XHTML again. Not because getting it right is too hard (each fix for each problem is quite straight-forward and often trivial), but because when you have the choice between having a completely broken page/site until you have time to log on and fix it and having a miniscully broken part of a page that's easily ignored by a visitor, then the idealism was just too bothersome. Unfortunately, that's human nature. Also see: rms's principles as exemplified by his life-style and how many follow his example perfectly.
frenchyatwork 7y ago
br is an empty element (https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Stric...), so should work fine
- rimliu 7y ago
 In XHTML. No browsers treat documents (no matter the doctype) as XHTML unless the proper MIME type is used. Without it your XHTML markup is treated as SGML application (which HTML is) and thus means completely different thing. See http://jkorpela.fi/html/empty.html http://jkorpela.fi/html/empty.html for the details.
 - detaro 7y ago
 although nowadays there's HTML5, which isn't an SGML application. It allows (but ignores) the closing slash for void elements (like ), and specifies error recovery for non-void elements that treats it as if the slash didn't exist.
 - wahern 7y ago
 is syntactically correct HTML5. So is , but that's beside the point. From https://html.spec.whatwg.org/#start-tags https://html.spec.whatwg.org/#start-tags > 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. From https://html.spec.whatwg.org/#void-elements https://html.spec.whatwg.org/#void-elements > Void elements: area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr The problem with making the SOLIDUS optional for so-called void elements is that the set of void elements isn't finite across time. A new one could be added in the future, which means any document which relies on implicit syntactic behavior requires an updated parser simply to get the most basic AST. XML and XHTML formalized a distinction between syntax from semantics, permitting forward compatibility for code, like low-level parsers, only processing the syntax. The WHATWG made the argument that out in the real world syntactically correct documents are almost the exception, not the norm. Because that's true the vision of being able to ubiquitously slice-and-dice documents with a shared syntax but distinct internal semantics was not attainable as a general matter. Any software consuming HTML out in the open universe would always need to be aware of contemporary HTML semantics even for low-level parsing. The insistence on separating syntax from semantics for HTML had a high cost but very little realized benefit. However, the benefits are attainable within a closed universe, such as a CMS. And this is why HTML5 doesn't require, but nonetheless permits, XML- and XHTML-compliant syntax. It's not even treated as an error or exception, not in the way that other malformed but recoverable constructs are. A self-closing tag is syntactically valid, so there's absolutely no reason not to use it other than convenience. Excluding it out of convenience is perfectly acceptable, but in some situations--e.g. when using the more general and diverse ecosystems of XML and XSLT processors--it can be extremely inconvenient to exclude the SOLIDUS.

by rimliu 7y ago

innocenat 7y ago

I once toyed with the idea of serving XHTML page as application/xhtml+xml, but the fact the browser (back then, not sure about now) will just display XHTML error and doesn't render anything was a deal breaker for me.

sureaboutthis 7y ago
By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.
- ricardobeat 7y ago
  With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.
  - sureaboutthis 7y ago
    Has nothing to do with what I said. IE couldn't handle XHTML until IE9 https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/ https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/
    - ricardobeat 7y ago
      Sorry, but you’re mistaken. The parent never brought up IE - he was referring to the fact that when serving XHTML with the correct mime-type (application/xhtml+xml), any error causes the page not to render at all. This behaviour is intended per spec and was the same across all browsers, not due to lack of support. It’s called “draconian error handling”, consequence of being XML, and was a major factor in the death of XHTML.
      - sureaboutthis 7y ago
        The death of XHTML was brought on by the then crop of kids who don't want to understand how computers work and want it all done for them with someone else's code cause computer science is too hard and they'd have to think and thinking is too hard. While I often hear this "draconian error handling" about XML/XHTML by such people who then complain that a language compiler is just as draconian and real programmers complain when it's not and doesn't catch their every little mistake. It's this lack of education and drive for the pursuit of knowledge and understanding that caused XHTML to fall out of favor and no other reason.
        bmn__ 7y ago
        That's all well until you have external content (e.g. blog with comments or blog roll headlines). Many an enthusiastic Web author in the 2000s migrated off XHTML again. Not because getting it right is too hard (each fix for each problem is quite straight-forward and often trivial), but because when you have the choice between having a completely broken page/site until you have time to log on and fix it and having a miniscully broken part of a page that's easily ignored by a visitor, then the idealism was just too bothersome. Unfortunately, that's human nature. Also see: rms's principles as exemplified by his life-style and how many follow his example perfectly.

frenchyatwork 7y ago

br is an empty element (https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict https://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Stric...), so should work fine

rimliu 7y ago
In XHTML. No browsers treat documents (no matter the doctype) as XHTML unless the proper MIME type is used. Without it your XHTML markup is treated as SGML application (which HTML is) and thus means completely different thing. See http://jkorpela.fi/html/empty.html http://jkorpela.fi/html/empty.html for the details.
- detaro 7y ago
 although nowadays there's HTML5, which isn't an SGML application. It allows (but ignores) the closing slash for void elements (like ), and specifies error recovery for non-void elements that treats it as if the slash didn't exist.
- wahern 7y ago
 is syntactically correct HTML5. So is , but that's beside the point. From https://html.spec.whatwg.org/#start-tags https://html.spec.whatwg.org/#start-tags > 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. From https://html.spec.whatwg.org/#void-elements https://html.spec.whatwg.org/#void-elements > Void elements: area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr The problem with making the SOLIDUS optional for so-called void elements is that the set of void elements isn't finite across time. A new one could be added in the future, which means any document which relies on implicit syntactic behavior requires an updated parser simply to get the most basic AST. XML and XHTML formalized a distinction between syntax from semantics, permitting forward compatibility for code, like low-level parsers, only processing the syntax. The WHATWG made the argument that out in the real world syntactically correct documents are almost the exception, not the norm. Because that's true the vision of being able to ubiquitously slice-and-dice documents with a shared syntax but distinct internal semantics was not attainable as a general matter. Any software consuming HTML out in the open universe would always need to be aware of contemporary HTML semantics even for low-level parsing. The insistence on separating syntax from semantics for HTML had a high cost but very little realized benefit. However, the benefits are attainable within a closed universe, such as a CMS. And this is why HTML5 doesn't require, but nonetheless permits, XML- and XHTML-compliant syntax. It's not even treated as an error or exception, not in the way that other malformed but recoverable constructs are. A self-closing tag is syntactically valid, so there's absolutely no reason not to use it other than convenience. Excluding it out of convenience is perfectly acceptable, but in some situations--e.g. when using the more general and diverse ecosystems of XML and XSLT processors--it can be extremely inconvenient to exclude the SOLIDUS.