Putting the X back into XHTML
Setting aside for the moment all concerns as to whether HTML or XHTML is the better doctype, I was wondering this morning why we don’t take more advantage of the extensibility and modularisation of XHTML.
To wit—I was working on a page with a list of locations and a Google Maps instance, where clicking on the location would re-focus the map. I needed a way to tell the JavaScript which link had been clicked, and figure out which latitude/longitude coordinates the map should move to. There are several possible ways to approach this problem; one could put the coords directly into the onclick event of the link:
<a href="#" onclick="showThisHotel(52.635, 0.0223); return false;">Seaview Hotel</a>
Ack, inline scripting. Or I could give the link a value via the id attribute and look up the coords from a JavaScript array or JSON object elsewhere in the page:
<a href="#" id="hotel123">Seaview Hotel</a>
But that means that (assuming the hotel data is coming from a datasource of some kind) that I have to loop through the array twice—once to output the links, again to create the JS array. Inefficient.
Finally, I could store the coords in an unused attribute or class name for retrieval with JavaScript:
<a href="#" rel="52.635, 0.0223">Seaview Hotel</a>
Not really the correct or semantic use of the rel attribute, though. Bad.
eXstensibility
Surely the most sensible way of encoding the metadata into the link would be to extend the doctype with some custom attributes to hold the information?
<a href="#" lat="52.635" lon="0.0223">Seaview Hotel</a>
The new non-standard attributes are now accessible with getAttribute(), and both the XHTML and JavaScript code makes a lot more sense to any other developers needing to work on it.
So why don’t we do this more often? Doctypes aren’t that hard to understand and extend, and it was for this precise reason that XHTML was created. What do you think?
Further reading
- Developing DTDs with defined and extended modules
- XML.com: Extending the Web
- Extending XHTML to add the target attribute back into Strict
Filed under: XHTML.
Technorati tags: xhtml javascript doctype
Bookmark this article with del.icio.us
Previously: iPhone Apps - what's the point?
Next: Pink for October
Comments
- Matthew Pennell
- 551 days ago
To take your second point first, Ben, the example
href="#"links were only done that way for brevity; in the real world they would be links to either the map or to a specific location page. And yes, if they were links to the map then the lat/long could be extracted from the URL—so let’s assume that they link to semi-static pages (”/seaview-hotel.html”, for example), and perhaps the behaviour we are wanting is a hover, not a click.In respect to the namespacing of attributes: surely that is only an issue if you plan to release your XHTML module into the wild? If the doctored doctype is only for internal use, where’s the harm in taking a copy of the standard Strict and adding your own attributes to the A element?
- #2
- Jonathan Snook
- 551 days ago
I’d be more inclined to jump on the HTML5 bandwagon and use data-* attributes.
data-coord=”rel=”52.635, 0.0223”
But I’m a rebel like that…
- #3
- Ben Ward
- 550 days ago
Snook is right to mention the data- prefix attributes in HTML5. They are the new official solution for this sort of thing, although I’m still sceptical about whether it’s a real problem to solve or not.
With regard to namespaces, if you were to make use of XHTML specifically for this sort of extension, then they are necessary. You’d be referencing a separate XML schema for your geo attributes.
Editing the DOCTYPE to add new attributes isn’t making use of XHTML’s designed extensibility, it’s making a new language (and is a technique that can apply to both HTML and XHTML alike, albeit with the caveat that a custom DOCTYPE is not valid HTML)
- #4
- Matthew Pennell
- 548 days ago
Eric – but the DTD isn’t used by the browser, it’s only of use to validators?
- #6
Two things come to mind.
Firstly, in terms of the extensibility of XHTML, those attributes you’ve added would need to be namespaced. You can’t just drop new nodes into the global namespace. That may throw in exciting compatability/usefulness issues in IE. I never can remember how its JavaScript parser handles namespaced attributes.
Second though, even once you move the extensions into geo:lat and geo:long, I’m not sure I see the value of custom attributes for JavaScript functionality.
That link, with a href=”#” attribute should never be part of the page content. It should be added dynamically by the same script that initialises the map. OR, it should enhance an existing link to a map on a different page.
If it’s generated by a script (in which case I’d personally generate button elements rather than href-less links), the geo data can be loaded directly by the script as well, probably through JSON, and therefore be available in a much faster and convenient manner to reading non-standard attributes from the page content. It also completely avoids the unquantified risk of browser incompatibility with your choice of custom attribute names, as well as keeping data and the script using the data together, reducing the cost of future maintenance.
If it’s generated from a set of static links — presumably linking to the co-ordinates on some other mapping service, those co-ordinates will already be included in the map URL — something like http://maps.google.com/maps?ll=45.460131,-105.161133&z=13. So in this case, the co-ordinates are embedded in the link. Whilst not as quick to parse out as using DOM methods, it would be better for your script to handle the co-ords from the URL and avoid duplicating the data output to the page (as that increases the risk of inconsistency and error).