Re: Writing spec algorithms in ES6?

2015-06-11 Thread Rick Waldron
On Thu, Jun 11, 2015 at 4:53 PM Domenic Denicola d...@domenic.me 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: [Gamepad] Liveness of Gamepad objects

2014-04-30 Thread Rick Waldron
On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard gl...@zewt.org wrote:

 On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com 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

2014-04-29 Thread Rick Waldron
On Tue, Apr 29, 2014 at 10:39 AM, Ted Mielczarek t...@mozilla.com 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: [Gamepad] Liveness of Gamepad objects

2014-04-29 Thread Rick Waldron
On Tue, Apr 29, 2014 at 1:45 PM, Brandon Jones bajo...@google.com wrote:

 On Tue Apr 29 2014 at 10:24:48 AM, Mark S. Miller erig...@google.com
 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 
 bren...@secure.meer.netwrote:

 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

2014-04-29 Thread Rick Waldron
On Tue, Apr 29, 2014 at 3:27 PM, Florian Bösch pya...@gmail.com 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

2014-04-29 Thread Rick Waldron
On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org 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

2014-04-29 Thread Rick Waldron
On Tue, Apr 29, 2014 at 9:38 PM, Rick Waldron waldron.r...@gmail.comwrote:




 On Tue, Apr 29, 2014 at 7:28 PM, Glenn Maynard gl...@zewt.org 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: [HTML Imports]: what scope to run in

2013-11-20 Thread Rick Waldron
On Wed, Nov 20, 2013 at 12:38 PM, Brian Di Palma off...@gmail.com wrote:

 On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com 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 jo...@sicking.cc 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:
  link rel=import href=... id=mylib
 
  Once imported, in script:
  new $('mylib').import.MyCommentElement;
  $('mylib').import.doStuff(12);
 
  or
 
  In markup:
  link rel=import href=... id=mylib import=MyCommentElement
 doStuff
 
  Once imported, in script:
  new MyCommentElement;
  doStuff(12);
 
 
  How about this?
 
  In the host document:
  link ref=import href=foo.js import=foo1 foo2
  script
  foo1.bar();
  foo2();
  /script
 
  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...
  script
  import {foo1, foo2} from foo;
 
  foo1();
  foo2();
  /script
 
  // 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

2013-11-19 Thread Rick Waldron
On Mon, Nov 18, 2013 at 7:14 PM, Jonas Sicking jo...@sicking.cc 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 script elements in the imported
 document are run in the scope of the window of the document linking to
 the import. I.e. the global object of the document that links to the
 import is used as global object of the running script.

 This is exactly how script elements have always worked in HTML.

 However this is a pretty terrible way of importing libraries.
 Basically the protocol becomes here is my global, do whatever
 modifications you want to it in order to install yourself.

 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.
 * Internal functions that the library does not want to expose require
 ugly anonymous-function tricks to create a hidden scope.

 Many platforms, including Node.js and ES6 introduces modules as a way
 to address these problems.

 It seems to me that we are repeating the same mistake again with HTML
 imports.

 Note that this is *not* about security. It's simply about making a
 more robust platform for libraries. This seems like a bad idea given
 that HTML imports essentially are libraries.

 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


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.

Rick


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

2013-11-19 Thread Rick Waldron
On Tue, Nov 19, 2013 at 5:27 PM, John J Barton
johnjbar...@johnjbarton.comwrote:


  (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: Sync API for workers

2013-10-13 Thread 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 javascript:_e({}, 'cvml',
 'pira...@gmail.com'); pira...@gmail.com javascript:_e({}, 'cvml',
 '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.comjavascript:_e({}, 'cvml', 
 '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.comjavascript:_e({}, 'cvml', 
 '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 javascript:_e({}, 'cvml', '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

2013-09-11 Thread Rick Waldron
On Wed, Sep 11, 2013 at 9:33 AM, Anne van Kesteren ann...@annevk.nl 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: import instead of link

2013-05-14 Thread Rick Waldron
On Tue, May 14, 2013 at 4:01 PM, Scott Miles sjmi...@google.com 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

2013-04-27 Thread Rick Waldron
This is hard to follow... Almost like two different discussions are
happening at the same time. One discussion has person: ... the other
person ...

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:

  
 http://www.w3.org/2013/04/26-**webapps-minutes.htmlhttp://www.w3.org/2013/04/26-webapps-minutes.html
 

 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 http://www.w3.org/


  - DRAFT -


  Web Applications WG F2F Meeting


26 Apr 2013

 Agenda 
 http://www.w3.org/wiki/**Webapps/April2013Meetinghttp://www.w3.org/wiki/Webapps/April2013Meeting
 

 See also:IRC log 
 http://www.w3.org/2013/04/26-**webapps-irchttp://www.w3.org/2013/04/26-webapps-irc
 


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 
 http://www.w3.org/2013/04/26-**webapps-minutes.html#agendahttp://www.w3.org/2013/04/26-webapps-minutes.html#agenda
 
 1. testing 
 http://www.w3.org/2013/04/26-**webapps-minutes.html#item01http://www.w3.org/2013/04/26-webapps-minutes.html#item01
 
 2. Move to Github

 http://www.w3.org/2013/04/26-**webapps-minutes.html#item02http://www.w3.org/2013/04/26-webapps-minutes.html#item02
 
 3. Progress Events

 http://www.w3.org/2013/04/26-**webapps-minutes.html#item03http://www.w3.org/2013/04/26-webapps-minutes.html#item03
 
 4. XHR Status

 http://www.w3.org/2013/04/26-**webapps-minutes.html#item04http://www.w3.org/2013/04/26-webapps-minutes.html#item04
 
 5. Coordination (TC39)

 http://www.w3.org/2013/04/26-**webapps-minutes.html#item05http://www.w3.org/2013/04/26-webapps-minutes.html#item05
 
  * Summary of Action Items

 http://www.w3.org/2013/04/26-**webapps-minutes.html#**ActionSummaryhttp://www.w3.org/2013/04/26-webapps-minutes.html#ActionSummary
 

 --**--**
 

 ArtB Scribe: Josh_Soref

 ArtB ScribeNick: timeless

 Yves i

 Yves trackbot, start telcon

 trackbot Meeting: Web Applications Working Group Teleconference

 trackbot Date: 26 April 2013

 Ms2ger Ta

 darobin Shenzhen

 ArtB*ACTION:*barstow announce the WG will meet during TPAC 2013 in
 November [recorded inhttp://www.w3.org/2013/04/**26-webapps-minutes.html#*
 *action01 http://www.w3.org/2013/04/26-webapps-minutes.html#action01]

 trackbot Created ACTION-692 - Announce the WG will meet during TPAC 2013
 in November [on Arthur Barstow - due 2013-05-03].

 darobin 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

 ArtBInventory of Charter updates that need to be made or might be made 
 http://www.w3.org/wiki/**Webapps/Charterhttp://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

 hallvord_ Hi Jungkee

 Robin:if we're just republishing, why not automate it?

 chaals:uh, we actually want a responsible editor

 Ms2ger 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

 ArtB*ACTION:*charles to be the default Editor of URL spec [recorded
 inhttp://www.w3.org/2013/04/**26-webapps-minutes.html#**action02http://www.w3.org/2013/04/26-webapps-minutes.html#action02
 ]

 trackbot Created ACTION-693 - Be the default Editor of URL spec [on
 Charles McCathie Nevile - 

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

2013-04-17 Thread Rick Waldron
On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann derhoe...@gmx.net 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 `time /` element yet or


I would expect a time element to be constructed with:

new HTMLTimeElement();

... since that's the name of the constructor/prototype that's defined for
the time 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 `font /` elements probably wouldn't
 cross your mind much.


Because I would constructor a font element with:

new HTMLFontElement()

... since that's the name of the constructor/prototype that's defined for
the font 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 there
 is some dependency on global state that your own code did not create.


I agree that's bad


 I would expect that code to fail because the ownerDocument has not been
 specified,


I should hope so as well


 and even if I would expect that particular code to succeed,
 I would be unable to tell what would happen if `example` was invoked in
 some other way, especially when `example` comes from another global.


document !== [[Global]], so I'm not sure what other global this `example`
method could be defined on that this would ever possibly

Re: [webcomponents]: element Wars: A New Hope

2013-04-17 Thread Rick Waldron
On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner dan...@mozilla.com 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 waldron.r...@gmail.comwrote:




 On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov dglaz...@google.comwrote:

 Inspired by Allen's and Scott's ideas in the Benadryl thread, I dug
 into understanding what element actually represents.

 It seems that the problem arises when we attempt to make element
 _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 element 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 element and
 script can contribute to defining the same custom element.

 With that in mind, we take Scott's/Allen's excellent idea and twist it
 up a bit. We invent a HTMLElementElement.define method (name TBD),
 which takes two arguments: a custom element name, and an object. I
 know folks will cringe, but I am thinking of an Object.create
 properties object:


 The are called Property Descriptors.




 HTMLElementElement.define('x-foo', {
 erhmahgerd: { writable: false, value: BOOKS! }
 });


 This is just a repackaging of Object.defineProperties( target,
 PropertyDescriptors ) thats slightly less obvious because the target
 appears to be a string.


 Rick





 When the registration line comes, the browser-thing matches element
 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.

 We now have a working declarative syntax that doesn't hack script,
 is ES6-module-friendly, and still lets Scott build his tacos. Sounds
 like a win to me. I wonder how Object.create properties object and
 Class syntax could mesh better. I am sure ES6 Classes peeps will have
 ideas here.

 So... When is the registration line? Clearly, by the time the parser
 finishes with the document, we're too late.

 We have several choices. We could draw the line for an element when
 its corresponding /element is seen in document. This is not going to
 work for deferred scripts, but maybe that is ok.

 For elements that are imported, we have a nice delineation, since we
 explicitly process each import in order, so no problems there.

 What do you think?

 :DG






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

2013-04-17 Thread Rick Waldron
On Wed, Apr 17, 2013 at 10:34 PM, Bjoern Hoehrmann derhoe...@gmx.netwrote:

 * Rick Waldron wrote:
 On Tue, Apr 16, 2013 at 9:51 PM, Bjoern Hoehrmann derhoe...@gmx.net
 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 `a` might be HTML or it might be SVG, so mapping
 `new Button()` to `button` 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 foo




  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
 `a` element or a a SVG `a` 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]: element Wars: A New Hope

2013-04-17 Thread Rick Waldron
On Wed, Apr 17, 2013 at 7:33 PM, Daniel Buchner dan...@mozilla.com wrote:

 So let me be *crystal clear*:

 If define() internally does this -- When the registration line comes,
 the browser-thing matches element 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 waldron.r...@gmail.comwrote:




 On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner dan...@mozilla.comwrote:

 *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 waldron.r...@gmail.comwrote:




 On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov 
 dglaz...@google.comwrote:

 Inspired by Allen's and Scott's ideas in the Benadryl thread, I dug
 into understanding what element actually represents.

 It seems that the problem arises when we attempt to make element
 _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 element 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 element and
 script can contribute to defining the same custom element.

 With that in mind, we take Scott's/Allen's excellent idea and twist it
 up a bit. We invent a HTMLElementElement.define method (name TBD),
 which takes two arguments: a custom element name, and an object. I
 know folks will cringe, but I am thinking of an Object.create
 properties object:


 The are called Property Descriptors.




 HTMLElementElement.define('x-foo', {
 erhmahgerd: { writable: false, value: BOOKS! }
 });


 This is just a repackaging of Object.defineProperties( target,
 PropertyDescriptors ) thats slightly less obvious because the target
 appears to be a string.


 Rick





 When the registration line comes, the browser-thing matches element
 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.

 We now have a working declarative syntax that doesn't hack script,
 is ES6-module-friendly, and still lets Scott build his tacos. Sounds
 like a win to me. I wonder how Object.create properties object and
 Class syntax could mesh better. I am sure ES6 Classes peeps will have
 ideas here.

 So... When is the registration line? Clearly, by the time the parser
 finishes with the document, we're too late.

 We have several

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

2013-04-16 Thread Rick Waldron
On Tue, Apr 16, 2013 at 5:33 PM, Dimitri Glazkov dglaz...@google.comwrote:

 On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren ann...@annevk.nl
 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(x)
  currently gives different results from new x's interface. 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 textarea, input,
 details, fieldset, 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

2013-04-15 Thread Rick Waldron
On Mon, Apr 15, 2013 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu 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

2013-04-15 Thread Rick Waldron
On Mon, Apr 15, 2013 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu 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 === button:)/button; // 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

2013-04-14 Thread Rick Waldron
On Sat, Apr 13, 2013 at 10:16 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:



 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 element 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 x-foo would have
 a dom node that was an instance of HTMLAppDefinedElement and so would every
 x-bar. 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 element 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 script bock using
 normal JS techniques.

 It would be a mistake to automatically generate the constructor and then
 to invent some new convention to be used in a special kind of nested script
 block for installing properties into a prototype of the generated
 constructor. This is one of the main things I was objecting to, JS already
 has multiple ways to define constructors and ES6 will have a very
 straightforward way using class declarations. We don't need a new ad hoc
 way for this specific use case.

 For what it's worth, I have nothing against making constructor= an
 option that is used instead of the tag name, but why force extra
 boilerplate if people would be just as comfortable dealing with a
 constructor name based on the tag name they specify? (as elements do now)

 The purpose of constructor= should be to explicitly say, this element
 uses a app defined element constructor which is hereby identified.  The
 absence should indicate that a platform provided element constructor will
 be used


Exactly and I apologize if I was previously unclear about this.

Rick



 Allen





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

2013-04-14 Thread Rick Waldron
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner dan...@mozilla.com 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

2013-04-14 Thread Rick Waldron
On Sun, Apr 14, 2013 at 3:46 PM, Daniel Buchner dan...@mozilla.com 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

2013-04-12 Thread Rick Waldron
On Fri, Apr 12, 2013 at 7:14 PM, Dimitri Glazkov dglaz...@google.comwrote:

 On Fri, Apr 12, 2013 at 3:56 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
 
  On Fri, Apr 12, 2013 at 6:52 PM, Dimitri Glazkov dglaz...@google.com

  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

2013-04-10 Thread Rick Waldron
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan...@mozilla.com 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 sjmi...@google.com 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 rafa...@google.comwrote:

 On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov dglaz...@google.com
 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 element
  and what goes inside of it. Eat some parsley.
 
  == Templates Bound to Tags ==
 
  Instead, suppose you only have a template:
 
  template
  divYay!/div
  /template
 
  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:
 
  template bindtotagname=my-yay
  divYay!/div
  /template
 
  2) Whenever my-yay is seen by the parser or
  createElement/NS(my-yay) is called, the template is stamped out to
  produce:
 
  my-yay
  divYay!/div
  /my-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
  shadowroot to the rescue:
 
  1) Define a template with a shadow tree and bind it to a tag name:
 
  template bindtotagname=my-yay
  shadowroot
  divYay!/div
  /shadowroot
  /template
 
  2) For each my-yay 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 my-yay. Sure, no
 problem:
 
  template bindtotagname=my-yay
  shadowroot
  divYay!/div
  /shadowroot
  script runwhenbound
  // runs right after document.register is triggered
  this.register(ExactSyntaxTBD);
  script
  /template
 
  So-cool-it-hurts! We built a fully functional custom element, taking
  small steps from an extremely simple concept to the full-blown thing.
 
  In the process, we also saw a completely decoupled shadow DOM from
  custom elements in both imperative and declarative forms, achieving
  singularity. Well, or at least a high degree of consistence.
 
  == Problems ==
 
  There are severe issues.
 
  The shadowroot is turning out to be super-magical.
 
  The bindtotagname attribute will need to be also magical, to be
  consistent with how document.register could be used.
 
  The stamping out, after clearly specified, may raise eyebrows and
  turn out to be unintuitive.
 
  Templates are supposed to be inert, but the whole script
  runwhenbound thing is strongly negating this. There's probably more
  that I can't remember now.

 The following expresses the same semantics:

 element tagname=my-yay
   template
 shadowroot
   divYay!/div
 /shadowroot
   /template
   script runwhenbound
   /script
 /element

 I get that your proposal is fewer characters to type. Are there other
 advantages?

 
  == Plea ==
 
  However, I am hopeful that you smart folk will look at this, see the
  light, tweak the idea just a bit and hit the homerun. See the light,
  dammit!
 
  :DG






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

