Death To The Div | Hacker News Reader

Death To The Div

russellheimlich.com

60 pointskingkool6837 comments

You can achieve the same effect now using XHTML namespaces. I defined <question:required>, <question:optional>, <question:subquestion>, <answer:trigger> tags when working on a dynamic survey application I did that would hide or display followup questions based on answers to previous questions.

I'm quite interested in how you use it. Do you have an example?

Same way you use namespaces in any other XML document. Do something like:

   <html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:question="http://www.my.unique/ns/question">
   ...

I love being able to use pure SVG markup in XHMTML just by having it in a separate namespace (of course, there is trouble in IE land ...)

Exactly like smanek described to define the tags. Then you use them like this:

  <question:required>
    <question:text>
      Would you recommend us to a friend?
    </question:text>
    <answer:choice>
      <input type="radio" value="Yes">
    </answer:choice>
    <answer:trigger>
      <input type="radio" value="No">
    </answer:trigger>
    <question:subquestion question:trigger="No">
      Please explain why you wouldn't recommend us:
        ...
    </question:subquestion>
  </question:required>

I then used jQuery to bind events to the newly created tags to hide/display subquestions based on the response, and css to style it.

Maybe this is a dumb question, but do you have any problems with cross-browser support for that situation? I'd love to try this out in my app -- div soup is a killer.

Using the namespace and jQuery there was no problem in IE6/7, FF 1.5/2, Safari, Chrome, and Opera 8 (this was in 2008)

Yes! I've always thought that HTML should be more like XML in that arbitrary tags should possess little presentational meaning without an associated stylesheet. Perhaps we'll call this new concoction... HXTML!

I can't tell if you're being sarcastic or not, but let's remember that <div id="article"> is just as meaningless as <article> without the stylesheet, and the second one looks nicer, and has more chance of becoming an (unofficial?) standard.

The difference is that a non-expert (such as myself) probably has a rough idea what div means. To know article is actually a div, I'd have to make sure there wasn't a valid html <article> tag.

That's a good point. I learned all my web development skills by looking at other people's code. If they were using tags that weren't actually "real" HTML tags, but just ones they made up and defined with CSS, it would have been a hell of a lot harder to get to where I am today.

Ah yes, very good point!

Yah, my post was laced with (semi-blatant?) sarcasm surrounding the fact that this, as byoung2 mentioned, is already possible using a technology that was chosen for deprecation.

I'm not of the pro-XHTML side, but it will be interesting to see what happens after HTML 5. XHTML attempted to solve, or at least provide a stop-gap to, a lot of problems that may not go away as easily as we hope.

<article> has a major difference from <div> -- it resets the heading heirarchy.

<article> and <section> are nearly identical with no reason for both to exists (the only difference is that only <article> can have a pubdate attribute)

This is exactly what I thought when I read the article.

However, one needs to remember the reasons for the pushback that XML and XHTML got in the web developer/designer community: The SGML based HTML allows all these nice quirks through the SGML declaration and DTD. There it is defined that tags are case insensitive, BR is always empty, you don't need to close TD and P etc...

XML on the other hand has this stric notion of well-formedness where you can parse any well-formed document without a DTD or schema. This is what allows you to more easily invent your own tags and attach a style to them.

Thus, with sticking with an SGML based language, HTML made a decision to make the authoring of the core language more convenient while sacrificing some of the benefits that XML would have had. It's a design decision and it has been debated a lot already. It's just something people should keep in mind.

I like this thought, but I'm not going to suggest that I can see all the ramifications and which ones we'd all end up hating in 10 years.

Like never being able to define another HTML keyword again without hosing random sites that used it first?

Would the DOCTYPE declaration of the html version be able to overcome that problem?

YES!

That's what namespaces are for.

XML namespaces are terrifying. Please don't make me do that just to make websites.

I'm probably wrong, but isn't this exactly what XSLT does? You define your custom tags and document structure in xml and then apply the visual styles with xsl?

This would be a lossy transformation. An <address> tag would still need to be transformed into a <div> which would destroy the association between the tag name and its contents. After that getElementsByTagName('address') wouldn't return any results, browser plugins wouldn't see the connection between the original and rendered data, etc.

Convert it to <div class='address'> or something along those lines.

I hate to nitpick. But <address> is probably a bad example in this case as the tag <address> already exists in HTML 4.

I agree 100%.

This would make it a lot easier to edit pages with tricky navigation divs. It would help in many other places too.

I always thought that was (on of) the point of css, with display essentially defining what a tag was.

You can also achieve the same effect using XML and XSLT.

[edit]^ beaten by the few minutes it took me to log in! Great minds et al.

Sadly there is an important feature missing in one of the bigger browsers: Firefox does not support disable-output-encoding.

https://bugzilla.mozilla.org/show_bug.cgi?id=98168

The bug was opened almost exactly 8 years ago. All other major browsers support XSLT quite nicely.

Lispers had this for ages too; CL-WHO lets me define my own tags and define what to translate them to, divs or spans or whatever.

One problem with allowing arbitrary elements is that the browser won't know whether element <foobar> should display as block, inline, etc. CSS styles would need to be specified accordingly whenever custom elements would be used.

Treat it exactly like a div. So display as block with default div positioning, margin, border etc. CSS can then customize as needed.

This has the side effect of being unable to introduce any new tags in the HTML spec which have any properties different to div. (How would the browser know if it was a pseudodiv or a new tag? Possibly DOCTYPE, but that as a switch has had a varied history, which is one of the reasons for HTML5's <!DOCTYPE html>.) This solution creates more problems than it solves.

Also interesting to note is that FF3 (and quite possibly older versions) interpret and display custom tags which have been styled using CSS.

i've been thinking about this considerably lately. Isn't this in many ways what facebook has done with FBML? Just created there own tags, and get a javascript to manipulate it?

I understand that it is a dtd, but can't you create any element you want and define it's behaviour in a dtd? I'm still just getting into the research on this.

Meh, I don't see the problem with "div soup". The only thing I agree with that's mentioned in the article is that at least you could tell where a specific tag started and ended. But whenever I nest div's more than a few levels deep, I always leave comments in my code for the closing tags to state what specific id/class they are closing. Is that really so hard? No, it's not.

Also, as others have mentioned, having made-up tags littered throughout a site's HTML would lead to two problems:

- For people learning HTML, you'd have no idea what tags are real and which are make-believe

- It would be hard to update the HTML standard in the future without breaking a bunch of sites

Both of those are serious problems from my POV.

It's a big problem for accessibility. Modern web pages are a nightmare for screen readers, for example. Tags which explicitly mark where the navigation is, amongst other things, would be a great help.

I'm not sure that I see the value of just being able to define whatever tags you want, though. Sounds like a recipe for disaster to me.

"you could tell where a specific tag started and ended"

Wouldn't a nice view-source mechanism with syntax and, perhaps, block highlighting, suffice?

Wouldn't it also be nice to have it pretty-print the HTML and JavaScript of the page upon request?

For people just learning HTML: I think they would have an easier time if they were taught that HTML tags mean something rather than perform a function. I know when I was learning HTML you would use tags to make a document look a certain way much like you would use MS Paint to draw a picture. The web has evolved and HTML takes care of describing what the content is. That's a big difference. Wouldn't the concept of "Use whatever tags you want to describe your content but here is a list of ones that are already reserved for other functions." be simple enough to pick up? It's the same idea with programming.

Updating HTML standard: That's what the doctype could be for, for introducing new tags and functionality without breaking the old. Atleast that is what the doctype should be used for.

Reply on news.ycombinator.com