[whatwg] Should onfoo event handler properties be on Element or HTMLElement?

Philip Jägenstedt philipj at opera.com
Wed Oct 9 01:53:29 PDT 2013

On Wed, Oct 9, 2013 at 12:02 AM, Ian Hickson <ian at 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?


More information about the whatwg mailing list