2013-04-10 Thread Rick Waldron
On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner dan...@mozilla.com 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 waldron.r...@gmail.comwrote:




 On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner dan...@mozilla.comwrote:

 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 sjmi...@google.comwrote:

 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 
 rafa...@google.comwrote:

 On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov dglaz...@google.com
 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 element
  and what goes inside of it. Eat some parsley.
 
  == Templates Bound to Tags ==
 
  Instead, suppose you only have a template:
 
  template
  divYay!/div
  /template
 
  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:
 
  template bindtotagname=my-yay
  divYay!/div
  /template
 
  2) Whenever my-yay is seen by the parser or
  createElement/NS(my-yay) is called, the template is stamped out to
  produce:
 
  my-yay
  divYay!/div
  /my-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
  shadowroot to the rescue:
 
  1) Define a template with a shadow tree and bind it to a tag name:
 
  template bindtotagname=my-yay
  shadowroot
  divYay!/div
  /shadowroot
  /template
 
  2) For each my-yay 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 my-yay. Sure, no
 problem:
 
  template bindtotagname=my-yay
  shadowroot
  divYay!/div
  /shadowroot
  script runwhenbound
  // runs right after document.register is triggered
  this.register(ExactSyntaxTBD);
  script
  /template
 
  So-cool-it-hurts! We built a fully functional custom element, taking
  small steps from an extremely simple concept to the full-blown thing.
 
  In the process, we also saw a completely decoupled shadow DOM from
  custom elements in both imperative and declarative forms, achieving
  singularity. Well, or at least a high degree of consistence.
 
  == Problems ==
 
  There are severe issues.
 
  The shadowroot is turning out to be super-magical.
 
  The bindtotagname attribute will need to be also magical, to be
  consistent with how document.register could be used.
 
  The stamping out, after clearly specified, may raise eyebrows and
  turn out to be unintuitive.
 
  Templates are supposed

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

2013-04-10 Thread Rick Waldron
On Wed, Apr 10, 2013 at 5:35 PM, Daniel Buchner dan...@mozilla.com wrote:

 One thing I'm wondering re template 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
 template 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

2013-04-10 Thread 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:
style scoped
2. It would be new for script elements, but hardly new for other
elements. There are plenty of elements that have various behaviors or
visual representations only when placed inside specific elements. Given
this is already an advanced web API, I'm not sure a little upfront learning
is a huge concern. We could even allow for this, given the paradigm is
already established: script scoped  *// could scope 'this' ref to
the parentNode*
3. Are you referring to template attachment here? If so, I agree,
thus the proposal I submitted allows for both (
https://gist.github.com/csuwldcat/5360471). If you want your template
automatically associated with your element, put it inside, if not, you
can specify which template a custom element should use by reference to
its ID.


 On Wed, Apr 10, 2013 at 8:00 PM, John J Barton 
 johnjbar...@johnjbarton.com javascript:_e({}, 'cvml',
 'johnjbar...@johnjbarton.com'); wrote:




 On Wed, Apr 10, 2013 at 6:51 PM, Dimitri Glazkov 
 dglaz...@google.comjavascript:_e({}, 'cvml', 'dglaz...@google.com');
  wrote:

 On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron 
 waldron.r...@gmail.comjavascript:_e({}, 'cvml', 
 'waldron.r...@gmail.com');
 wrote:
  Everyone's answer to this should be no; changing the expected value
 of the
  top level this, in some magical way, simply won't work.

 Can you explain why you feel this way?


 1) Because script has never done this before, so it better be
 compelling.
 2) Because causing |this| to change by moving the script tag in the
 HTML or adding a layer of elements etc seems likely to cause hard to
 understand bugs.
 3) Forcing the binding based on position is inflexible.

 To be sure this is implicit-declarative vs explicit-imperative bias, not
 evidence.

 Oh, sorry you were asking Rick.
  jjb





Re: Fixing appcache: a proposal to get us started

2013-03-26 Thread Rick Waldron
This is a lot to digest, but I know the developer community will greatly
appreciate the work that has gone into this—thank you.


On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking jo...@sicking.cc wrote:

 (snip)

 First we need a way to get at AppCache objects:


No mention of installAppCache, removeAppCache or getAppCacheList anywhere
else in the email—not even to say they are in progress?



 partial interface Navigator {
   FutureAppCache installAppCache(url);
   FutureAppCache getAppCache(url);
   Futureboolean removeAppCache(url);
   FutureDOMString[] getAppCacheList();
 }


There is no way to create an alias binding for shortening these calls—the
kids love shorthanding ;)

This isn't really a navigator capability is it? Perhaps instead of adding
surface to navigator, a new global called platform, for platform related
APIs that aren't quite navigator, document or window (?) capabilities...


  partial interface Window {
Object platform
  }

  partial interface platform {
Object appCache
  }

  interface appCache {
FutureAppCache install(url);
FutureAppCache get(url);
Futureboolean remove(url);
FutureDOMString[] list();
  }


If that's not desirable (which I can easily understand), then dump it on
the window. Yes, it stinks to put more things on the window object, but
developers understand recognize the pattern (it's also minifier friendly)

  partial interface Window {
Object appCache
  }

  interface appCache {
FutureAppCache install(url);
FutureAppCache get(url);
Futureboolean remove(url);
FutureDOMString[] list();
  }


With this API surface, the code I might ship:

  (function(window) {
var appCache = window.appCache;
appCache.get(url a).then(function(cache) {
  // do stuff and things...
});
appCache.remove(url b).then(function(cache) {
  // do stuff and things...
});
  }(this));


Minifies to:

  (function(a){var b=a.appCache;b.get(url
a).then(function(){}),b.remove(url b).then(function(){})})(this);


vs. the proposed API:

  (function(window) {
var navigator = window.navigator;
navigator.getAppCache(url a).then(function(cache) {
  // do stuff and things...
});
navigator.removeAppCache(url b).then(function(cache) {
  // do stuff and things...
});
  }(this));

  (function(a){var b=a.navigator;b.getAppCache(url
a).then(function(){}),b.removeAppCache(url b).then(function(){})})(this);



Specifically, the interesting parts are:

  b.get(url a).then(function(){}),b.remove(url b).then(function(){})
  b.getAppCache(url a).then(function(){}),b.removeAppCache(url
b).then(function(){})






 partial interface Document {
   AppCache appCache;
   readonly attribute boolean appCacheUpdateAvailable;
   attribute EventHandler onappcacheupdateavailable;
 }


As an author, I would already know that I'm working with an appCache
object, therefore the word appCache prefix on the boolean property is
just junk that's not minifiable. So...

appCacheUpdateAvailable =
  - updateAvailable
  - hasUpdate
  - isAvailable
  - ?

Anyway, great work from all involved. I'm excited to see such momentum and
dedication to getting app cache back on track :)

Rick



 snip



  / Jonas




Re: Fixing appcache: a proposal to get us started

2013-03-26 Thread Rick Waldron
On Tue, Mar 26, 2013 at 9:58 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Tue, Mar 26, 2013 at 6:28 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
  This is a lot to digest, but I know the developer community will greatly
  appreciate the work that has gone into this—thank you.

 Yeah, I hope this is possible to consume despite its length. I'll
 create a shorter writeup with less background for the next iteration.


  On Tue, Mar 26, 2013 at 3:02 AM, Jonas Sicking jo...@sicking.cc wrote:
 
  (snip)
 
 
  First we need a way to get at AppCache objects:
 
 
  No mention of installAppCache, removeAppCache or getAppCacheList anywhere
  else in the email—not even to say they are in progress?

 Sorry, i missed this. I hope they are generally pretty obvious what
 they do on a high level though?


Yes, they are—you were so thorough that their absence was alarming ;)



  partial interface Navigator {
FutureAppCache installAppCache(url);
FutureAppCache getAppCache(url);
Futureboolean removeAppCache(url);
FutureDOMString[] getAppCacheList();
  }
 
 
  There is no way to create an alias binding for shortening these calls—the
  kids love shorthanding ;)
 
  This isn't really a navigator capability is it? Perhaps instead of adding
  surface to navigator, a new global called platform, for platform
 related
  APIs that aren't quite navigator, document or window (?) capabilities...

 Yeah, I wasn't sure what to do about this. I'm not really exited about
 adding a property to the global object which has a name that is as
 generic as platform.

partial interface Window {
  Object platform
}
 
partial interface platform {
  Object appCache
}
 
interface appCache {
  FutureAppCache install(url);
  FutureAppCache get(url);
  Futureboolean remove(url);
  FutureDOMString[] list();
}

 I like this general approach other than the issue mentioned above.

  If that's not desirable (which I can easily understand), then dump it on
 the
  window. Yes, it stinks to put more things on the window object, but
  developers understand recognize the pattern (it's also minifier friendly)
 
partial interface Window {
  Object appCache
}
 
interface appCache {
  FutureAppCache install(url);
  FutureAppCache get(url);
  Futureboolean remove(url);
  FutureDOMString[] list();
}

 This might be more ok. As would sticking the appCache property on the
 navigator object be.

  partial interface Document {
AppCache appCache;
readonly attribute boolean appCacheUpdateAvailable;
attribute EventHandler onappcacheupdateavailable;
  }
 
  As an author, I would already know that I'm working with an appCache
  object, therefore the word appCache prefix on the boolean property is
 just
  junk that's not minifiable.

 The updateAvailable isn't really a property of the AppCache object
 though. An appcache is updated as soon as it has been downloaded. It's
 the view that the user is currently looking at that is out-of-date.


Yep, I misread that—thanks for clarifying.


 Possibly if we add a appCache property on window or navigator then
 putting the property there might work.


Even better :)


 / Jonas



Re: FYI: JSON mailing list and BoF

2013-02-19 Thread Rick Waldron
cc John Neumann


On Tue, Feb 19, 2013 at 11:48 AM, Oliver Hunt oli...@apple.com wrote:

 JSON is deliberately minimal and deliberately unversioned.

 What are you expecting this working group to do?  Also, given that JSON is
 essentially a subset of ECMAScript literal syntax, I'm unsure why this
 isn't being handled by TC39


It's more then a subset, it's specified in Ecma-262 Edition 5.1, which is
ISO/IEC 16262:2011[0].


Rick

[0]
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=55755


 --Oliver


 On Feb 18, 2013, at 4:19 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:

  * Joe Hildebrand (jhildebr) wrote:
  We're planning on doing a BoF in Orlando to discuss starting up a JSON
  working group.  The BoF is currently planned for Monday afternoon at
 1300
  in Carribean 6.  A very preliminary version of a charter can be found
 here:
 
  http://trac.tools.ietf.org/wg/appsawg/trac/wiki/JSON
 
  But obviously we'll need to build consensus on what it should actually
  contain.  Please discuss on the j...@ietf.org mailing list:
 
  https://www.ietf.org/mailman/listinfo/json
 
  (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08912.html
 )
  --
  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: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:

 Folks,

 I propose just a bit of sugaring as a compromise, but I want to make
 sure this is really sugar and not acid, so please chime in.

 1) We give up on unified syntax for ES5 and ES6, and instead focus on
 unified plumbing
 2) document.register returns a custom element constructor as a result,
 just like currently specified:

 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register
 3) There are two ways to register an element: with a constructor and
 with a prototype object.
 4) When registering with the constructor (aka the ES6 way), you must
 supply the constructor/class as the constructor member in the
 ElementRegistrationOptions dictionary
 (
 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#api-element-registration-options
 )
 5) If the constructor is supplied, element registration overrides
 [[Construct]] internal function as described in
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0250.html
 6) Registering with a prototype object (aka the current way) uses the
 prototype member in ElementRegistrationOptions dictionary and works
 roughly as currently specified


See Q's below...


 7) If the prototype object is supplied, the constructor is generated
 as two steps:
   a) Instantiate the platform object
   b) Call created callback from lifecycle callback interface bound to
 this
 8) We remove any sort of shadow tree creation and the corresponding
 template argument from the spec. Shadow tree management is left
 completely up to the author.

 Effectively, the created callback becomes the poor man's
 constructor. It's very easy to convert from old syntax to new syntax:

 The prototype way:

 function MyButton() {
   // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



Does this actually mean that the second argument has a property called
prototype that itself has a special meaning?

Is the re-assignment MyButton intentional? I see the original MyButton
reference as the value of the created property, but then
document.register's return value is assigned to the same identifier? Maybe
this was a typo?




 The constructor way:

 function MyButton() {
  // do constructor stuff ...
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
  ...
 });
 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


Same question as above, but re: constructor?


When I first read this, I was expecting to see something about syntax, this
is all API.


Rick




 This is nearly the same approach as what  Scott sketched out here:
 http://jsfiddle.net/aNHZH/7/, so we already know it's shimmable :)

 What do you think?

 :DG




Re: Custom elements ES6/ES5 syntax compromise, was: document.register and ES6

2013-02-14 Thread Rick Waldron
On Thu, Feb 14, 2013 at 5:15 PM, Erik Arvidsson a...@chromium.org wrote:

 Yeah, this post does not really talk about syntax. It comes after a
 discussion how we could use ES6 class syntax.

 The ES6 classes have the same semantics as provided in this thread using
 ES5.

 On Thu, Feb 14, 2013 at 5:10 PM, Rick Waldron waldron.r...@gmail.comwrote:


 On Thu, Feb 14, 2013 at 4:48 PM, Dimitri Glazkov dglaz...@google.comwrote:


 MyButton = document.register(‘x-button’, {
   prototype: MyButton.prototype,
   lifecycle: {
  created: MyButton
   }
 });



 Does this actually mean that the second argument has a property called
 prototype that itself has a special meaning?


 This is just a dictionary.



 Is the re-assignment MyButton intentional? I see the original MyButton
 reference as the value of the created property, but then
 document.register's return value is assigned to the same identifier? Maybe
 this was a typo?


 document.register(‘x-button’, {
  constructor: MyButton,
  ...
 });


 Same question as above, but re: constructor?


 Same answer here.

 I'm not happy with these names but I can't think of anything better.


Fair enough, I trust your judgement here. Thanks for the follow up—always
appreciated.

Rick


 --
 erik




Re: RfR: Proximity Events (DAP) Last Call

2012-12-06 Thread Rick Waldron
I see the distance measurement unit in centimeters is mentioned only
once, in the description of current device proximity, I would suggest
being explicit and including it in minimum proximity distance and
maximum proximity distance as well.

When the current proximity changes, the user agent must fire a device
proximity event.

Any discussion regarding frequency of dispatch?

Thanks!

Rick



On Thu, Dec 6, 2012 at 5:37 PM, Charles McCathie Nevile 
cha...@yandex-team.ru wrote:

 http://www.w3.org/TR/2012/WD-**proximity-20121206/http://www.w3.org/TR/2012/WD-proximity-20121206/


Re: RfR: Proximity Events (DAP) Last Call

2012-12-06 Thread Rick Waldron
Please ignore the second question. Thanks.


On Thu, Dec 6, 2012 at 6:02 PM, Rick Waldron waldron.r...@gmail.com wrote:

 I see the distance measurement unit in centimeters is mentioned only
 once, in the description of current device proximity, I would suggest
 being explicit and including it in minimum proximity distance and
 maximum proximity distance as well.

 When the current proximity changes, the user agent must fire a device
 proximity event.

 Any discussion regarding frequency of dispatch?

 Thanks!

 Rick



 On Thu, Dec 6, 2012 at 5:37 PM, Charles McCathie Nevile 
 cha...@yandex-team.ru wrote:

 http://www.w3.org/TR/2012/WD-**proximity-20121206/http://www.w3.org/TR/2012/WD-proximity-20121206/





Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

2012-10-22 Thread Rick Waldron


On Monday, October 22, 2012 at 6:04 PM, Chris Pearce wrote:

 On 16/10/12 18:48, Maciej Stachowiak wrote:
  Many games could work with only non-alphanumeric keys or in some cases only 
  the mouse. As could slideshows. You only need space/enter/arrows for a full 
  screen slide presentation.
 FWIW I agree. Pretty much the only uses cases that I can envisage that would 
 really need alpha-numeric keyboard access are games, or 3D modellers, like 
 CAD software.

What if applications, such as iA Writer wanted to offer a web version? Too bad, 
no keyboard for distraction-free mode?

(http://www.iawriter.com/)

Rick

 
 
 On 19/10/12 14:31, Feross Aboukhadijeh wrote:
  I wrote the attack demo that prompted this discussion. Here are my thoughts 
  on how to improve the spec and/or the implementations in browsers: 
  
  requestFullscreen() should trigger fullscreen mode with limited keyboard 
  input allowed (only space, arrow keys, and perhaps some modifier keys like 
  CTRL, ALT, etc.). The browser should display a notification that the user 
  is in fullscreen mode, although it can fade away after some time since the 
  risk of phishing is significantly reduced when keyboard input is limited 
  (note that Safari currently sees fit to show NO notification at all about 
  fullscreen mode because keyboard is limited). 
  
  This level of functionality will support 90% of current fullscreen use 
  cases like video players, slideshow viewers, and games with simple input 
  requirements. 
  
  However, the spec should also support an optional ALLOW_KEYBOARD_INPUT 
  parameter to requestFullscreen() which, when passed, triggers fullscreen 
  mode with full keyboard support (except for ESC to exit fullscreen). When 
  this parameter is passed, the browser should show a prominent modal dialog 
  on top of the page content, requesting permission to use fullscreen mode. 
  No keyboard or mouse input should be allowed until the user clicks Allow. 
  
 
 This looks remarkably like Mozilla's original proposal:
 https://wiki.mozilla.org/Gecko:FullScreenAPI
 
 We chose not to implement this as it offers little protection against 
 phishing or spoofing attacks that don't rely on keyboard access. In those 
 cases making the user aware that they've entered fullscreen is pretty much 
 the best defence the user has. Other than not having a fullscreen API at all.
 
 Our fullscreen approval UI in Firefox is based around the assumption that for 
 most users the set of sites that use the fullscreen API that the user 
 encounters on a daily basis is small, and users would tend to opt to 
 remember the fullscreen approval for those domains. I'd imagine the set 
 would be YouTube, Facebook, and possibly ${FavouriteGame}.com for most users. 
 Thus users would see a notification and not an approval prompt most of the 
 time when they entered fullscreen. But when some other site goes fullscreen 
 they do get a prompt, which is out of the ordinary and more likely to be read.
 
 
 
 Chris Pearce



Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

2012-10-17 Thread Rick Waldron
On Tue, Oct 16, 2012 at 5:42 AM, Florian Bösch pya...@gmail.com wrote:

 On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak m...@apple.com wrote:

 What are the cases where webpage-driven (as opposed to
 browser-chrome-driven) fullscreen is really compelling, but they need full
 keyboard access including alphanumeric keys? (Not saying there aren't any,
 I am just not sure what they would be - fullscreen Nethack?)

 There are many games that require key input. There exist popular
 keymappings for certain genres (such FPSes) that are colloquially shortned
 to the moniker WASD. FPS games (and any other game that uses the mouse for
 view control) usually prefers WASD over cursor keys because it allows the
 arms to rest at a relaxed position, whereas using the cursor keys for the
 same either involves a painful posture or an adjustment of the keyboard
 position.

 Beyond the simple directional control, which give you 2 axes of freedom.
 There are games (such as descent, flight simulators, strategy games etc)
 where often a third axis might be needed. A common input scheme for these
 games is QWEASD.

 Beyond a simple 3-axis implementation there are categories of games (like
 RTSes or RPGs) which make heavy use of shortcuts (for instance starcraft
 and world of warcraft, nethack, etc.) because they need to deal with a
 large catalogue of actions to be performed and clicking around in menus
 would mostly be undesired by frequent players.

 Beyond axial control and shortcuts games do require keyboard input for
 text (such as in entering an avatar nickname, chatting etc.)

 Beyond axial control, shortcuts and text input there is a good reason to
 allow people to map the game action keys to whatever keys they prefer. It
 is considered bad form to assume everybody is comfortable with the same
 input scheme/locations. This problem becomes especially apparent in
 physically disabled users who often cannot use standard input schemes at
 all.


I'm not sure where this falls, but how would things like control-w or cmd-w
work? If the non-alphanumerics work, but the alphanumerics do not... will
that close the window?

Thanks!

Rick


Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

2012-10-17 Thread Rick Waldron
On Wed, Oct 17, 2012 at 12:06 PM, Florian Bösch pya...@gmail.com wrote:

 On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron waldron.r...@gmail.comwrote:

 I'm not sure where this falls, but how would things like control-w or
 cmd-w work? If the non-alphanumerics work, but the alphanumerics do not...
 will that close the window?

 Far as I understood it the keyboard disabled refers to keyboard events
 to JS/DOM, it's not a statement about key response by the browser. There is
 a separate topic called keyboardlock which is intended to deal with
 things where you wouldn't want a special key interrupting your game (such
 as a windows key, ctrl+tab etc.) Though I don't know how far or favored
 that is.


It seems I was reading too literally—thanks for the clarification!

Rick


Re: [pointerlock] Is Pointer Lock feature complete i.e. LC ready? [Was: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15]

2012-10-02 Thread Rick Waldron


On Tuesday, October 2, 2012 at 6:14 PM, Florian Bösch wrote:

 Speaking from the point of view of a web developer having to use this 
 feature. It is quite painful having to perform an end-run about failure modes 
 that are unspecified, undocumented and a moving target. In my understanding, 
 this is precisely the intent of a specification, to avoid such 
 incompatibilities and headaches for developers.
  
 1) If it is intended that additional failure modes are to be randomly 
 introduced by vendors, then this should be made explicit in the specification.
 2) If such wording is added to the specification, I don't see any residual 
 value in the specification since any developer will have to perform the 
 trialerror endrun repeatedly patching things up as the failure modes move, 
 we can just skip the specification altogether.
As I read through this thread, I was thinking exactly the same thing that 
Florian has said here. Looking forward to real feature completion ;)

Rick
  
  
 On Wed, Oct 3, 2012 at 12:08 AM, Vincent Scheib sch...@google.com 
 (mailto:sch...@google.com) wrote:
  I agree that pointer lock is quite useful outside of fullscreen, but
  before attempting to codify that in the specification I would want buy
  in from other browser vendors. I can appreciate an argument to remain
  restricted to fullscreen.
   
  Application developers can automatically escalate to requesting
  fullscreen upon the first pointerlockerror given the current behavior
  of FireFox.  It's more code, but not a burdensome amount.
   
  If future abuse of the feature appears on the web, there may be other
  criteria used by browsers to suppress the feature. The specification
  states The user agent determines if pointer lock state will be
  entered which allows for browsers to add additional constraints. I
  could word that more explicitly if it would help. But my intent was
  specifically to allow browsers to use additional discretion. E.g. see
  the 'A full screen approach' in the specification's non-normative
  security section. Also, note that Chrome allows users to enter global
  suppression of the feature via the content settings preference, a
  override accepted similarly by the specification.
   
  Also, a small nit regarding chrome requires the pointer lock request
  to fail if not resulting from a user interaction target. Chrome
  allows pointer lock without any user gesture if requested when in
  fullscreen. Out of fullscreen a user gesture (click, key press) is
  required. See http://www.chromium.org/developers/design-documents/mouse-lock
   
  On Tue, Oct 2, 2012 at 2:59 PM, Florian Bösch pya...@gmail.com 
  (mailto:pya...@gmail.com) wrote:
   On Tue, Oct 2, 2012 at 11:52 PM, Olli Pettay olli.pet...@helsinki.fi 
   (mailto:olli.pet...@helsinki.fi)
   wrote:
  
   On 10/02/2012 11:55 PM, Florian Bösch wrote:
  
   I'd like to point out that vendors are using additional failure criteria
   to determine if pointerlock succeeds that are not outlined in the
   specification. Firefox uses the fullscreen change event to determine
   failure and chrome requires the pointer lock request to fail if not
   resulting
   from a user interaction target. I think that Firefoxes interpretation is
   less useful than Chromes,
  
   But safer
  
   Also not in conformance to the specification (hence a bug). Additionally, 
   it
   will make it really difficult to follow the specification since
   non-fullscreen mouse capture is specifically intended by the specification
   by not adding that failure mode *to* the specification (there's a fairly
   long discussion on this on the chrome ticket for pointerlock resulting in
   what Chrome does now).
  
  
and that Chromes interpretation should be amended
  
   to the spec since it seems like a fairly good idea.
  
   I'm not yet convinced that it is safe enough.
   Also, it is not properly defined anywhere.
  
   So either Chrome is also implementing in conformance to the specification,
   or the specification is changed. Ipso facto, the specification is not
   complete since I don't think Chrome will drop this failure mode, and it
   seems like Firefox is intending to follow Chromes lead because otherwise 
   it
   wouldn't be possible to implement non-fullscreen pointerlock.
  



Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-10-01 Thread Rick Waldron
On Mon, Oct 1, 2012 at 10:58 AM, Travis Leithead 
travis.leith...@microsoft.com wrote:

 From: Rick Waldron [mailto:waldron.r...@gmail.com]
 
  I wasn't specific enough in my original question, but I did note that I
 wasn't referring to construction exceptions, so I'm guessing by your
 response that you actually _just_ meant testing for constructability. I
 apologize for not being clearer, but I was actually referring to the URL
 string parameter itself, and how to test if passing an argument to the
 constructor is supported (the example I gave falls short of answering that
 question).
 
 Loosely related... will invalid URL string parameters throw in the same
 manner that invalid selectors throw? eg. context.querySelector(?)

 Hmm, that's not a question for WebIDL, as far as I know. The spec defining
 the constructor behavior would need to specify that.


Fair enought, apologies for the noise. Thanks!

Rick


Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-29 Thread Rick Waldron
On Fri, Sep 28, 2012 at 9:24 PM, Travis Leithead 
travis.leith...@microsoft.com wrote:

  I was alluding to this behavior for interface objects (e.g., “URL”):

 ** **

 *4.4.1.1. Interface object [[Call]] method 
 §http://dev.w3.org/2006/webapi/WebIDL/#es-interface-call
 *

 If the interface http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface is
 declared with a 
 [Constructor]http://dev.w3.org/2006/webapi/WebIDL/#Constructor extended
 attribute http://dev.w3.org/2006/webapi/WebIDL/#dfn-extended-attribute,
 then the interface 
 objecthttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-objectcan be 
 called as a function to create an object that implements that
 interface. Interfaces that do not have a constructor will throw an
 exception when called as a function. 

 ...”not supported” just means “URL is not a constructor/won’t parse a URL
 string parameter”. As Cameron noted, it’s not an idea test—in the instance
 you note in Chome, that’s due to the subtle difference in implementation of
 WebIDL per the above requirement.


Thanks, but this part I already very much understand, ie. non-constructors
will throw if an attempt is made to call them as a function, with or
without the new operator (call or construct, as the case may. 9.11, 11.2.2,
11.2.3, 13.2 of 262/ES5.1)

I wasn't specific enough in my original question, but I did note that I
wasn't referring to construction exceptions, so I'm guessing by your
response that you actually _just_ meant testing for constructability. I
apologize for not being clearer, but I was actually referring to the URL
string parameter itself, and how to test if passing an argument to the
constructor is supported (the example I gave falls short of answering that
question).


Loosely related... will invalid URL string parameters throw in the same
manner that invalid selectors throw? eg. context.querySelector(?)


Rick




 

 ** **

 *From:* Rick Waldron [mailto:waldron.r...@gmail.com]
 *Sent:* Friday, September 28, 2012 4:24 PM
 *To:* Cameron McCormack
 *Cc:* Travis Leithead; Boris Zbarsky; public-script-co...@w3.org;
 public-webapps
 *Subject:* Re: In WebIDL, should having a .prototype on interface objects
 be optional?

 ** **

 ** **

 On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack c...@mcc.id.au wrote:*
 ***

 Travis Leithead:

 I guess you'd check for URL.href then? Or try { new URL(/test); } catch
 (ex) { console.log(not supported); }


 I agree with Travis, you should be checking the particular features you
 want to use, rather than checking the existence of the prototype as a proxy
 for that test.

 If URL.prototype was required to exist, you could just do (href in
 URL.prototype).  Since it currently doesn't, you could do (href in
 (URL.prototype || {})).

 ** **

 I'm interested in knowing more about what would throw. If URL is not a
 constructor function, it will throw, but if it is what aspect of the above
 would be not supported. I ask because currently Chrome's URL (webkitURL)
 can construct, but it constructs a fairly useless instance and throws
 nothing (new webkitURL(/test);)

 ** **

 Thanks in advance 

 ** **

 Rick

 ** **



Re: In WebIDL, should having a .prototype on interface objects be optional?

2012-09-28 Thread Rick Waldron
On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack c...@mcc.id.au wrote:

 Travis Leithead:

 I guess you'd check for URL.href then? Or try { new URL(/test); } catch
 (ex) { console.log(not supported); }


 I agree with Travis, you should be checking the particular features you
 want to use, rather than checking the existence of the prototype as a proxy
 for that test.

 If URL.prototype was required to exist, you could just do (href in
 URL.prototype).  Since it currently doesn't, you could do (href in
 (URL.prototype || {})).


I'm interested in knowing more about what would throw. If URL is not a
constructor function, it will throw, but if it is what aspect of the above
would be not supported. I ask because currently Chrome's URL (webkitURL)
can construct, but it constructs a fairly useless instance and throws
nothing (new webkitURL(/test);)

Thanks in advance

Rick


Re: Sync API for workers

2012-09-01 Thread Rick Waldron

David,

Thanks for preparing this summary—I just wanted to note that I still stand 
behind my original, reality based arguments.

One comment inline..  

On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:

 Hi,
  
 A Sync API for workers is being implemented in Firefox [1].
 I'd like to come back to the discussions mentionned in comment 4 of the bug.
  
  

The original post actually describes an async API—putting the word sync in 
the middle of a method or event name doesn't make it sync.

As the proposed API developed, it still retains the event handler-esque 
design (https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c12). All of the 
terminology being used is async:  
- event  
- callback
- onfoo

Even Olli's proposal example is async. 
https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c9 (setTimeout)

If the argument is callback hell, save it—because if that's the problem with 
your program, then your doing it wrong (see: node.js ecosystem).


If this API introduces any renderer process blocking, the result will be 
catastrophic in the hands of inexperienced web developers.


Rick
  
  
 A summary of points I find important and my comments, questions and concerns
  
 # Discussion 1
 ## Glenn Maynard [2] Use case exposed:
 Ability to cancel long-running synchronous worker task
 Terminating the whole worker thread is the blunt way to do it; that's
 no good since it requires starting a new thread for every keystroke, and
 there may be significant startup costs (eg. loading search data).
 = It's a legitimate use case that has no good solution today other than
 cutting the task in smaller tasks between which a cancellation message
 can be interleaved.
  
  
 ## Tab Atkins [3]
 If we were to fix this, it needs to be done at the language level,
 because there are language-level issues to be solved that can't be
 hacked around by a specialized solution.
 = I agree a lot with that point. This is a discussion that should be
 had on es-discuss since JavaScript is the underlying language.
 ECMAScript per se doesn't define a concurrency model and it's not even
 on the table for ES.next, but might be in ES.next.next (7?). See [concurr]
  
 ## Jonas Sicking [4]
 Ideas of providing control (read-only) over pending messages in workers.
 (not part of the current Sync API, but interesting nonetheless)
  
  
  
 # Discussion 2
 ## Joshua Bell [5]
 This can be done today using bidirectional postMessage, but of course
 this requires the Worker to then be coded in now common asynchronous
 JavaScript fashion, with either a tangled mess of callbacks or some sort
 of Promises/Futures library, which removes some of the benefits of
 introducing sync APIs to Workers in the first place.
 = What are these benefits? Is the cost of the Promises/Future library
 so high it
 Back to Tab's point of the previous discussion, this is a language
 issue, not an API issue. It ought to be solved at the language level
  
  
 ## Rick Waldron [6]
 This is counter to the whole premise of Workers, which should be
 independent of their renderer process and certainly not block themselves
 while waiting for responses from the renderer (which inherently
 describes an async behaviour).
 = Indeed. Having a blocked worker makes that when you need other tasks
 to happen in parallel, you need to spawn new workers which is a waste of
 resources, very much like Apache which opens a new thread for each HTTP
 connection while some thread are idling (I don't know if it's still the
 case, but it used to)
  
  
 ## Glenn Maynard [7]
 I think this is a fundamental missing piece to worker communication. A
 basic reason for having Workers in the first place is so you can write
 linear code, instead of having to structure code to be able to return
 regularly (often awkward and inconvenient), but currently in order to
 receive messages in workers you still have to do that.
 = A basic reason for having workers is to move computation away from
 window to a concurrent and parallel computation unit so that the UI is
 not blocked by computation. End of story. Nothing to do with writing
 linear code. If JavaScript as it is doesn't allow people to write code
 as they wish, once again, it's a language issue. Either ask a change in
 the language or create a language that looks the way you want and
 compiles down to JavaScript.
  
  
  
 I wish to add that adding a sync API (even if the sync aspect is
 asymetrical as proposed in [1]) breaks the event-loop run-to-completion
 model of in-browser-JavaScript which is intended to be formalized at
 [concurr]. This model is what prevents web pages from ever freezing from
 a deadlock. The proposed API preserves this, but create the threat of
 deadlocks for workers.
  
 Besides programmer convenience, few arguments have been advanced to
 justify the breakage of the current concurrency model (I don't even
 think the breakage has been mentionned at all!). And as said several
 times, programmer convenience are more

