Re: Writing spec algorithms in ES6?

[Rick Waldron]

On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola  wrote:

> Some previous discussion: [1] especiallly [2]
>
> In general I think this is a reasonable thing, but it requires a decent
> bit more infrastructure to do things “safely”. For example, consider the
> definition [3]. It's generic in its arguments, which I think is nice (but
> does not fit with Web IDL---whatever). However, it's susceptible to author
> code overriding Array.prototype.join. Similarly, [4] relies upon the
> author-modifiable Math.max and Math.min, not to mention the
> author-modifiable Math binding.
>

Yep. The correct way to use these is to normatively reference the
Well-Known Intrinsic Objects Table[0] in ES2015, and cite any "extensions".
This is how Ecma 402 and the new SIMD spec ensure object integrity when
referring to built-ins.

Rick



[0]
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-intrinsic-objects

Re: RE: It doesn't make sense to use [MapClass] for the CacheList interface

[Rick Waldron]

On Fri, May 9, 2014 at 3:59 AM, 송정기  wrote:

> Jungkee wrote:
> > > Right. We're defining an AsyncMap interface [1] which Cache interface
> and CacheList interface are based off of. AsyncMap isn't spec'd yet in any
> place than in the .ts file. A difficulty encountered is we don't have any
> IDL construct for this yet. Any suggestion? Btw, IMO AsyncMap somehow
> should be standardized in ES7?
>
> Dominic wrote:
> >
> > I don't understand how an AsyncMap "interface" (class) could exist and
> be generic---especially not as a language construct.
> >
> If we do not make it as a language construct, AsyncMap interface would be
> defined in SW space just for Cache interface and CacheList interface I
> guess.
>
> > Things are asynchronous for a reason, e.g. they require I/O to happen.
> No generic class could encapsulate that knowledge.
> Promise already abstracts that async operation. AsyncMap is just a Map
> that runs async. No more no less. It does get/set/... the entry exactly the
> same way as Map does but returning Promise that resolves with the value.
>
> > E.g. what does the algorithm for `get` say in AsyncMap? For some async
> maps it will do file I/O; for others, network I/O; for others, they will
> ask the user for values. A definition for `get` in a generic AsyncMap would
> have to delegate to some kind of `get` hook, but that's pointless, since
> you already have a `get` hook, namely the `get` method you're in the middle
> of defining.
> >
>
> The "hook" should be provided by additional methods defined in the derived
> class, when necessary. Assuming we have AsyncMap (something like the
> following) ready as a language construct in ES,
> // Syntax is in TypeScript
> interface AsyncMap {
>   get(key: K): Promise;
>   has(key: K): Promise;
>   set(key: K, val: V): Promise;
>   clear(): Promise;
>   delete(key: K): Promise;
>   forEach(callback: Function, thisArg?: Object): void;
>   items(): Promise;
>

If trying to match ES APIs, please use "entries", as "items" is not a
thing.


>   keys(): Promise;
>   values(): Promise;
> }
>

Pardon me if I've missed some important context, but why would keys, values
and entries return a Promise when the ES APIs of the same name return an
Iterator?

Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Wed, Apr 30, 2014 at 7:11 AM, Ted Mielczarek  wrote:

> On 4/29/2014 10:39 AM, Ted Mielczarek wrote:
> > The only major issue that needs to be fixed in the Gamepad API spec
> > currently is the liveness of Gamepad objects[1].
> After reading through the discussion here I'm leaning towards specifying
> the snapshot behavior that Chrome implements. Regardless of whether we
> spec an event-based update mechanism in the future, being able to refer
> to a snapshot of Gamepad state seems useful, and there's not much
> overhead in calling navigator.getGamepads()[i] instead of referring
> directly to a saved Gamepad object.
>
> My only reservation is that if Gamepad becomes a snapshot instead of a
> live object, it feels weird to suggest adding output methods to it (like
> adding vibration support). Perhaps I'm overthinking it, though.
>
> Any other thoughts here?
>

I agree with this concern.


Another argument for "live" objects is that it should be possible to reason
about gamepad objects as instances of a Gamepad constructor. The "snapshot"
design destroys any notion of object identity that could be associated with
a gamepad object.

Consider the case where a WeakMap is used to store some side table of
information:

// Live object use...
var wm = new WeakMap();
var gamepad = navigator.getGamepads()[0];

// store some foo counter state
wm.set(gamepad, { foo: 1 });

// later access the foo count (some other aspect of the program has been
updating it)
wm.get(gamepad).foo;


There is no analog in the snapshot case because "gamepad" will be a new
snapshot object every rAF turn, since the reference is lost the WeakMap
will dispose of the key/val pair and the side-table state disposed along
with it.

Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard  wrote:

