Death To The Div(russellheimlich.com)
russellheimlich.com
Death To The Div
http://www.russellheimlich.com/blog/death-to-the-div/
12 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">
...
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>
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!
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.
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 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.
<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)
<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)
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.
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.
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.
I hate to nitpick. But <address> is probably a bad example in this case as the tag <address> already exists in HTML 4.
Convert it to <div class='address'> or something along those lines.
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.
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.
[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.
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.
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.
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.
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.
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.
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.
"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?
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?