xmlns Considered Harmful

I’ve just spent about a day banging my head against a wall, only to discover that the problem was entirely caused by an XML attribute that was tacked onto the XML standard after XML 1.0 was “finalized”. (Fascinatingly, files which use this tag are still labeled XML 1.0. Apparently it’s part of XML 1.0 “second edition” — a new meaning of “1.0” that I hadn’t previously encountered.)

That attribute is xmlns (the “ns” stands for “namespace”) and it’s kind of symbolic of what a clusterf*ck W3C has managed to be.

So here’s the deal. If you put an xlmns attribute in an XML node then it switches that node and all descendants of that node into a new namespace (which is defined by a pretty much arbitrary string — by convention a URI pointing to documentation of the DTD). In my case the xmlns string was a URN referring to a physical book by ISBN. Handy.

But that wasn’t the problem. The problem was finding out that it was an attribute that was making all the tags in an XML file I was trying to process disappear. If I saw a tag <title> then it would not be recognized by <xsl:template match=”title”>. Now, this is probably just an obvious gotcha for anyone who happens to know what xmlns does, but to my mind it’s simply a violation of everything XML is supposed to be about.

First of all, XML has explicit namespaces that work exactly as you’d expect. E.g. <xsl:template … > is a tag in the xsl namespace. The nice thing about  this is it’s really clear which tags are in the xsl namespace, and it’s also going to be clear even if I take a fragment of the XML tree, because every tag in the xsl namespace has an xsl: in front of its name. But xmlns simply turns all the tags in the tree below it to garbage. <document xmlns=”my-arbitrary-string”><title>…</title> … </document> does not contain a document or title tag any more. You can’t “see” them until you remap the arbitrary xmlns string to a local namespace tag, (e.g. <xsl:stylesheet …. xmlns:foo=”my-arbitrary-string” …>) and then use it everywhere (so <xsl:template match=”foo:title”>> would then match <title …>). But if you grabbed a subtree below <document xmln=…> using your XML library then that subtree would lose its namespace and map to the unadorned tag as expected.

I hope I’m not the only person who thinks this is f*cked up.

Now, if you’re a programmer, you’re probably used to OO languages having some facility for making a given object or class easier to refer to within a specific context, e.g. with import foo.bar.someClass; someClass x; x = new someClass. This is handy, especially in overly normalized languages like Java, as it saves both typing and improves code readability.

But XML is designed so that the content of any node of an XML tree should be valid XML that makes sense by itself. Most programming languages — especially C-syntax languages —  assume you need to read declarations to understand the code below them.