Re: Sync API for workers

2012-09-01 Thread Rick Waldron



On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote:

 On Sat, Sep 1, 2012 at 11:49 AM, David Bruant bruan...@gmail.com 
 (mailto:bruan...@gmail.com) wrote:
  A Sync API for workers is being implemented in Firefox [1].
  I'd like to come back to the discussions mentionned in comment 4 of the bug.
  
  A summary of points I find important and my comments, questions and concerns
  
  # Discussion 1
  ## Glenn Maynard [2] Use case exposed:
  Ability to cancel long-running synchronous worker task
  Terminating the whole worker thread is the blunt way to do it; that's
  no good since it requires starting a new thread for every keystroke, and
  there may be significant startup costs (eg. loading search data).
  = It's a legitimate use case that has no good solution today other than
  cutting the task in smaller tasks between which a cancellation message
  can be interleaved.
 
 The solution proposed in 783190 seems more complex and less useful than the 
 one Sicking and I discussed.  To summarize that one: add a 
 getMessage(timeout) method, which consumes and returns the next message 
 (causing onmessage to not be called[1]).  If timeout is nonzero, wait for a 
 message for up to that duration; if zero the function never blocks (eg. peek 
 for a waiting message).  If the timeout expires, returns null.
 
 This turns the first example in 783190 into:
 worker.js: var res = getMessage(timeout);
 page.html: worker = new Worker(...); setTimeout(function() { 
 worker.postMessage(data, transferrable); }, 1000); I think this has several 
 advantages.
 
 - Mozilla's proposal effectly creates a separate, parallel messaging channel 
 on the MessagePort; synchronous vs. asynchronous messages.  This is simpler: 
 messages are just messages, and no new API is exposed outside of workers.
 - User messaging protocols are much simpler.  For example, take a 
 long-running processing task in a worker which wants to be able to receive a 
 stop what you're doing, I have new information that affects your processing 
 task message.  With this proposal, the UI thread (or whatever) simply sends 
 a message with the new information.  With Mozilla's proposal, it would have 
 to wait for the thread to periodically send a do you have anything to tell 
 me? message, in order to be able to send a response that the thread can 
 receive synchronously.
 - Polling is much cheaper.  With Mozilla's proposal, you have to send a 
 message to another thread, then sit and wait until you get a response.  If 
 it's the UI thread, that may take many milliseconds, since it may be busy 
 doing other things.  With this proposal, polling for new messages in a 
 processing loop should never block due to activity in the other thread.
 - The resulting message protocols are more robust.  With the query/response 
 approach, if someone fails to send a response, the worker will wait forever 
 or time out.
 
 
 [1] We didn't come to agreement on whether it's better to return the message 
 or to call onmessage synchronously, but that's a detail; whichever approach 
 is used, it's possible to implement the other in script.
 
  # Discussion 2
  ## Joshua Bell [5]
  This can be done today using bidirectional postMessage, but of course
  this requires the Worker to then be coded in now common asynchronous
  JavaScript fashion, with either a tangled mess of callbacks or some sort
  of Promises/Futures library, which removes some of the benefits of
  introducing sync APIs to Workers in the first place.
  = What are these benefits?
 
 The benefit of being able to write linear code.  I don't think anyone who's 
 written complex algorithms in JavaScript can seriously dispute this as 
 anything but a huge win.

I can seriously dispute this, as someone who involved in research and 
development of JavaScript programming for hardware. Processing high volume 
serialport IO is relatively simple with streams and data events. It's just a 
matter of thinking differently about the program. 


Rick

 
 
  ## Glenn Maynard [7]
  I think this is a fundamental missing piece to worker communication.  A
  basic reason for having Workers in the first place is so you can write
  linear code, instead of having to structure code to be able to return
  regularly (often awkward and inconvenient), but currently in order to
  receive messages in workers you still have to do that.
  = A basic reason for having workers is to move computation away from
  window to a concurrent and parallel computation unit so that the UI is
  not blocked by computation. End of story. Nothing to do with writing
  linear code.
 
 That's another good reason; it doesn't in any way reduce the importance of 
 being able to write linear code, which *is* an important use case of workers. 
  It's precisely why we have APIs like FileReaderSync.
 
  If JavaScript as it is doesn't allow people to write code
  as they wish, once again, it's a language issue. Either ask a change in
  the language or create a language 

Re: Sync API for workers

2012-09-01 Thread Rick Waldron



On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:

 On 09/01/2012 11:19 PM, Rick Waldron wrote:
   
  David,
   
  Thanks for preparing this summary—I just wanted to note that I still stand 
  behind my original, reality based arguments.
   
  One comment inline..
   
  On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:
   
   Hi,

   A Sync API for workers is being implemented in Firefox [1].
   I'd like to come back to the discussions mentionned in comment 4 of the 
   bug.

   
  The original post actually describes an async API—putting the word sync 
  in the middle of a method or event name doesn't make it sync.
   
  As the proposed API developed, it still retains the event handler-esque 
  design (https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c12). All of the
  terminology being used is async:
  - event
  - callback
  - onfoo
   
  Even Olli's proposal example is async. 
  https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c9 (setTimeout)
   
  If the argument is callback hell, save it—because if that's the problem 
  with your program, then your doing it wrong (see: node.js ecosystem).
   
   
  If this API introduces any renderer process blocking, the result will be 
  catastrophic in the hands of inexperienced web developers.
  
  
 I haven't seen any proposal which would block rendering/main/dom thread
So far, they all look async. Just calling them sync doesn't make them sync. 
A sync worker API:

// really sync behaviour means blocking until this returns:  
var result = rendererBlockingAPI( data );

Unless you specifically design that to stop everything and wait for a response 
(renderer blocking), JavaScript will run to completion.

Rick
  
  
  
  
 We've been thinking the following approaches:
  
 Proposal 1
 Parent Thread:
 var w = new Worker('foo.js');
 w.onsyncmessage = function(event) {
 event.reply('bar');
 }
 Worker:
 var r = postSyncMessage('foobar', null, 1000 /* timeout */);
 if (r == 'bar') ..
 PRO:
 - It's already implemented :)
 CON:
 - Multiple event listeners - Multiple reply() calls. How to deal with it?
 - Multiple event listeners - is this your message?
 - Wrong order of the messages in worker if parent sends async message just 
 before receiving sync message
 - The message must be read in order to reply
  
  
 Proposal 1.1
 Parent Thread:
 var w = new Worker('foo.js');
 w.onsyncmessage = function(event) {
 var r = new Reply(event);
 r.reply(bar); // Can be called after event dispatch.
 }
 Worker:
 var replies = postSyncMessage('foobar', null, 1000 /* timeout */);
 for (var r in replies) {
 handleEachReply(r);
 }
 PRO:
 - Can handle multiple replies.
 - No awkward limitations on main thread because of reply handling
 CON:
 - A bit ugly.
 - Reply on the worker thread becomes an array - unintuitive
 - Wrong order of the messages in worker if parent sends async message just 
 before receiving sync message
 - The Reply object must be created during event dispatch.
  
  
 Proposal 2
 Parent Thread:
 var w = new Worker('foo.js');
 w.setSyncHandler('typeFoobar', function(message) {
 return 'bar';
 });
 Worker:
 var r = postSyncMessage('typeFoobar', 'foobar', null, 1000 /* timeout */);
 if (r == 'bar') ..
 PRO:
 - no multple replyies are possible
 - types for sync messages
 CON:
 - Just a single listener
 - It's not based on event - it's something different compare with any other 
 worker/parent communication.
 - Wrong order of the messages in worker if parent sends async message just 
 before receiving sync message
  
  
 Proposal 3
 Worker:
 postMessage(I want reply to this);
 var events = [];
 while (var m = waitForMessage()) {
 if (m.data != /* the reply * /) {
 events.push(m);
 } else {
 // do something with message
 }
 }
 while (events.length()) {
 dispatchEvent(events.shift());
 }
 PRO:
 - Flexible
 - the order of the events is changed by the developer
 - since there isn't any special sync messaging, multiple event listeners don't
 cause problems.
 CON:
 - complex for web developers(?)
 - The message must be read in order to reply
 - Means that you can't use libraries that use sync messages. Only frameworks 
 are possible as all message handling needs to be aware of the new  
 syncmessages.
  
  
  
  
 Atm, I personally prefer the proposal 3.
  
  
 -Olli
  
  
   
   
  Rick

   A summary of points I find important and my comments, questions and 
   concerns

   # Discussion 1
   ## Glenn Maynard [2] Use case exposed:
   Ability to cancel long-running synchronous worker task
   Terminating the whole worker thread is the blunt way to do it; that's
   no good since it requires starting a new thread for every keystroke, and
   there may be significant startup costs (eg. loading search data).
   = It's a legitimate use case that has no good solution today other than
   cutting the task in smaller tasks between which a cancellation message
   can be interleaved.


   ## Tab Atkins [3]
   If we were to fix this, it needs

Re: Sync API for workers

2012-09-01 Thread Rick Waldron
On Sat, Sep 1, 2012 at 4:51 PM, Oliver Hunt oli...@apple.com wrote:

 My reading (from the proposed APIs) is that these are only synchronous
 from the Worker's PoV.  If that's correct I have no real objections to such
 an API - the render thread simply sees a regular message.  It doesn't even
 need a special API on the receiving side.  If the Worker has

 ...
 var response = postSynchronousMessage(message)
 ...

 and the renderer has

 worker.onmessage =function() { ; return foo }

 There are no UI blocking hazards (other than the usual slow event handler
 problem, which is already present anyway)

 The only real problem I can see is along the lines of:

 // Worker1
 onmessage = function () { ...worker2.postSynchronousMessage(...)... }

 // Worker2
 onmessage = function () { ...worker1.postSynchronousMessage(...)... }

 In the current implementations I imagine that this may cause difficulty,
 but I don't think that there is an actual technical argument against it.


Perhaps I misread or misinterpreted the goals of the proposal and while I
appreciate the clarification here, I'm still left wondering: what is the
benefit of a synchronous in-worker-only messaging API if the alleged pain
point is the desire to write linear code.

That aside, I agree with Oliver, if no renderer process blocking can occur
and no existing APIs are broken, then there is no harm (aside from
polluting the global object with more verbosely named APIs, but that's just
a nit) .

Rick



 --Oliver


 On Sep 1, 2012, at 1:38 PM, Rick Waldron wrote:



 On Saturday, September 1, 2012 at 4:28 PM, Olli Pettay wrote:

 On 09/01/2012 11:19 PM, Rick Waldron wrote:


 David,

 Thanks for preparing this summary—I just wanted to note that I still stand
 behind my original, reality based arguments.

 One comment inline..

 On Saturday, September 1, 2012 at 12:49 PM, David Bruant wrote:

 Hi,

 A Sync API for workers is being implemented in Firefox [1].
 I'd like to come back to the discussions mentionned in comment 4 of the
 bug.

 The original post actually describes an async API—putting the word sync
 in the middle of a method or event name doesn't make it sync.

 As the proposed API developed, it still retains the event handler-esque
 design (https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c12). All of
 the
 terminology being used is async:
 - event
 - callback
 - onfoo

 Even Olli's proposal example is async.
 https://bugzilla.mozilla.org/show_bug.cgi?id=783190#c9 (setTimeout)

 If the argument is callback hell, save it—because if that's the problem
 with your program, then your doing it wrong (see: node.js ecosystem).


 If this API introduces any renderer process blocking, the result will be
 catastrophic in the hands of inexperienced web developers.



 I haven't seen any proposal which would block rendering/main/dom thread

 So far, they all look async. Just calling them sync doesn't make them
 sync. A sync worker API:

 // really sync behaviour means blocking until this returns:
 var result = rendererBlockingAPI( data );

 Unless you specifically design that to stop everything and wait for a
 response (renderer blocking), JavaScript will run to completion.

 Rick





 We've been thinking the following approaches:

 Proposal 1
 Parent Thread:
 var w = new Worker('foo.js');
 w.onsyncmessage = function(event) {
 event.reply('bar');
 }
 Worker:
 var r = postSyncMessage('foobar', null, 1000 /* timeout */);
 if (r == 'bar') ..
 PRO:
 - It's already implemented :)
 CON:
 - Multiple event listeners - Multiple reply() calls. How to deal with it?
 - Multiple event listeners - is this your message?
 - Wrong order of the messages in worker if parent sends async message just
 before receiving sync message
 - The message must be read in order to reply


 Proposal 1.1
 Parent Thread:
 var w = new Worker('foo.js');
 w.onsyncmessage = function(event) {
 var r = new Reply(event);
 r.reply(bar); // Can be called after event dispatch.
 }
 Worker:
 var replies = postSyncMessage('foobar', null, 1000 /* timeout */);
 for (var r in replies) {
 handleEachReply(r);
 }
 PRO:
 - Can handle multiple replies.
 - No awkward limitations on main thread because of reply handling
 CON:
 - A bit ugly.
 - Reply on the worker thread becomes an array - unintuitive
 - Wrong order of the messages in worker if parent sends async message just
 before receiving sync message
 - The Reply object must be created during event dispatch.


 Proposal 2
 Parent Thread:
 var w = new Worker('foo.js');
 w.setSyncHandler('typeFoobar', function(message) {
  return 'bar';
 });
 Worker:
 var r = postSyncMessage('typeFoobar', 'foobar', null, 1000 /* timeout */);
 if (r == 'bar') ..
 PRO:
 - no multple replyies are possible
 - types for sync messages
 CON:
 - Just a single listener
 - It's not based on event - it's something different compare with any
 other worker/parent communication.
 - Wrong order of the messages in worker if parent sends async message just
 before receiving sync

Re: Sync API for workers

2012-09-01 Thread Rick Waldron
On Sat, Sep 1, 2012 at 5:12 PM, Olli Pettay olli.pet...@helsinki.fi wrote:

 On 09/01/2012 11:38 PM, Rick Waldron wrote:

  So far, they all look async. Just calling them sync doesn't make them
 sync.


 Sure they are sync. They are sync inside worker. We all know that we must
 not introduce
 new sync APIs in the main thread.



See my response to Oliver Hunt's message

Rick


Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

2012-08-21 Thread Rick Waldron
Comments inline...

On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Tue, Aug 21, 2012 at 3:15 PM, Brian Kardell bkard...@gmail.com wrote:
  On Aug 21, 2012 5:40 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
  On Tue, Aug 21, 2012 at 2:28 PM, Ojan Vafai o...@chromium.org wrote:
  On a somewhat unrelated note, could we somehow also incorporate jquery
  style
  live event handlers here? See previous www-dom discussion about this: .
  I
  suppose we'd still just want listen/unlisten(selector, handler)
 methods,
  but
  they'd get applied at the same time as cascaded attributes. Although,
 we
  might want to apply those on attribute changes as well.
 
  Using CAS to apply an onfoo attribute is nearly the same (use a
  string value to pass the function, obviously).  It'll only allow a
  single listener to be applied, though.
 
  If it's considered worthwhile, we can magic up this case a bit.  CAS
  properties don't accept functions normally (or rather, as I have it
  defined in the OP, it would just accept a FUNCTION token, which is
  just the function name and opening paren, but I should tighten up that
  definition).  We could have a magic function like listen(string)
  that, when used on an onfoo attribute (more generally, on a
  host-language-defined event listener attribute) does an
  addEventListener() call rather than a setAttribute() call.
 
  Can you give some pseudo code or something that is relatively close to
 what
  you mean here?  I'm not entirely sure I follow.

 Sure!

 So, in my current proposal, you can just set an onfoo attribute:





 ul.special  li {
   onclick: alert('You clicked me!');
 evt.target.classlist.add('clicked');;
 }


This is certainly interesting, but...

1. It's a string that will have to be eval'ed, right? In what scope? Does
this get wrapped in a function expression?
2. Using inline attributes that match up to node.onfoo will pave over each
other... if some other style sheet is introduced, by some third party
widget that happens to have

ul.special  li {
  onclick: alert('busted');
}

...Bummer?

