Hacker News new | ask | show | jobs
by thorax 5968 days ago

  That is, it is impossible to generate malformed webpages while using XHP.
While the purist in me thinks this is great if everyone else uses it, the immense amount of productivity lost when I first started using kid templating (e.g. http://turbogears.org/about/kid.html ) really burned me on this whole concept.

Sometimes I really do want to make a quick test page without crossing all my i's and dotting all the t's. Importing non-perfect markup from a designer is a big pain, too, in this kind of templating system.

And, though it's unfair to say so, some companies do well enough without 100% valid XML markup: http://blog.errorhelp.com/2009/06/27/the-highest-traffic-sit...

1 comments

Saving 14 bytes per request is something only a very few sites need to think about...

For the rest of us, clarity and semantically correct code are much more useful.

Wasn't there just a thread complaining about how the end tags make HTML so much more verbose and difficult to read, and that's why people are writing preprocessors like HAML and XHP? I've found that the code is much clearer when you omit your end tags.

As for semantic correctness - it's in the HTML spec, and every major modern browser handles it correctly. Sometimes I wonder if Google's the only folks who actually read the W3C specs, there's been so much cargo-cult advice passed down between web developers.

The "always close your tags" advice came from the early 2000s, when people were pushing XHTML as a way to make your HTML pages XML compliant (the big buzzword back then). It gives essentially no benefit to users, no benefit to developers, costs you bandwidth, makes your pages slower, and clutters up your markup.

Actually, I once visited a website that didn't close its tags where that practice hindered my use of it. That page used backticks instead of curly quotes, so I wanted to use a bookmarklet to fix that. The bookmarklet cycles through every DOM text node and replaces the text. When I tried to run it on that page, nothing happened – probably because there were no text-only nodes, because the page was treated as one big tag. So browsers don't handle missing closing tags completely correctly, and therefore one should include closing tags.
If you don't close your tags,

<div>foo<a>bar<span>baz box

how can you tell the difference between,

<div>foo<a>bar</a><span>baz</span> box</div>

and

<div>foo<a>bar<span>baz</span> box</a></div>

By "don't close your tags", I mean "don't close your tags when the HTML spec does not require you to." You still need to close your <a>, <div>, and <span> tags. You don't need to close your <li>, <th>, <tr>, <td>, <dl>, <dt>, and several other tags. You don't even need to open your <html> and <head> tags, if you're not doing funky stuff like putting comments in them.
The HTML tag closing rules specify they only get closed when they have to be. So neither of your solutions is correct. It is:

<div>foo<a>bar<span>baz box</span></a></div>

my solution was to merely demonstrate the difference between what a programmer writes and what gets sent as an http response.
Rendered html that will be sent has an http response should have ending tags. That doesn't mean the programmer/designer has to write them: #a dumb ruby example: def p(content) "<p>"+content+"</p>" end

p "hello" #=> "<p>hello</p>"

SGML is fun. It looks like XML, but is way crazier.