Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: It would break existing pages that use expandos on elements or documents via barewords in on* attributes. Isn't that the point of look at element's named properties (if it has any) and look at element's form's named properties (if it has a form)? I assumed named properties meant expando attributes. We could add a check for the document's named properties too. This way, if we introduce Element.prototype.matches or something, that would be skipped entirely in bareword on* lookups. The only new properties we define that would ever be hit for bareword on* lookups are ones on the window, and those would be last in the lookup chain -- which is the same behavior as for non-on* bareword uses.
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On 12/1/11 2:12 PM, Aryeh Gregor wrote: On Fri, Nov 25, 2011 at 11:06 PM, Boris Zbarskybzbar...@mit.edu wrote: It would break existing pages that use expandos on elements or documents via barewords in on* attributes. Isn't that the point of look at element's named properties (if it has any) and look at element's form's named properties (if it has a form)? I assumed named properties meant expando attributes. No, named properties means things exposed via the NameGetter in WebIDL. expandos means things that are just stuck on the object via JS. -Boris
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
Yehuda Katz (ph) 718.877.1325 On Sat, Nov 26, 2011 at 12:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/26/11 1:03 AM, Yehuda Katz wrote: Honestly, before this discussion, I would have been surprised to hear that this works at all. It also seems to me that the group of people who know how to add an expando and the group of people who use onxxx= is pretty small to begin with. This isn't about people doing it on purpose. It's about people doing it by accident via copy/paste programming, which is the common case of using barewords in on* attributes to start with: people who do it have no idea _why_ that code works, just that they copied it from somewhere and that it works. Got it. Can we come up with a real-worldish example of someone using expandos with barewords? -Boris
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On 11/29/11 10:27 PM, Yehuda Katz wrote: Got it. Can we come up with a real-worldish example of someone using expandos with barewords? I'll look around. I recall seeing things like that somewhat recently, but I might be misremembering -Boris
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On 11/26/11 1:03 AM, Yehuda Katz wrote: Honestly, before this discussion, I would have been surprised to hear that this works at all. It also seems to me that the group of people who know how to add an expando and the group of people who use onxxx= is pretty small to begin with. This isn't about people doing it on purpose. It's about people doing it by accident via copy/paste programming, which is the common case of using barewords in on* attributes to start with: people who do it have no idea _why_ that code works, just that they copied it from somewhere and that it works. -Boris
[whatwg] API design restrictions due to barewords in onxxx= attributes
This problem of using bare variables names rather than window.variableName in event handler attributes (which Boris mentions in https://developer.mozilla.org/Writing_Forward_Compatible_Websites) seems annoying. Is there any way we can avoid it by codifying current property lookup behaviour for all existing properties on elements/Document/Window while allowing newly introduced properties not to be found when using bare identifiers? I think we could have an object on the scope chain (when onxxx=s are run) that will, instead of having names resolved in this order: 1. look on element 2. look on element's form (if it has one) 3. look on document 4. look on window (which I assume is achieved by simply having those four objects on the scope chain in that order) does this instead: 1. if property name is in set S, then: a. look on element b. look on element's form (if it has one) c. look on document otherwise: a. look at element's named properties (if it has any) b. look at element's form's named properties (if it has a form) 2. look on window where S is the set of property names corresponding to * the IDL attributes, operations and constants on element's interface, * those on HTMLFormElement (if the element has a form), and * those on Document for the current set of APIs we have deployed. Would this work? Does it sound too brittle or hacky?
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
On 11/25/11 10:19 PM, Cameron McCormack wrote: 1. if property name is in set S, then: a. look on element b. look on element's form (if it has one) c. look on document otherwise: a. look at element's named properties (if it has any) b. look at element's form's named properties (if it has a form) 2. look on window where S is the set of property names corresponding to * the IDL attributes, operations and constants on element's interface, * those on HTMLFormElement (if the element has a form), and * those on Document for the current set of APIs we have deployed. Would this work? Does it sound too brittle or hacky? It would break existing pages that use expandos on elements or documents via barewords in on* attributes. One important question is whether pages do that, of course. -Boris
Re: [whatwg] API design restrictions due to barewords in onxxx= attributes
Yehuda Katz (ph) 718.877.1325 On Fri, Nov 25, 2011 at 8:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/25/11 10:19 PM, Cameron McCormack wrote: 1. if property name is in set S, then: a. look on element b. look on element's form (if it has one) c. look on document otherwise: a. look at element's named properties (if it has any) b. look at element's form's named properties (if it has a form) 2. look on window where S is the set of property names corresponding to * the IDL attributes, operations and constants on element's interface, * those on HTMLFormElement (if the element has a form), and * those on Document for the current set of APIs we have deployed. Would this work? Does it sound too brittle or hacky? It would break existing pages that use expandos on elements or documents via barewords in on* attributes. Honestly, before this discussion, I would have been surprised to hear that this works at all. It also seems to me that the group of people who know how to add an expando and the group of people who use onxxx= is pretty small to begin with. One important question is whether pages do that, of course. -Boris
