But for now, the rel tag is easy, supported, and makes getting a little bit of meta information to your script quite easy.

Two uses I’ve written recently are:

(1) Creating abstracted div collapse scripts.  The script just looks at the rel tag for the link and finds the matching rel tag among a class of divs on the page.  Anything matching is shown, anything not matching is hidden.  I never have to go back and touch the script, and I only have to add a rel tag to my divs.

(2) Letting my css-based navigation know which page we’re currently on.  With includes, the idea that your navigation should reflect your current page location fell out of favor a bit.  Kind of suspicious, if you ask me.  It often seems designers and front-end developers adapt their pet styles to suit the latest technology.  Regardless, it’s dang easy with the rel tag to revert to the “old” style of location-aware navigation.  I just drop a rel tag in my nav links and a matching rel tag in my content div within the content include file.  They search for each other.  They find one another.  It’s like an interface component romance paperback.

Part of the reason that HTML 5 is going to include some developer-defined tags is that people have been using rel and a few other tags to include meta data (and sometimes some not-so-meta data) in their front-end code.  I completely understand the cold chill that comes over some folks when they start contemplating gobs of data gooping up the front end.  I also think it’s possible to fret too much.  As the linked article above points out well, it’s possible to include some meta data inline and still be semantically useful, degrade nicely, and not offend the browser.

If people hadn’t been expanding on the uses of the rel attribute so effectively, we may not have had the push for user-defined attributes in HTML 5.  This is a good thing.  It’s important to remember this truism: no amount of standards will stop people from writing ugly code.  But, paying attention to what developers are doing in practice and honoring those practices in new standards definitions can benefit everyone.

Dagnabit!  What is the point of combining xml and html standards if I can’t use them together all the time?  I know, you may be thinking, but xml is not html , no matter what you throw into your nodes.  You’re right, and this is exactly what jQuery tells us.  You can grab the text contents of any node, but if you have html tags in there, the .text() method in jQuery will just look right past them.  As it should.  This works fine, for little snippets like my titles, but what if I want to put some (ostensibly) well-formatted html code in my data?  Further, what about all those applications where you want to store html snips in a database and read them out in XML?  How do you get around this?

For that, we’d want to use the .html() method of jQuery, and for that, my friends, we suddenly get quite strict.  XML, according to jQuery, is not html, and so has no innerHTML quality for the .html() method to grab.  It doesn’t matter, says jQuery, if your html code is so well formatted that it can be parsed as xml…it’s just not possible to access an html-specific property that does not exist.

Like fun, I say!

But before we get to the solution, let’s heartlessly go over some available options:

1) We could punt on the whole jQuery thing and use Flash, which knows just what to do with a string of html parsed from within an xml node.  Furthermore, Flash has a nifty .htmlText property on its text fields, and although the formatting of said html pales compared to real css, it will faithfully render as html anything you tell it to, caveat codeur.  Since the project in question did involve some Flash, this was an option, but one of the points of the project was to take the same xml data and have both flash and jQuery parse it for different purposes, and thereby provide ease for content providers and improve accessibility.  So doing the whole thing in Flash was out.

2) We could escape the heck out of all our characters and turn the whole node into a mess of html character codes.  Un-fun to code and messy for the content people.  Also, I tried that and it rendered out a block of actual html onto my screen.  I’m sure I could have reconverted those characters back into actual html behind the scenes, but again, un-fun and a hassle.

3) Use a fancy xml consuming plugin or script.  There are some neat ones out there, and I tried one in particular that looked pretty good, but it seems they have a common issue – you have to know what tags you’re looking for in order to seek and replace within the script.  Some of them will hunt for anything that looks like an html tag in the string and convert that, but mostly these plugins seem like scripts that people wrote to perform functions for themselves, and then extracted and shared.  Which I applaud.  But these were not what I was looking for, and I found the implementation sometimes troublesome.

4) [Warning: bad solution] Hand jQuery a bag of grapes and say it’s “nature’s jellybeans” (at least that’s what my mom used to do to us).  It goes like so: grab your xml file with an ajax() call, and use the optional key/value pair:

dataType: “html”

And then you’d do ike so:

$.ajax({ url: “myXMLdoc.xml”,
dataType: “html”,
success: function(xml){
var myHtmlContent = $(‘node’,xml).eq(id).find(“nodeName”).html();
$(“#targetdiv”).html(myHtmlContent);
}
});

…and there you have it!  Or, would…if…

…can you see where this is going?

…search your feelings, Luke…

…if only Internet Explorer handled the XMLHTTPRequest result like the rest of the world!  Like most Microsoft stuff, IE, with its own version of the XMLHTTPRequest (someone correct me if I’m wrong on that), wants to get too clever and won’t let you, the developer, tell it what kind of data you’d like to see (even if it’s either of several types that are verging toward common standard).  No siree!

Supposedly, recent versions of IE (7+) have their own XMLHTTPRequest, not the previous Microsoft HTTPRequest.  However, the Microsoft XMLHTTPRequest doesn’t behave like the other girls and boys, even in the recent versions of IE.  Now, this post didn’t start off to be a discussion of the supposed evils of Microsoft’s proprietary habits.  But who else has almost 11 million results on a google search of how much they suck?  Hint: not Chrome (3 M), Firefox (1 M), or Safari (1 M).  (Can’t evaluate Opera on this critrion because sadly a lot of people out there think that real, actual opera – the music – sucks too).  For comparison: “yanni sucks” (400 K), “death metal sucks” (700 K), “paris hilton sucks” (1 M), “the lions suck” (1 M), “tv sucks” (11 M), and “new york sucks” (12 M).  So, yeah.

Anyway, after that turgid digression, finally, we come to the solution.  And…

It’s simple!  Maybe I’m, like, the last one to figure this out, but you just use XML’s CDATA declaration, and wrap it around our html code within our xml node.  If I had found that idea earlier, it would have saved me some time, but I would have missed a brain-scratching moment or ten for sure.

Anyway, this is fascinating to me for several reasons:

a) When oh when is Microsoft going to just give up and give us a truly standards-compliant web browser?  Maybe they should spin off a company whose software is intuitive and flexible and plays nice with others.  Oh wait, they already did that.

