Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Thu, 03 May 2012 02:31:40 +0200, Cameron McCormack c...@mcc.id.au wrote: Rik Cabanier: There was a discussion in the SVG WG about dropping the SVGAnimatedxxx objects and have replace them with regular values. We would need some tricks so we can change the DOM, but make it backward compatible at the same time. We have discussed this a few times, and I would desparately love for it to work, but I am unconvinced it will. I can an imagine an author writing code like: if (!elt.className) ... to test if a class has been set. Even if we made the SVGElement.className SVGAnimatedString object one that stringifies to the class, add a [PutForwards] on to it so that assigning a string works, it would still break the above code, since the ! operator always returns false for an object. I don't think the use of animated 'class' attributes in svg is all that common, and I'd favor an approach that'd makes .className in svg a bit more like the html .className, perhaps in the way Cameron is suggesting. On the topic of which interface the .classList property should be in, Element seems better than HTMLElement. -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Fri, 19 Nov 2010, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. How do you handle the difference between SVG and HTML's className? I think it would be confusing to have classList work the same on both but not className. (Currently, DOM Core and HTML both define classList; the former on Element and the latter on HTMLElement, because Anne and I disagree on what should happen here.) For the spec's purposes my plan is to follow whatever implementations converge on. Currently WebKit does what the HTML/SVG specs say (.className is a string in HTML, an object in SVG, and .classList is HTML-specific), Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string in HTML, an object in SVG, and .classList is on both but returns null in unknown namespaces), and Opera does a different mixture (.className is a string in HTML, an object in SVG, and .classList is on SVG and HTML nodes but not on nodes from unknown namespaces). (Didn't have other browsers available to test on this machine.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 5/2/12 6:09 PM, Ian Hickson wrote: On Fri, 19 Nov 2010, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. How do you handle the difference between SVG and HTML's className? Right now in Gecko it's on HTMLElement (and XULElement), with a domstring return value and on SVGStylable with a SVGAnimatedString return value. Longer term we could put it on Element and just have SVG shadow it, of course. I would love being able to drop the SVG-specific className, but I bet there's content I think it would be confusing to have classList work the same on both but not className. Why? It doesn't seem to be any more confusing than the fact that className is present on both and just acts totally differently to start with... For the spec's purposes my plan is to follow whatever implementations converge on. Currently WebKit does what the HTML/SVG specs say (.className is a string in HTML, an object in SVG, and .classList is HTML-specific), Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string in HTML, an object in SVG, and .classList is on both but returns null in unknown namespaces) Thos last might be changing: see https://bugzilla.mozilla.org/show_bug.cgi?id=741295 -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Wed, May 2, 2012 at 5:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/2/12 6:09 PM, Ian Hickson wrote: On Fri, 19 Nov 2010, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. How do you handle the difference between SVG and HTML's className? Right now in Gecko it's on HTMLElement (and XULElement), with a domstring return value and on SVGStylable with a SVGAnimatedString return value. Longer term we could put it on Element and just have SVG shadow it, of course. I would love being able to drop the SVG-specific className, but I bet there's content There was a discussion in the SVG WG about dropping the SVGAnimatedxxx objects and have replace them with regular values. We would need some tricks so we can change the DOM, but make it backward compatible at the same time. I think it would be confusing to have classList work the same on both but not className. Why? It doesn't seem to be any more confusing than the fact that className is present on both and just acts totally differently to start with... For the spec's purposes my plan is to follow whatever implementations converge on. Currently WebKit does what the HTML/SVG specs say (.className is a string in HTML, an object in SVG, and .classList is HTML-specific), Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string in HTML, an object in SVG, and .classList is on both but returns null in unknown namespaces) Thos last might be changing: see https://bugzilla.mozilla.org/** show_bug.cgi?id=741295https://bugzilla.mozilla.org/show_bug.cgi?id=741295 -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Rik Cabanier: There was a discussion in the SVG WG about dropping the SVGAnimatedxxx objects and have replace them with regular values. We would need some tricks so we can change the DOM, but make it backward compatible at the same time. We have discussed this a few times, and I would desparately love for it to work, but I am unconvinced it will. I can an imagine an author writing code like: if (!elt.className) ... to test if a class has been set. Even if we made the SVGElement.className SVGAnimatedString object one that stringifies to the class, add a [PutForwards] on to it so that assigning a string works, it would still break the above code, since the ! operator always returns false for an object.
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Wed, May 2, 2012 at 5:31 PM, Cameron McCormack c...@mcc.id.au wrote: Rik Cabanier: There was a discussion in the SVG WG about dropping the SVGAnimatedxxx objects and have replace them with regular values. We would need some tricks so we can change the DOM, but make it backward compatible at the same time. We have discussed this a few times, and I would desparately love for it to work, but I am unconvinced it will. I can an imagine an author writing code like: if (!elt.className) ... to test if a class has been set. Even if we made the SVGElement.className SVGAnimatedString object one that stringifies to the class, add a [PutForwards] on to it so that assigning a string works, it would still break the above code, since the ! operator always returns false for an object. Who would do this in the current SVG world? As you say, (!elt.className) would always return false... Are you worried that new content won't work with an old viewer? Rik
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Rik Cabanier: Who would do this in the current SVG world? As you say, (!elt.className) would always return false... Are you worried that new content won't work with an old viewer? No that would actually continue to behave the same. So I misspoke when I said things will break -- author expectations will break instead if they assume that that code which works on HTML elements would also work on SVG elements. But maybe that's OK?
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named id, and Element.className to an attribute named class. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 11/23/10 12:20 PM, Anne van Kesteren wrote: My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named id, and Element.className to an attribute named class. Why do we want to tie .className to a particular attribute name? I agree it may not be that convenient for authors if a particular language wants to use some other attr name for classes, but presumably they'd have really good reasons for doing that if they do it at all? -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
While we're on the topic of commonizing things at Element - can we introduce an 'inner' property on Element? This would map to innerHTML for HTMLElements. Other languages could introduce parsing rules for getting/setting that property. Presumably XML grammars would use the rules at http://dev.w3.org/html5/spec/apis-in-html-documents.html#innerhtml Jeff On Tue, Nov 23, 2010 at 9:20 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 19 Nov 2010 17:34:29 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named id, and Element.className to an attribute named class. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:37:51 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/23/10 12:20 PM, Anne van Kesteren wrote: My plan is to define Element.id, Element.className, Element.classList, and getElementsByClassName in DOM Core. And tie getElementById to Element.id somehow, tie Element.id to an attribute named id, and Element.className to an attribute named class. Why do we want to tie .className to a particular attribute name? I agree it may not be that convenient for authors if a particular language wants to use some other attr name for classes, but presumably they'd have really good reasons for doing that if they do it at all? So that you do not need namespace knowledge. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 18:50:06 +0100, Jeff Schiller codedr...@gmail.com wrote: While we're on the topic of commonizing things at Element - can we introduce an 'inner' property on Element? This would map to innerHTML for HTMLElements. Other languages could introduce parsing rules for getting/setting that property. Presumably XML grammars would use the rules at http://dev.w3.org/html5/spec/apis-in-html-documents.html#innerhtml http://html5.org/specs/dom-parsing.html It's simply called Element.innerHTML. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 11/23/10 12:58 PM, Anne van Kesteren wrote: Why do we want to tie .className to a particular attribute name? I agree it may not be that convenient for authors if a particular language wants to use some other attr name for classes, but presumably they'd have really good reasons for doing that if they do it at all? So that you do not need namespace knowledge. Namespace knowledge where? As an implementor? Or as an author? The whole point if a universal .classList and .className is to make authors not have to deal with namespace knowledge, imo. And it doesn't require mapping to a specific attr name for that. -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 19:48:03 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/23/10 12:58 PM, Anne van Kesteren wrote: So that you do not need namespace knowledge. Namespace knowledge where? As an implementor? Or as an author? Either? The whole point if a universal .classList and .className is to make authors not have to deal with namespace knowledge, imo. And it doesn't require mapping to a specific attr name for that. So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 20:06:02 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). I would much rather just make it work. Otherwise moving it to Element does not really seem right. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 11/23/10 2:08 PM, Anne van Kesteren wrote: I would much rather just make it work. Otherwise moving it to Element does not really seem right. Note that I only suggested moving classList (which I think should return null if the element doesn't actually support classes). -Boris
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, Nov 23, 2010 at 11:06 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/23/10 2:02 PM, Anne van Kesteren wrote: So if I set Element.className on an element that is not in a namespace and has no attributes. Its attributes collection remains empty or something? Hmm. I would think this should throw (since this won't do what you expect; e.g. CSS selectors and getElemetsByClassName won't start matching it). I agree that unless we get other groups in on this change, and get things like SVG cross-references and CSS styling reacting to these id and class-list changes, then we're just making things more confusing by making the DOM pretend that the class changed, when no other systems agree. / Jonas
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking jo...@sicking.cc wrote: I agree that unless we get other groups in on this change, and get things like SVG cross-references and CSS styling reacting to these id and class-list changes, then we're just making things more confusing by making the DOM pretend that the class changed, when no other systems agree. Well yes, obviously .class notation, #id, etc. would all have to remain functioning. To me it makes sense to define ID/class-ness at the DOM level. CSS operates on that level too. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Tue, Nov 23, 2010 at 12:25 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Nov 2010 21:04:37 +0100, Jonas Sicking jo...@sicking.cc wrote: I agree that unless we get other groups in on this change, and get things like SVG cross-references and CSS styling reacting to these id and class-list changes, then we're just making things more confusing by making the DOM pretend that the class changed, when no other systems agree. Well yes, obviously .class notation, #id, etc. would all have to remain functioning. To me it makes sense to define ID/class-ness at the DOM level. CSS operates on that level too. Right; CSS doesn't care what the underlying language is doing; it only cares that, when mapping from the underlying language to the CSS element-tree, there are things called elements arranged in a tree structure, which have ids, classes, and attributes. It just so happens that in HTML, the mapping is trivial. Theoretically CSS isn't tied in any way to HTML or XML. The WebSRT mapping to CSS, for example, shows how a language that isn't explicitly tree-based can still be mapped into a CSS element-tree and then styled. ~TJ
Re: [whatwg] classList should perhaps move from HTMLElement to Element
Boris Zbarsky: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. Would classList provide access to the SVG element’s base or animated value of class=? Base probably makes more sense. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On 11/19/10 2:25 PM, Cameron McCormack wrote: Would classList provide access to the SVG element’s base or animated value of class=? Base probably makes more sense. Imo, base value. In general, I think we should define classList as providing access to the value of the DOM attribute that the relevant language defines as a class (using the same definition as CSS Selectors). Note that this attribute my or may not actually be named class. -Boris