> On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek  wrote:
>
>>  On 4/29/2014 7:28 PM, Glenn Maynard wrote:
>>
>>   Gamepad objects should definitely be a snapshot.  Otherwise, change
>> events could only expose the most recent state of the gamepad.  For
>> example, if the user presses a button and then releases it very quickly
>> (before the down press gets handled by script), and you fire two change
>> events, the script would never see the buttons as pressed.
>>
>>
>> This is a good point--if we have live objects then if we do implement
>> change events we'd need to store the state elsewhere. Firefox has
>> gamepadbutton{press,release} events and gamepadaxismove events[1][2]
>> (behind a pref), they actually do this already but it's not fantastic.
>>
>
> There should simply be a "change" event, which is fired when any property
> changes.  (Some rate clamping might be needed for analog inputs, which
> could change very quickly, but that's an implementation detail.)
>
>  My original prototype provided the events mentioned above. The feedback I
>> received was overwhelmingly in favor of a polling API instead[3]. I decided
>> to go ahead with that (actually Scott beat me to the punch and implemented
>> that in Chrome first), figuring we could always spec events in a future
>> revision.
>>
>
> (Please try to direct conversations here or to the whatwg list, so
> everyone has a chance to participate...)
>
> Supporting polling is a separate issue from whether the Gamepad interface
> is live or a snapshot.  You definitely want to be able to retrieve a
> snapshot of the current state, and as long as you can do that you
> automatically support polling.
>
> That is, users can either use polling:
>
> onRequestAnimationFrame = function() {
> // Once we create this, it never changes, so we can compare it the
> next time around when it becomes lastGamepadState.
> var gamepadState = navigator.getGamepads();
>
> // Find differences between lastGamepadState and gamepadState and act
> on them:
> for(var i = 0; i < gamepadState.length; ++i)
> processInput(gamepadState[i], lastGamepadState[i]);
>
> // Save the current state, for comparison during the next frame.
> lastGamepadState = gamepadState;
> }
>
> or events:
>
> navigator.onGamepadChange = function(e) {
> var gamepadState = e.state;
> processInput(e.gamepadIndex, gamepadState, lastGamepadState);
> lastGamepadState[e.gamepadIndex] = gamepadState;
> }
>
>
This is exactly the semantics I described here
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0266.html,
with the exception that the Gamepad object is live and the change event
states are "snapshots".


Something else to consider: how does a Gamepad object behave with
Object.observe?

var gamepads = navigator.getGamepads();

Object.observe(gamepads[0], function(changeRecords) {
  ...
});


Presumably the "live" object design will work as expected, invoking the
observe handler at the end of each processing turn "microtask"
(changeRecords will always include the previous and current values), and
the "snapshot" does not.


Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Tue, Apr 29, 2014 at 9:38 PM, Rick Waldron wrote:

>
>
>
> On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard  wrote:
>
>> Gamepad objects should definitely be a snapshot.  Otherwise, change
>> events could only expose the most recent state of the gamepad.  For
>> example, if the user presses a button and then releases it very quickly
>> (before the down press gets handled by script), and you fire two change
>> events, the script would never see the buttons as pressed.
>>
>
> The previously node-dualshock-controller API, emits "change" events from
> the "live" object. The "change" event delivers the state of the actual
> change. A user might "quickly" press button "A" and the listener for "A"
> does whatever updating it must do in the program and has access to both the
> "change state" and the current "live state" of the object.
>


The node-xbox-controller module also follows this design.

Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard  wrote:

> Gamepad objects should definitely be a snapshot.  Otherwise, change events
> could only expose the most recent state of the gamepad.  For example, if
> the user presses a button and then releases it very quickly (before the
> down press gets handled by script), and you fire two change events, the
> script would never see the buttons as pressed.
>

The previously node-dualshock-controller API, emits "change" events from
the "live" object. The "change" event delivers the state of the actual
change. A user might "quickly" press button "A" and the listener for "A"
does whatever updating it must do in the program and has access to both the
"change state" and the current "live state" of the object.

Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Tue, Apr 29, 2014 at 3:27 PM, Florian Bösch  wrote:

> I think both semantics are workable. I'd likely prefer the gamepad state
> to be immutable from JS, because assigning state there is smelly.
>

Yes, there should be no way for user code to directly alter the value of
properties that represent the state of an entity in the physical world. A
firm capabilities limitation policy is used throughout the Johnny-Five
framework to enforce the immutability of such values (implemented as
get-only accessors).


Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Tue, Apr 29, 2014 at 1:45 PM, Brandon Jones  wrote:

> On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller 
> wrote:
>
>> I don't know anything about Gamepad. Could someone provide enough context
>> that I can understand the question? Thanks.
>>
>
> The Gamepad API returns an array of Gamepad state objects when you call
> getGamepads(), like so:
>
> requestAnimationFrame(function() {
> var gamepads = navigator.getGamepads();
> var playerGamepad = gamepads[0];
> if (playerGamepad.buttons[0].pressed) {
> player.jump();
> }
> }
>
> That code currently would work in both Firefox and Chrome. The "Liveness"
> question concerns the following code:
>
> var gamepads = navigator.getGamepads();
> var playerGamepad = gamepads[0];
> requestAnimationFrame(function() {
> if (playerGamepad.buttons[0].pressed) {
> player.jump();
> }
> }
>
> In Firefox this code will be functionally equivalent to the first code
> snippet, since it continues to update the values Gamepad state object after
> you've acquired it. AKA: The object is "live".
>
> In Chrome, however, the gamepad state returned is a snapshot and as such
> the second code snippet will not observe changes to the gamepad input.
>

I'd prefer to be very wrong about this, but my immediate reaction to this
is that it would be expensive to allocate these snapshot objects. Tell me
where I'm misunderstanding:

"SnapShot"

1. For each rAF turn:
  a. Let gp be a snapshot of gamepad
  b. Do stuff with one or more values from gp

vs.

"Live"

1. Let gp be gamepad
2. For each rAF turn:
  a. Do stuff with one or more values from gp


The latter also follows the general model used in Node-based hardware
programming/communication API designs.


Rick





> The spec is currently ambiguous on the matter, so we want to clarify
> whether or not the second code snippet is valid or not and update the
> browser implementations accordingly.
>
> --Brandon
>
>
>> On Tue, Apr 29, 2014 at 10:16 AM, Brendan Eich 
>> wrote:
>>
>>> Boris Zbarsky wrote:
>>>
 For what it's worth, the way Gecko implements this is by setting up
 that lifetime guarantee only when an expando is added to the object (or
 some other things, like use as a WeakMap key, happen).  Until then we allow
 it to be GCed.

>>>
>>> What do other engines do in general? Unobservable GC is a requirement,
>>> if you ask me and Mark Miller.
>>>
>>> /be
>>>
>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek  wrote:

> The only major issue that needs to be fixed in the Gamepad API spec
> currently is the liveness of Gamepad objects[1].
>
> Currently this is implemented differently in Firefox and Chrome--Firefox
> uses "live" Gamepad objects, in that you can take the .gamepad property
> from a GamepadEvent or a Gamepad from navigator.getGamepads(), assign it
> to a variable, and check its state on every pass through the event loop
> to get the latest values of .buttons[]/.axes[]. Chrome uses "snapshot"
> Gamepad objects, so the Gamepad you get from navigator.getGamepads() is
> static, and you have to call getGamepads() on every pass through the
> event loop to get the latest state of the controller.
>
> I obviously have a bias towards what I've already implemented, but I can
> see the appeal of both approaches. With the "live" approach you can take
> a Gamepad object and assign it as a property of another object and use
> it that way, like "player.input = gamepad", which makes it easy to
> manage Gamepad input as part of other code. With the "snapshot" approach
> you can easily save an old snapshot so that you can compare two
> snapshots and see what's changed. (Additionally as an implementation
> detail this maps very well to the Windows XInput API, which is a
> polling-based API.)
>
> Does anyone have any feedback on which of these seems more natural? Is
> there any precedent in the web platform to prefer one approach over the
> other?
>

We just implemented gamepad entity "live-ness" in the dualshock-controller
module for node. The discussion is here:
https://github.com/rdepena/node-dualshock-controller/issues/27



Rick

Re: [HTML Imports]: what scope to run in

[Rick Waldron]

On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma  wrote:

> On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron 
> wrote:
> >
> >
> >
> > On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa  wrote:
> >>
> >> We share the concern Jonas expressed here as I've repeatedly mentioned
> on
> >> another threads.
> >>
> >> On Nov 18, 2013, at 4:14 PM, Jonas Sicking  wrote:
> >>
> >> This has several downsides:
> >> * Libraries can easily collide with each other by trying to insert
> >> themselves into the global using the same property name.
> >> * It means that the library is forced to hardcode the property name
> >> that it's accessed through, rather allowing the page importing the
> >> library to control this.
> >> * It makes it harder for the library to expose multiple entry points
> >> since it multiplies the problems above.
> >> * It means that the library is more fragile since it doesn't know what
> >> the global object that it runs in looks like. I.e. it can't depend on
> >> the global object having or not having any particular properties.
> >>
> >>
> >> Or for that matter, prototypes of any builtin type such as Array.
> >>
> >> * Internal functions that the library does not want to expose require
> >> ugly anonymous-function tricks to create a hidden scope.
> >>
> >>
> >> IMO, this is the biggest problem.
> >>
> >> Many platforms, including Node.js and ES6 introduces modules as a way
> >> to address these problems.
> >>
> >>
> >> Indeed.
> >>
> >> At the very least, I would like to see a way to write your
> >> HTML-importable document as a module. So that it runs in a separate
> >> global and that the caller can access exported symbols and grab the
> >> ones that it wants.
> >>
> >> Though I would even be interested in having that be the default way of
> >> accessing HTML imports.
> >>
> >>
> >> Yes!  I support that.
> >>
> >> I don't know exactly what the syntax would be. I could imagine something
> >> like
> >>
> >> In markup:
> >> 
> >>
> >> Once imported, in script:
> >> new $('mylib').import.MyCommentElement;
> >> $('mylib').import.doStuff(12);
> >>
> >> or
> >>
> >> In markup:
> >> 
> >>
> >> Once imported, in script:
> >> new MyCommentElement;
> >> doStuff(12);
> >>
> >>
> >> How about this?
> >>
> >> In the host document:
> >> 
> >> 
> >> foo1.bar();
> >> foo2();
> >> 
> >>
> >> In foo.js:
> >> module foo1 {
> >> export function bar() {}
> >> }
> >> function foo2() {}
> >
> >
> >
> > Inline module syntax was removed and will not be included in the ES6
> module
> > specification. Furthermore, the example you've illustrated here isn't
> > entirely valid, but the valid parts are already covered within the scope
> of
> > ES6 modules:
> >
> > // in some HTML...
> > 
> > import {foo1, foo2} from "foo";
> >
> > foo1();
> > foo2();
> > 
> >
> > // foo.js
> > export function foo1() {}
> > export function foo2() {}
> >
> >
> > (note that foo2 isn't exported in your example, so would be undefined)
> >
> > Rick
> >
>
> I thought if an identifier wasn't exported trying to import it would
> result in fast failure (SyntaxError)?
>

Yes, my statement above is incorrect.

Rick

Re: [HTML Imports]: what scope to run in

[Rick Waldron]

On Tue, Nov 19, 2013 at 5:27 PM, John J Barton
wrote:

>
>  (snip)
>>
>

>  This isn't how node modules or ES6 modules work. A module designed for
>> use with node can define properties on the `global` (ie. the object whose
>> bound identifier is the word "global") and this is the same global object
>> making the require(...) call. ES6 modules are evaluated in the same global
>> scope from which they are imported.
>>
>
> However ES6 modules do solve the list of downsides in Jonas' list. And ES6
> modules create a scope so variables and functions declared in a module but
> not exported do not pollute the global object as a side-effect of
> declaration.
>
> I think ES6 modules for HTML imports provide a good compromise between
> current HTML import design (no modules just packaging) and total
> iframe-like encapsulation (many practical and design issues).
>

Yes, completely agree that they are the best solution—as long as their
capabilities are understood and their use is specified within the bounds of
those capabilities.

Rick

Re: [HTML Imports]: what scope to run in

[Rick Waldron]

On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa  wrote:

> We share the concern Jonas expressed here as I've repeatedly mentioned on
> another threads.
>
> On Nov 18, 2013, at 4:14 PM, Jonas Sicking  wrote:
>
> This has several downsides:
> * Libraries can easily collide with each other by trying to insert
> themselves into the global using the same property name.
> * It means that the library is forced to hardcode the property name
> that it's accessed through, rather allowing the page importing the
> library to control this.
> * It makes it harder for the library to expose multiple entry points
> since it multiplies the problems above.
> * It means that the library is more fragile since it doesn't know what
> the global object that it runs in looks like. I.e. it can't depend on
> the global object having or not having any particular properties.
>
>
> Or for that matter, prototypes of any builtin type such as Array.
>
> * Internal functions that the library does not want to expose require
> ugly anonymous-function tricks to create a hidden scope.
>
>
> IMO, this is the biggest problem.
>
> Many platforms, including Node.js and ES6 introduces modules as a way
> to address these problems.
>
>
> Indeed.
>
> At the very least, I would like to see a way to write your
> HTML-importable document as a module. So that it runs in a separate
> global and that the caller can access exported symbols and grab the
> ones that it wants.
>
> Though I would even be interested in having that be the default way of
> accessing HTML imports.
>
>
> Yes!  I support that.
>
> I don't know exactly what the syntax would be. I could imagine something
> like
>
> In markup:
> 
>
> Once imported, in script:
> new $('mylib').import.MyCommentElement;
> $('mylib').import.doStuff(12);
>
> or
>
> In markup:
> 
>
> Once imported, in script:
> new MyCommentElement;
> doStuff(12);
>
>
> How about this?
>
> In the host document:
> 
> 
> foo1.bar();
> foo2();
> 
>
> In foo.js:
> module foo1 {
> export function bar() {}
> }
> function foo2() {}
>


Inline module syntax was removed and will not be included in the ES6 module
specification. Furthermore, the example you've illustrated here isn't
entirely valid, but the valid parts are already covered within the scope of
ES6 modules:

// in some HTML...

import {foo1, foo2} from "foo";

foo1();
foo2();


// foo.js
export function foo1() {}
export function foo2() {}


(note that foo2 isn't exported in your example, so would be undefined)

Rick

Re: [HTML Imports]: what scope to run in

[Rick Waldron]

On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking  wrote:

> Hi All,
>
> Largely independently from the thread that Dimitri just started on the
> sync/async/-ish nature of HTML imports I have a problem with how
> script execution in the imported document works.
>
> Right now it's defined that any 

Re: Sync API for workers

[Rick Waldron]

On Sunday, October 13, 2013, James Greene wrote:

> Oh, does `yield` work anywhere? I thought it was only for use within
> generators. Admittedly, I haven't been keeping up with the latest ES6
> changes.
>

yield may only appear in the body of a generator function, denoted by star
syntax: function* g(){}

Rick



> On Oct 13, 2013 9:38 AM, "pira...@gmail.com  'pira...@gmail.com');>"  'pira...@gmail.com');>> wrote:
>
>> Javascript now has support for yield statements the same way Python does,
>> that's a way to stop (ie. sleep) the execution of a script to allow another
>> to work and restart from there. It's not their main function, but allow to
>> create what's called "greenlets", green threads, and that's how I seen sync
>> APIs are build in top of async ones...
>> El 13/10/2013 16:21, "James Greene" 
>> > 'james.m.gre...@gmail.com');>>
>> escribió:
>>
>>> > a) is necessary, but for b) it is sufficient for the sync thread to be
>>> > able to sleep until a condition/mutex/... is lifted
>>>
>>> In other words, your clarification is completely true but my initial
>>> statement was written with regard to client-side JavaScript, which cannot
>>> sleep. As such, I believe my original assertions are still correct with
>>> regard to writing a sync wrapper in JS.
>>> On Oct 13, 2013 9:09 AM, "James Greene" 
>>> >> 'james.m.gre...@gmail.com');>>
>>> wrote:
>>>
 Thanks for adding clarification. That CAN be true but it depends on the
 environment [so far as I can see].

 For example, such an API wrapper couldn't be built in today's
 client-side JavaScript because the UI thread can't do a synchronous
 yielding "sleep" but rather can only do a synchronous blocking wait, which
 means it wouldn't yield to allow for the Worker thread to asynchronously
 respond and toggle such a condition/mutex/etc. unless such can be
 synchronously requested by the blocking thread from within the busy wait
 loop (e.g. `processEvents();`) as browsers won't interrupt the synchronous
 flow of the JS busy loop to trigger `onmessage` handlers for async messages
 sent from the Worker.

 If I'm mistaken, please consider providing a code snippet, gist, etc.
 to get me back on track. Thanks!
 On Oct 13, 2013 5:06 AM, "David Rajchenbach-Teller" <
 dtel...@mozilla.com >
 wrote:

