-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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.
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
Inclusion criteria for the events index #8340
Labels
Comments
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. |
dontcallmedom
added a commit
to dontcallmedom/dom
that referenced
this issue
Oct 4, 2022
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
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
This is purely about |
correct |
tidoust
added a commit
to tidoust/webappsec-csp
that referenced
this issue
Oct 4, 2022
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
added a commit
to tidoust/webappsec-csp
that referenced
this issue
Oct 4, 2022
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
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
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 onGlobalEventHandlers
). Such events fall in 3 categories:<dfn>
:securitypolicyviolation
,slotchange
.<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 forslotchange
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
andinput
events link to their definition in UI Events, butcut
,copy
andpaste
do not. Could they rather link to their definitions in the Clipboard APIs spec? Forsecuritypolicyviolation
,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 forvisibilitychange
since that spec has now been merged with HTML.The text was updated successfully, but these errors were encountered: