[whatwg] Additional onxxxx event attributes for DOM Level3 Events

[Diego Perini]

Garrett,
what you suggest would really be appreciated seen from my point of
view and help improve cross-browser coding.

If we want to help avoid browser sniffing in user code this is surely
a top suggestion. It seems to me that previously proposed solutions
like "hasFeature()" and "isSupported()" did not get enough support and
never reached spread usage among developers.

I would like to add that currently "oninput", "onbeforeunload",
"onunload" events are almost impossible to detect in one or another
browser, for this same reason.

There should be "one" suggested (and implemented) way to do these
checking in a safe enough manner.

Testing for features makes our coding stronger and portable.

--
Diego


On Wed, Dec 1, 2010 at 12:18 AM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> On 11/30/10, Ian Hickson <ian at hixie.ch> wrote:
>> On Mon, 16 Aug 2010, Hajime Morita wrote:
>>>
>>> I noticed that some events which are defined in DOM Level3 Events [1]
>>> don't have
>>> associated HTML attributes.
>>> For example, "keypress" event has associated "onkeypress" attribute.
>>> But "focusin" event doesn't have "onfocusin" attribute.
>>>
> It does in IE.
>
>>> Here is a list:
>>>
>>> * wheel event
> `onmousewheel`? That's in IE.
>
>>> * textInput event
>
> Following the convention of lc for event handler properties, `ontextinput`?
>
>>> * focusin event
>>> * focusout event
>
> Those are in IE.
>
>>> * compositionstart event
>>> * compositionupdate event
>>> * compositionend event
>>> * DOMXxxx events
>>>
>>> I think these events should have associated attributes defined.
>>> DOM mutation events might be better to skip due to its long name and rare
>>> usage.
>>> But it's just a preference and not a strong opinion.
>>
>> I'm happy to add new event handler attributes, but not to add them just
>> based on completeness. New features are added based on either use cases
>> (i.e. problems that authors or users are facing), or compatibility (i.e.
>> things that browsers already do). If there are specific events for which
>> event handler attributes would be useful, I encourage you to request those
>> specifically, describing either the relevant use cases or citing the
>> existing implementations, as appropriate.
>>
>
> The reason event handler properties are useful is that they can be
> detected. A program can make a fair assessment as to whether the
> element supports the event handler in question and how to handle the
> case where that isn't supported.
>
> That isn't possible with event target; there is no such,
> `object.generatesEvent`, nor will there be in D3E, according its
> author.
>
> Garrett
>