> On 10/12/13 3:48 PM, James Greene wrote:
> > You can only build a synchronous API on top of an asynchronous API if
> > they are (a) running in separate threads/processes AND (b) the sync
> > thread can synchronously poll (busy loop) for the
> progress/completion of
> > the async thread.
>
> a) is necessary, but for b) it is sufficient for the sync thread to be
> able to sleep until a condition/mutex/... is lifted
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>

Re: Making selectors first-class citizens

[Rick Waldron]

On Wed, Sep 11, 2013 at 9:33 AM, Anne van Kesteren  wrote:

> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just like
> regular expressions, and have this:
>
>   var sel = new Selectors("i > love > selectors, so[much]")
>   sel.test(node)
>

A prime use case: a cache of selector objects that are useful when matching
event.target for event handler delegation patterns. Can you describe the
Selector instance object a little more? Thanks!

Rick

Re: webcomponents: instead of

[Rick Waldron]

On Tue, May 14, 2013 at 4:01 PM, Scott Miles  wrote:

> I can't think of any reason I would want to be able to mess with an import
> link ex-post-facto and have it do anything. I would also expect any
> registrations to be final and have no particular connection to the link tag
> itself.
>
> Now, this may be tangential, but users definitely need a way of loading
> imports dynamically. I believe the current gambit would be to inject a
> fresh link tag into head, which seems like the long way around Hogan's barn.
>
> I've been meaning to ask about the possibility of an imperative 'import'
> method.
>