b) With the XHTML standard in full force, it seems totally silly that one would have to pass off perfectly valid XHTML within an xml document as CDATA.  Isn’t the whole point of XHTML to be able to one day have a semantic web, where code itself can be meaningful?  How far away are we when it’s trouble to get even well-formatted html out of my xml nodes without basically commenting it out?  In theory, that means I can’t parse through my html elements, which seems to go against the whole ethos of XHMTL.

Well, heck.  I remember when CSS was going to put an end to bad code.

By this time, I’ve worked my head around the idea that, to many developers (and clients) out there, CSS is the one true way and tables are only good for displaying data – that is, data that they consider data and not data that someone else might consider data.  See my previous post on semantic html for more carping on this topic.  But enough negativity – I would hereby like to add my voice to the growing number of developers calling for a new future in CSS: [paraphrase] “If CSS is the golden chalice of front-end web development, how come it can interpret between pixels, point sizes, and em sizes, but it can’t add 1 + 1?”

Now, I know, purists will say that Javascript is for math, and CSS is for styling.  Just simply get a good Javascript library and do your math there.  The problem is that other purists will say that using Javascript to generate your CSS positions is pure hackery.  And yet other purists will say “everyone come to my website to check out my awesome CSS hacks!”

Let’s face up to it: there are some things that CSS is just not that good at.  The idea that you are ruining your SEO by adding three lines of table code to get your column heights equalized seems dubious.  But, I’m willing to go with that and check out some truly weird and wonderful tricks to arrive at the same solution that would take literally half a dozen lines of code using old clunky tables.  But yeah, I’m sure google’s robots are completely fooled by a table and a couple of <tr> tags… [sarcsasm alert].

Anyway, if CSS is going to be responsible for our layout and can have access to and control some of the DOM, why can’t we just do:

#layerid {
width:20%;
margin:10px auto;
height:width * 0.5;
}

That would really open things up and allow for some more creative, interactive layouts.  Hopefully, CSS 4 will allow for some of this.  It should be, in my opinion, a no-brainer.

The real dream has been that one day, HTML and XML would be combined (not just in terms of the XHTML standard), and that the web would turn into a big soup of meta information.  This would allow all sorts of wonderfully customizable content, searching, cross-threading, and possibly, someday, even help create some kind of internet based solely on context, rather than infrastructure and IP.  Positives: super-personalized web-browsing, advertisements, and content aggregation.  Negatives: super-personalized web-browsing, advertisements, and content aggregation.

But I digress.  The flock to div tags as cleaner and more semantically meaningful has been a beneficial one, but for we web developers who remember the [good?] [bad?] old days, there are more than a few cases in memory of the development community rushing en masse to the next greatest thing, and then flipping it into reverse with the release of the next IE browser / web standard / greatest thing.

It has gotten to the point where I have seen postings looking for people who write div- and css-based code – no tables allowed!

This is madness.  What is XML, after all, than a method of organizing data?  When you’re getting an XML feed from a backend, you are converting your data from a table-based format (database) to a markup-based format.  Same data (we hope).  The real question here is page layout.  Surely web developers who are using and editing one another’s code would rather see:

<div id=”header”><!– header –></div>

than

<table border=”0″ class=”table” cellpadding=”0″ cellspacing=”0″>
<tr>
<th><!– header –></th>
<tr>
etc.

But while that div is nice and neat and it allows for better accessibility, it does not do as well when it comes time for, let’s say:

this.

Also, despite the wonderful blessing that is CSS (it can be quite soothing), when something goes wrong with the style sheet, the result can be disastrous.  Of course, we all want to write code that degrades gracefully, but the fact is that, the more we ask of our code – especially as we utilize style sheets – the more risk we run that if something breaks on the backend (certainly our code would never break), or a user is tied to a hopelessly outdated browser, the result will be unintelligible.

But back to semantics, for their own sake.  Perhaps it comes down to a particular aesthetic, but the notion of a fully semantic web makes me think of those kitschy items that have the word for the item printed on them, for example a mug that says “MUG”.  Maybe there is a bit too much big-picture here, for a change.  Net neutrality’s goal is access and publishing rights for anyone with an internet connection.   It’s not hard to imagine a semantic web that wants to take choices out of our hands and push certain content in front of our eyeballs for us.

As for us developers, if the goal is good, solid code, the answer seems to be, like with much else, a healthy mix of new and old, with an eye towards every tool and its best use.