Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 22/01/2014 3:09 pm, Boris Zbarsky wrote: Or neither, if desired. In Gecko we don't expose the SVG* properties in IDL at all... We decided against requesting adding an onzoom attribute to GlobalEventHandlers to avoid any complications with whatever solution comes out of the CSSWG who are looking into new zoom related functionality (which possibly could come out with an event named zoom, which then might be incompatible with SVGZoom).
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:21:08 +0200, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( -Boris There are a couple of events in SVG which seem to be in conflict with the reflection pattern. The events with names: endEvent, beginEvent and repeatEvent [1]. The attributes that correspond to these are onend, onbegin and onrepeat respectively. Due to how the event-value syntax[2] works in SVG animation elements the event names can't be changed without conflicting with the sync-base value syntax[3]. I wish the event names were consistent with the pattern used for event handler content attributes, but they're not. In SVG2 most of the events with SVG event name prefixes have been removed[4], e.g SVGLoad is now a plain load, which means they follow the pattern for event handler content attributes. SVGResize, SVGScroll and SVGZoom still remain to be fixed in the spec. Of these only SVGZoom lacks an existing unprefixed counterpart, so that would be a possible addition to GlobalEventHandlers with the event name zoom. My question is: what should be done with the SVG specific event handlers? Should they be added to GlobalEventHandlers, or should they be just on SVGElement? This was ACTION-3542 (SVG WG). [1] http://www.w3.org/TR/SVG11/interact.html#BeginEvent [2] http://www.w3.org/TR/SVG11/animate.html#EventValueSyntax [3] http://www.w3.org/TR/SVG11/animate.html#SyncbaseValueSyntax [4] https://svgwg.org/svg2-draft/interact.html#SVGEvents -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 1/22/14 9:06 AM, Erik Dahlström wrote: In SVG2 most of the events with SVG event name prefixes have been removed[4], e.g SVGLoad is now a plain load, which means they follow the pattern for event handler content attributes. SVGResize, SVGScroll and SVGZoom still remain to be fixed in the spec. Of these only SVGZoom lacks an existing unprefixed counterpart, so that would be a possible addition to GlobalEventHandlers with the event name zoom. My question is: what should be done with the SVG specific event handlers? Should they be added to GlobalEventHandlers, or should they be just on SVGElement? Or neither, if desired. In Gecko we don't expose the SVG* properties in IDL at all... -Boris
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 8 Oct 2013, Simon Pieters wrote: I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. Yeah, that's the main reason I wouldn't put this on Element if it was up to me. It seems weird to say to everyone around the world that we're basically stomping on any content attribute starting with on. It's one thing to take id, and even maybe ok to take class (though that starts getting a bit iffy, it's easy to come up with examples where the attribute class means something different than we do in HTML), but I'm sure there's all kinds of vocabularies that have an onclick attribute with _very_ different semantics than ours. For example, I'm sure there's many XML-based UI languages that have onclick= handlers but I doubt that they all use JavaScript and I really doubt that they all have the crazy semantics that HTML has: OK, I hadn't considered that moving this to Element would imply the content attributes being reflected for all namespaces. Even though Blink has the IDL attributes on Element, it looks like the reflection with the content attributes only works for HTMLElement and SVGElement. In other words, whatever Blink does doesn't look like something worth standardizing. Erik, does going with SVGElement implements GlobalEventHandlers (like Gecko) seems like a way forward for the SVG spec? Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt phil...@opera.com wrote: ... OK, I hadn't considered that moving this to Element would imply the content attributes being reflected for all namespaces. Even though Blink has the IDL attributes on Element, it looks like the reflection with the content attributes only works for HTMLElement and SVGElement. In other words, whatever Blink does doesn't look like something worth standardizing. Erik, does going with SVGElement implements GlobalEventHandlers (like Gecko) seems like a way forward for the SVG spec? Philip Given the reasons brought up in this thread I should think that the WG would agree that SVGElement implements GlobalEventHandlers is an acceptable way forward. -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Wed, Oct 9, 2013 at 1:29 PM, Erik Dahlstrom e...@opera.com wrote: On Wed, 09 Oct 2013 10:53:29 +0200, Philip Jägenstedt phil...@opera.com wrote: ... OK, I hadn't considered that moving this to Element would imply the content attributes being reflected for all namespaces. Even though Blink has the IDL attributes on Element, it looks like the reflection with the content attributes only works for HTMLElement and SVGElement. In other words, whatever Blink does doesn't look like something worth standardizing. Erik, does going with SVGElement implements GlobalEventHandlers (like Gecko) seems like a way forward for the SVG spec? Philip Given the reasons brought up in this thread I should think that the WG would agree that SVGElement implements GlobalEventHandlers is an acceptable way forward. OK, that's what I'll try to get implemented in Blink. Thanks all! Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 4:26 PM, Erik Dahlstrom e...@opera.com wrote: On Tue, 08 Oct 2013 15:49:48 +0200, Philip Jägenstedt phil...@opera.com wrote: 1. Do what Gecko does, even though there's no SVG spec requiring it yet. 2. Just say Element implements GlobalEventHandlers. I would prefer option 2, since we already have a unified Document implements GlobalEventHandlers. Either option is probably fine from a web compat standpoint, but I'd prefer option 2 too. Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. -- http://annevankesteren.nl/
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 10/8/13 11:26 AM, Anne van Kesteren wrote: Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. In terms of DOM behavior, in Gecko we have been shipping an id attribute on Element.prototype for a good long while now. We haven't moved className to Element.prototype yet. In terms of the behavior of the content attribute, I don't think we've made id= on random nodes do anything interesting. -Boris
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( -Boris
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 5:26 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 8, 2013 at 4:26 PM, Erik Dahlstrom e...@opera.com wrote: On Tue, 08 Oct 2013 15:49:48 +0200, Philip Jägenstedt phil...@opera.com wrote: 1. Do what Gecko does, even though there's no SVG spec requiring it yet. 2. Just say Element implements GlobalEventHandlers. I would prefer option 2, since we already have a unified Document implements GlobalEventHandlers. Either option is probably fine from a web compat standpoint, but I'd prefer option 2 too. Have we had success yet making id= and class= super-global? Not sure we should extend the experiment prematurely. I don't know anything about the move of those attributes, has it been attempted in spec and implementation and run into trouble? Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( Is there a spec for how the event handler content attributes (with reflection) work in SVG? In any event I haven't intended any changes here, whatever is already implemented sounds good. If implementations disagree, then getting agreement and a spec for it seems orthogonal to which interface the IDL attributes sit on. Philip
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, Oct 8, 2013 at 8:35 PM, Philip Jägenstedt phil...@opera.com wrote: I don't know anything about the move of those attributes, has it been attempted in spec and implementation and run into trouble? http://dom.spec.whatwg.org/ is the specification, but I don't think it's been implemented yet. Moving more attributes to be superglobal probably makes sense, but I feel somewhat hesitant since we haven't discussed this in detail and thought through the implications. Given that almost everyone ends up with HTMLElement and to a lesser extent SVGElement the implications are probably marginal to begin with... -- http://annevankesteren.nl/
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 08 Oct 2013 20:38:48 +0200, Philip Jägenstedt phil...@opera.com wrote: On Tue, Oct 8, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/8/13 9:49 AM, Philip Jägenstedt wrote: Gecko has HTMLElement implements GlobalEventHandlers in its IDL,[1] but somewhat surprisingly also SVGElement implements GlobalEventHandlers.[2] Note that in Gecko SVG elements also have event handler content attributes and whatnot. What's your proposed handling of event handler content attributes? And note that the handling of these is not quite identical for HTML and SVG last I checked. :( Is there a spec for how the event handler content attributes (with reflection) work in SVG? http://www.w3.org/TR/SVG/script.html#EventAttributes http://www.w3.org/TR/SVG2/script.html#EventAttributes I don't see any IDL for event handlers in the SVG spec, so per spec there should only be content attributes... And only those that are specified for some elements, unlike HTML where most event handlers are available everywhere. In any event I haven't intended any changes here, whatever is already implemented sounds good. I'm not sure what should be done with SVG. Clearly the SVG spec doesn't reflect the we should do whatever HTML does idea. If implementations disagree, then getting agreement and a spec for it seems orthogonal to which interface the IDL attributes sit on. I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. -- Simon Pieters Opera Software
Re: [whatwg] Should onfoo event handler properties be on Element or HTMLElement?
On Tue, 8 Oct 2013, Simon Pieters wrote: I think it would be bad to have an IDL attribute without a working content attribute for a given element. That's just confusing. Yeah, that's the main reason I wouldn't put this on Element if it was up to me. It seems weird to say to everyone around the world that we're basically stomping on any content attribute starting with on. It's one thing to take id, and even maybe ok to take class (though that starts getting a bit iffy, it's easy to come up with examples where the attribute class means something different than we do in HTML), but I'm sure there's all kinds of vocabularies that have an onclick attribute with _very_ different semantics than ours. For example, I'm sure there's many XML-based UI languages that have onclick= handlers but I doubt that they all use JavaScript and I really doubt that they all have the crazy semantics that HTML has: http://whatwg.org/html/#event-handler-content-attributes -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