"import" is a FutureReservedWord that will be a Keyword as of ES6, so this
"import" method would have to be a method of some platform object and not a
method on [[Global]] object.


Rick

Re: Draft minutes: 26 April 2013 f2f meeting

[Rick Waldron]

This is hard to follow... Almost like two different discussions are
happening at the same time. One discussion has "person: ..." the other
" ..."

Rick

On Saturday, April 27, 2013, Arthur Barstow wrote:

> The Draft minutes from WebApps' April 26 f2f meeting are at the following
> and copied below:
>
>  
> 
> >
>
> If you have corrections, comments, etc., please reply by May 2.
>
> Thanks very much to Josh Soref for once again being an excellent Scribe!
>
> And a Huge thanks to Daniel Austin and PayPal for hosting the meeting!
>
> -AB
>
> W3C 
>
>
>  - DRAFT -
>
>
>  Web Applications WG F2F Meeting
>
>
>26 Apr 2013
>
> Agenda 
> 
> >
>
> See also:IRC log 
> 
> >
>
>
>Attendees
>
> Present
>Art_Barstow, Charles_McCathieNevile, Josh_Soref, Robin_Berjon,
>Yves_Lafon, Ted_Oconnor, Laszlo_Gombos, Tyler_Barton,
>Adrian_Bateman, Glenn_Adams, Doug_Turner, Bryan_Sullivan, Bin_Hu,
>Arnaud_Braud, Yosuke_Funahasi, Jae_Won_Chung, Hiroyuki_Aizu,
>adrianba, Lyle_Troxell, eliot_graff, Yosuke_Funahashi, krisk,
>Jungkee_Song, Eduardo_Fullea, Jonghong_Jeon, Mike_Smith,
>Arun_Ranganathan, Wonsuk_Lee, MikeSmith!, hober
> Regrets
> Chair
>Art, Charles
> Scribe
>Josh_Soref
>
>
>Contents
>
>  * Topics 
> 
> >
> 1. testing 
> 
> >
> 2. Move to Github
>
> 
> >
> 3. Progress Events
>
> 
> >
> 4. XHR Status
>
> 
> >
> 5. Coordination (TC39)
>
> 
> >
>  * Summary of Action Items
>
> 
> >
>
> --**--**
> 
>
>  Scribe: Josh_Soref
>
>  ScribeNick: timeless
>
>  i
>
>  trackbot, start telcon
>
>  Meeting: Web Applications Working Group Teleconference
>
>  Date: 26 April 2013
>
>  Ta
>
>  Shenzhen
>
> *ACTION:*barstow announce the WG will meet during TPAC 2013 in
> November [recorded inhttp://www.w3.org/2013/04/**26-webapps-minutes.html#*
> *action01 ]
>
>  Created ACTION-692 - Announce the WG will meet during TPAC 2013
> in November [on Arthur Barstow - due 2013-05-03].
>
>  ScribeNick: darobin
>
> chaals:that was painless
> ... the chartering stuff
> ... what do we need to add or remove
> ... we have a spec called URL, we asked if people would work on it
>
> Inventory of Charter updates that need to be made or might be made <
> http://www.w3.org/wiki/**Webapps/Charter
> >
>
> chaals:Anne is not in WebApps, so can't edit
> ... no one in WebApps is editing it
> ... Anne is working on it outside W3C
> ... should we keep it in our charter
>
>  Hi Jungkee
>
> Robin:if we're just republishing, why not automate it?
>
> chaals:uh, we actually want a responsible editor
>
>  I note that chaals said "Anne puts his spec in the public domain,
> so you can just copy it"
>
> dougt:how about we could just resolve the dispute over the licensing
> instead?
>
> chaals:we could, but that's outside the scope of this group
> ... if the AC get a consensus, then the problem goes away
> ... until that happens, we need to figure out what to do with that spec
> ... if no one is committing to it, seems pointless to have it in the
> charter
>
> robin:just pointing out that this is pretty fundamental
>
> bryan:is this really cut and paste?
>
> group:yeah
>
> bryan:so why not just do it?
>
> chaals:because no one volunteers
>
> dougt:the problem is the license, so we should transition to an open
> license
>
> ArtB:do we want to start a CfC to drop URL?
>
> chaals:alternative proposal...
>
> robin:the group could go on strike until there's a new license
>
> chaals:I can take over URL if the group appoints me to it
>
> *ACTION:*charles to be the default Editor of URL spec [recorded
> inhttp://www.w3.org/2013/04/**26-webapps-minutes.html#**action02

Re: [webcomponents]: Wars: A New Hope

[Rick Waldron]

On Wed, Apr 17, 2013 at 7:33 PM, Daniel Buchner  wrote:

> So let me be *crystal clear*:
>
> If define() internally does this --> "When the registration line comes,
> the browser-thing matches  instances and supplied property objects
> by custom element names, uses them to create prototypes, and then calls
> document.register with respective custom element name and prototype as
> arguments." - it's doing a hell-of-a-lot more than simply redirecting to
> Object.create - in fact, I was thinking it would need to do this:
>

I didn't say Object.create, I said Object.defineProperties. I think you
should get your Object meta APIs straight before having discussions about
them.


>
>- Retain all tagName-keyed property descriptors passed to it on a
>common look-up object
>- Interact with the portion of the system that handles assessment of
>the "registration line", and whether it has been crossed
>- and if called sometime after the "registration line" has been
>crossed, immediately invokes code that upgrades all in-DOM elements
>matching the tagName provided
>
> I could be mistaken - but my interest is valid, because if true I would
> need to polyfill the above detailed items, vs writing something as simple
> and derpish as: HTMLElementElement.prototype.define = ...alias to
> Object.create...
>
This appears to move the previously static HTMLFooElement.define( tag,
descriptor ) method and now pollutes the prototype with a method of the
same name? Why? Do you actually want every instance of HTMLFooElement to be
able to call a define() method over and over again? I assumed this was a
once-per-element operation...

At any rate, of course it's not as simple as an alias assignment and no one
suggested that—perhaps you're not familiar with the definition of the word
"repackage"? It means to alter or remake, usually to make something more
appealing. Sounds about right, doesn't it? I think you should be careful of
what you refer to as "derpish".



Rick



>  Dimitri, Scott can you let me know if that sounds right, for polyfill
> sake?
>
> On Wed, Apr 17, 2013 at 4:11 PM, Rick Waldron wrote:
>
>>
>>
>>
>> On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner wrote:
>>
>>> *"This is just a repackaging of Object.defineProperties( target,
>>> PropertyDescriptors ) thats slightly less obvious because the target
>>> appears to be a string."
>>> *
>>> Is another difference that the 'x-foo' doesn't have to be 'known' yet?
>>> It seems to be a bit more than a repack of Object.defineProperties to me.
>>>
>>>
>> I'm sorry if I was unclear, but my comments weren't subjective, nor was I
>> looking for feedback.
>>
>> Looks like Dimitri agrees:
>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0306.html
>>
>> Rick
>>
>>
>>
>>>
>>>
>>> On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov 
>>>> wrote:
>>>>
>>>>> Inspired by Allen's and Scott's ideas in the "Benadryl" thread, I dug
>>>>> into understanding what  actually represents.
>>>>>
>>>>> It seems that the problem arises when we attempt to make 
>>>>> _be_ the document.register invocation, since that draws the line of
>>>>> when the declaration comes to existence (the registration line) and
>>>>> imposes overly restrictive constraints on what we can do with it.
>>>>>
>>>>> What if instead, the mental model of  was a statement of
>>>>> intent? In other words, it says: "Hey browser-thing, when the time is
>>>>> right, go ahead and register this custom element. kthxbai"
>>>>>
>>>>> In this model, the proverbial registration line isn't drawn until
>>>>> later (more on that in a moment), which means that both  and
>>>>> 

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Wed, Apr 17, 2013 at 10:34 PM, Bjoern Hoehrmann wrote:

