Hacker News Reader

Comment by JadeNB | Hacker News Reader

> Sure your xhtml won't validate, but it probably wasn't going to anyway.

Writing XHTML without validating is sort of like writing Haskell without type-checking, isn't it? It seems like all the pain with none of the benefit.

View on HN

Much closer to writing C without type-checking, and even that might be too strong. Back when that was the cool thing to do, I put a lot of effort into always generating valid XHTML out of a sense of pride, and I'm not sure it ever had any practical benefits. The things that the validator checked for and the things that browsers actually had issues with didn't have a lot of overlap.

Same here, and it helped me exactly once: it taught me about proper html escaping of variables before setting them in the source (& broke in a <a href="...">).

Not sure if that was worth all the trouble.

Writing valid XHTML was good practice for writing valid XSLT. Browsers would definitely choke on invalid XSL. I remember spending a fair amount of time looking at that pale yellow Firefox error screen that would point out invalid XML documents during my XSL days.

It's been a while, so I'm not completely sure this is true, but I think any XHTML within an XSL document also had to be valid XML (that would also validate against the XHTML schema), so you couldn't get away with as much as you could with rendering a plain XHTML page.

It wasn't that we weren't validating, but instead there was always something that prevented us from getting to 100% that we were unable to fix. That is what I mean by 'probably will not validate anyway'.

Reply on news.ycombinator.com