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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
23 matches
Mail list logo
