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 comment:1
Changed January 23, 2010 12:37AM UTC by 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 comment:3
keywords: | className → className xml svg needsreview |
---|---|
milestone: | 1.4 |
priority: | minor → low |
version: | 1.3.2 → 1.4.4 |
Changed November 21, 2010 04:48AM UTC by comment:4
blocking: | → 7584 |
---|
Changed December 01, 2010 10:09AM UTC by 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 comment:6
blockedby: | → 5766, 5807 |
---|
Changed December 07, 2010 04:28AM UTC by 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.
Changed February 05, 2011 01:13AM UTC by comment:8
blockedby: | 5766, 5807 → 5766 |
---|
Changed March 02, 2011 07:11PM UTC by 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 comment:10
resolution: | → patchwelcome |
---|---|
status: | new → closed |
See thoughts in #7584.
See also #4850 which also includes relationship selectors, attribute selectors, attribute handling, and event handling.