3. Where did evt come from?


 Here's a suggestion for a similar API that would invoke
 addEventListener instead of setAttribute:

 ul.special  li {
   onclick: listen(alert('You clicked me!');
 evt.target.classlist.add('clicked'););
 }


How do we know where the body ends?



 ~TJ



Thanks in advance! :)

Rick


Re: Proposal for Cascading Attribute Sheets - like CSS, but for attributes!

2012-08-21 Thread Rick Waldron
On Tue, Aug 21, 2012 at 6:40 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 On Tue, Aug 21, 2012 at 3:29 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
  On Tue, Aug 21, 2012 at 6:17 PM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
  ul.special  li {
onclick: alert('You clicked me!');
  evt.target.classlist.add('clicked');;
  }
 
 
  This is certainly interesting, but...
 
  1. It's a string that will have to be eval'ed, right? In what scope? Does
  this get wrapped in a function expression?

 No, it's a string that gets passed as an argument to setAttribute()
 (or the moral equivalent of such).  Any eval'ing that happens is just
 part of the normal way that onfoo attributes are handled.


Ah-ha, I was thinking of this a bit too script literally



  2. Using inline attributes that match up to node.onfoo will pave over
 each
  other... if some other style sheet is introduced, by some third party
 widget
  that happens to have
 
  ul.special  li {
onclick: alert('busted');
  }
 
  ...Bummer?

 Yes.  That's why I just suggested the listen() function, which would
 invoke addEventListener instead of setAttribute.

 This *would* require a little bit more detail about evaling the
 string.  I suppose it should just be passed through the Function
 constructor in the global scope before being passed to aEL.


  3. Where did evt come from?

 Isn't that one of the magically-defined variables in inline event
 handlers?  If not, swap it out with whatever the correct equivalent
 is.


Nope? (Maybe in 1990's? :D )






  Here's a suggestion for a similar API that would invoke
  addEventListener instead of setAttribute:
 
  ul.special  li {
onclick: listen(alert('You clicked me!');
  evt.target.classlist.add('clicked'););
  }
 
  How do we know where the body ends?

 Do you mean the function body?  It's a string.  The end is well-defined.
 ^_^


Yep, function body.

The string broke over two lines and tricked my eyes and brain. ;)


Rick




 ~TJ



Re: Shrinking existing libraries as a goal

2012-05-17 Thread Rick Waldron
On Thu, May 17, 2012 at 9:31 AM, Scott González scott.gonza...@gmail.comwrote:

 I'm sure Yehuda can speak more to the status of scriptlib, but the way I
 see it is:

 There was a some buzz about scriptlib and the W3C being excited about
 developers participating via CGs.
 Very few developers joined. 33 scriptlib members compared to 287
 jquery-standards[1] members.
 There were 0 meaningful posts. 4 total messages (including hello world)
 compared to 138 messages for jquery-standards.
 Nothing came out of scriptlib, compared to 19 issues[2] in jquery-standards

 AFAICT, there are two explanations for this: First, developers at large
 don't find CGs very inviting. Second, everyone on scriptlib is highly
 experienced and very interested in standards; to the point where they'll
 just go to the appropriate non-CG list to discuss things.

 With that being said, It's good to see W3C pointing to CGs for input :-)

 [1] https://groups.google.com/group/jquery-standards
 [2] https://github.com/jquery/standards/issues



 On Thu, May 17, 2012 at 7:17 AM, Arthur Barstow art.bars...@nokia.comwrote:

 FYI, a Script Library Community Group (Cc'ed) was formed some time ago
 and it may have some similar interest(s) http://www.w3.org/community/**
 scriptlib/ http://www.w3.org/community/scriptlib/ (although their
 mail list archive indicates the CG isn't very active).

 Perhaps someone in that CG has some comments on Yehuda' email.

 -AB

 P.S. Yehuda's email archive is http://lists.w3.org/Archives/**
 Public/public-webapps/**2012AprJun/0762.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0762.html
 


 On 5/16/12 10:13 PM, ext Ojan Vafai wrote:

 In principle, I agree with this as a valid goal. It's one among many
 though, so the devil is in the details of each specific proposal to balance
 out this goal with others (e.g. keeping the platform consistent). I'd love
 to see your list of proposals of what it would take to considerably shrink
 jQuery.

 On Tue, May 15, 2012 at 9:32 PM, Yehuda Katz wyc...@gmail.com mailto:
 wyc...@gmail.com wrote:

In the past year or so, I've participated in a number of threads
that were implicitly about adding features to browsers that would
shrink the size of existing libraries.

Inevitably, those discussions end up litigating whether making it
easier for jQuery (or some other library) to do the task is a good
idea in the first place.

While those discussions are extremely useful, I feel it would be
useful for a group to focus on proposals that would shrink the
size of existing libraries with the implicit assumption that it
was a good idea.

From some basic experimentation I've personally done with the
jQuery codebase, I feel that such a group could rather quickly
identify enough areas to make a much smaller version of jQuery
that ran on modern browsers plausible. I also think that having
data to support or refute that assertion would be useful, as it's
often made casually in meta-discussions.

If there is a strong reason that people feel that a focused effort
to identify ways to shrink existing popular libraries in new
browsers would be a bad idea, I'd be very interested to hear it.

Thanks so much for your consideration,

Yehuda Katz
jQuery Foundation
(ph) 718.877.1325 tel:718.877.1325





Mike Taylor and I tried to ignite scriptlib interest at JSConf with a track
B presentation to raise awareness. It's just not happening.


I fully support Yehuda's proposed goals. DOM APIs are being designed by
non-web developers and non-JavaScript programmers that simply don't get
it and when confronted, the response is frequently library authors will
fix this - which in turns makes libraries bigger, instead of smaller.


Even more important then considering library size is to simply consider
motivating factors for library adoption. Take the following API evolution...


What standards bodies did:

element.onclick = ...

↓

element.addEventListener( click, ..., boolean );


What we did in the trenches:

element.onclick = ...

↓

element.addEventListener( click, ..., boolean );

↓

element.observe( click, 

↓

[elements].on( click, ...


Why isn't this being standardized? There is concrete evidence that supports
this as a preferred API.


Even more problematic is event object target creation: JavaScript programs
that run in browsers are asynchronous event systems, but libraries have to
create their own systems because in 2012, we still can't inherit from
EventTarget [1] - and even if I could, the API is an overlong wind-bag.
Compare the IDL definition for EventTarget to a very popular, generic,
reusable Event system API: http://nodejs.org/docs/v0.7.8/api/events.html


Consider the cowpath metaphor - web developers have made highways out of
sticks, grass and mud - what we need is someone to pour the concrete.


Rick


[1] 

Re: Shrinking existing libraries as a goal

2012-05-17 Thread Rick Waldron
On Thu, May 17, 2012 at 1:05 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, May 17, 2012 at 6:29 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
  [...]

 FWIW, we have bugs filed against DOM for both better event
 registration and constructing of event targets:

 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16487

 I have not made the time yet to work out the details for either
 however and neither has anyone else.


Anne,

Thank you for your continued commitment to real progress.

Rick




 --
 Anne — Opera Software
 http://annevankesteren.nl/
 http://www.opera.com/



Re: Shrinking existing libraries as a goal

2012-05-17 Thread Rick Waldron
On Thu, May 17, 2012 at 2:35 PM, Brian Kardell bkard...@gmail.com wrote:

 So, out of curiosity - do you have a list of things?  I'm wondering
 where some efforts fall in all of this - whether they are good or bad
 on this scale, etc... For example:  querySelectorAll - it has a few
 significant differences from jQuery both in terms of what it will
 return (jquery uses getElementById in the case that someone does #,
 for example, but querySelectorAll doesn't do that if there are
 multiple instances of the same id in the tree)


Which is an abomination for for developers to deal with, considering the ID
attribute value must be unique amongst all the IDs in the element's home
subtree[1] . qSA should've been spec'ed to enforce the definition of an ID
by only returning the first match for an ID selector - devs would've
learned quickly how that worked; since it doesn't and since getElementById
is faster, jQuery must take on the additional code burden, via cover API,
in order to make a reasonably usable DOM querying interface. jQuery says
you're welcome.




 and performance (this
 example illustrates both - since jQuery is doing the simpler thing in
 all cases, it is actually able to be faster (though technically not
 correct)



I'd argue that qSA, in its own contradictory specification, is not
correct.



 in some very difficult ones. Previously, this was something
 that the browser APIs just didn't offer at all -- now they offer them,
 but jQuery has mitigation to do in order to use them effectively since
 they do not have parity.



Yes, we're trying to reduce the amount of mitigation that is required of
libraries to implement reasonable apis. This is a multi-view discussion:
short and long term.



Rick


[1] http://www.whatwg.org/specs/web-apps/current-work/#the-id-attribute




 On Thu, May 17, 2012 at 2:16 PM, Yehuda Katz wyc...@gmail.com wrote:
 
  Yehuda Katz
  (ph) 718.877.1325
 
 
  On Thu, May 17, 2012 at 10:37 AM, John J Barton
  johnjbar...@johnjbarton.com wrote:
 
  On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
   On Thu, May 17, 2012 at 9:56 AM, John J Barton
   johnjbar...@johnjbarton.com wrote:
   On Thu, May 17, 2012 at 9:29 AM, Rick Waldron 
 waldron.r...@gmail.com
   wrote:
   Consider the cowpath metaphor - web developers have made highways
 out
   of
   sticks, grass and mud - what we need is someone to pour the
 concrete.
  
   I'm confused. Is the goal shorter load times (Yehuda) or better
   developer ergonomics (Waldron)?
  
   Of course *some* choices may do both. Some may not.
  
   Libraries generally do three things: (1) patch over browser
   inconsistencies, (2) fix bad ergonomics in APIs, and (3) add new
   features*.
  
   #1 is just background noise; we can't do anything except write good
   specs, patch our browsers, and migrate users.
  
   #3 is the normal mode of operations here.  I'm sure there are plenty
   of features currently done purely in libraries that would benefit from
   being proposed here, like Promises, but I don't think we need to push
   too hard on this case.  It'll open itself up on its own, more or less.
Still, something to pay attention to.
  
   #2 is the kicker, and I believe what Yehuda is mostly talking about.
   There's a *lot* of code in libraries which offers no new features,
   only a vastly more convenient syntax for existing features.  This is a
   large part of the reason why jQuery got so popular.  Fixing this both
   makes the web easier to program for and reduces library weight.
 
  Yes! Fixing ergonomics of APIs has dramatically improved web
  programming.  I'm convinced that concrete proposals vetted by major
  library developers would be welcomed and have good traction. (Even
  better would be a common shim library demonstrating the impact).
 
  Measuring these changes by the numbers of bytes removed from downloads
  seems 'nice to have' but should not be the goal IMO.
 
 
  We can use bytes removed from downloads as a proxy of developer
 ergonomics
  because it means that useful, ergonomics-enhancing features from
 libraries
  are now in the platform.
 
  Further, shrinking the size of libraries provides more headroom for
 higher
  level abstractions on resource-constrained devices, instead of wasting
 the
  first 35k of downloading and executing on relatively low-level primitives
  provided by jQuery because the primitives provided by the platform itself
  are unwieldy.
 
 
 
  jjb
 
  
   * Yes, #3 is basically a subset of #2 since libraries aren't rewriting
   the JS engine, but there's a line you can draw between here's an
   existing feature, but with better syntax and here's a fundamentally
   new idea, which you could do before but only with extreme
   contortions.
  
   ~TJ
 
 



Re: Shrinking existing libraries as a goal

2012-05-17 Thread Rick Waldron
On Thu, May 17, 2012 at 3:21 PM, Brian Kardell bkard...@gmail.com wrote:

 On Thu, May 17, 2012 at 2:47 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
 
 
  On Thu, May 17, 2012 at 2:35 PM, Brian Kardell bkard...@gmail.com
 wrote:
 
  So, out of curiosity - do you have a list of things?  I'm wondering
  where some efforts fall in all of this - whether they are good or bad
  on this scale, etc... For example:  querySelectorAll - it has a few
  significant differences from jQuery both in terms of what it will
  return (jquery uses getElementById in the case that someone does #,
  for example, but querySelectorAll doesn't do that if there are
  multiple instances of the same id in the tree)
 
 
  Which is an abomination for for developers to deal with, considering the
 ID
  attribute value must be unique amongst all the IDs in the element's home
  subtree[1] . qSA should've been spec'ed to enforce the definition of an
 ID
  by only returning the first match for an ID selector - devs would've
 learned
  quickly how that worked; since it doesn't and since getElementById is
  faster, jQuery must take on the additional code burden, via cover API, in
  order to make a reasonably usable DOM querying interface. jQuery says
  you're welcome.
 
 
 
 
  and performance (this
  example illustrates both - since jQuery is doing the simpler thing in
  all cases, it is actually able to be faster (though technically not
  correct)
 
 
 
  I'd argue that qSA, in its own contradictory specification, is not
  correct.

 It has been argued in the past - I'm taking no position here, just
 noting.  For posterity (not you specifically, but for the benefit of
 those who don't follow so closely), the HTML link also references DOM
 Core, which has stated for some time that getElementById should return
 the _first_  element with that ID in the document (implying that there
 could be more than one) [a] and despite whatever CSS has said since
 day one (ids are unique in a doc) [b] a quick check in your favorite
 browser will show that CSS doesn't care, it will style all IDs that
 match.  So basically - qSA matches CSS, which does kind of make sense
 to me... I'd love to see it corrected in CSS too (first element with
 that ID if there are more than one) but it has been argued that a lot
 of stuff (more than we'd like to admit) would break.

  in some very difficult ones. Previously, this was something
  that the browser APIs just didn't offer at all -- now they offer them,
  but jQuery has mitigation to do in order to use them effectively since
  they do not have parity.
 
 
  Yes, we're trying to reduce the amount of mitigation that is required of
  libraries to implement reasonable apis. This is a multi-view discussion:
  short and long term.
 

 So can someone name specific items?   Would qSA / find been pretty
 high on that list?  Is it better for jQuery (specifically) that we
 have them in their current state or worse?  Just curious.


TBH, the current state can't get any worse, though I'm sure it will.
Assuming you're referring to this:
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1454.html

... Yes, APIs like this would be improvements, especially considering the
pace of implementation in modern browsers - hypothetically, this could be
in wide implementation in less then a year; by then development of a sort
of jQuery 2.0 could happen -- same API, but perhaps modern browser only??
This is hypothetical of course.



Rick




 [a] -
 http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-getelementbyid
 [b] - http://www.w3.org/TR/CSS1/#id-as-selector














 
  Rick
 
 
  [1] http://www.whatwg.org/specs/web-apps/current-work/#the-id-attribute
 
 
 
 
  On Thu, May 17, 2012 at 2:16 PM, Yehuda Katz wyc...@gmail.com wrote:
  
   Yehuda Katz
   (ph) 718.877.1325
  
  
   On Thu, May 17, 2012 at 10:37 AM, John J Barton
   johnjbar...@johnjbarton.com wrote:
  
   On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. 
 jackalm...@gmail.com
   wrote:
On Thu, May 17, 2012 at 9:56 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Thu, May 17, 2012 at 9:29 AM, Rick Waldron
waldron.r...@gmail.com
wrote:
Consider the cowpath metaphor - web developers have made highways
out
of
sticks, grass and mud - what we need is someone to pour the
concrete.
   
I'm confused. Is the goal shorter load times (Yehuda) or better
developer ergonomics (Waldron)?
   
Of course *some* choices may do both. Some may not.
   
Libraries generally do three things: (1) patch over browser
inconsistencies, (2) fix bad ergonomics in APIs, and (3) add new
features*.
   
#1 is just background noise; we can't do anything except write good
specs, patch our browsers, and migrate users.
   
#3 is the normal mode of operations here.  I'm sure there are
 plenty
of features currently done purely in libraries that would benefit
from
being proposed here, like

Re: GamepadObserver (ie. MutationObserver + Gamepad)

2012-05-03 Thread Rick Waldron
 snip


Weird, because you posted
this:
https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US

here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40


Just to be clear, I'm not trying to be aggressive or confrontational, but I
just reread my message from last night and realized it could easily be read
that way - apologies!  :)


I'm not sure what you mean. It is my opinion is that it would be
inefficient to spam 50+ button and axis events multiplied by (say) 4
devices @ 60Hz, which is why I've been pursuing the design of a
polling API. So, though what you quoted was written a while back, it
seems to still represent my opinion pretty accurately


I'm not sure if everyone agrees with me on that though, which is why I
said I didn't think there was a consensus. I believe Mozilla's
vendor-prefixed implementation includes some of those type of events,
so perhaps we will soon have more empirical data on the subject.


I agree with both arguments, because you're right: it's simply too much
volume. As for existing data or APIs, Microsoft's DirectInput API provides
both polling and event notifications.

Going back to the notes at
http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events I'd
say the single event gamepagechanged, where the event object has a
property describing the complete state of the gamepad, is more in line with
the DirectInput event system. Something like this would also make it easier
to detect multiple, sequentially and/or simultaneously changed states...

eg. press and hold B; while holding B, press A
(for the sake of example, the states will be HIGH and LOW, both start LOW)

Dispatch an event for the change of state on B. B set HIGH
Dispatch an event for the change of state on A. A set HIGH, B still HIGH

When the event is dispatched for the changed state of A, the handler
receives an event object that will show no change to the state of B since
it was set to HIGH.


With separate axis and button events, I dont think this could be reasonably
feasible.


Again, apologies for any perceived negative tone from earlier messages :)


Rick




[snip]


GamepadObserver (ie. MutationObserver + Gamepad)

2012-05-02 Thread Rick Waldron
Instead of traditional DOM events being used for Other Events[1], and
considering the high frequency of Gamepad state changes, it might make
sense to provide an API similar to MutationObserver, where a MutationRecord
is created that has snapshots of current and previous states of axes or
buttons...


This is entirely hypothetical:

(new GamepadObserver(function(mutations) {

  console.log( mutations );
  /*
  {
previousState: {
  readonly attribute string   id;
  readonly attribute long index;
  readonly attribute DOMTimeStamp timestamp;

// Either or both of the following, bases on the options list

  readonly attribute float[]  axes;
  readonly attribute float[]  buttons;
}

currentState: {
  readonly attribute string   id;
  readonly attribute long index;
  readonly attribute DOMTimeStamp timestamp;

// Either or both of the following, bases on the options list

  readonly attribute float[]  axes;
  readonly attribute float[]  buttons;
}
  }
  */
})).observe(navigator.gamepads[0], { axesList: true });

