Mootools has 3 native methods for accessing an attribute/property for a node (which in the DOM, often overlaps). .get(’name’), .retrieve(’name’), and getProperty(’name’). While they are all meant to do things a little differently (eg. set an attribute for a node, store a data object in an existing object (which could be a DOM node) or store a property in an object (which again, could be a DOM node), they seem to overlap a lot.

So I have this anchor, and when I tried accessing it (grabbing the href) using the accessors I have, here at the results for FF (mac) vs. IE6 (windows):

.[name]
FF: full path including host
IE6: full path including host

.get
FF: request path (excluding host)
IE6: full path including host

.retrieve
FF: null
IE6: null

.getProperty
FF: request path (excluding host)
IE6: full path including host

Now it’s hard to say what is the correct expectation. I’m sure I could figure it out in the eyes of the W3C, but rather, here’s what I’ve noticed. Both browsers take whatever path is specified and render it internally with the host. I understand this since it’s what the browser would need to actually make a full request.

The 2nd and 4th accessors, though, are inconsistent and cause problems since their expected results different. IE6 includes the full path & host each time which is most likely an issue with how it accesses it. When the browser defines the href in memory it must overwrite the local pointer which then can’t be accessed properly.

So what do I do about this? Nothing really. I have this documented now so that if there is a pre-dom-ready source that I need to inspect (for example, href values written but no rendered after the dom has been loaded), I should be using the .[name] accessor, and make adjustments accordingly based on what is being accessed (in this case the href which has the host prepended).

These differences really suck since they introduce inconsistencies in places where you wouldn’t expect them and thus break applications/scripts (like what drove me to discover this). I would hope a framework/library would help mitigate this kind of thing, but alas, they can’t do everything, and I’m just happy for what they do bring to the table.

In the 4.0 release, the first thing you realize about Safari is how fast it is. While non-web developers would often remark that there isn’t much of a difference, it’s something you pick up very noticeably when you spend 10 hours in a browser. It’s not that every second counts, it’s just that you notice it and lean towards the one that will save you any time at all.

As a developer, it misses many things like Firebug, plugins (has a few, but not comparable), web developer toolbar, and while Safari has it’s own web-kit based inspector, in my opinion, it’s terrible. You can view the DOM, but not do much with it.

I find that the only time I’m not using Safari is when I need to do some post-render editing using firebug, or test out a plugin in FF; any other time, Safari and it’s speed an UI dominate for me. My only hope that it gets a little more plugin compliant to make it more useful more of the time.