> * Rick Waldron wrote:
> >On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann 
> wrote:
> >> * Rick Waldron wrote:
> >> >If I want to make a new button to put in the document, the first thing
> my
> >> >JS programming experience tells me:
> >> >
> >> >  new Button();
> >>
> >> And if you read code like `new A();` your programming experience would
> >> probably tell you that you are looking at machine-generated code.
> >
> >I'm not sure what your own experience is, but I completely disagree.
>
> I think it is easy to agree with your analogy above. My purpose was to
> offer reasons why it is a bad analogy that does not hold when you take
> into account various other constraints and problems. For the specific
> example, I think it is unreasonable for humans to define single-letter
> global names in a shared namespace, and even more unreasonable for some
> standards organisation to do so. With `A` in particular, there is also
> the problem that `` might be "HTML" or it might be "SVG", so mapping
> `new Button()` to `` is not an analogy that works all the time.
>

It's a good thing I never suggested this... I never assumed anything
cheaper then HTMLFooElement to construct a 



>
> >> And between
> >>
> >>   new HTMLButtonElement();
> >>
> >> and
> >>
> >>   new Element('button');
> >>
> >> I don't see why anyone would want the former in an environment where you
> >> cannot rely on `HTMLHGroupElement` existing (the `hgroup` element had
> >> been proposed, and is currently withdrawn, or not, depending on where
> >> you get your news from).
> >
> >The latter is indeed a much nicer to look at then the former, but Element
> >is higher then HTMLButtonElement, so how would Element know that an
> >argument with the value "button" indicated that a HTMLButtonElement should
> >be allocated and initialized? Some kind of nodeName => constructor map, I
> >suppose...? (thinking out loud)
>
> As above, `new Element('a')` does not indicate whether you want a HTML
> `` element or a a SVG `` element. When parsing strings there is,
> in essence, such a map, but there is more context than just the name.
> That may well be a design error, perhaps "HTML" and "SVG" should never
> have been separate namespaces.
>
>
I'm with you here, certainly unfortunate. But new SVGAElement() is pretty
straightforward.



>  >> in contrast to, if you will,
> >>
> >>   var button = new Button();
> >>   button.ownerDocument.example(...);
> >
> >I would expect this:
> >
> >  var button = new HTMLButtonElement();
> >  button.ownerDocument === null; // true
> >
> >  document.body.appendChild(button);
> >
> >  button.ownerDocument === document; // true
>
> Indeed. But browser vendors do not think like that.
>

I'm of the mind that browser vendors and implementors need to be
accountable to the developers using the platform, instead of developers
being hostages of the platform.

Rick


> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: [webcomponents]: Wars: A New Hope

[Rick Waldron]

On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner  wrote:

> *"This is just a repackaging of Object.defineProperties( target,
> PropertyDescriptors ) thats slightly less obvious because the target
> appears to be a string."
> *
> Is another difference that the 'x-foo' doesn't have to be 'known' yet? It
> seems to be a bit more than a repack of Object.defineProperties to me.
>
>
I'm sorry if I was unclear, but my comments weren't subjective, nor was I
looking for feedback.

Looks like Dimitri agrees:
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0306.html

Rick



>
>
> On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron wrote:
>
>>
>>
>>
>> On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov wrote:
>>
>>> Inspired by Allen's and Scott's ideas in the "Benadryl" thread, I dug
>>> into understanding what  actually represents.
>>>
>>> It seems that the problem arises when we attempt to make 
>>> _be_ the document.register invocation, since that draws the line of
>>> when the declaration comes to existence (the registration line) and
>>> imposes overly restrictive constraints on what we can do with it.
>>>
>>> What if instead, the mental model of  was a statement of
>>> intent? In other words, it says: "Hey browser-thing, when the time is
>>> right, go ahead and register this custom element. kthxbai"
>>>
>>> In this model, the proverbial registration line isn't drawn until
>>> later (more on that in a moment), which means that both  and
>>> 

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann  wrote:

> * Rick Waldron wrote:
> >Of course, but we'd also eat scraps from the trash if that was the only
> >edible food left on earth. document.createElement() is and has always been
> >"the wrong way"—the numbers shown in those graphs are grossly skewed by a
> >complete lack of any real alternative.
> >
> >If I want to make a new button to put in the document, the first thing my
> >JS programming experience tells me:
> >
> >  new Button();
>
> And if you read code like `new A();` your programming experience would
> probably tell you that you are looking at machine-generated code.


I'm not sure what your own experience is, but I completely disagree.



> And if
> you read `new Time();` you would have no idea whether this creates some
> `new Date();`-like object, or throw an exception because the browser you
> try to run that code on does not support the `` element "yet" or
>

I would expect a  element to be constructed with:

new HTMLTimeElement();

... since that's the name of the constructor/prototype that's defined for
the  element.


> "anymore" (the element was proposed, withdrawn, and then proposed again)
> and if it's something like
>
>   var font = new Font("Arial 12pt");
>   canvas.drawText("Hello World!", font);
>
> The idea that you are constructing `` elements probably wouldn't
> cross your mind much.


Because I would constructor a  element with:

new HTMLFontElement()

... since that's the name of the constructor/prototype that's defined for
the  element.


> And between
>
>   new HTMLButtonElement();
>
> and
>
>   new Element('button');
>
> I don't see why anyone would want the former in an environment where you
> cannot rely on `HTMLHGroupElement` existing (the `hgroup` element had
> been proposed, and is currently withdrawn, or not, depending on where
> you get your news from).


The latter is indeed a much nicer to look at then the former, but Element
is higher then HTMLButtonElement, so how would Element know that an
argument with the value "button" indicated that a HTMLButtonElement should
be allocated and initialized? Some kind of nodeName => constructor map, I
suppose...? (thinking out loud)



> Furthermore, there actually are a number of
> dependencies to take into account, like in
>
>   var agent = new XMLHttpRequest();
>   ...
>   agent.open('GET', 'example');
>
> Should that fail because the code does not say where to get `example`
> from, or should it succeed by picking up some base reference magically
> from the environment (and which one, is `example` relative to from the
> script code, or the document the code has been transcluded into, and
> when is that decision made as code moves across global objects, and so
> on)?


I'm not sure how this is a dependency or even relevant to the discussion.



> Same question for `new Element('a')`, if the object exposes some
> method to obtain the "absolute" value of the `href` attribute in some
> way.
>
> >But I live in the "bad old days" (assuming my children won't have to use
> >garbage APIs to program the web) and my reality is still here:
> >
> >  document.createElement("button");
>
> That very clearly binds the return value to `document` so you actually
> can do
>
>   var button = document.createElement("button");
>   ...
>   button.ownerDocument.example(...);
>

As a static factory, sure, but implied ownerDocument context binding isn't
a strong argument for neutering the specific element constructors. Really,
I should be able to do both... If I create a new element, I should have the
ability to bind that element to whatever document that makes the most sense
for my application's needs (an iframe's document? an xml document?).
Inserting a new-born-detached element into a specific document or
explicitly binding that element to a document via some imperative mechanism
makes just as much sense as your example.


>
> in contrast to, if you will,
>
>   var button = new Button();
>   button.ownerDocument.example(...);
>

I would expect this:

  var button = new HTMLButtonElement();
  button.ownerDocument === null; // true

  document.body.appendChild(button);

  button.ownerDocument === document; // true

Or

  // pass a context arg?
  var button = new HTMLButtonElement(document);
  button.ownerDocument === document; // true

OR

  var button = new HTMLButtonElement();
  // explicitly set the context?
  button.ownerDocument = document;



>
> where `button.ownerDocument` could only have a Document value if ther

Re: Using readyCallback for built-in elements, was: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Tue, Apr 16, 2013 at 5:33 PM, Dimitri Glazkov wrote:

> On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren 
> wrote:
> >
> > I think we should go for one interface per element here. "abstract
> > classes" not being constructable seems fine. Node/CharacterData are
> > similar to that. This would mean HTMLH1Element, ..., of which
> > compatibility impact has not been measured.
> >
> > The other problem we need to solve is that document.createElement()
> > currently gives different results from new . E.g. new
> > Audio() sets an attribute, document.createElement("audio") does not. I
> > think we should settle for document.createElement("audio") also
> > creating an attribute here.
>
> What if we use the newly-found power if readyCallback here?
>
> Suppose that HTMLAudioElement has a readyCallback that, among other things
> does:
>
> if (!this.parentNode) // aha! I am created imperatively
>this.setAttribute("controls");
>
> Several HTML elements will need to use the callback to build their
> shadow trees and set internal state, like , ,
> , , etc.
>
> If we just build readyCallback into DOM, we have cake.
>

Can someone point me to the discussion that lead to the name choice
"readyCallback"?

Thanks

Rick


>
> :DG<
>

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky  wrote:

> On 4/15/13 10:45 AM, Rick Waldron wrote:
>
>> Sorry, I should've been more specific. What I meant was that:
>>
>> new HTMLButtonElement();
>>
>> Doesn't construct an HTMLButtonElement, it throws with an "illegal
>> constructor" in Chrome and "HTMLButtonElement is not a constructor" in
>> Firefox (I'm sure this is the same across other browsers)
>>
>
> Oh, I see.  That's not anything inherent, for what it's worth; making this
> particular case work would be <10 lines of code.  Less on a per-element
> basis if we want to do this for most elements.
>
>
>  function Smile() {
>>HTMLButtonElement.call(this);
>>this.textContent = ":)";
>> }
>>
>> Smile.prototype = Object.create(**HTMLButtonElement.prototype);
>>
>
> Ah, so... This would not work even if "new HTMLButtonElement" worked,
> right?


I guess I assumed this would work if new HTMLButtonElement() could
construct things


> In particular, if HTMLButtonElement were actually something that could
> construct things in Gecko, it would still ignore its argument when called
> and always creates a new object.  You can see the behavior with something
> like XMLHttpRequest if you want.
>

What I was expecting the above to produce is a constructor capable of
something like this:

  var smile = new Smile();
  smile.nodeType === 1;
  smile.outerHTML === ":)"; // true
  // (and so forth)
  document.body.appendChild(smile);

results in something like this: http://gul.ly/de0


Rick



>
>  Hopefully that clarifies?
>>
>
> Somewhat.  Trying to understand what things we really need to support here
> and in what ways, long-term...
>
> -Boris
>

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky  wrote:

> On 4/14/13 5:35 PM, Rick Waldron wrote:
>
>> I have a better understanding of problem caused by these generated
>> HTML*Element constructors: they aren't constructable.
>>
>
> I'd like to understand what's meant here.  I have a good understanding of
> how these constructors work in Gecko+SpiderMonkey, but I'm not sure what
> the lacking bit is, other than the fact that they have to create JS objects
> that have special state associated with them, so can't work with an object
> created by the [[Construct]] of a typical function.
>
> Is that what you're referring to, or something else?


Sorry, I should've been more specific. What I meant was that:

new HTMLButtonElement();

Doesn't construct an HTMLButtonElement, it throws with an "illegal
constructor" in Chrome and "HTMLButtonElement is not a constructor" in
Firefox (I'm sure this is the same across other browsers)

Which of course means that this is not possible even today:

function Smile() {
  HTMLButtonElement.call(this);
  this.textContent = ":)";
}

Smile.prototype = Object.create(HTMLButtonElement.prototype);


Since this doesn't work, the prototype method named "readyCallback" was
invented as a bolt-on stand-in for the actual [[Construct]]

Hopefully that clarifies?

Rick


PS. A bit of trivial... A long time ago some users requested that
jQuery facilitate a custom constructor; to make this work, John put the
actual constructor code in a prototype method called "init" and set that
method's prototype to jQuery's own prototype. The thing called
"readyCallback" is similar. For those that are interested, I created a gist
with a minimal illustration here: https://gist.github.com/rwldrn/5388544





>
>
> -Boris
>

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner  wrote:

> *>> Here are four ways to avoid the subclassing problem for custom
> elements
> *
> *>> 1)  Only allow instances of custome dom elements to be instantiated
> using document.createElement("x-foo").
> *
> *
> *
> *Wearing web developer hat, I never make elements any other way than
> createElement (or HTML), so this would be standard operating procedure, so
> that's all good if we can get buy in.*
>
> As long as the above supports all other DOM element creation vectors
> (innerHTML, outerHTML, etc), then this is fine. Practically speaking, if it
> so happened that custom elements could *never *be instantiated with
> constructors, developers on the web today wouldn't shed a tear, they use
> doc.createElement(), not constructors -->
> https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/viewanalytics
>
> -
>
>
> *>> Alex Russell have been advocating that WebIDL should be allow
> constructor-like interfaces*
> *
> *
> *Absolutely agree. But these are horns of this dilemma.*
> *
> *
> *>> #4 has been accepted for ES6 by all TC39 participants*
> *
> *
> *Yes, I believe this is a timing issue. I am told it will be a long time
> before #4 is practical.*
>
> Yes, it will be along time, especially for IE9 and 10 (read: never), which
> are support targets for custom element polyfills. Reliance on anything that
> is optional or future should be avoided for the custom element base case.
> Right now the polyfills for document.register(), and a few of the
> declarative proposals, can give developers these awesome APIs today -
> please, do not imperil this.
>
>
After reading Scott Miles' post here
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0209.html, I
have a better understanding of problem caused by these generated
HTML*Element constructors: they aren't constructable. No amount of ES6
subclass support will fix that problem. The platforms need to make them
constructable—and that can't be polyfilled. I also now understand why such
great lengths have been taken to "hack" around the problem, and the
resulting "solution" with bolt-on ready* callbacks (that aren't really
callbacks, just prototype methods that will be called after some turn of
execution has initialized some element state) as stand-ins for the real
constructor function. This is somehow "ok" because it's polyfillable?


Rick

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner  wrote:

> *>> Here are four ways to avoid the subclassing problem for custom
> elements
> *
> *>> 1)  Only allow instances of custome dom elements to be instantiated
> using document.createElement("x-foo").
> *
> *
> *
> *Wearing web developer hat, I never make elements any other way than
> createElement (or HTML), so this would be standard operating procedure, so
> that's all good if we can get buy in.*
>
> As long as the above supports all other DOM element creation vectors
> (innerHTML, outerHTML, etc), then this is fine. Practically speaking, if it
> so happened that custom elements could *never *be instantiated with
> constructors, developers on the web today wouldn't shed a tear, they use
> doc.createElement(), not constructors -->
> https://docs.google.com/forms/d/16cNqHRe-7CFRHRVcFo94U6tIYnohEpj7NZhY02ejiXQ/viewanalytics
>