//  axesList, buttonsList


[1] http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events


Rick


Re: GamepadObserver (ie. MutationObserver + Gamepad)

2012-05-02 Thread Rick Waldron
On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi wrote:

 On 05/03/2012 12:48 AM, Rick Waldron wrote:

 Instead of traditional DOM events being used for Other Events[1], and
 considering the high frequency of Gamepad state changes, it might make
 sense to provide an API similar to MutationObserver, where a
 MutationRecord is created that has snapshots of current and previous
 states of axes or buttons...


 This is entirely hypothetical:

 (new GamepadObserver(function(**mutations) {

   console.log( mutations );
   /*
   {
 previousState: {
   readonly attribute string   id;
   readonly attribute long index;
   readonly attribute DOMTimeStamp timestamp;

 // Either or both of the following, bases on the options list

   readonly attribute float[]  axes;
   readonly attribute float[]  buttons;
 }

 currentState: {
   readonly attribute string   id;
   readonly attribute long index;
   readonly attribute DOMTimeStamp timestamp;

 // Either or both of the following, bases on the options list

   readonly attribute float[]  axes;
   readonly attribute float[]  buttons;
 }
   }
   */
 })).observe(navigator.**gamepads[0], { axesList: true });

 //  axesList, buttonsList

 [1] http://dvcs.w3.org/hg/gamepad/**raw-file/tip/gamepad.html#**
 other-eventshttp://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events


 Rick



 no need for this kind of thing. Gamepad data is external, so dispatching
 events is better. The event can of course keep
 a list of changes since the previous event dispatch.


I had originally argued for an event, though met with resistance. The
reasoning was that gamepad state changes are far too high resolution which
would result in high event dispatch volume.

Is there documented discussion surrounding the return to an event being
desirable?

Thanks for your time.


Rick






 -Olli




Re: GamepadObserver (ie. MutationObserver + Gamepad)

2012-05-02 Thread Rick Waldron
On Wed, May 2, 2012 at 7:01 PM, Scott Graham scot...@chromium.org wrote:

 On Wed, May 2, 2012 at 3:12 PM, Rick Waldron waldron.r...@gmail.com
 wrote:
  On Wed, May 2, 2012 at 5:54 PM, Olli Pettay olli.pet...@helsinki.fi
 wrote:
 
  On 05/03/2012 12:48 AM, Rick Waldron wrote:
 
  Instead of traditional DOM events being used for Other Events[1], and
  considering the high frequency of Gamepad state changes, it might make
  sense to provide an API similar to MutationObserver, where a
  MutationRecord is created that has snapshots of current and previous
  states of axes or buttons...
 
 
  This is entirely hypothetical:
 
  (new GamepadObserver(function(mutations) {
 
console.log( mutations );
/*
{
  previousState: {
readonly attribute string   id;
readonly attribute long index;
readonly attribute DOMTimeStamp timestamp;
 
  // Either or both of the following, bases on the options list
 
readonly attribute float[]  axes;
readonly attribute float[]  buttons;
  }
 
  currentState: {
readonly attribute string   id;
readonly attribute long index;
readonly attribute DOMTimeStamp timestamp;
 
  // Either or both of the following, bases on the options list
 
readonly attribute float[]  axes;
readonly attribute float[]  buttons;
  }
}
*/
  })).observe(navigator.gamepads[0], { axesList: true });
 
  //  axesList, buttonsList
 
  [1]
 http://dvcs.w3.org/hg/gamepad/raw-file/tip/gamepad.html#other-events
 
 
  Rick
 
 
 
  no need for this kind of thing. Gamepad data is external, so dispatching
  events is better. The event can of course keep
  a list of changes since the previous event dispatch.
 
 
  I had originally argued for an event, though met with resistance. The
  reasoning was that gamepad state changes are far too high resolution
 which
  would result in high event dispatch volume.
 
  Is there documented discussion surrounding the return to an event being
  desirable?

 I'm not aware of any pro/against discussion on that other than the
 Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=604039. I
 don't think there's consensus on that point yet.


Weird, because you posted this:
https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US

here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40

In which you state:

*The current proposal for accessing Joysticks from Mozilla is an
 event-based one, mirroring keyboard and mouse input.
 https://wiki.mozilla.org/JoystickAPI*
 At 60fps, with all the of the analog buttons, triggers, vibration,
 gyroscope on modern game pad (PS3, Xbox 360, and others) there will easily
 be many events within each 16ms frame.
 With so many events, it’s both inefficient, as many events will only be
 handled in order to update the “current state”, and complex to correctly
 maintain and update the state, which will have to be written in every
 application.
 On the positive side, events and polling are not mutually exclusive. While
 it seems like the primary use-case for gamepad input is for games, which
 would prefer polling, there may be some uses where the event-based is
 better, say for using the gamepad as an input device to advance frames in a
 presentation.



Rick



 The observer ability of filtering to desired-only seems interesting. I
 guess it might get complex if it was to be filtered more finely than
 just axesList/buttonsList.



 
  Thanks for your time.
 
 
  Rick
 
 
 
 
 
 
  -Olli
 
 



Re: [EventSource] Make it available in Worker

2012-04-22 Thread Rick Waldron
Are you saying this is no longer possible? 

https://gist.github.com/552549 

-Rick


On Sunday, April 22, 2012 at 9:47 AM, Ivan Enderlin @ Hoa wrote:

 Hello folks,
 
 Are they any reasons to not have the EventSource interface available in 
 a WorkerGlobalScope?
 
 The W3C specifies that they must be no interface objects and 
 constructors in this scope [1], and the MDN documentation confirms that 
 [2]. Indeed, the EventSource interface [3] has no DOM-related impact 
 (e.g. it never uses document or window) and it could be useful to 
 receive events from server-side in a Worker.
 Moreover, I don't see any particular technical reason that coud be blocking.
 
 Thoughts?
 Best regards.
 
 [1] http://w3.org/TR/workers/#interface-objects-and-constructors
 [2] 
 https://developer.mozilla.org/En/DOM/Worker/Functions_available_to_workers
 [3] http://w3.org/TR/eventsource/
 
 -- 
 Ivan Enderlin
 Developer of Hoa
 http://hoa.42/ or http://hoa-project.net/
 
 PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
 http://disc.univ-fcomte.fr/ and http://www.inria.fr/
 
 




Re: [DOM4] NodeList should be deprecated

2012-03-13 Thread Rick Waldron

On Mar 13, 2012, at 4:29 AM, Anne van Kesteren ann...@opera.com wrote:

 On Mon, 12 Mar 2012 21:06:00 +0100, Rick Waldron waldron.r...@gmail.com 
 wrote:
 On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r...@gmail.com 
 wrote:
 The NodeList item() method is a blocker.
 
 Blocker in what way?
 
 As I've always understood it - the item() method is what differentiates 
 NodeList from Array and blocks it from being just an array.
 
 Is this incorrect?
 
 I think there is more, such as arrays being mutable, but the suggestion was 
 to change two accessors from mutation observers to return platform array 
 objects rather than NodeLists, which is a change we can still make given that 
 mutation observers is not widely deployed yet.

I that case, very cool. Thanks for the clarification.

 
 
 -- 
 Anne van Kesteren
 http://annevankesteren.nl/



Re: [DOM4] NodeList should be deprecated

2012-03-13 Thread Rick Waldron
On Tue, Mar 13, 2012 at 10:24 PM, Ojan Vafai o...@chromium.org wrote:

 Upon further thought, I take this suggestion back. Static NodeList as it
 currently exists is just an underpowered array, but that doesn't mean
 that's what it always has to be. In the future, we should add methods to
 NodeList that operate on Nodes, e.g. add a remove method to NodeList that
 call remove on all the Nodes in the NodeList. Also, in theory, browser may
 be able to optimize common cases of NodeLists (e.g. cache frequently
 accessed NodeLists).

 We should make static NodeList inherit from Array though so that you can
 do regular array operations on it.


In the future, it will be incredibly easy to make a NodeList into an Array
with the spread operator:

[ ...NodeList ]

// [ node, node, node ]

Rick





 On Tue, Mar 13, 2012 at 5:59 AM, Rick Waldron waldron.r...@gmail.comwrote:


 On Mar 13, 2012, at 4:29 AM, Anne van Kesteren ann...@opera.com
 wrote:

  On Mon, 12 Mar 2012 21:06:00 +0100, Rick Waldron 
 waldron.r...@gmail.com wrote:
  On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com
 wrote:
  On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron 
 waldron.r...@gmail.com wrote:
  The NodeList item() method is a blocker.
 
  Blocker in what way?
 
  As I've always understood it - the item() method is what
 differentiates NodeList from Array and blocks it from being just an array.
 
  Is this incorrect?
 
  I think there is more, such as arrays being mutable, but the suggestion
 was to change two accessors from mutation observers to return platform
 array objects rather than NodeLists, which is a change we can still make
 given that mutation observers is not widely deployed yet.

 I that case, very cool. Thanks for the clarification.

 
 
  --
  Anne van Kesteren
  http://annevankesteren.nl/





Re: [DOM4] NodeList should be deprecated

2012-03-12 Thread Rick Waldron
On Mon, Mar 12, 2012 at 2:00 PM, Adam Klein ad...@chromium.org wrote:

 On Thu, Mar 8, 2012 at 11:57 PM, Anne van Kesteren ann...@opera.comwrote:

 On Thu, 08 Mar 2012 23:24:45 +0100, Ojan Vafai o...@chromium.org wrote:

 Dynamic NodeLists have a significant memory and performance cost. Static
 NodeLists are basically just under-powered arrays. We should just return
 Node arrays from any new APIs that return a list of Nodes. I'd like to
 see NodeList get similar treatment to hasFeature, i.e. a note that it not be
 used for new APIs and possibly even the explicitly list the APIs allowed
 to return them.

 I don't see the Dynamic/Static distinction in DOM4 or the HTML spec. Is
 this specified anywhere?


 We use the words live and static.



  For reference, this came up in WebKit with some new Regions APIs
 https://bugs.webkit.org/show_**bug.cgi?id=80638https://bugs.webkit.org/show_bug.cgi?id=80638
 .


 Mutation observers uses NodeList too.


 Though there's no reason they couldn't use arrays instead (they're not
 live). In fact, that would make the API more self-consistent, since arrays
 (of MutationRecords) are already part of the interface.


The NodeList item() method is a blocker.


Rick




 - Adam



Re: [DOM4] NodeList should be deprecated

2012-03-12 Thread Rick Waldron
On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com wrote:

 On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r...@gmail.com 
 wrote:
 The NodeList item() method is a blocker.
 
 Blocker in what way?

As I've always understood it - the item() method is what differentiates 
NodeList from Array and blocks it from being just an array.

Is this incorrect?

Rick


 
 
 -- 
 Anne van Kesteren
 http://annevankesteren.nl/



Re: Templates 2: The Real World

2012-02-13 Thread Rick Waldron



 Short answer: yes.  Particularly, I know that Rafael has spent
 significant time with several of the templating systems, and Dimitri
 and several others have had at least a decent exposure to them and the
 developers of them.

 ~TJ


Great! Thanks for the follow up :)


Templates 2: The Real World

2012-02-09 Thread Rick Waldron
Hey everyone,

I've been following the HTML Parsing and the template element
thread/conversation since it began yesterday and it's very interesting, but
one thing keeps coming to mind - has anyone working on template spent any
significant time using the existing web template systems and practices?

Here are a few that are fairly common and in production use:

Mustache.js (logic-less)
https://github.com/janl/mustache.js

Embedded.js (logic)
http://embeddedjs.com/

JST (gaining developer mindshare)
http://ricostacruz.com/backbone-patterns/#jst_templates

This list is by no means intended to be comprehensive or to imply any
endorsement - in fact, I don't use any of these (I use underscore.js's
super simple pre-compiled templates)



Benchmarking information:
http://www.viget.com/extend/benchmarking-javascript-templating-libraries/


Rick


Re: [webcomponents] Considering declarative event handlers

