So I’ve dabbled in Single Sign-On solutions a couple of times before, and none of them have struck me as particularly usable. They all function, certainly – but the amount of technical acumen required to try and get them up and running; or to actually use them tends to be too great.
So Facebook has been around for a while, they have a rather widely-used API, and now they’ve announced “Facebook Connect” – a single sign-on solution that uses your FB credentials to log you in to an external website. Nice.
So, on a lark, and borne of my extraordinary laziness and lack of desire to input yet-another-set-of-credentials-into-another-form, I added FB Connect to a personal app of mine. It only took me a little bit of an evening and an hour or so in the morning. I was surprised. It works pretty well. I didn’t have to totally overhaul my application – which is always nice. One thing I found that was very weird was that everything is asynchronous. You do all your work in Javascript. I would expect to do code like – “okay, facebook, make sure this guy is logged in. Then, do this other thing, and so on.” That’s not how it works, it’s all callbacks, because it’s all done asynchronously. You instead say, “Okay, facebook, make sure this guy is logged in, and as soon as you’re sure he is, do this whole big other thing for him.”
It’s an odd way to program, but probably the absolutely right way to design this API. Very AJAX-friendly. Okay, we’ll come back to this in a minute.
I’ve been working on some web stuff lately – both experimenting and trying to do real useful stuff – in XHTML5. I’m tired of people saying that certain things aren’t possible, when in fact, they are; they’re just really hard. So even though I myself have taken XML (and, by extension, XHTML) to task, I thought I’d give it a try.
I even did the super-nerdy “Serve as application/xhtml+xml to those who can read it, text/html otherwise” and that even worked. I did some CSS stuff that IE can’t read, but if you’re using IE, I don’t care about you that much. I’ve even tried to make it so the XHTML contains no ‘presentational’ tags – like div’s for forcing breaks, etc. And it looks kinda crappy, but I’m still working on it. The Content-Type trick I used didn’t work at first, but I got it to work all of the sudden and I watched my pages break right before my eyes. It really just helped me find missing close tags, I didn’t find it all that jarring.
The whole thing got me to thinking – it really seems that XHTML 1.1 and 2.0 are the real ‘problem’ here, and that XHTML 1.0 may actually be a decent standard. It seems to work OK. And the idea of mixing tags together from both XHTML and another namespace in order to get the best of both sounded appealing – and yet, that’s precisely what the Facebook Connect API does! It creates “XFBML” which turns into facebook-branded login buttons and so on. So I thought I’d give a quick look to my just-recently-built FB Connect app and see if I could do the same XHTML nerd thing I did before. Seems pretty obvious – I mean, even the <html> tag has namespace attributes for both xhtml and xfbml, it sounds just like this stuff is real XHTML and it should just work.
*****BZZZZT!!!!**** WRONG! Big fail. It does not work at all. It seems to be dependent upon HTML javascript rules. One of which I was able to work around, the other; they will have to. And there may of course be other problems buried in there that I can’t see yet because it doesn’t yet work. Hell, I even copied it to my website and tweaked my local copy and am still having trouble getting it to work. I got to the point where I am trying to de-obfuscate code, so I think that means “I lose”.
So this is a very weird world we’re now in – here’s one of the highest traffic websites in the world (fifth most popular at the time of this writing according to Alexa), and they’re encouraging people to write this hybridized, weird semi-xhtml/semi-html markup. The thing that I find most impressive is that it even works at all, to be honest.
And it does work, and works well. And lots of people are using it, as far as I know, but I haven’t heard anything about its general unusableness in XHTML. It just makes me wonder, is all. Is validity really important? Certainly, it makes sense to define a language and have everyone try and implement it to that standard, but going nuts about valid this and valid that does seem a little…I dunno…disconnected. Or, more likely, the Web Powers That Be have dictated that XHTML = dumb, so people are just making stuff in HTML4.01 or HTML5, hence no one noticing that FB Connect is totally broken in real XHTML mode.
I think Facebook cares about what *works* and doesn’t give a shit about what’s *valid*. And I think the standards committees have historically cared about what’s *valid* and haven’t given a shit about what’s *worked*. And I am willing to bet that somewhere in the middle is where we should be.
The irony here is that the feature I despised most in XML – namespaces – *could* find its way into HTML5 (Hey, FB is using it!). And HTML5 is really a reaction to some of the more horrible missteps made in XHTML 1.1 and XHTML 2.0. Which is the primary form of XML on the web. I’ve got to admit, though, it does certainly show a somewhat pleasant way to extend HTML – the HTML stuff goes in its namespace, the crazy crap you just invented goes into your own namespace, and if I can’t read your crazy crap, I won’t display anything. Deal? Deal.
Edit – Stupid Blogger preview doesn’t match what you post. Whoops. Added back those pesky carriage returns.