Snippets code from my daily experience

January 25, 2009

XUL developers please add id attribute to elements (Sunday Thought)

Filed under: sunday_thought,xul — dafi @ 1:00 pm

The XUL overlay mechanism is great, it allows to extend virtually any UI widget.

Damn, why developers continue to forget to add id attributes to elements candidate to be re-used (ie all)?

Please dear developers follow these simple rules

  • Please don’t forget windows and dialogs or simply refer to this short list😛
  • Please don’t forget menu and menuitems (not generated dinamically)
  • Add id attribute to every element
  • Add id attribute to every element (#1)
  • Add id attribute to every element (#2)
  • Add id attribute to every element (#n)

iwilluseid

Based on my experience no application is fully compliant: Firefox, Thunderbird, SeaMonkey and also Komodo contain elements I needed to access without an associated id attribute

How to survive to bad practices

Sometimes (but not always) it is possible to use some workaround.
Consider that workarounds can be worst than initial problem

  • Find target element with getAttributesByName method, it is especially useful for menuitems passing the ‘value’ attribute
  • Find an element closer to the target using its id then navigate DOM with methods/attributes like firstChild & co.

10 Comments

  1. Agreed.

    Comment by Daniel Glazman — January 25, 2009 @ 4:47 pm

  2. I agree as well, but if I remember correctly, a long time ago an effort was made to actually REMOVE IDs from the Mozilla/Firefox source code because there were performance issues with having IDs on every XUL attribute…

    Someone can refresh my memory.

    Comment by Michael Kaply — January 25, 2009 @ 6:23 pm

  3. whimboo just landed a patch for fx to add IDs to (more or less) all menu items in Firefox. We need this to write locale-independent tests touching menu items, including but not limited to mozmill tests.

    Which brings me to “getElementsByAttribute with the value attribute”, that’s going to break as soon as your user has a localized version. Dafi, the API and the MDC link don’t match, I assume that the pitfall doesn’t really depend on which you actually meant.

    Comment by Axel Hecht — January 25, 2009 @ 6:52 pm

  4. Axel you are right, using getElementsByAttribute can be dangerous on localized versions, infact I say “workarounds can be worst than initial problem”

    Lucky I’ve used it only on menuitems returning value locale-aware.

    Comment by dafi — January 25, 2009 @ 7:04 pm

  5. I still remember being unable to plug an extension’s menuitem into the right menupopup because that menupopup did not have an id. Making id mandatory on all elements is probably overkill but some elements should always have one. Menuitems for instance don’t always need an id, but menuseparators do because when you want to overlay a menupopup, you often want to position your add-on before or aftera given separator…

    Comment by Daniel Glazman — January 25, 2009 @ 7:22 pm

  6. Could you please file bugs on any case where you actually wanted an ID but missed one? I’m sure at least the SeaMonkey team would be more than willing to get such things fixed.
    Oh, and there’s one other thing: Almost as important as having IDs set is that you don’t have duplicate IDs in your windows. Mnyromyr wrote a cool chrome mochitest to check for that in SeaMonkey, see bug 474716 about porting this to Firefox as well.

    Comment by Robert Kaiser — January 25, 2009 @ 9:09 pm

    • @Robert Sure I will try to do a list and attach it to a file bug.

      Comment by dafi — January 26, 2009 @ 7:41 am

  7. Wouldn’t it be possibly easier to have a more expressive language for overlay hookup (xpath, say, or Selectors?) than littering the chrome with IDs? You’d still want IDs on certain nodes to anchor the XPath expressions, of course.

    Comment by Boris — January 26, 2009 @ 4:05 am

    • @Boris mmmm honestly I love the standard DOM approach based on IDs but a new way to write XUL code is welcome

      Comment by dafi — January 26, 2009 @ 7:43 am

  8. See bug 473829 for the menu additions for Firefox. I hope we will get it into Firefox 3.1.

    Comment by Henrik — January 26, 2009 @ 4:57 pm


RSS feed for comments on this post.

Blog at WordPress.com.

%d bloggers like this: