Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inclusion criteria for the events index #8340

Closed
tidoust opened this issue Sep 30, 2022 · 3 comments
Closed

Inclusion criteria for the events index #8340

tidoust opened this issue Sep 30, 2022 · 3 comments
Labels
clarification Standard could be clearer topic: events

Comments

@tidoust
Copy link

tidoust commented Sep 30, 2022

As noted in #8062 (review), it's not entirely clear what the criteria are for listing events in the events index. I'm wondering whether these criteria could be clarified.

Context for the request is that @dontcallmedom and I have started to extract event information in Webref to create the @webref/events npm package. Event summary tables such as the events index in the HTML spec are useful to get the info we need, including the list of target interfaces at which an event can fire.

The index currently lists events for which there also exists an onxxx IDL attribute in the HTML spec (mainly on GlobalEventHandlers). Such events fall in 3 categories:

  1. Events that the HTML spec fires. Most of the events in the index are in that category. That seems all good to me!
  2. Events that some other spec fires but does not define with a <dfn>: securitypolicyviolation, slotchange.
  3. Events that some other spec both fires and defines with a <dfn>: click, contextmenu, copy, cut, input, paste.

I'm wondering whether you actually want the index to represent events that are fired by the spec, or all events that can fire on HTML interfaces.

If the former, events in 2. and 3. could be dropped from the index. The CSP spec for securitypolicyviolation and the DOM spec for slotchange could then benefit from a small update to actually define the event types themselves. It seems a good idea to encourage specs that fire events to define them in any case.

If the latter, events in 2. and 3. would remain in the index but then I wonder whether we could converge on a common pattern to represent them. The click, contextmenu and input events link to their definition in UI Events, but cut, copy and paste do not. Could they rather link to their definitions in the Clipboard APIs spec? For securitypolicyviolation, slotchange, as above, I think it would be good to have them defined in DOM and the CSP spec instead of in the HTML spec, and to use a link afterwards as well.

I don't feel strongly either way. Dropping the events in categories 2. and 3. from the index has the advantage of being straightforward and to push the definition of the events back to where they belong.

Side note: the reference to [PAGEVIS] could be dropped for visibilitychange since that spec has now been merged with HTML.
@domenic
Copy link
Member

domenic commented Oct 3, 2022

Thanks for this clear problem statement and breakdown! I would be happy with (1). Would you be willing to work on PRs for that? I guess you'd need ones for CSP, DOM, and HTML.

@domenic domenic added clarification Standard could be clearer topic: events labels Oct 3, 2022
dontcallmedom added a commit to dontcallmedom/dom that referenced this issue Oct 4, 2022
@dontcallmedom
Define slotchange event
1a23b37 
Following discussions in whatwg/html#8340, the events
index in the HTML spec will be restricted to event types that gets fired within
the HTML spec. The `slotchange` event will be dropped as a result.

This turns the mention of the `slotchange` event into a proper event type
definition, so that other specs (including the HTML spec) can reference it.
dontcallmedom added a commit to dontcallmedom/html that referenced this issue Oct 4, 2022
@dontcallmedom
Clean events index
c682c6c 
This implements the rule suggested in whatwg#8340 to have the events table only
include events that the HTML spec actually fires.

Changes made:
- Drop `click`, `contextmenu`, `copy`, `cut`, `input`, `paste`,
`securitypolicyviolation` and `slotchange` entries from the table
- Complete the Dependencies section to mention the `copy`, `cut` and `paste`
events defined in Clipboard API and Events, the `slotchange` event (about to be)
defined in DOM and the `securitypolicyviolation` (about to be) defined in CSP.
- Add Clipboard API and Events to the list of references.
- Drop the reference to Page Visibility and drop Page Visibility from the list
of references.

Pull request should only be merged once DOM and CSP get updated to define the
`securitypolicyviolation` and `slotchange` events.
This was referenced Oct 4, 2022
Merged
Merged
@annevk
Copy link
Member

annevk commented Oct 4, 2022

This is purely about <dfn>s for events, right? As in, HTML continue to define onslotchange?

@dontcallmedom
Copy link
Contributor

correct

tidoust added a commit to tidoust/webappsec-csp that referenced this issue Oct 4, 2022
@tidoust
Define securitypolicyviolation event
7c7a894 
Following discussions in whatwg/html#8340, the events
index in the HTML spec will be restricted to event types that gets fired within
the HTML spec. The `securitypolicyviolation` event will be dropped from the
index as a result.

This turns the mention of `securitypolicyviolation` into a proper event type
definition so that other specs (including the HTML spec to map
`onsecuritypolicyviolation` to `securitypolicyviolation`) can reference it.

This also defines the event targets more precisely. In HTML, the event was
defined as firing on `HTMLElement`. In practice, if I read the spec correcty,
the event fires on interfaces that derive from `GlobalEventHandlers` in general
(`HTMLElement`, `MathMLElement`, `SVGElement`, `Document`), and on
`WorkerGlobalScope`.

I note that the definition of `WorkerGlobalScope` should probably also be
amended in HTML to add an `onsecuritypolicyviolation` IDL attribute, as was done
for `GlobalEventHandlers`.

The definition of "policy" suggests that the event could in theory also fire on
`WorkletGlobalScope` but that interface does not inherit from `EventTarget`.
That seems to be adequately covered by the "Report a violation" algorithm. If
firing at `WorkletGlobalScope` is also expected, more changes would be needed.
@tidoust tidoust mentioned this issue Oct 4, 2022
Merged
tidoust added a commit to tidoust/webappsec-csp that referenced this issue Oct 4, 2022
@tidoust
Define securitypolicyviolation event
18c0935 
Following discussions in whatwg/html#8340, the events
index in the HTML spec will be restricted to event types that gets fired within
the HTML spec. The `securitypolicyviolation` event will be dropped from the
index as a result.

This turns the mention of `securitypolicyviolation` into a proper event type
definition so that other specs (including the HTML spec to map
`onsecuritypolicyviolation` to `securitypolicyviolation`) can reference it.

This also defines the event targets more precisely. In HTML, the event was
defined as firing on `HTMLElement`. In practice, if I read the spec correcty,
the event fires on interfaces that derive from `GlobalEventHandlers` in general
(`HTMLElement`, `MathMLElement`, `SVGElement`, `Document`), and on
`WorkerGlobalScope`.

I note that the definition of `WorkerGlobalScope` should probably also be
amended in HTML to add an `onsecuritypolicyviolation` IDL attribute, as was done
for `GlobalEventHandlers`.

The definition of "policy" suggests that the event could in theory also fire on
`WorkletGlobalScope` but that interface does not inherit from `EventTarget`.
That seems to be adequately covered by the "Report a violation" algorithm. If
firing at `WorkletGlobalScope` is also expected, more changes would be needed.
antosart pushed a commit to w3c/webappsec-csp that referenced this issue Oct 4, 2022
@tidoust
Define securitypolicyviolation event (#568)
886ac5d 
Following discussions in whatwg/html#8340, the events
index in the HTML spec will be restricted to event types that gets fired within
the HTML spec. The `securitypolicyviolation` event will be dropped from the
index as a result.

This turns the mention of `securitypolicyviolation` into a proper event type
definition so that other specs (including the HTML spec to map
`onsecuritypolicyviolation` to `securitypolicyviolation`) can reference it.

This also defines the event targets more precisely. In HTML, the event was
defined as firing on `HTMLElement`. In practice, if I read the spec correcty,
the event fires on interfaces that derive from `GlobalEventHandlers` in general
(`HTMLElement`, `MathMLElement`, `SVGElement`, `Document`), and on
`WorkerGlobalScope`.

I note that the definition of `WorkerGlobalScope` should probably also be
amended in HTML to add an `onsecuritypolicyviolation` IDL attribute, as was done
for `GlobalEventHandlers`.

The definition of "policy" suggests that the event could in theory also fire on
`WorkletGlobalScope` but that interface does not inherit from `EventTarget`.
That seems to be adequately covered by the "Report a violation" algorithm. If
firing at `WorkletGlobalScope` is also expected, more changes would be needed.
annevk pushed a commit to whatwg/dom that referenced this issue Oct 4, 2022
@dontcallmedom
Meta: define slotchange event
c3ca964 
Following discussions in whatwg/html#8340, the events index in the HTML spec will be restricted to event types that gets fired within the HTML spec. The slotchange event will be dropped as a result.
@domenic domenic closed this as completed in 627ee28 Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarification Standard could be clearer topic: events
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dontcallmedom @domenic @tidoust @annevk