Skip to main content

Bug Tracker

Side navigation

#4705 closed enhancement (patchwelcome)

Opened May 30, 2009 07:03PM UTC

Closed April 17, 2011 12:12AM UTC

Last modified March 13, 2012 04:19PM UTC

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: Blocking:
Description

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.

Attachments (1)
Change History (10)

Changed July 07, 2009 10:53PM UTC by kbwood comment:1

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

Changed January 23, 2010 12:37AM UTC by tvongaza comment:2

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

Changed November 19, 2010 04:50AM UTC by snover comment:3

keywords: classNameclassName xml svg needsreview
milestone: 1.4
priority: minorlow
version: 1.3.21.4.4

Changed November 21, 2010 04:48AM UTC by snover comment:4

blocking: → 7584

Changed December 01, 2010 10:09AM UTC by Marc Diethelm comment:5

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

Changed December 01, 2010 03:03PM UTC by rwaldron comment:6

blockedby: → 5766, 5807

Changed December 07, 2010 04:28AM UTC by paul.irish comment:7

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/

Changed February 05, 2011 01:13AM UTC by jitter comment:8

blockedby: 5766, 58075766

Changed March 02, 2011 07:11PM UTC by mpedrotti comment:9

_comment0: 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 on #4850:5) 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!1299093187343262

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!

Changed April 17, 2011 12:12AM UTC by john comment:10

resolution: → patchwelcome
status: newclosed

See thoughts in #7584.