5 ms·
There's still a few nice things about XHTML that I miss. It's really helpful in debugging and catching mistakes. I'll actually force it on for dev and test sys
by capitainenemo 3y ago
There's still a few nice things about XHTML that I miss.
It's really helpful in debugging and catching mistakes. I'll actually force it on for dev and test systems just to quickly identify errors. I've caught hundreds of issues with templates that way. Sure there are markup validators, but the always on strict was nice. And still usable with XHTML5... So long as the web page is being generated by your code, the strictness is a win I think. And you can turn off strict in browsers by serving XHTML5 as HTML5 with text/html content type.
The responseXML in XHR for XHTML is really nice, and still available though mostly useless. I wish when XHTML was abandoned that a responseParsedDOM was offered to avoid some of the exploitable hacks people came up with instead.
XML transforms using XSL could do some pretty nifty tricks with static docs and no other processors but your browser.
So, yeah, don't feel it was wholly a mistake. Sure for random content or user generated isn't a good idea, and it'd be nice if there were clean ways to handle that (not iframes), but saying that your app shouldn't have a strict rendering is like saying JSON should be forgiving of misplaced braces... If you're feeding bad JSON to your modern JS driven app, well, that's your fault and there should be errors and it should be fixed. Similar for XHTML for your server side app IMO.
- nayuki 3y agoGood news: XHTML was never abandoned. It still exists today as an optional serialization format for HTML5. I am using it in practice on my website and described it in great detail: https://www.nayuki.io/page/practical-guide-to-xhtml https://www.nayuki.io/page/practical-guide-to-xhtml
- capitainenemo 3y agoYep! Nice guide. And there's https://www.w3.org/TR/html-polyglot/ https://www.w3.org/TR/html-polyglot/ for polyglots. The main thing you lose (no idea why XHTML5 doesn't add support for this) is <noscript> is ignored. Obviously if you did any other form of JS detection in a session, you can just use that to offer alternate content.
- GoblinSlayer 3y agonoscript is usually abused to death for tracking pixels, "this site requires javascript" warnings and what not.
- nayuki 3y agoEh, even without <noscript>, you could achieve those things by declaring them in the HTML code and then writing a script on the page that hides them immediately. As for the grandparent comment, I checked and <noscript> works fine in XHTML in Firefox. I used this as an example: https://www.nayuki.io/page/caesar-cipher-javascript https://www.nayuki.io/page/caesar-cipher-javascript
- capitainenemo 3y agoInteresting. It isn't officially supported. Browsers do seem to honour it though without parsing errors, even as a tag in the header (say for a redirect fallback instead of JS in a handler). Tested Firefox and Chromium - good to know, had had issues there in the past. Thanks!