2012-02-07 Thread Rick Waldron
On Tue, Feb 7, 2012 at 2:41 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:

 Folks,

 To make Web Components more usable, I would like to consider providing
 a way to declare event handlers in markup. As I look over the use
 cases and try to implement them using the proposed syntax
 (http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html),
 a pattern emerges, where a bunch of event handlers is declared and
 registered early in the lifecycle of the custom elements
 (
 http://dvcs.w3.org/hg/webcomponents/raw-file/tip/samples/entry-helper.html
 ,
 http://dglazkov.github.com/Tabs/tabs-control.js as rough examples).

 Even thought it's a perfectly workable solution, it also implies that
 we must run script in order to just write up the events. However,
 given that the template element takes care of setting up the initial
 state of the shadow DOM subtree for the custom element, in many
 controls, the only script that runs during initialization will be just
 wiring up events.

 It seems that we can do better. Consider this inspirational example
 (loosely reimagines Internet Explorer's existing functionality
 http://msdn.microsoft.com/en-us/library/ms533746(v=vs.85).aspx):

 element name=x-tab-manager
 template
 div class=container
 ...
 div class=overflow
script event=click
// this is the parent div element.
// event is the current event object.
if (event.target.className != 'more')
return;
if (this.moreOpened)
this.closeMore();
   ...
/script
 /div


This directly contradicts separation of concern and promotes coupling
logic with presentation. public-webapps should be defined way to avoid
those practices, not encourage them.

Rick








 ...

 /div
 /template
 /element

 In other words, this imaginary new thing will operate similarly to the
 style scoped, where it registers an event handler on the parent
 element of its declaration.

 The pros are:
 * It's declarative and intuitively logical
 * The script does not have to run (or even compile) until event fires
 * The author does not need to imperatively go find the element in the
 tree to attach an event handler to it

 The cons are:
 * It's a new syntax
 * It doesn't allow to close over the event handler code, which is a
 common way to manage variable scoping in JS.

 I would appreciate any thoughts, ideas, or results of existing
 research on this. I am sure someone had thought about this harder and
 longer than I did.

 :DG




Re: [webcomponents] Considering declarative event handlers

2012-02-07 Thread Rick Waldron
What about conflict with existing specification rules?

http://dev.w3.org/html5/spec/Overview.html#the-script-element - under #12,
limits the use of event and for attributes to load and window respectively.


Rick




On Tue, Feb 7, 2012 at 3:05 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 2/7/12 2:41 PM, Dimitri Glazkov wrote:

 div class=overflow
 script event=click
 // this is the parent div element.
 // event is the current event object.
 if (event.target.className != 'more')
 return;
 if (this.moreOpened)
 this.closeMore();
...
 /script
 /div


 This looks an awful lot like what XBL does (it uses handler elements for
 this).

 People had some issues with this, which is why XBL2 had moved to a single
 script blob that just set things like the onclick attribute.

 I assume you've looked into what these issues were?  At least ask hyatt
 and hixie, please.


  * It's declarative and intuitively logical
 * The script does not have to run (or even compile) until event fires
 * The author does not need to imperatively go find the element in the
 tree to attach an event handler to it


 #3 is achievable with other approaches (e.g. just having a script that
 runs with this set to the element in question or something).

 #2 is true, but would be equally true with:

  this.onclick = function() {  }

 I think.  The only thing the UA would have to do there is syntax-check the
 function, which I think is desirable to do anyway for error reporting
 purposes.

 -Boris




Re: CG for Speech JavaScript API

2012-02-01 Thread Rick Waldron
So, one of the biggest issues facing the web right now is the ones that
aren't seen by end users of web sites - they are seen by web developers who
have to wade through cryptic, often bizarre, frequently asymmetrical and
almost alway too concise or too verbose APIs. Proposal and spec authors
have the power to change this, and I understand it's hard to open your work
for others to pick apart, but think of it this way: if you came to work and
someone in the office had brought in new desks and computers without asking
you and just said use this, because I said so and I know better, at the
very least, you'd be frustrated. There are too many examples of DOM APIs
that suck and not enough examples of ones that are great and easy to use.

Rick



On Wed, Feb 1, 2012 at 9:51 AM, Charles McCathieNevile cha...@opera.comwrote:

 Hi Satish,


 On Wed, 01 Feb 2012 10:50:25 +0100, Satish S sat...@google.com wrote:

  Re the mail list, if we turn this around and look at it from the
 perspective of someone that is mostly interested in the CG and not
 WebApps, they would then receive close to an additional 2K emails
 per quarter.


   I really don't think you want that so I recommend against using
 public-webapps.


 Speech API discussions could use a [speech api] prefix in the email
 subject so that participants can filter emails based on that. I see this
 style being used by File API and possibly others in the webapps mailing
 list.


 True, but those are deliverables of the Web Apps group. Which already has
 a number of deliverables, and a lot of mail traffic for work it has agreed
 to take on. We have already moved various kinds of work to other lists to
 reduce that traffic.


  As Glen mentioned keeping discussions in the webapps mailing list
 will provide visibility to a wider audience, with a balanced web-centric
 view for new JavaScript APIs.


 The wider audience are welcome to subscribe to a list for the group
 working on the API - but they may not want to. The fact that you add
 messages to people's inbox doesn't mean that they will read them, as we all
 know already. I do not think it is reasonable to use this list for the work
 given that it has not been accepted as a work item by the group.

 Cheers

 Chaals

 --
 Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
 http://my.opera.com/chaals   Try Opera: http://www.opera.com




Re: CG for Speech JavaScript API

2012-02-01 Thread Rick Waldron
Apologies, cited the wrong message in this thread, please forgive.


( Rick: -2 ;)  )

On Wed, Feb 1, 2012 at 10:20 AM, Rick Waldron waldron.r...@gmail.comwrote:

 So, one of the biggest issues facing the web right now is the ones that
 aren't seen by end users of web sites - they are seen by web developers who
 have to wade through cryptic, often bizarre, frequently asymmetrical and
 almost alway too concise or too verbose APIs. Proposal and spec authors
 have the power to change this, and I understand it's hard to open your work
 for others to pick apart, but think of it this way: if you came to work and
 someone in the office had brought in new desks and computers without asking
 you and just said use this, because I said so and I know better, at the
 very least, you'd be frustrated. There are too many examples of DOM APIs
 that suck and not enough examples of ones that are great and easy to use.

 Rick



 On Wed, Feb 1, 2012 at 9:51 AM, Charles McCathieNevile 
 cha...@opera.comwrote:

 Hi Satish,


 On Wed, 01 Feb 2012 10:50:25 +0100, Satish S sat...@google.com wrote:

  Re the mail list, if we turn this around and look at it from the
 perspective of someone that is mostly interested in the CG and not
 WebApps, they would then receive close to an additional 2K emails
 per quarter.


   I really don't think you want that so I recommend against using
 public-webapps.


 Speech API discussions could use a [speech api] prefix in the email
 subject so that participants can filter emails based on that. I see this
 style being used by File API and possibly others in the webapps mailing
 list.


 True, but those are deliverables of the Web Apps group. Which already has
 a number of deliverables, and a lot of mail traffic for work it has agreed
 to take on. We have already moved various kinds of work to other lists to
 reduce that traffic.


  As Glen mentioned keeping discussions in the webapps mailing list
 will provide visibility to a wider audience, with a balanced web-centric
 view for new JavaScript APIs.


 The wider audience are welcome to subscribe to a list for the group
 working on the API - but they may not want to. The fact that you add
 messages to people's inbox doesn't mean that they will read them, as we all
 know already. I do not think it is reasonable to use this list for the work
 given that it has not been accepted as a work item by the group.

 Cheers

 Chaals

 --
 Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan litt norsk
 http://my.opera.com/chaals   Try Opera: http://www.opera.com





Re: CG for Speech JavaScript API

2012-01-31 Thread Rick Waldron
Just wondering why, in 2012, there are proposals for elements with abbreviated 
names. Please stop doing that.

record 

Is two characters longer and infinitely more intuitive. Say no to mistakes like 
img

Rick

On Jan 31, 2012, at 11:51 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:

 * Glen Shires wrote:
 We at Google propose the formation of a new Community Group to pursue a
 JavaScript Speech API. Specifically, we are proposing this Javascript API
 [1], which enables web developers to incorporate speech recognition and
 synthesis into their web pages, and supports the majority of use-cases in
 the Speech Incubator Group's Final Report [2]. This API enables developers
 to use scripting to generate text-to-speech output and to use speech
 recognition as an input for forms, continuous dictation and control. For
 this first specification, we believe this simplified subset API will
 accelerate implementation, interoperability testing, standardization and
 ultimately developer adoption.
 
 Looking at HTML Speech Incubator Group Final Report, there is a propo-
 sal for a reco element. Let's say the Community Group adopts this idea
 and several browser vendors implement it. Is the assumption that Mozilla
 would implement a mozReco element while Microsoft would implement some
 msReco element if they choose to adopt this, or would they agree on a
 experimentalReco element? Or would they implement a reco element? If
 they implement plain reco, there is not much room for a Working Group,
 where this might be standardized in the future, to make major changes,
 meaning they would be mostly rubber-stamping the Community Group output.
 -- 
 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/ 
 



postMessage is the new wtf

2011-12-13 Thread Rick Waldron
Following the recent blog post
http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand
subsequent Twitter discussion regarding changes to the parameter list
of:

Worker.prototype.postMessage( message [, transfer ] ) [1]

DedicatedWorkerGlobalScope void
postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any
message, optional sequenceTransferable transfer) [2][3]


I'm unable to find documentation or discussion that would clarify the
rationale of over-using and over-loading the postMessage Identifier;
considering the the blog cited above shows this example:

[window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer]);

which conflicts with:

window.postMessage(message, targetOrigin [, transfer ]) [4][5]

and they both conflict with:

DedicatedWorkerGlobalScope : WorkerGlobalScope ...
 void postMessage(in any message, in optional MessagePortArray ports); [6]

Currently, passing a second arg to worker.postMessage(), that is not a
MessagePortArray raises
Uncaught TypeError: MessagePortArray argument must contain only
MessagePorts in Chrome and Could not get domain warning in Firefox.


Any reasonable clarification would be greatly appreciated.

Thanks in advance

Rick


[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface

[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface

[3]
http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface

[4]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging

[5]
http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages

[6] PREVIOUS SPECIFICATION STATE!!!
http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface


Re: postMessage is the new wtf

2011-12-13 Thread Rick Waldron
On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov dslo...@chromium.org wrote:

 Hi Rick,
 here are some clarifications.

 There were many (long!) discussions on public-webapps about the new
 signature for postMessage:
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0304.html
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0805.html
 http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0985.html


I appreciate these links and to clarify, I wasn't subscribed to this last
in April of 2011, so my search started here:

https://www.google.com/search?gcx=csourceid=chromeie=UTF-8q=postmessage+api+change

...Among several other similar searches. I promise this wasn't a case of
just not looking, so again, thank you for providing the links



 window.webkitPostMessage(msg, transferables) does not really exist (it is
 an error in the blog post, and I am told the post will be amended). What
 exists is window.webkitPostMessage(msg, targetOrigin, transferables).


This supports the subject line postMessage is the new wtf



 Regarding second argument to worker.(webkit)postMessage, this is the new
 spec for it:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
 .


Thank you, please see [2]




 The spec mandates 'void postMessage(any message, optional
 sequenceTransferable transfer)'. Transferable includes both MessagePorts
 and ArrayBuffers, so in the new spec the transfer argument to postMessage
 may be a mix of both types, and a backwards-compat extension to what we had
 before (sequenceMessagePort aka MessagePortArray). Note that message
 ports got an additional change in semantics, and can now be mentioned in
 the message as well - both

   worker.postMessage({p:port}, [port])
 and
worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
 work. Therefore this extension to postMessage semantics is both
 backwards-compatible and consistent.


Can you provide a reference for this? I'm unable to locate anything that
covers these semantics.



 On the receiving side, the 'ports' property of event object will still
 contain only the message ports from the transfer list, so that behavior is
 preserved as well.


Great!



 I hope this helps,
 Thanks,
 Dmitry



 On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron waldron.r...@gmail.comwrote:

 Following the recent blog post
 http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand 
 subsequent Twitter discussion regarding changes to the parameter list
 of:

 Worker.prototype.postMessage( message [, transfer ] ) [1]

 DedicatedWorkerGlobalScope void 
 postMessagehttp://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage(any
 message, optional sequenceTransferable transfer) [2][3]


 I'm unable to find documentation or discussion that would clarify the
 rationale of over-using and over-loading the postMessage Identifier;
 considering the the blog cited above shows this example:

 [window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer
 ]);

  which conflicts with:

 window.postMessage(message, targetOrigin [, transfer ]) [4][5]

 and they both conflict with:

 DedicatedWorkerGlobalScope : WorkerGlobalScope ...
  void postMessage(in any message, in optional MessagePortArray ports); [6]

 Currently, passing a second arg to worker.postMessage(), that is not a
 MessagePortArray raises
 Uncaught TypeError: MessagePortArray argument must contain only
 MessagePorts in Chrome and Could not get domain warning in Firefox.


 Any reasonable clarification would be greatly appreciated.

 Thanks in advance

 Rick


 [1]
 http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface

 [2]
 http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface

 [3]
 http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface

 [4]
 http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging

 [5]
 http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages

 [6] PREVIOUS SPECIFICATION STATE!!!
 http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface





Re: postMessage is the new wtf

2011-12-13 Thread Rick Waldron
Dmitry,

Thanks for taking the time to provide these references and resources

Rick


Re: Synchronous postMessage for Workers?

2011-11-18 Thread Rick Waldron


On Nov 18, 2011, at 12:56 PM, Glenn Maynard gl...@zewt.org wrote:

 On Fri, Nov 18, 2011 at 12:18 PM, David Levin le...@chromium.org wrote:
 The primary use case is one in which messages sent to 
 DedicatedWorkerGlobalScope are reserved for synchronous messaging.
 
 Mostly, yes, or otherwise dealing with unrelated messages coming in while 
 you're waiting for a response.
 
 It's possible to safely use async and sync message receipt on the same 
 channel.  For example,
 
 onmessage = function(e)
 {
 if(e.data.message == pause)
 {
 msg = waitForMessage();
 // assert(msg.message == continue);

The name waitForMessage() definitely has a promise/futures connotation... 


 }
 }
 
 and in the main thread,
 
 worker.postMessage({message = pause});
 alert(The worker is currently paused and waiting to be continued);
 worker.postMessage({message = continue});


My initial concerns aside and with no trolling intentions... The above literal 
expressions are all syntax errors, = should be :
 
 Once you send pause, events and timers in the worker will be deferred until 
 you resume it.  Since messages are delivered in order, this is guaranteed to 
 work.
 
 (By the way, the above isn't why I prefer this API; I prefer it because it 
 avoids adding more messaging mechanisms and it creates a simpler API.  The 
 above is just an interesting way it might be used.)
 
 -- 
 Glenn Maynard
 


Re: Synchronous postMessage for Workers?

2011-11-17 Thread Rick Waldron
On Thu, Nov 17, 2011 at 1:37 PM, Joshua Bell jsb...@chromium.org wrote:

 Jonas and I were having an offline discussing regarding the synchronous
 Indexed Database API and noting how clean and straightforward it will allow
 Worker scripts to be. One general Worker issue we noted - independent of
 IDB - was that there are cases where Worker scripts may need to fetch data
 from the Window. This can be done today using bidirectional postMessage,
 but of course this requires the Worker to then be coded in now common
 asynchronous JavaScript fashion, with either a tangled mess of callbacks or
 some sort of Promises/Futures library, which removes some of the benefits
 of introducing sync APIs to Workers in the first place.


Workers are suited quite well to Promises/Futures apis. Sync apis are sore
thumb in GlobalWorkerScope's world.



 Wouldn't it be lovely if the Worker script could simply make a synchronous
 call to fetch data from the Window?

 GTNW.prototype.end = function () {
 var result = self.sendMessage({action: prompt_user, prompt: How
 about a nice game of chess?});
 if (result) { chess_game.begin(); }
 }

 The requirement would be that the Window side is asynchronous (of course).
 Continuing the silly example above, the Window script responds to the
 message by fetching some new HTML UI via async XHR, adding it to the DOM,
 and only after user input and validation events is a response sent back to
 the Worker, which proceeds merrily on its way.

 I don't have a specific API suggestion in mind. On the Worker side it
 should take the form of a single blocking call taking the data to be passed
 and possibly a timeout, and allowing a return value (on
 timeout return undefined or throw?).


This is counter to the whole premise of Workers, which should be
independent of their renderer process and certainly not block themselves
while waiting for responses from the renderer (which inherently describes
an async behaviour).



 On the Window side it could be a new event on Worker which delivers a
 Promise type object which the Window script can later fulfill (or break).
 Behavior on multiple event listeners would need to be defined (all get the
 same Promise, first fulfill wins, others throw?).



Rick


Re: Synchronous postMessage for Workers?

2011-11-17 Thread Rick Waldron


On Nov 17, 2011, at 2:37 PM, Glenn Maynard gl...@zewt.org wrote:

 On Thu, Nov 17, 2011 at 2:16 PM, Rick Waldron waldron.r...@gmail.com wrote:
 This is counter to the whole premise of Workers, which should be independent 
 of their renderer process and certainly not block themselves while waiting 
 for responses from the renderer (which inherently describes an async 
 behaviour). 
 
 That's backwards.  The premise is that the renderer (UI) will not be blocked 
 by workers, not that workers won't be blocked by the renderer.

No, it's not. Messaging should not block either process. 

 
  Sync apis are sore thumb in GlobalWorkerScope's world.
 
 I don't know what that means.  Synchronous APIs are one of the major reasons 
 to have Workers in the first place.

Considering the current messaging API and the allowed host APIs, I strongly 
disagree. 



 
 -- 
 Glenn Maynard
 


Re: Synchronous postMessage for Workers?

2011-11-17 Thread Rick Waldron
On Thu, Nov 17, 2011 at 6:50 PM, Glenn Maynard gl...@zewt.org wrote:

 On Thu, Nov 17, 2011 at 6:17 PM, Rick Waldron waldron.r...@gmail.comwrote:

 No, it's not. Messaging should not block either process.


 No, it's perfectly fine to block a worker, as long as the worker
 explicitly requests it and is expecting it.

 I don't know what that means.  Synchronous APIs are one of the major
 reasons to have Workers in the first place.

 Considering the current messaging API and the allowed host APIs, I
 strongly disagree.


 I'm not quite sure what you mean by allowed host APIs, but there are
 lots of synchronous APIs in Workers: File API, Filesystem API, IndexedDB.
 These are all new APIs, not historical accidents (like sync XHR in the UI
 thread).  Synchronous (blocking) APIs in workers is entirely by design, in
 order to allow writing clean, linear code instead of code that has to yield
 to the calling environment all the time.


Sorry, I should've been clearer - I was referring to the renderer-to-worker
messaging API - all event based, all async.

TBH, at this point I'd be more interested in an actual prototype
implementation to see the effects it would have on Worker to Worker
messaging, SharedWorker etc.