The way it should work is that you should be forced to map a custom namespace tag (like foo) to a specific namespace string (e.g. <?xmlns foo=”my-arbitrary-string”> and then use it consistently everywhere (<foo:document><foo:title>), so it’s explicit and subtrees will be explicitly assigned to that namespace (and even if you’d lost the mapping it would be clear that you needed it). That would make sense. After all, that’s how the normal namespace stuff works.

But we can’t expect common sense from W3C.

W3C Considered Harmful

Most standards suck. The one thing that doesn’t suck about standards is that they’re standards. Except that all the W3C’s standards seem to be notable mainly for the utter lack of compliance. If W3C’s standards were like voltage, then no power outlet in the US would deliver a voltage in the range 100-120V. You’d just have to hope that the voltage from a given outlet wouldn’t blow up anything you plugged into it or electrocute you.

But, W3C’s standards suck worse than that.

Consider frames. Frames were created by Netscape in a retarded attempt to solve a really simple problem — web pages need static navigation/UI components. Frames sucked, but were adopted as a standard for pragmatic reasons — which is why standards suck. But the way in which standards don’t suck should be that a less horrible approach should also be provided and gradually dominate. Instead, we got a whole slew of progressive approximations (e.g. CSS) that failed to give us static panels, or window-like elements without huge amounts of effort.

We could have gotten something like <float left=10 top=10 width=100 height=auto />, instead we get <div style=”position: fixed ….”> plus a ton of JavaScript to fix all the browsers that don’t support it.

Consider CSS. CSS was designed to allow precise graphic design in web pages without messing up HTML’s content representation. A great idea. Pity that despite all that effort it’s almost impossible to use CSS to create a header, footer, snaking text columns, or vertically centered elements. I don’t know hope many blogs there are explaining so-and-so’s semi-functional scheme to get a three column layout to work.

We could have gotten <div style=”column-count: 3; column-spacing: 16px….”> but instead we have padding which increases the size of an element and margin which doesn’t, except when it does.

Consider buttons. It was always obvious that web page designers would want to embed graphical buttons in web pages. It seems like 75% of the JavaScript in the world has been written to implement button rollovers. We could have gotten <button imgurl=”….” rolloverurl=”…” …>, instead — if we’re really lucky — we’ve got <script type=”text/javascript”>$(‘.button’).hover( function() { …. }, function() { …. } ); </script>. Yup, we need a class library, function callbacks, nameless functions to get this “elegant” implementation of a simple button. Without a library like jQuery, implementing a button rollover is even uglier.

Then there’s plugins. To begin with, the standard mechanism for including plugin content is retarded (<object …><embed /></object>), but why on earth isn’t there a simpler option for the most common media type. It seems like we’ll need to wait for HTML5 to be out and adopted before we can naively stick something like <video width=”400″ height=”256″>foo.mov</video> in a web page. Maybe by 2019 we’ll have <video width=”400″ height=”256 allowFullScreen=”1″> — I hope the replicants don’t get me first.

Heck, HTML still doesn’t implement includes. You can import a CSS file or a JavaScript file into a web page with no server-side scripting, but if you want to do something as simple as to reuse menu code between two web pages, you either need to convert the shared HTML into JavaScript document.write statements (which is disgusting and stupid) or you need to use PHP or something similar.

So I guess in the greater scheme of things, xmlns is pretty much par for the course.

IE8 Finds New Ways To Fuck Up Rendering

I’m used to many things not working properly or as expected in IE6 and IE7, but Microsoft has managed to figure out new ways to mess up rendering in IE8.

Here’s a simple example:

<div style=”position: absolute; background-color: #f00; height: 24px; left: 0px; right: 0px; top: 0px;”>I am a menu bar</div>

Try to guess what IE8 will do with it.

Now try to figure out how to fix it. Hint: width 100% will not work.

Software Abstraction Layers

I’m not doing much more than linking two interesting articles I read today. First I read this short piece on 10 Useful Techniques To Improve Your User Interface Designs (I liked this even though it was mainly typographic advice and really more about web pages than apps) and then this very interesting blog entry on Objective-J and Leaky Abstractions.

I’ve always been a bit leery of plugins and toolbox calls from within a given scripting environment. I would go to great lengths in tools as diverse as Authorware, Director, Visual Basic, HyperCard, and RealBasic to build stuff purely using the built-in functions rather than use a “simple” plugin or API call (Visual Basic and RealBasic both let you call the OS toolbox directly with a little extra work). I’ve never really understood why I’m like this, but I think it’s for much the same reason I always preferred Algebra to Calculus or Analysis. I don’t like hairy, open-ended problems. I like working within a well-defined space and treating its boundaries, even when those boundaries are porous, as being absolute.

Anyway, the second article essentially obviates the first article. The point of Cappucino (the class library for which Objective-J was initially developed) is to abstract out annoyances like using CSS to correctly place captions inside buttons or make your text fields look right on different browsers. This is how it should be. I like working in a Walled Garden, but only if the Walled Garden is beautiful. I want my buttons to look good, but I want them to be produced automatically.

Oddly enough, this little insight helps explain my tastes in all kinds of things, from software development tools (I can’t stand Runtime Revolution because it produces ugly user interfaces) to operating systems to programming languages to fields of Mathematics.

Anyway, it’s nice to know that there’s a way to suppress OS X’s text field focus hilite using CSS ( input:focus { outline: none } ). I’ll bear that in mind. And it’s also nice to know that if I learn to build web apps in Cappucino using Objective-J I won’t have to worry about that kind of stupidity ever again.

I wish I loved Sandvox

You can use any font you like as long as it’s the default or you’re willing to painfully override it manually everywhere.

My first cut of our twins website was done with Sandvox, but I quickly ran into the same problem I always run into with Sandvox, i.e.

  • Most of its themes either suck or have obvious flaws (e.g. lame fonts)
  • It’s very fiddly to fix the simple flaws in a theme
  • Even the best themes have dumb and annoying problems (e.g. CAPS in menus)
  • The home page is inflexible and retarded
  • iPhoto integration is poor
  • You can’t do any theme customization inside Sandvox, it’s basically use the theme as isor hack undocumented code; not surprising there’s basically no third-party support out there
  • There’s no way to do obvious low-level html styling inside text boxes, e.g. you can’t put in bullet points without resorting to raw html. Once you have raw html in text fields, they become buggy
  • The html in the themes isn’t very good. Clickable widgets, in particular, have very peculiar “hotspots”.

Nothing says “kid’s website” like tiny fonts in badly chosen colors. And bath toys!

If you just want to toss together a reasonably attractive website on the Mac without hand coding it, your options are RapidWeaver, SandVox, and iWeb. Of the three, iWeb is the most flexible, RapidWeaver probably has more to offer power-users, and then there’s Sandvox.

Originally, Sandvox had the advantage of not being iWeb 1.x. iWeb 1.x produced extremely heavy pages, had lousy browser compatibility, and basically sucked. iWeb ’08 fixes all of iWeb 1.x’s obvious flaws, and has the advantage of Apple-quality page templates, flexibility, and quite a lot of power under the hood. In the meantime, Sandvox has basically stood still.

If you could just tweak the CSS to reduce the whitespace and fix the default fonts, this theme might not suck.

If Sandvox had user forums (the lack of which is pretty despicable for an indie program) I would be ranting my complaints in them.

So I find myself using iWeb, marveling (most of the time) at just how damn good it is, and occasionally lamenting its flaws.