I’m one of those people who believes the web shouldn’t be so forgiving with junk inputs. The argument at the end is, “Hey, relax. It’s kinda funner that way.”
I mean, people tried to make XHTML happen, but it turned out that “display a blank page if a document is slightly malformed” is not actually behaviour that anyone wants in practice.
And yet, blank pages when things are slightly malformed (or even just completely randomly because of nobody knows what) is what we actually get today when some javascript error happens on a SPA…
Though I’d also note that blank pages is not what actually happened with XHTML - you got a pretty detailed explanation for why it didn’t work, which generally made fixing it very easy, so even rudimentary testing on the dev side resolves the issue, and it’d help prevent mystery problems later like one of the error recovery algorithms putting the submit button outside the form if one template fragment happened to be used on that load, so clicking on it simply had no effect… yes, I’m still bitter that bug went to production!
So yes, that is what I want in practice, and that’s (one of many reasons) why own web things work this way, in both dev and prod deployments. (And doing it this way also makes auto testing easier; template partials all most be valid nodes on themselves, so plugging them together is not going to mysteriously break things elsewhere on the form either, so end users almost never see the “mismatched tag” etc errors; the dev process catches them with minimal effort.)
I adopted XHTML for my own things and never had problems. It’s much easier to work with than HTML5 because I can parse it into a generic tree and process it in arbitrary ways, interleaved with other things. XHTML can contain SVG and I can treat the SVG as just a tree of stuff I don’t understand when parsing. Atom and XMPP can embed XHTML and they’re just trees that the outer layer processor can extract and pass to something that renders XHTML. I recently learned that there are some tags in HTML5 that not only don’t need closing but may not be closed and browsers do surprising things if you close them. That’s a far worse design choice than anything in XHTML because every step of processing needs to know that these special nodes do not have children.
I remember a story on here fairly recently about how you can’t sanitise HTML with anything other than the browser that is going to display it. My initial reaction was probably something like “haha what? this nerd hasn’t heard of parsing then serialising?” but no, it’s pretty much true. Not only is it remarkably difficult to divine from the specs how things like and are supposed to be parsed, it’s only temporary protection if you do. They could add another weird element tomorrow.
It reminds me of “only Perl can parse Perl”, except the undecidability comes from the future instead of the past. XML was sometimes a bit annoying, XSLT and XSD were both horribly flawed languages, but it never even approached this level of stupidity.
Much of the problem with XHTML was that there was a lot of website authoring software that was incapable of ensuring that the site is valid XML at all stages. It’s possible to get away with a loosey-goosey XML-from-text-templates system if you are careful, but it gets harder if you accept third party content. There’s Mark Pilgrim’s classic rant about invalid XHTML which uses as examples the blogs of lots of XML advocates (all invalid XML) and malformed blog pingback as a longer illustration. An unfair summary might be that Wordpress was to blame, but there were similar stories from newspaper publication systems.
Ironically, modern web authoring software tends to be more DOM-oriented than template-oriented, so it’s in a better position to make good use of XHTML — or would be, if it hadn’t been killed by HTML5.
The point they make is fun and backwards compatibility. Try running a piece of software from 1990s from any other platform. Good luck. Corporate control and other factors have basically made this impossible.
Not on the web. This is why I love the web. It is unowned and it works.
Well, “fun” is pretty subjective, but backwards compatibility (and, especially historically, sideways compatibility between various not-exactly-standard-compliant diverging implementations) is a very serious requirement, and the way that it has influenced the evolution of the web is fascinating to me.
As a recovering correctness zealot, I must admit that browser behavior makes a mockery of Postel’s Maxim and has more or less completely gotten away with it. Sandboxing and other preemptive vulnerability mitigation strategies make that possible, I suppose.
There’s an important lesson here for software in general, but I’m not sure I can formulate it clearly.
Great post, I love learning about how forgiving HTML and going into its quirky details.
I just have a nit that we should retire the Chuck Norris memes if we can. They were never funny to begin with and he is a pretty shitty person, that it’s a waste to give him any more attention.
I’m one of those people who believes the web shouldn’t be so forgiving with junk inputs. The argument at the end is, “Hey, relax. It’s kinda funner that way.”
Eh. Good point. Thanks for the reminder.
I mean, people tried to make XHTML happen, but it turned out that “display a blank page if a document is slightly malformed” is not actually behaviour that anyone wants in practice.
And yet, blank pages when things are slightly malformed (or even just completely randomly because of nobody knows what) is what we actually get today when some javascript error happens on a SPA…
Though I’d also note that blank pages is not what actually happened with XHTML - you got a pretty detailed explanation for why it didn’t work, which generally made fixing it very easy, so even rudimentary testing on the dev side resolves the issue, and it’d help prevent mystery problems later like one of the error recovery algorithms putting the submit button outside the form if one template fragment happened to be used on that load, so clicking on it simply had no effect… yes, I’m still bitter that bug went to production!
So yes, that is what I want in practice, and that’s (one of many reasons) why own web things work this way, in both dev and prod deployments. (And doing it this way also makes auto testing easier; template partials all most be valid nodes on themselves, so plugging them together is not going to mysteriously break things elsewhere on the form either, so end users almost never see the “mismatched tag” etc errors; the dev process catches them with minimal effort.)
I adopted XHTML for my own things and never had problems. It’s much easier to work with than HTML5 because I can parse it into a generic tree and process it in arbitrary ways, interleaved with other things. XHTML can contain SVG and I can treat the SVG as just a tree of stuff I don’t understand when parsing. Atom and XMPP can embed XHTML and they’re just trees that the outer layer processor can extract and pass to something that renders XHTML. I recently learned that there are some tags in HTML5 that not only don’t need closing but may not be closed and browsers do surprising things if you close them. That’s a far worse design choice than anything in XHTML because every step of processing needs to know that these special nodes do not have children.
I remember a story on here fairly recently about how you can’t sanitise HTML with anything other than the browser that is going to display it. My initial reaction was probably something like “haha what? this nerd hasn’t heard of parsing then serialising?” but no, it’s pretty much true. Not only is it remarkably difficult to divine from the specs how things like and are supposed to be parsed, it’s only temporary protection if you do. They could add another weird element tomorrow.
It reminds me of “only Perl can parse Perl”, except the undecidability comes from the future instead of the past. XML was sometimes a bit annoying, XSLT and XSD were both horribly flawed languages, but it never even approached this level of stupidity.
Much of the problem with XHTML was that there was a lot of website authoring software that was incapable of ensuring that the site is valid XML at all stages. It’s possible to get away with a loosey-goosey XML-from-text-templates system if you are careful, but it gets harder if you accept third party content. There’s Mark Pilgrim’s classic rant about invalid XHTML which uses as examples the blogs of lots of XML advocates (all invalid XML) and malformed blog pingback as a longer illustration. An unfair summary might be that Wordpress was to blame, but there were similar stories from newspaper publication systems.
Ironically, modern web authoring software tends to be more DOM-oriented than template-oriented, so it’s in a better position to make good use of XHTML — or would be, if it hadn’t been killed by HTML5.
The point they make is fun and backwards compatibility. Try running a piece of software from 1990s from any other platform. Good luck. Corporate control and other factors have basically made this impossible.
Not on the web. This is why I love the web. It is unowned and it works.
Well, “fun” is pretty subjective, but backwards compatibility (and, especially historically, sideways compatibility between various not-exactly-standard-compliant diverging implementations) is a very serious requirement, and the way that it has influenced the evolution of the web is fascinating to me.
As a recovering correctness zealot, I must admit that browser behavior makes a mockery of Postel’s Maxim and has more or less completely gotten away with it. Sandboxing and other preemptive vulnerability mitigation strategies make that possible, I suppose.
There’s an important lesson here for software in general, but I’m not sure I can formulate it clearly.
I still cannot fathom how css gray ended up as darker than dark gray.
They are from different color palettes.
Some of the colours the author discovered are hilarious! I might actually use #grass and #midnight.
My favourite is still
#FAAAAB.Edit: Call me a nationalist, but
quebecproduces#00ebecwhich is a teal or light blue!Again: I am losing my head at
weeg/weegiei’m a pretty big fan of #sonic, haha
Great post, I love learning about how forgiving HTML and going into its quirky details.
I just have a nit that we should retire the Chuck Norris memes if we can. They were never funny to begin with and he is a pretty shitty person, that it’s a waste to give him any more attention.