Rick




 --
 Glenn Maynard




Re: What type should .findAll return

2011-11-14 Thread Rick Waldron

 [snip]



 ES5.1 clause 8.6.2 says:
The value of the [[Class]] internal property of a host object
 may be any String value except one of Arguments, Array,...
  In other words, host object provides (such as a DOM implementation) are
 not allowed to define new kinds of objects whose [[Class]] is Array.
  It's fine to want to define a new kind of host object that is
 behaviorally very similar (but slight different) from instances of the
 built-in Array constructor.  But characterizing such objects by saying they
 have [[Class]]==Array
   is a not meaningful from a ES5.1 specification perspective.

 I'm fine with any formulation, as long as it gives the correct behaviour
 in cases like Array.prototype.concat and Array.isArray.


ES 5.1 15.4.3.2 Array.isArray()
...
2. If the value of the [[Class]] internal property of arg is Array, then
return true.
...

Considering Allen's previous comment, this is not going to be allowed.

Rick



 Do you have suggestions for what to write?

 / Jonas


Re: What type should .findAll return

2011-11-11 Thread Rick Waldron
Any DOM NodeList/NodeArray could be converted into a real array by passing 
to Array.from( array like )

http://wiki.ecmascript.org/doku.php?id=strawman:array_extras

Avoids creating yet another DOM NodeThing.

/Rick 

On Nov 11, 2011, at 6:57 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Fri, Nov 11, 2011 at 3:07 PM, Allen Wirfs-Brock
 al...@wirfs-brock.com wrote:
 
 On Nov 11, 2011, at 2:16 PM, Jonas Sicking wrote:
 
 On Fri, Nov 11, 2011 at 1:22 PM, Allen Wirfs-Brock
 al...@wirfs-brock.com wrote:
 
 BTW, I think that either the immutable or mutable approach would work.  
 However, since the collection is not live I don't see why you would 
 really care whether or not a client mutated it.  If they want to process 
 it by deleting elements after they are examined, so what?
 
 Exactly, this is why I'm proposing that it should be mutable.
 
 This does still leave the problem of making Array.filter(myNodeArray,
 function(el) { ... }) work though. I.e. I think we'd like it to
 return a NodeArray rather than a plain Array.
 
 This is a problem for ES=5.  Filter and all the other similar 
 Array.prototype functions are specified to produce an object created as if 
 by calling: new Array();
 
 I have a scheme that we can probably get in place for ES.next that would 
 allow filter and friends to produce NodeArray's for you, but I don't see how 
 that helps right now.
 
 Well, if we can get implementations to implement this new scheme for
 the existing filter-like functions at the same time as they implement
 .findAll, then we should be golden.
 
 More importantly, we want myNodeArray.filter(function(el){ ... }) to
 return a NodeArray. This would be doable by putting a special version
 of filter on NodeArray.prototype which would shadow
 Array.prototype.filter.
 
 
 It isn't just filter that creates new instances that you would probably want 
 to be NodeArrays. Also at least(I might have missed other when I just 
 checkeds): concat, slice, splice, map
 
 Indeed, I was just using filter as an example.
 
 Over-riding them explicitly for NodeArray would be an immediate fix, but 
 wouldn't solve the problem for future additions to Array.prototype.  
 However, if you assume that ES.next is going to provide the needed extension 
 mechanism then you should also assume that it will use it for any new 
 Array.prototype methods and they should pretty much just work.
 
 Indeed. If we went down this path we would have to continuously update
 the spec to make NodeArray override any filter-like methods that are
 added to Array.
 
 This would make myNodeArray.filter work, but
 not Array.filter.
 
 An inherent problem with this approach. But if your NodeArrays supplies 
 correctly working over-rides there is probably little reason somebody would 
 try to use the Array.prototype versions  with NodeArrays.
 
 Note that I was saying Array.filter and not Array.prototype.filter. My
 assumption was that if people call Array.prototype with an Array as
 the first argument, they would also do so with a NodeArray as first
 argument.
 
 I don't see a way around this short of modifying the specification of the 
 Array.prototype methods.  That seems like a job for ES.next rather than a 
 DOM spec.
 
 Definitely, hence the cc :)
 
 I'm happy to start a separate thread on es-discuss about this, but I'm
 worried that it'll fragment the current thread.
 
 In theory, public-script-coord exists for exactly this sort of discussion 
 and the ESdiscuss people who care should be subscripted. Rather than 
 starting a new thread, perhaps should should just post to es-discuss a 
 pointer to this thread.
 
 Will do!
 
 / Jonas
 



Re: What type should .findAll return

2011-11-11 Thread Rick Waldron
Right, but I'm saying: why create yet more stuff in the DOM?

 findAll will return a NodeArray while querySelectorAll and friends return 
static and live NodeLists? No thanks.

/Rick 

On Nov 11, 2011, at 8:38 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Fri, Nov 11, 2011 at 5:35 PM, Rick Waldron waldron.r...@gmail.com wrote:
 Any DOM NodeList/NodeArray could be converted into a real array by 
 passing to Array.from( array like )
 
 http://wiki.ecmascript.org/doku.php?id=strawman:array_extras
 
 Avoids creating yet another DOM NodeThing.
 
 Jonas explains very well why we don't want a real Array, but rather
 something that just acts like an Array.
 
 ~TJ



Re: QSA, the problem with :scope, and naming

2011-10-30 Thread Rick Waldron
On Sat, Oct 29, 2011 at 11:28 PM, Cameron McCormack c...@mcc.id.au wrote:

 On 20/10/11 3:50 AM, Alex Russell wrote:

 I strongly agree that it should be an Array *type*, but I think just
 returning a plain Array is the wrong resolution to our NodeList
 problem. WebIDL should specify that DOM List types *are* Array types.
 It's insane that we even have a NodeList type which isn't a real array
 at all. Adding a parallel system when we could just fix the one we
 have (and preserve the value of a separate prototype for extension) is
 wonky to me.

 That said, I'd *also* support the ability to have some sort of
 decorator mechanism before return on .find() or a way to re-route the
 prototype of the returned Array.

 +heycam to debate this point.


 Late replying here again, apologies, but I agree with others who say that
 an actual Array object should be returned from this new API given that it
 is not meant to be live.  What benefit is there from returning a NodeList?


As much as I hate saying this: introducing a third return type would be
counter-productive, as you'd now have live NodeList, static NodeList and
subclassed Array. Congratulations, the cluster-f*ck continues in true form.


Re: A proposal for Element constructors

2011-10-26 Thread Rick Waldron
On Wed, Oct 26, 2011 at 4:33 PM, Cameron McCormack c...@mcc.id.au wrote:

 On 25/10/11 8:54 PM, Adam Barth wrote:

 Another solution to that more than one tag per interface problem is
 to introduce subclasses of those interfaces for each tag.


 Instead of introducing more interfaces (which don't have additional
 functionality), and instead of introducing Element.create, I would rather
 see a pattern like:

  var e = new Element(div, ...);


This exists in the Prototype.js lib (
http://api.prototypejs.org/dom/Element/new/) which has seen massive
abandonment in the past 3-4 years.



 There is no requirement that the object returned from a constructor be an
 object that has the constructor.prototype as its [[Prototype]], so having
 the above constructor return an HTMLDivElement is fine.

 (Also note that the constructor text nodes should be Text rather than
 TextNode, according to the interface name in DOM Core.)




Re: A proposal for Element constructors

2011-10-26 Thread Rick Waldron
As a developer that writes JavaScript every single day, the sheer amount of
typed characters required for using the constructors in this proposal is
enough for me to avoid it at all costs.



On Tue, Oct 25, 2011 at 11:42 PM, Kentaro Hara hara...@chromium.org wrote:

 Hi folks,

 * Background *

 I have been working on making DOM objects look and feel more like ordinary
 JavaScript objects. I implemented Event constructors  [1], for example.


 * Proposal *

 Element.create() has proposed and been under discussion [2]. Besides
 Element.create(), I propose constructors for Elements, like new
 HTMLButtonElement(...), new HTMLDivElement(...) and new
 HTMLVideoElement(...). I think that both Element.create() *and* Element
 constructors are useful.

 For example,

 var button = new HTMLButtonElement( {disabled: true},

 [new TextNode(Click Me!!),

  new Image( {src: http://example.com/xxx.png http://xxx.com/xxx.png} )
 ] );
 document.body.appendChild(button);

 is equivalent to the following HTML:

 button disabled
 Click Me!!
 img src = http://example.com/xxx.png http://xxx.com/xxx.png /
 /button

 As shown in above, the constructor has two arguments. The first one is a
 dictionary of Element properties. The second one is an array of Nodes, which
 become child nodes of the Element.


 * Advantages of Element constructors *

 (a) Better errors when you misspell it
 Element.create(vdieo, {src: ...} ) == No error; HTMLUnknownElement is
 created
 new HTMLVdieoElement( {src: ...} ) == ReferenceError; Stack trace points
 you to the faulty line of code

 (b) Consistency with other constructable DOM objects
 e.g. new XMLHttpRequest(), new Image(), new Event(), new CustomEvent(), new
 MessageEvent(), ...

 (c) Enables to subtype DOM objects in the future
 We are planning to make DOM objects subtype-able, like this:

 function MyButton(text) {
 HTMLButtonElement.call(this);/* (#) */
 this.textContent = text;
 }
 MyButton.prototype = Object.create(HTMLButtonElement.prototype, {...});
 var fancyButton = new MyButton(Click Me!!);

 In order to make the line (#) work, HTMLButtonElement must have a
 constructor.


 * Spec examples *

 interface [
 NamedConstructor(optional HTMLButtonElementInit initDict, optional
 NodeArray children)
 ] HTMLButtonElement : HTMLElement {
 attribute boolean disabled;
 attribute DOMString value;
 ... (omitted)
 }

 dictionary HTMLButtonElementInit : HTMLElementInit {
 boolean disabled;
 DOMString value;
 ... (omitted)
 }

 interface [
 NamedConstructor(optional HTMLElementInit initDict, optional NodeArray
 children)
 ] HTMLElement : Element {
 attribute DOMString lang;
 attribute DOMString className;
 ... (omitted)
 }

 dictionary HTMLElementInit : ElementInit {
 DOMString lang;
 DOMString className;
 ... (omitted)
 }

 interface Element : Node {
 readonly attribute DOMString tagName;
 ... (omitted)
 }

 dictionary ElementInit : NodeInit {
 DOMString tagName;
 ... (omitted)
 }

 interface Node {
 readonly attribute unsigned short nodeType;
 ... (omitted)
 }

 dictionary NodeInit {
 unsigned short nodeType;
 ... (omitted)
 }


 * Discussion

 (a) Element.create() *and* Element constructors?
 I think that both are useful for the reasons that dominicc pointed out in
 [3]. Element.create() is good when we have a tag name in hand, like

 var tag = button;
 Element.create(tag, { }, ...);

 On the other hand, Element constructors have the advantages that I
 described above.

 (b) How to specify properties and attributes in the dictionary argument
 A property and an attribute are two different things [4]. A property is the
 thing that can be set by a setter like foo.value, and an attribute is the
 thing that can be set by foo.setAttribute(). A discussion has been conducted
 on how we can set up properties and attributes in the dictionary argument
 [2]. Proposed approaches in [2] are as follows:

 (b-1) Let a constructor have two dictionaries, one for properties and the
 other for attributes, e.g. new HTMLButtonElement( {disabled: true}, {class:
 myButton, onclick: func}, ...)
 (b-2) Add a prefix character to attributes, e.g new HTMLButtonElement(
 {disabled: true, @class: myButton, @onclick: func} )
 (b-3) Introduce a reserved key attributes, e.g new HTMLButtonElement(
 {disabled: true, attributes: {class: myButton, onclick: func} } )

 Another difficulty around attributes is how to naturally set a value of a
 boolean attribute in the dictionary when we have the value in hand. In case
 of a property, you just need to write like this:

 var b = new HTMLButtonElement({disabled: value});

 However, in case of an attribute, we need to write like this:

 var options = {};
 if (value)
 options.disabled = ;
 var b = new HTMLButtonElement(options);

 Basically, I think that we should keep the succinctness of constructors and
 should 

Re: Is BlobBuilder needed?

2011-10-26 Thread Rick Waldron
var b = new Blob([foo, bar], { contentType: text/plain });

This is really nice looking and feeling. Options objects are definitely a win

/rw



On Oct 26, 2011 7:17 PM, Jonas Sicking lt;jo...@sicking.ccgt; wrote: 

On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. lt;jackalm...@gmail.comgt; 
wrote:

gt; On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai lt;o...@chromium.orggt; 
wrote:

gt;gt; The new API is smaller and simpler. Less to implement and less for web

gt;gt; developers to understand. If it can meet all our use-cases without

gt;gt; significant performance problems, then it's a win and we should do it.

gt;gt;

gt;gt; For line-endings, you could have the Blob constructor also take an 
optional

gt;gt; endings argument:

gt;gt; new Blob(String|Array|Blob|ArrayBuffer 
data,nbsp;[optional]nbsp;String contentType,

gt;gt; [optional] String endings);

gt;

gt; I believe (or at least, I maintain) that we're trying to do

gt; dictionaries for this sort of thing. nbsp;Multiple optional arguments are

gt; *horrible* unless they are truly, actually, order-dependent such that

gt; you wouldn't ever specify a later one without already specifying a

gt; former one.



I don't have a super strong opinion. I will however note that I think

it'll be very common to specify a content-type, but much much more

rare to specify any of the other types. But maybe using the syntax



b = new Blob([foo, bar], { contentType: text/plain })


Thi


isn't too bad. The other properties that I could think of that we'd

want to add sometime in the future would be encoding for strings,

including endianness for utf16 strings.



/ Jonas




Re: Is BlobBuilder needed?

2011-10-24 Thread Rick Waldron
From a real-world developer perpective, this API modification is a win.


On Mon, Oct 24, 2011 at 7:01 PM, Ojan Vafai o...@chromium.org wrote:

 On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:

 Hi everyone,

 It was pointed out to me on twitter that BlobBuilder can be replaced
 with simply making Blob constructable. I.e. the following code:

 var bb = new BlobBuilder();
 bb.append(blob1);
 bb.append(blob2);
 bb.append(some string);
 bb.append(myArrayBuffer);
 var b = bb.getBlob();

 would become

 b = new Blob([blob1, blob2, some string, myArrayBuffer]);


 I like this API. I think we should add it regardless of whether we get rid
 of BlobBuilder. I'd slightly prefer saying that Blob takes varargs and rely
 on ES6 fanciness to expand the array into varargs.

 In theory, a BlobBuilder could be backed by a file on disk, no? The
 advantage is that if you're building something very large, you don't
 necessarily need to be using all that memory. You can imagine a UA having
 Blobs be fully in-memory until they cross some size threshold.


 or look at it another way:

 var x = new BlobBuilder();
 becomes
 var x = [];

 x.append(y);
 becomes
 x.push(y);

 var b = x.getBlob();
 becomes
 var b = new Blob(x);

 So at worst there is a one-to-one mapping in code required to simply
 have |new Blob|. At best it requires much fewer lines if the page has
 several parts available at once.

 And we'd save a whole class since Blobs already exist.

 / Jonas





Re: Proposal for a new Matrix API

2011-10-21 Thread Rick Waldron
On Fri, Oct 21, 2011 at 11:28 AM, João Eiras jo...@opera.com wrote:

 On Thu, 20 Oct 2011 16:39:56 +0200, Igor Oliveira 
 igor.olive...@openbossa.org wrote:

  Hello,

 Currently CSSMatrix and SVGMatrix has an immutable API. None of the
 method calls change the Matrix, instead, it creates a new Matrix with
 the changed value. It can be a problem specially when CSSMatrix is
 used together with WebGL. [1]


 I would suggest that the matrix should not be a host object. Instead is
 should be a pure ecmascript object so it can run closer to the metal (be
 jitted easily).


Assuming you mean native object when you refer to pure ecmascript
object, there is no performance benefit, JIT or otherwise. In fact, it's
possible to implement ES functionality with better performance then the
native implementations.




 I did suggest previously extending array a bit, like

 {length: 6, height: 2, width:3, 0. ..., 1: ..., 2: ..., 3: ..., 4: ..., 5:
 ...,  }

 which represents a 2x3 matrix. The matrix would not have any kind of side
 effects or limitations, possibly being of any arbitrary size, hence usable
 not only by graphical APIs, but by any algebra you throw at it.

 The methods you suggest, would then be on the prototype, or in the Math
 object.