Bug Tracker

Opened 10 years ago

Closed 8 years ago

Last modified 7 years ago

#4705 closed enhancement (patchwelcome)

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

Reported by: dhbaird Owned by:
Priority: low Milestone:
Component: core Version: 1.4.4
Keywords: className xml svg needsreview Cc:
Blocked by: #5766 Blocking: #7584


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}
  1. 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.

Attachments (1)

jquery-1.3.2-className.patch (3.0 KB) - added by dhbaird 10 years ago.

Download all attachments as: .zip

Change History (11)

Changed 10 years ago by dhbaird

comment:1 Changed 10 years ago by kbwood

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

comment:2 Changed 9 years ago by 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 :).


comment:3 Changed 8 years ago by snover

Keywords: xml svg needsreview added
Milestone: 1.4
Priority: minorlow

comment:4 Changed 8 years ago by snover

Blocking: 7584 added

comment:5 Changed 8 years ago by 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...

comment:6 Changed 8 years ago by Rick Waldron

Blocked by: 5766, 5807 added

comment:7 Changed 8 years ago by 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/

comment:8 Changed 8 years ago by jitter

Blocked by: 5807 removed

comment:9 Changed 8 years ago by 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!

Last edited 8 years ago by mpedrotti (previous) (diff)

comment:10 Changed 8 years ago by john

Resolution: patchwelcome
Status: newclosed

See thoughts in #7584.

Note: See TracTickets for help on using tickets.