This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The CSS3 Image Values spec defines an element() function <http://dev.w3.org/csswg/css3-images/#element-reference> which allows an author use an element as an image. This was inspired by Mozilla's proprietary -moz-element() experiment. <https://developer.mozilla.org/en/CSS/-moz-element> One interesting feature of -moz-element() is the ability to use <img>, <video>, and <canvas> in it without inserting them into the document; you instead use mozSetImageElement(<name>, <element>) to give it an additional "pseudo-id" which will then match the id selector used in -moz-element(). When I put this feature into the specification, I wanted a similar feature, but didn't like the design. Discussion with Hixie led to the creation of the CSSElementMap <http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-csselementmap>, which is simply a map from strings to elements, and otherwise works the same way. This didn't make it into the W3C's version of HTML5 because it happened to be in a feature-freeze at the time, and got missed when we unfroze. I would like the W3C HTML5 to define CSSElementMap as well, matching the WHATWG HTML5 definition. There are some caveats, however. If this feature is purely for CSS, it is more appropriately placed in the CSSOM. However, this is potentially useful for similar purposes in other DOM operations. For example, querySelector() with an id selector could return elements from the map, or even getElementByID() (in which case we should rename it to ElementMap or something). Do we think that this is better suited as a pure-CSS feature, or are we interested in integrating it elsewhere in the DOM?
What is the use case outside of CSS? You already have access to those elements from script.
The main use-case I can see is allowing JS-based selector queries (qS/A, find/All) select those elements in an identical fashion to how CSS does. If you were, say, writing a polyfill for some new CSS feature that used element() (or another function that takes an id selector), you'd have to first run the selector normally and then (if it didn't return anything) check the map yourself. This isn't exactly difficult, though. You just strip off the first # and then see if the string maps to anything.
Letting Selectors select elements outside of the tree breaks an invariant of Selectors. Doing that just seems unwise as all kinds of code depending on that invariant will need to be adjusted.
See also: http://krijnhoetmer.nl/irc-logs/whatwg/20120315#l-754 (and onwards)
I'm not interested in changing the currently specced behavior of the element() function - it's useful, and it matches Mozilla's current experimental implementation of the feature. I'm solely interested in seeing if there is any interest to use CSSElementMap more widely in DOM (in which case we should probably rename it), or if it should be defined in CSSOM just for CSS's use (in which case we should move it).
Tab, what is the current status here?
Based on conversations, it looks like the general opinion is that this should be a CSSOM feature, not a DOM one. So I've gone ahead and closed this RESOLVED WONTFIX for now. We can reopen if someone feels strongly that it would be cool idea to allow stuff besides element() to use this functionality.