Some questions about writing interoperable websites
Thinking more about interoperability fetishism, a few specific web problems occur to me:
Last I knew, not many browsers supported the
font-variant: small-capsCSS property. To use this style interoperably, you’d want to do some CSS detection: if the browser does support that property, use it; otherwise, either use a smaller font size andtext-transform: uppercaseor just avoid using it altogether. You have to write a lot of nasty browser-detection code to make this work.HTML 5 will contain client side storage of name-value pairs with more flexibility than cookies. In particular, you can bind a name-value pair to a particular session. But not all browsers support HTML 5, so you’d need to fall back to using cookies if that’s the only available mechanism. To be interoperable, then, will web developers be expected to write two sets of code, one that uses cookies and one that uses the newer interfaces?
The
elementFromPoint()DOM method will be “a godsend for drag-and-drop scripts”: “If the user drops an element, get the mouse coordinates and use this method to find out which HTML element is located at these coordinates.” I’m not familiar enough with Ajax to know how this would have been implemented before, but it sounds like there wasn’t anything like this in earlier incarnations of the DOM. Presumably if you wanted to write drag-and-drop code, you had to hack around the browsers’ limitations. Now you won’t have to. So again: should developers keep two separate branches going and use browser detection to figure out which one to run?Interoperability purists will insist that your code should be able to work even if the browser doesn’t have JavaScript. If you’re a site like Amazon, and you’d lose a lot of money when even 1% of the browser market can’t use your site, I can see wanting to code for this case: you’d want to fall back to server-side code for more or less everything. If you’re a smaller-time developer, though, the marginal benefit from spending another hour on server-side code (another branch in the tree) seems pretty tiny. Apologies, but: I don’t care how my blog looks under Lynx, or how it looks for the two people in the last year who visited my site using Mosaic. Facebook doesn’t care how it looks under text-only browsers (in this case w3m) either:
Now, it’s a whole different story if someone writes a nice set of abstractions for you. My sense is that the Yahoo! User Interface Library (YUI) is one such set of abstractions. If it takes me no effort to write code that degrades nicely, then I’ll do it. But if the abstractions are client-side-only, I don’t see how they’ll solve the problem of ancient browsers; in that case, the abstraction would need to fall back to server-side code. Does anyone know whether the Google Web Toolkit generates server-side code as well? If it did, that would be pretty sweet.