Notes to self

The first argument for setAttributeNS is supposed to be a string. So, if you want to put an attribute in the null namespace, it makes sense to use "". This works fine in Opera and Firefox, but webkit requires null if you want to get the desired result. Bug 15172

So, I need to quit using setAttributeNS("", "name", "value") and start using setAttributeNS(null, "name", value"). Since setAttribute works fine for this case, I could use it, but that's no fun. 🙂 The whole "" or null issue might bring back some getAttribute memories.

Speaking of webkit stuff, where are all the HTMLFooElement constructor objects? Element, Node and Document are available, just not the specific ones. (Oops. Actually, they're there if you use a nightly.)

Also, webkit really needs to support the input event for textareas. Opera and Firefox support it and IE has onpropertychange.

With Safari being released for windows, it really helps me see where webkit is lacking (although some problems are win32-only). For example, I've found that .click() doesn't work and I have to bust out dispatchEvent, which isn't a big deal, but is mildy annoying. It can be wrapped though, so it's not too bad.

Also, I need to make sure to use .ownerDocument instead of .document when getting the document of an element. Firefox doesn't support .document. Besides, ownerDocument is what I should be using anyway.

You really have to watch your JS with Safari.

4 Replies to “Notes to self”

  1. null-namespaceURI:createElementNS”Per [XML Namespaces], applications must use the value null as the namespaceURI parameter for methods if they wish to have no namespace.”How is webkit’s behaviour a bug when the Dom Level 3 recommendation requires it? Am I missing something?I’m currently getting into namespaceURI problems myself. I had to want to write application/xhtml+xml…

  2. comment 2 explains it pretty well.null should be used like the spec says, but my type-centric mind says that if the namespace argument is of type “DOMString” (like the spec says), then I should always be passing in a string. And, if I’m always passing in a string, an empty string would be the way to describe no namespace.Then, if it really needs to be null behind the scenes, the function should check to see if the string is empty and do the right thing.But, regardless of what I think and what the spec says, Firefox and Opera allow “” to work like null. Fixing Webkit to do it also will prevent breakage on pages where “” is used.See this post also though. You can find the type of issue all over the net.I’m not sure making Firefox and Opera do like webkit could be done. It might break a lot of things. Maybe not though.Anyway, null seems to work fine in FF, Opera and Safari, so that’s what I’m using now.

  3. I agree, providing null instead of an empty string where a DOMString is expected violates strong data typing. That still isn’t a bug in Webkit… instead it’s a bug in the recommendation. :)Who knows? Maybe it’ll even get fixed. One day.

  4. That still isn’t a bug in Webkit.Yeh, it’s more of a recommendation issue imo also.The bug I filed is a “Compatibility with other browsers” issue, not a spec violation bug.Being different and outnumbered is often a bug in itself.

Leave a Reply

Your email address will not be published. Required fields are marked *