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