- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 9 Oct 2013 10:53:29 +0200
- To: Ian Hickson <ian@hixie.ch>, Erik Dahlström <ed@opera.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Simon Pieters <simonp@opera.com>
On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson <ian@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
Received on Wednesday, 9 October 2013 08:53:56 UTC