Hacker News Reader

Comment by Arnavion | Hacker News Reader

This reasoning is why I write all the web pages for my personal projects using XHTML. I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc. Everything's consistent in XHTML.

View on HN

Agreed. Years ago I started doing all my projects in XHTML because I found that debugging silent HTML errors was not fun.

Silent errors include things like malformed tags and attributes, incorrect nesting structure (thus also messing up where CSS rules are applied), and unescaped left-angles and ampersands.

This is why I've always advocated DTD-validation of HTML (which is shockingly underused).

I've never actually seen anyone validate their HTML. If you suggested this in most companies, they would look at you like you had two heads.

I'm pretty sure Moz has HTML validator built into its SEO tool, so it may be more common than you think solely because of that. We validate HTML at my company—If we don't we'll hear about it next time our boss runs an SEO check,

A good text editor will validated against the DTD as you type. And after you publish, you can use https://validator.w3.org/

About a decade ago it was a pretty commonplace thing to happen.

HTML 4/4.1 was kind of messy, and could have rendering issues. So going with an (x)HTML validator was a common thing, as well as a marketable value proposal to clients.

HTML 5 had much "saner" implementations, so validators fell by the wayside as they weren't as necessary for compatibility.

The Firefox source viewer (not the developer tools DOM viewer) does validation. It will highlight bad tags in red and if you hover over them it shows the error.

How can you validate HTML when most of the HTML these days is templated and generated dynamically?

It turns into a complete document eventually.

It's why I stopped using hand coded markup at all, aside from markdown for article data. Everything else is data pushed into templates that generate "whatever the code is that the client needs to receive", and let the build tools figure it out. That's what they're for.

As long as you're sure it will never be interpreted as HTML, you can do that. Which is harder than it should be, because doctype declarations are ignored. One lost header or unforseen embedding and everything after that <script /> tag gets eaten.

I've started using haml recently, it handles this for you and works well for me.

You shouldn't have to remember it, but you editor could and should.

If you are writing <p>something <div>like this</div><p> then your editor knows you are making a mistake and can highlight it.

If on the other hand you are not closing tags that autoclose, how can your editor tell you? There is no way to know it's not intended.

The editor could have a setting for that.

But mostly I meant that you don't have to close the autoclosing tags.

XML validators are much more common in editors than HTML validators, probably because XML is both easier to parse and used for a lot more than XHTML.

I write and edit all my Genshi [1] templates as xhtml, so I can validate and process them as crisp clean hi-fidelity xml, and then pump them out to browsers with the html serializer [2].

If I were inclined to follow Google's guidelines on omitting optional tags, it would be easy to write a stream filter that removed them [3].

But I prefer source templates to have all the explicit properly indented structure, so they're easier to validate and process with XML tools (and by eye), and unintentional mistakes don't sneak through as easily.

For the same reason, I also prefer not to write minified JavaScript source code: that should be done by post-processors, no humans. ;)

[1] https://genshi.edgewall.org/

[2] https://genshi.edgewall.org/wiki/ApiDocs/genshi.output

[3] https://genshi.edgewall.org/wiki/Documentation/streams.html#...

interesting - which mime/type do you use?

application/xhtml+xml as it's supposed to be, though it's not that I have a choice since Github sets all the headers.

So you don't? Coz it would be nuts.. I'd wager 90%+ of the 3rd party JavaScript out there will choke on it.

You can use text/html. Technically it wouldn't be an XML resource, but it's correct for HTML5. You can also use an xhtml doctype[1]. And don't forget that the HTML5 namespace is http://www.w3.org/1999/xhtml! [2] So basically you use your xhtml tools and just publish as HTML5.

[1] https://www.w3.org/TR/html5/syntax.html#obsolete-permitted-d... [2] https://www.w3.org/TR/html5/infrastructure.html#namespaces

"I can't be bothered to remember which tags are self-closing, which tags need explicit closing tags which can't be combined into the opening tag, etc"

You're right lets not bother ourselves with this small things, cause === and == do the exact same comparison in Javascript and all browsers are exact replicates when implementing html, css and javascript.

Beyond all the sarcasm, in reality, web programming is a hassle. But other programming languages and markups have their quirks as well. I'm glad you found a solution, but it doesn't mean we shouldn't look at the fine details of a specification.

I don't understand your argument. Yes, web programming has lots of warts and subtle behaviors and inconsistencies. So shouldn't we jump on a chance to remove a small part of that from our day-to-day development? OP isn't advocating ignorance of the spec, just a way not to need to reason with it as often.

No argument, just a comment that displays my disapproval of not fully complying with the spec before blaming it.

How is anyone not complying with the spec by not micro-optimizing away legal-but-redundant tags?

>cause === and == do the exact same comparison in Javascript

I also don't bother remembering how == works. I use === everywhere. The reason is the same - lower cognitive overhead.

>all browsers are exact replicates when implementing html, css and javascript

The browsers I care about all parse XML correctly.

>I'm glad you found a solution, but it doesn't mean we shouldn't look at the fine details of a specification.

I'm only talking about myself, yes. I only make websites for my personal projects. I'm certainly not a web dev by profession or even by hobby.

Reply on news.ycombinator.com