-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Conversation
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 |
From the mdn/content perspective, I think we should
That way we achieve:
We can likely have a script to check for redirects and be sure not to forget one. |
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 |
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. |
One more thing: Remove on- event content attributes from https://github.com/mdn/browser-compat-data/blob/main/html/elements/body.json |
I've updated the title and description of this PR. @foolip could you take a look again? |
This now removes lots of stuff, but are all of these events correctly represented in Window.json, every single one? |
They are, yes -- I double-checked by originally creating a |
All right then! And how about the versions, is all data exactly the same, no differences to account for? |
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! |
Alright, thanks for the extra checks! |
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. |
I made all the content updates on MDN for all |
Is this done or can it be a follow-up? |
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. |
There was a problem hiding this 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.
I looked this PR over again and I realize that this is really just adding spec URLs to the existing events on the |
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.