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.

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

Remove WindowEventHandlers mixin; remove duplicate event content attributes on <body> #15477

Merged
merged 9 commits into from
Apr 27, 2022

Conversation

queengooborg
Copy link
Contributor

@queengooborg queengooborg commented Mar 22, 2022

This PR removes the WindowEventHandlers mixin. The events are placed in Window.json already.

The HTMLBodyElement, HTMLFrameSetElement, and SVGSVGElement interfaces contain the event handler properties as aliases but they are targeted on the window object.

Further, the event content attributes are removed from the HTML body element data to avoid duplication.

@queengooborg queengooborg added data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API needs content update This PR needs a corresponding update to mdn/content to update the documentation labels Mar 22, 2022
@foolip
Copy link
Contributor

foolip commented Mar 28, 2022

I think we should have just a single entry per event here, in Window.idl. Although there are event handler properties in other places, there's just one event. The properties on the other interfaces are a kind of aliases, see this example:

<!DOCTYPE html>
<body>
<script>
var handler = function(){};
window.onhashchange = handler;
alert(document.body.onhashchange == handler); // true
</script>

I think the documentation for these events could mention that it's possible to listen for these events via those other interfaces, and BCD could use partial_implementation if any of the ways aren't supported, but separate entries don't make sense to me.

@teoli2003
Copy link
Contributor

teoli2003 commented Mar 28, 2022

From the mdn/content perspective, I think we should

  1. Have one entry at the topmost possible place (likely Window) redirect.
  2. Have a redirect for onXYZ to the XYZ_event on Window.
  3. For each interface (let's call it IF) it can be thrown at or is bubbling through, we should:
  • have a redirect from IF.onXYZ to Window.XYZ_event
  • have a redirect from IF.XYZ_event to Window.XYZ_event
  • Have a text on each interface page, under Events that the global (or another term) can be caught on such element (with a link to the section of Window or the page where they are listed and explained.

That way we achieve:

  • no duplication of content
  • no surprise any combination of interface.XYZ_event or interface.onXYZ that does exist leads to the correct page.
  • information about all events of a specific object on its interface page.

We can likely have a script to check for redirects and be sure not to forget one.

@Elchi3
Copy link
Member

Elchi3 commented Mar 31, 2022

mdn/content#14515 is an example PR that does what Philip proposed above. I think it makes sense. This way, we just need data in Window.json and we can use partial_implementation when there are issues in any of the other interfaces.

@Elchi3
Copy link
Member

Elchi3 commented Apr 4, 2022

The discussion and proof of concept in mdn/content#14515 was successful. There is a single page for the hashchange event under Window now. The HTMLBodyElement, HTMLFrameSetElement, and SVGSVGElement interface pages list the events but link to the docs under Window.

I will start to work on making the same update for the other events.

In the meantime, this PR needs to change: The events should only appear in Window.json. WindowEventHandlers.json should be removed and no new files in _mixins should be added.

@Elchi3
Copy link
Member

Elchi3 commented Apr 4, 2022

One more thing: Remove on- event content attributes from https://github.com/mdn/browser-compat-data/blob/main/html/elements/body.json

@github-actions github-actions bot added the data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML label Apr 4, 2022
@Elchi3 Elchi3 changed the title Demix WindowEventHandlers; adapt to new events structure Remove WindowEventHandlers mixin; remove duplicate event content attributes on <body> Apr 4, 2022
@Elchi3
Copy link
Member

Elchi3 commented Apr 4, 2022

I've updated the title and description of this PR.

@foolip could you take a look again?

@Elchi3 Elchi3 requested a review from foolip April 4, 2022 15:27
@foolip
Copy link
Contributor

foolip commented Apr 4, 2022

This now removes lots of stuff, but are all of these events correctly represented in Window.json, every single one?

@queengooborg
Copy link
Contributor Author

They are, yes -- I double-checked by originally creating a WindowEventHandlers__Window.json mixin and checking for duplicates. All events were accounted for!

@foolip
Copy link
Contributor

foolip commented Apr 5, 2022

All right then! And how about the versions, is all data exactly the same, no differences to account for?

@queengooborg
Copy link
Contributor Author

There are some version number differences between the two, but I had looked through the commit history and confirmed that the differences are due to updates that have been made after testing (mostly by myself), as well as spec URL differences and some status changes. I'll be copying over the spec URLs now!

@foolip
Copy link
Contributor

foolip commented Apr 5, 2022

Alright, thanks for the extra checks!

@queengooborg queengooborg marked this pull request as draft April 7, 2022 17:24
@queengooborg
Copy link
Contributor Author

I'm marking this as a draft because there is some inaccurate flag data in this mixin that I'd like to get removed first before this is merged.

@Elchi3 Elchi3 removed the needs content update This PR needs a corresponding update to mdn/content to update the documentation label Apr 22, 2022
@Elchi3
Copy link
Member

Elchi3 commented Apr 22, 2022

I made all the content updates on MDN for all WindowEventHandlers events and I opened mdn/content#15246 to remove the WindowEventHandlers mixin page from MDN altogether. It would be good to get this in.

@Elchi3
Copy link
Member

Elchi3 commented Apr 25, 2022

I'm marking this as a draft because there is some inaccurate flag data in this mixin that I'd like to get removed first before this is merged.

Is this done or can it be a follow-up?

@queengooborg
Copy link
Contributor Author

The flag data has mostly been taken care of! I'm leaving this marked as a draft though because I probably need to recreate it, or like GlobalEventHandlers, it'd probably be better to update events one by one.

Copy link
Member

@Elchi3 Elchi3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, as you like. I'm r+ on this PR, though.
I'm quite happy with how WindowEventHandlers is represented on MDN now and with this PR in BCD.

@queengooborg queengooborg marked this pull request as ready for review April 26, 2022 17:11
@queengooborg
Copy link
Contributor Author

I looked this PR over again and I realize that this is really just adding spec URLs to the existing events on the Window interface, so no need to recreate this PR or anything!

@Elchi3 Elchi3 merged commit 682aaf3 into mdn:main Apr 27, 2022
@queengooborg queengooborg deleted the api/WindowEventHandlers branch April 27, 2022 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API data:html Compat data for HTML elements. https://developer.mozilla.org/docs/Web/HTML
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants