Reroute access to DOM className via jQuery.className.get and jQuery.className.set

[dhbaird]

The goal of this patch is to add a layer of indirection for className. The rationale is that the HTML DOM and the SVG DOM have different (and incompatible) interface definitions for className. Introducing a layer of indirection makes possible to provide uniform access to both HTML and SVG DOMs.

The attached patch affects any parts of jQuery which reference DOM's className. Currently, that means that only two parts of the jQuery core are affected:

1. jQuery.className.{add,remove,has}

2. The selector backend (the one which appears derived from Sizzle)

One of the most important effects of this patch is that it enables querying SVG elements by class name, e.g.:

   $("#my-svg-element .my-class") // this currently won't work
   // ...but it does work after applying the patch

Another important effect is that it makes possible to use addClass, hasClass, removeClass, and toggleClass.

A patch for this was originally proposed here:

​http://groups.google.com/group/jquery-dev/browse_thread/thread/c2c56e4591f4f101 "Adding SVG class (className) support to jQuery"

If the developers seek to mitigate possible impacts on performance or browser compatibility, then the get/set accessors (see attached patch) could be rewritten like so:

  className: {
  
    get: function( elem ) {
      return elem.className;
    },
   
    set: function( elem, value ) {
      elem.className = value;
    },

    ...
  }

Although the above code causes jQuery to continue acting as it current does (and thus, will not support SVG className), it does provide a hook point for which plugins could override features. (Although I am not sure if this is a good idea since it seems hard to wrap/nest this such that one plugin simply extends another plugin.)

...then, conceivably, there could be a plugin which overrides the accessors to work like this (which is compatible with the SVG DOM):

jQuery.className.get = function( elem ) {
      var classNames = elem.getAttribute("class");
      classNames = classNames ? classNames : "";
      return classNames;
}

jQuery.className.set = function( elem, value ) {
    elem.setAttribute("class", value);
}

I have not done browser compatibility testing, nor I have I done performance testing. The only browser I have tested on is Firefox 3.0.8.

[kbwood]

See also #4850 which also includes relationship selectors, attribute selectors, attribute handling, and event handling.

[tvongaza]

Anyone have a patch for this bug for jQuery 1.4? Running into issues w/ live events and SVG and it is real pain :).

Tys

[Marc Diethelm]

Shouldn't this be blocking #4850?

With HTML5 on the rise, SVG usage will finally become more common. jQuery could (should) play an important part in that...

[paul.irish]

Couldn't add/removeClass just be duck punched for the same effect? Seems like it'd be the same level of work for the end user. ​http://paulirish.com/2010/duck-punching-with-jquery/

[mpedrotti]

This sentence near the end of the original description is significant to me:

"Although I am not sure if this is a good idea since it seems hard to wrap/nest this such that one plugin simply extends another plugin."

Instead of the development, testing, and documentation effort to add hooks so people (like me ;-) can try to make them work :-(but fall short in various incompatible ways), wouldn't it be better in the long run to invest the effort to make classes for SVG elements in XHTML5 documents work as expected in jQuery?

A careful implementation of access to the class attribute within jQuery and Sizzle (see my recent comment 5 on #4850) might have no more impact on performance in ordinary HTML and XHTML than an externally accessible layer of indirection would.

Because IE9 will support SVG, Web designers and developers who begin to consider it seriously would be disappointed if jQuery doesn't support it. As a wise person said, the opportunities are insurmountable!

[john]

See thoughts in #7584.