Of course, but we'd also eat scraps from the trash if that was the only
edible food left on earth. document.createElement() is and has always been
"the wrong way"—the numbers shown in those graphs are grossly skewed by a
complete lack of any real alternative.

If I want to make a new button to put in the document, the first thing my
JS programming experience tells me:

  new Button();

But I live in the "bad old days" (assuming my children won't have to use
garbage APIs to program the web) and my reality is still here:

  document.createElement("button");

This indicates nothing about state or initialization. And of course
developers are going to fill out a survey and say they use this API—there
isn't any other API to use! It would be awkward to have a few new Image()
or new Option() expressions sprinkled around your code—unless all element
instantiation looked like that, then it would be the status quo and that
survey would have very different results.



>
> -
>
>
> *>> Alex Russell have been advocating that WebIDL should be allow
> constructor-like interfaces*
> *
> *
> *Absolutely agree. But these are horns of this dilemma.*
> *
> *
> *>> #4 has been accepted for ES6 by all TC39 participants*
> *
> *
> *Yes, I believe this is a timing issue. I am told it will be a long time
> before #4 is practical.*
>
> Yes, it will be along time, especially for IE9 and 10 (read: never), which
> are support targets for custom element polyfills. Reliance on anything that
> is optional or future should be avoided for the custom element base case.
> Right now the polyfills for document.register(), and a few of the
> declarative proposals, can give developers these awesome APIs today -
> please, do not imperil this.
>
>
And progress suffers.


Rick

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock
wrote:

>
>
> I see two ways you might do this:
>
> 1) create a new *anonymous* constructor object that inherits  from
> HTMLElement.  It wouldn't have any unique behavior but it would be uniquely
> associated the particular  that defined it and it might be useful
> for doing instanceof tests.  It would be the constructor that you register
> with the tag.
>


This is much better then the semantics I described for handling cases where
no explicit constructor exists—nice!


> 2) Have a new kind of HTML*Element that is used when instantiating all
> custom elements that don't have explicit constructors. As a placeholder
> name I'll use HTMLAppDefinedElement.  One system defined
> HTMLAppDefinedElement constructor can be used for all such custom elements
> because they have no distinguishing behavior.  So every  would have
> a dom node that was an instance of HTMLAppDefinedElement and so would every
> . The instances only differ in their identify and the value of the
> tag names (and their children, etc.).
>
> Note in both these cases there are no  specific behaviors and
> hence no need to install prototype properties. I think if an element needs
> such custom behavior it should be required to use a "constructor="
> attribute to associate an app provided constructor object with the element
> and the constructor should be specified in a normal 

Re: [webcomponents]: Of weird script elements and Benadryl

[Rick Waldron]

On Fri, Apr 12, 2013 at 7:14 PM, Dimitri Glazkov wrote:

> On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron 
> wrote:
> >
> >
> >
> > On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov 
>
> > Can you point me to some concrete example, docs, implementation, code
> > (anything) that I might gain some insight into these generated
> constructors
> > you speak of? Thanks :)
>
> Spec:
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#elements-and-dom-interfaces
>
> Implementation in Blink/WebKit:
>
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/WebCore/dom/CustomElementConstructor.h
>
> Implementation in Mozilla:
>
> https://hg.mozilla.org/integration/mozilla-inbound/diff/871fea464883/content/base/src/nsDocument.cpp#l1.245
>
> Hope this helps!
>
>
This does help, but at the moment I can't think of a solution to your
earlier "con" point. Thanks for the info!

Rick



> :DG<
>

Re: [webcomponents]: Platonic form of custom elements declarative syntax

[Rick Waldron]

cc Allen Wirfs-Brock, Dave Herman

Allen, Dave

Would you mind reading back through the  thread to provide some deeper
insight? Thanks

Rick



On Wednesday, April 10, 2013, Daniel Buchner wrote:

> Here are a few (compelling?) answers/arguments:
>
>1. Style elements had never done this before, yet it rocks socks:
>

Re: [webcomponents]: Platonic form of custom elements declarative syntax

[Rick Waldron]

On Wed, Apr 10, 2013 at 5:35 PM, Daniel Buchner  wrote:

> One thing I'm wondering re  elements and the association of a
> specific script with them, is what is it really doing for me? From what I
> see, not much. It seems the only thing it does, is allows you to have the
> generic, globally-scoped script run at a given time (via a new runwhen___
> attribute) and the implicit relationship created by inclusion within the
>  element itself - which is essentially no different than just
> setting a global delegate in any 'ol script tag on the page.
>

I'd be interested in seeing a reasonable set of semantics defining how that
specific script tag knows what its "this" value is; so far I understand
that inside those script tags, |this| !== |window|.


@Erik, what about |self|? That actually makes more sense and *almost* has a
precedent in worker global scope


 Rick

