@@unscopable and event handlers

# Jason Orendorff (12 years ago)

Suppose I have:

<p onclick="alert('hello')">

This creates new object environment records. (See the HTML spec, "When an event handler content attribute is set", step 6: www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-content-attributes)

  1. I think the design intent of @@unscopable was that event handlers would be affected, but it doesn't seem to be specified that way, yet. Should ES6 factor anything differently to accommodate what HTML is trying to do there?

  2. Will this cause document[@@unscopable] to be retrieved and examined? If so, that can trigger arbitrary user code, right? Is that OK?

# Allen Wirfs-Brock (12 years ago)

On Sep 25, 2013, at 3:02 PM, Jason Orendorff wrote:

Suppose I have:

<p onclick="alert('hello')">

This creates new object environment records. (See the HTML spec, "When an event handler content attribute is set", step 6: www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-content-attributes)

  1. I think the design intent of @@unscopable was that event handlers would be affected, but it doesn't seem to be specified that way, yet. Should ES6 factor anything differently to accommodate what HTML is trying to do there?

I once tried to convince Hixie that he shouldn't try to tie into ES spec. internal in that manner and that a better alternative would be to express this as a code rewriting such as:

function makeEventHandler (__element__) {
    with (Document)
          with (__element__) 
               return function(event) {
                    <<insert event handler code here >>
                };
 }

I didn't succeed. Doing so would have decoupled the HTML spec. from the actual ES spec. formalism and and instead couple it to the ES language semantics in an edition independent manner.

In this case, explicitly using a with statement would have automatically triggered and @@unscopable with semantics we define. Instead, at some point, the HTML spec. is going to have to do a set of updates in order to bring it into alignment with new ES6 formalisms.

  1. Will this cause document[@@unscopable] to be retrieved and examined? If so, that can trigger arbitrary user code, right? Is that OK?

If document[@@unscopable] is defined as non-configurable the users should be able to associate code with its access.

# Ian Hickson (12 years ago)

On Wed, 25 Sep 2013, Allen Wirfs-Brock wrote:

On Sep 25, 2013, at 3:02 PM, Jason Orendorff wrote:

Suppose I have:

<p onclick="alert('hello')">

This creates new object environment records. (See the HTML spec, "When an event handler content attribute is set", step 6: www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-content-attributes)

  1. I think the design intent of @@unscopable was that event handlers would be affected, but it doesn't seem to be specified that way, yet. Should ES6 factor anything differently to accommodate what HTML is trying to do there?

I once tried to convince Hixie that he shouldn't try to tie into ES spec. internal in that manner and that a better alternative would be to express this as a code rewriting such as:

function makeEventHandler (__element__) {
    with (Document)
          with (__element__) 
               return function(event) {
                    <<insert event handler code here >>
                };
 }

I didn't succeed.

Specifically, this was the conversation: www.w3.org/Bugs/Public/show_bug.cgi?id=11977

Doing so would have decoupled the HTML spec. from the actual ES spec. formalism and and instead couple it to the ES language semantics in an edition independent manner.

I agree with the goal, but I don't think that defining things as a string transformation makes sense, for the reasons discussed in the bug above, primarily that it is hard to reason about exactly what the implications of a particular transform are.

The way we've been doing this for all the other specs is to provide explicit spec hooks, essentially a prose-level stable interface that one specification provides for other specifications to hook into. For example, see this in the HTML spec:

whatwg.org/html#unloading-document-visibility-change-steps

...which is then referenced by the Page Visibility specification. Or see this, which is referenced from HTML:

dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode

Instead, at some point, the HTML spec. is going to have to do a set of updates in order to bring it into alignment with new ES6 formalisms.

Happy to do that when it's appropriate; let me know.