Death To The Div

http://www.russellheimlich.com/blog/death-to-the-div/

by kingkool68 • 17 years ago

60 37 17 years ago

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.

CamperBob• 17 years ago

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

gregc• 17 years ago

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

fauigerzigerk• 17 years ago

That's what namespaces are for.

byoung23• 17 years ago

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.

bbx• 17 years ago

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

smanek• 17 years ago

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 ...)

nkohari• 17 years ago

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.

byoung23• 17 years ago

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)

ars• 17 years ago

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.

mcav• 17 years ago

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.

chime• 17 years ago

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

d4rt• 17 years ago

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.

totalrager• 17 years ago

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?

nimbix• 17 years ago

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.

jamesbritt• 17 years ago

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

hellotoby3• 17 years ago

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

hellotoby3• 17 years ago

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.

aw3c2• 17 years ago

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.

fretlessjazz2• 17 years ago

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!

sho• 17 years ago

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.

lsc• 17 years ago

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.

fretlessjazz2• 17 years ago

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.

blasdel• 17 years ago

<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)

voidpointer• 17 years ago

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.

pedalpete• 17 years ago

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.

hellotoby3• 17 years ago

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

schammy2• 17 years ago

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.

AlisdairO• 17 years ago

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.

rbanffy• 17 years ago

"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?

kingkool682• 17 years ago

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.

mahmud• 17 years ago

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.

Death To The Div

Related Stories