Closed domenic closed 6 years ago
My issue with that name is that a new developer would likely interpret a layoutchange
as an event that fired when the UI or DOM layout changed (or something similar to that).
This would impact devs wanting to use the keyboard layoutchange
event having more trouble finding docs and devs looking for a UI layout change event who would find an event that didn't do what they were looking for.
To avoid this potential confusion, I think that keyboardlayoutchange
is a better choice even though it's a bit redundant now that it's on the Keyboard object.
Let me know if you have further thoughts on this.
I just don't think this makes sense. You always add an event listener to something. I can't imagine a developer being confused by seeing keyboard.addEventListener("layoutchange", ...) and thinking it has to do with UI or DOM layout.
We don't do input.addEventListener("inputtextchange", ...) we just do "change". We don't do eventSource.addEventListener("eventsourcedata", ...) we just do "data".
I was thinking specifically about things like web search. Yes, a dev won't likely be confused when they see the code in context attached to the keyboard object, but when someone searches for "layoutchange" or "layout change" that context will not always be present or apparent. And for the web, "layout" does not typically mean keyboard layout.
Question: Might we ever want to have something called "layoutchange" that fired on a different object? Because if so, that would be very confusing.
I don't see why that would be confusing. We have tons of "data" and "change" events across the platform. We can't pick unique string names for every event, and prefixing names until they are unique seems like a bad strategy.
Name changed to "layoutchange"
Since it's on the Keyboard object, it can just be "layoutchange"