Re: [webcomponents]: Platonic form of custom elements declarative syntax

[Rick Waldron]

On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner  wrote:

> *What about CSP that forbids inline 
> scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
> *
>
> Is there any reason developers wouldn't just modify the script tag under
> either method proposed to use src="link-to-non-inline-script" to satisfy
> CSP requirements? The proposal I submitted certainly doesn't exclude that
> ability/use case (or so I thought - correct if wrong)
>
>
There is nothing stopping that at all.

A bigger issue with proposal is that the global object appears to be the
element's instance object itself, which isn't going to work

Rick



>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Corporation
>
>
> On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron wrote:
>
>>
>>
>>
>> On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner wrote:
>>
>>> I have a counter proposal that takes into a count both the
>>> easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements
>>> case: https://gist.github.com/csuwldcat/5358039
>>>
>>
>>
>> What about CSP that forbids inline scripts?
>>
>> https://wiki.mozilla.org/Apps/Security#Default_CSP_policy
>>
>> Rick
>>
>>
>>>
>>>
>>> I can explain the advantages a bit more in an hour or so, I just got
>>> pulled into a meeting...le sigh.
>>>
>>> Daniel J. Buchner
>>> Product Manager, Developer Ecosystem
>>> Mozilla Corporation
>>>
>>>
>>> On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles wrote:
>>>
>>>> No, strictly ergonomic. Less nesting and less characters (less nesting
>>>> is more important IMO).
>>>>
>>>> I would also argue that there is less cognitive load on the author then
>>>> the more explicit factoring, but I believe this is subjective.
>>>>
>>>> Scott
>>>>
>>>>
>>>> On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein 
>>>> wrote:
>>>>
>>>>> On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov 
>>>>> wrote:
>>>>> > Dear Webappsonites,
>>>>> >
>>>>> > There's been a ton of thinking on what the custom elements
>>>>> declarative
>>>>> > syntax must look like. Here, I present something has near-ideal
>>>>> > developer ergonomics at the expense of terrible sins in other areas.
>>>>> > Consider it to be beacon, rather than a concrete proposal.
>>>>> >
>>>>> > First, let's cleanse your palate. Forget about the  element
>>>>> > and what goes inside of it. Eat some parsley.
>>>>> >
>>>>> > == Templates Bound to Tags ==
>>>>> >
>>>>> > Instead, suppose you only have a :
>>>>> >
>>>>> > 
>>>>> > Yay!
>>>>> > 
>>>>> >
>>>>> > Templates are good for stamping things out, right? So let's invent a
>>>>> > way to _bind_ a template to a _tag_. When the browser sees a tag to
>>>>> > which the template is bound, it stamps the template out. Like so:
>>>>> >
>>>>> > 1) Define a template and bind it to a tag name:
>>>>> >
>>>>> > 
>>>>> > Yay!
>>>>> > 
>>>>> >
>>>>> > 2) Whenever  is seen by the parser or
>>>>> > createElement/NS("my-yay") is called, the template is stamped out to
>>>>> > produce:
>>>>> >
>>>>> > 
>>>>> > Yay!
>>>>> > 
>>>>> >
>>>>> > Cool! This is immediately useful for web developers. They can
>>>>> > transform any markup into something they can use.
>>>>> >
>>>>> > Behind the scenes: the presence of "boundtotagname" triggers a call
>>>>> to
>>>>> > document.register, and the argument is a browser-generated prototype
>>>>> > object whose readyCallback takes the template and appends it to
>>>>> > "this".
>>>>> >
>>>>> > == Organic Shadow Trees  ==
>>>>> >
>>>>> > But what if they also wanted to employ encapsulation boundaries,
>>>>> >

Re: [webcomponents]: Platonic form of custom elements declarative syntax

[Rick Waldron]

On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner  wrote:

> I have a counter proposal that takes into a count both the
> easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements
> case: https://gist.github.com/csuwldcat/5358039
>


What about CSP that forbids inline scripts?

https://wiki.mozilla.org/Apps/Security#Default_CSP_policy

Rick


>
>
> I can explain the advantages a bit more in an hour or so, I just got
> pulled into a meeting...le sigh.
>
> Daniel J. Buchner
> Product Manager, Developer Ecosystem
> Mozilla Corporation
>
>
> On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles  wrote:
>
>> No, strictly ergonomic. Less nesting and less characters (less nesting is
>> more important IMO).
>>
>> I would also argue that there is less cognitive load on the author then
>> the more explicit factoring, but I believe this is subjective.
>>
>> Scott
>>
>>
>> On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein wrote:
>>
>>> On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov 
>>> wrote:
>>> > Dear Webappsonites,
>>> >
>>> > There's been a ton of thinking on what the custom elements declarative
>>> > syntax must look like. Here, I present something has near-ideal
>>> > developer ergonomics at the expense of terrible sins in other areas.
>>> > Consider it to be beacon, rather than a concrete proposal.
>>> >
>>> > First, let's cleanse your palate. Forget about the  element
>>> > and what goes inside of it. Eat some parsley.
>>> >
>>> > == Templates Bound to Tags ==
>>> >
>>> > Instead, suppose you only have a :
>>> >
>>> > 
>>> > Yay!
>>> > 
>>> >
>>> > Templates are good for stamping things out, right? So let's invent a
>>> > way to _bind_ a template to a _tag_. When the browser sees a tag to
>>> > which the template is bound, it stamps the template out. Like so:
>>> >
>>> > 1) Define a template and bind it to a tag name:
>>> >
>>> > 
>>> > Yay!
>>> > 
>>> >
>>> > 2) Whenever  is seen by the parser or
>>> > createElement/NS("my-yay") is called, the template is stamped out to
>>> > produce:
>>> >
>>> > 
>>> > Yay!
>>> > 
>>> >
>>> > Cool! This is immediately useful for web developers. They can
>>> > transform any markup into something they can use.
>>> >
>>> > Behind the scenes: the presence of "boundtotagname" triggers a call to
>>> > document.register, and the argument is a browser-generated prototype
>>> > object whose readyCallback takes the template and appends it to
>>> > "this".
>>> >
>>> > == Organic Shadow Trees  ==
>>> >
>>> > But what if they also wanted to employ encapsulation boundaries,
>>> > leaving initial markup structure intact? No problem, much-maligned
>>> >  to the rescue:
>>> >
>>> > 1) Define a template with a shadow tree and bind it to a tag name:
>>> >
>>> > 
>>> > 
>>> > Yay!
>>> > 
>>> > 
>>> >
>>> > 2) For each  created, the template is stamped out to create a
>>> > shadow root and populate it.
>>> >
>>> > Super-cool! Note, how the developer doesn't have to know anything
>>> > about Shadow DOM to build custom elements (er, template-bound tags).
>>> > Shadow trees are just an option.
>>> >
>>> > Behind the scenes: exactly the same as the first scenario.
>>> >
>>> > == Declarative Meets Imperative ==
>>> >
>>> > Now, the developer wants to add some APIs to . Sure, no
>>> problem:
>>> >
>>> > 
>>> > 
>>> > Yay!
>>> > 
>>> > 
>>> > // runs right after document.register is triggered
>>> > this.register(ExactSyntaxTBD);
>>> >