date:20130913

From: Boris Zbarsky [mailto:bzbar...@mit.edu] 

> Consider this IDL:
>
>   dictionary Dict1 {
> long a = 5;
>   };
>
>   dictionary Dict2 {
> sequence dicts;
>   }
>
>   void foo(optional Dict2 arg);
>
> How would you express eqivalent semantics with destructuring?

```js
function foo({ dicts: [...dict1s] } = undefined) { }
```

gets pretty close. (`= undefined` is unnecessary, of course, but I include it 
for clarity.) All that remains is some kind of annotation to ensure that every 
element of `dict1s` also gets destructured as `let { a } = dict1s[0]` etc., and 
then type coercion `let numberA = Number(a)`.

> How does destructuring take care of making sure that arg.dicts is a new array?

As you can see this is taken care of.

> How does it ensure arg.dicts[0] is a new object with an "a" property, not 
> whatever was passed in?

Indeed, there is no way to set up a destructuring pattern for every element in 
a sequence, but destructuring is still the approach you will want to use, i.e. 
`let { a } = dict1s[i]` in a loop.

> And in any case it does not do any coercion on arg.dicts[0].a.

Indeed, I think we've said a few times in this thread that the biggest piece 
any IDL needs that is not provided by JS is type coercions.

Re: Selectors: name find method and find signature

On Fri, Sep 13, 2013 at 5:01 PM, Domenic Denicola
 wrote:
> Or "let `returnValue` be `new this.constructor(1, 2, 3)`"?

We already define the return type in IDL. If the return type equals
the class type we could have an annotation that indicates it uses
this.constructor vs it using new.

The filtering of the Elements class for Element objects could be
largely declarative too. If we indicate somehow in IDL what it ought
to be filtered on. Elements<~Element> extends Array or some such. Does
not put actual restrictions on the array, but makes those kind of
things clearer. Of course, you get a bit further from just ES, but
more chance of people doing the right thing and code getting shared.


-- 
http://annevankesteren.nl/

Re: Selectors: name find method and find signature


On 9/13/13 3:19 PM, Domenic Denicola wrote:

From: Boris Zbarsky [mailto:bzbar...@mit.edu]


Consider this IDL:

   dictionary Dict1 {
 long a = 5;
   };

   dictionary Dict2 {
 sequence dicts;
   }

   void foo(optional Dict2 arg);

How would you express eqivalent semantics with destructuring?


```js
function foo({ dicts: [...dict1s] } = undefined) { }
```

gets pretty close. (`= undefined` is unnecessary, of course, but I include it 
for clarity.)


It does?


All that remains is some kind of annotation to ensure that every element of 
`dict1s` also gets destructured


Ah, you mean "the hard part" is all that remains?  ;)  What happens when 
the nesting is deeper?



as `let { a } = dict1s[0]` etc.


No, this doesn't do what.  What's needed here is a "destructuring" 
in-place so that foo ends up with a single object representing "arg" 
that's safe to use and that it can pass to other functions that want to 
work with it.  That's what WebIDL gives me right now and what 
destructuring most emphatically does not do.  With destructuring the 
best that can be done is to manually break the input up into its 
component pieces and then rebuild it from scratch.


Now obviously destructuring can be an implementation strategy for 
implementing the current WebIDL behavior, but what WebIDL does right now 
does not just turn into some simple destructuring one-liner.



How does destructuring take care of making sure that arg.dicts is a new array?


As you can see this is taken care of.


No, it's not.  that I can see.  What I end up with in the function is a 
variable called "dicts1", which is an array.  I end up with a variable 
called "dicts" which is also an array (but not a "safe" one).  What I 
don't end up with is an object named "arg" which is a safe object and 
which has a property named "dicts" which is a safe array.



How does it ensure arg.dicts[0] is a new object with an "a" property, not 
whatever was passed in?


Indeed, there is no way to set up a destructuring pattern for every element in 
a sequence, but destructuring is still the approach you will want to use, i.e. 
`let { a } = dict1s[i]` in a loop.


Again, that's a reasonable implementation strategy, but it's something I 
don't want people to have to write by hand every time given that there's 
a perfectly simple declarative way of describing this sort of 
datastructure, and then we can auto-generate the boilerplate 
destructuring and rematerializing bits.  Because when doing it by hand, 
it's too easy to forget to do it...


-Boris

Re: Selectors: name find method and find signature

On 9/13/13 2:46 PM, Domenic Denicola wrote:

Thanks Boris, this is indeed all very helpful. I just wanted to point out that what you are calling
"dictionaries" is largely covered by what I called "destructuring," on the
input side at least. E.g.

Furthermore, privileged code should never be working with raw page-provided ES
objects, because doing that makes confused-deputy scenarios impossible to avoid
in practice. For example, dictionaries that will be operated on by privileged
script first need to be coerced to a new clean object with a sane proto chain,
only value properties, and the values themselves coerced to be safe to work
with. To the extent that we do not have a way to specify or perform such a
coercion, we have a problem.

I believe this is almost entirely taken care of by destructuring.

Consider this IDL:

dictionary Dict1 {
long a = 5;
};

dictionary Dict2 {
sequence dicts;
}

void foo(optional Dict2 arg);

How would you express eqivalent semantics with destructuring? How does
destructuring take care of making sure that arg.dicts is a new array?
How does it ensure arg.dicts[0] is a new object with an "a" property,
not whatever was passed in? And in any case it does not do any
coercion on arg.dicts[0].a.

This is not a hypothetical setup; there are WebRTC APIs that want
behavior akin to this.

Or am I just completely out of touch with what destructuring can do
nowadays?

Aside from that, much appreciate you spelling out what you find most important,
and I think we're on the same page there.

Good, good. ;)

-Boris

Re: Making selectors first-class citizens

On Wed, Sep 11, 2013 at 7:54 PM, Francois Remy  wrote:
> A lot of code now rely on a prefixed or unprefixed version of
> `matchesSelector` as this has shipped in an interoperable fashion in all
> browsers now.

Unprefixed?


-- 
http://annevankesteren.nl/

Re: RfC: LCWD of Web Notifications; deadline October 24

2013-09-13 Thread Marcos Caceres




On Thursday, September 12, 2013 at 5:19 PM, Arthur Barstow wrote:

> WebApps - the Web Notification WG asked WebApps to review their 
> September 12 LCWD of Web Notifications:
> 
> 
> 
> Individual WG members are encouraged to provide individual feedback.
> 
> If anyone in WebApps wants to propose an official WG response, please do 
> so ASAP, in reply to this e-mail so the WG can discuss it.
> 
> Comments should be sent to public-web-notificat...@w3.org by October 24.

The link to the Editor's draft seems bad in the published version.

The actual Editor's draft is here, I think:

http://notifications.spec.whatwg.org/

RE: Selectors: name find method and find signature

Thanks Boris, this is indeed all very helpful. I just wanted to point out that 
what you are calling "dictionaries" is largely covered by what I called 
"destructuring," on the input side at least. E.g.

> Furthermore, privileged code should never be working with raw page-provided 
> ES objects, because doing that makes confused-deputy scenarios impossible to 
> avoid in practice.  For example, dictionaries that will be operated on by 
> privileged script first need to be coerced to a new clean object with a sane 
> proto chain, only value properties, and the values themselves coerced to be 
> safe to work with.  To the extent that we do not have a way to specify or 
> perform such a coercion, we have a problem.

I believe this is almost entirely taken care of by destructuring.

Aside from that, much appreciate you spelling out what you find most important, 
and I think we're on the same page there.

RE: Selectors: name find method and find signature

From: Boris Zbarsky [mailto:bzbar...@mit.edu] 

> None of those affect the common pitfalls people run into.

Really? Argument defaulting and destructuring, at the very least, seems like 
something that's historically been done many different and un-ESey ways. As has 
been defining classes with constructors and classes that can be inherited from. 
What common pitfalls would you be thinking of?

> The benefit of using a declarative language is that it lets optimal-speed 
> macro-code be generated for the various JS implementations...  This is not a 
> benefit to throw away lightly.  As in, I expect UAs to continue to use such 
> declarative languages internally no matter what the specs are doing.

Certainly. There's no desire to create something that's not useful to 
implementers. But, how would you declaratively specify something like "iterate 
over `iterable`, performing the following steps"? Or "let `returnValue` be `new 
this.constructor(1, 2, 3)`"? These are algorithmic pieces, not annotations to 
the return type or incoming arguments. As their side effects are observable, 
they often need to occur in the middle of algorithms, not up front.

I ask these questions in earnest, to be clear. I want a useful JSIDL, or 
WebIDL: The Evolution. What implementers want is a large part of that. So:

- What common pitfalls does WebIDL help you avoid, that fall outside the realm 
of class definitions/argument defaulting/argument destructuring/type coercions?
- How would you propose creating declarative forms for observable algorithmic 
steps?

Re: Selectors: name find method and find signature


On 9/13/13 12:01 PM, Domenic Denicola wrote:

Really? Argument defaulting and destructuring, at the very least


Is typically not used in web specs until very recently.


As has been defining classes with constructors and classes that can be 
inherited from.


Classes with constructors, agreed.  Most web specs so far have not 
defined classes that can be inherited from, so it hasn't been a pitfall, 
exactly, more of an annoyance.



What common pitfalls would you be thinking of?


Not defining order of argument coercions/checks.  Not defining 
interoperable handling of dictionary and arraylike inputs.  Not defining 
behavior of various arraylikes and hashlikes.



Certainly. There's no desire to create something that's not useful to implementers. But, 
how would you declaratively specify something like "iterate over `iterable`, 
performing the following steps"?


That depends.  WebIDL has 
http://dev.w3.org/2006/webapi/WebIDL/#es-sequence for the special case 
of "iterate over arraylike, performing type coercions".


What you might want in practice is prose describing the iteration (as 
here) and then declarative syntax for invoking that prose (e.g. 
sequence means you do the sequence steps, with the Foo steps at the 
point where the sequence steps are parametrized over Foo).


That's obviously more limited than being able to invoke an arbitary 
algorithm, but also addresses a slightly different use case.  Which one 
is more common, we'll see.



Or "let `returnValue` be `new this.constructor(1, 2, 3)`"?


I'd need to see this in the context of an actual algorithm to answer 
this question.  It depends.



As their side effects are observable, they often need to occur in the middle of 
algorithms, not up front.


Why not up front?  This is a serious question.

The way type coercions in WebIDL work right now is that they're done up 
front, and then operations mostly occur on objects without observable 
side-effects of any sort.


This is also how jquery handles things in many cases; see the extend({}, 
argument) stuff sprinkled all over it at the starts of methods.


This obviously doesn't work in all cases, but it works in quite a number 
of them.  And it reduces the chance of algorithms or data structures 
ending up in inconsistent states, since any operation that has side 
effects can typically throw, and if your algorithm can throw at random 
points in the middle you have to be a _lot_ more careful how you write it.



- What common pitfalls does WebIDL help you avoid, that fall outside the realm 
of class definitions/argument defaulting/argument destructuring/type coercions?


1) Return value creation.  For example, naive code people write to 
return a dictionary-like things or arrays sets properties on the return 
value via [[Set]] instead of defineProperty.


2) Clear definitions of the behavior for things with named/indexed 
getters/setters.  Maybe you include that under "class definitions"?  But 
the key here is that it's just one keyword to opt into a pretty 
complicated class of behavior, whereas doing this with an ES6 class, 
even is possible, would require per-class boilerplate.


But the meat of the benefits is in what you call "type coercions". 
There's more to it than just "end up with the right type".  E.g. if I 
have a method that takes a Node, then after I'm done with the type 
coercion I have an object that I can then operate on without triggering 
random side-effects on property access or whatnot, so my .textContent 
getter doesn't have to worry that getting the firstChild will do 
something wacky.  This is especially important if you have code that has 
elevated privileges (whether it be C++ or Rust or privileged JS) 
operating on these objects: in that situation it's critical to present a 
sanitized view of the object, which can only behave in certain very 
limited ways, to the code in question.  Otherwise you end up with 
confused-deputy security bugs all over the place.


Basically, my goal as an implementor, based on years of experience 
observing other implementors, is that someone implementing a DOM method 
should not have to know either the ins and outs of the ES spec or the 
details of the APIs for the browser's JS implementation.  Especially 
because both are in fairly constant flux.  Any time an implementor has 
to deal with those two (fairly large) cognitive burdens in addition to 
the (already large) cognitive burden of whatever the browser's internal 
representation for DOM objects is, they end up getting it wrong.  That 
includes fairly experienced implementors, not just new folks.


A good rule of thumb is that if a method implementor has to manually 
invoke anything in [[]] they will probably get it wrong.


Furthermore, privileged code should never be working with raw 
page-provided ES objects, because doing that makes confused-deputy 
scenarios impossible to avoid in practice.  For example, dictionaries 
that will be operated on by privileged script first need to be c

Re: Selectors: name find method and find signature


On 9/13/13 11:50 AM, Boris Zbarsky wrote:

As in, I expect UAs to continue to use such declarative languages internally no
matter what the specs are doing.


And if the expectation is correct, there is value on only doing the 
mapping from behavior to declarative once in the open instead of each UA 
doing it on their own and ending up with bugs.


-Boris

Re: Selectors: name find method and find signature


On 9/13/13 11:22 AM, Domenic Denicola wrote:

Ideally, ES6 will give most of the "macros" needed, in the form of class 
syntax, default arguments, and destructuring argument lists. It's not all you need, 
certainly, but it does obviate a lot of WebIDL


None of those affect the common pitfalls people run into.


Apart from that, the remaining idiomatic patterns will look a lot more like, as 
you say, macros, instead of declarative interface-definition language.


The benefit of using a declarative language is that it lets 
optimal-speed macro-code be generated for the various JS 
implementations...  This is not a benefit to throw away lightly.  As in, 
I expect UAs to continue to use such declarative languages internally no 
matter what the specs are doing.


-Boris

RE: Selectors: name find method and find signature

From: Boris Zbarsky [mailto:bzbar...@mit.edu] 

>> TC39 and like-minded people are pushing in the direction of the platform 
>> being mostly a JavaScript library which would indeed give you exactly those 
>> problems...

> Why?

> There is no reason we can't have macros for commonly used ES-style patterns 
> that people can use by reference in specs.  That's supposed to be the purpose 
> of WebIDL.

There's a few aspects of this. Ideally, ES6 will give most of the "macros" 
needed, in the form of class syntax, default arguments, and destructuring 
argument lists. It's not all you need, certainly, but it does obviate a lot of 
WebIDL, the largest remaining piece being type conversions, which Yehuda 
already made a very rough and incomplete start at [1].

Apart from that, the remaining idiomatic patterns will look a lot more like, as 
you say, macros, instead of declarative interface-definition language. For 
example, some kind of macro to indicate "iterate over this incoming iterable 
and/or array-like, and perform the following steps, but throw if not 
`IsObject(putativeIterable)`". Or one to indicate "let returnValue be `new 
this.constructor(...args)`". Or "if `x` is outside the range `y` to `z`, throw 
a `RangeError`".

Now that I write this, I am reminded of the "shorthand phrases" I added for 
promise specs [2]. Hmm.

[1]: http://wycats.github.io/jsidl/jsidl.html
[2]: 
https://github.com/domenic/promises-unwrapping/blob/master/writing-specifications-with-promises.md#shorthand-phrases

Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-09-13 Thread James Greene

Also, will there be any way for us to feature detect when this is available?

I'm thinking that just using `document.queryCommandSupported("copy")` and
`document.queryCommandEnabled("copy")` could return some false positives
(i.e. the feature is not yet implemented but returns `true` anyway) when
the user is working within a "contenteditable" element, right?

Sincerely,
James Greene

On Fri, Sep 13, 2013 at 10:10 AM, James Greene wrote:

> Excellent.  Thank you!
>
> Should we be including touch device events, too?  e.g. "touchend",
> "pointerup", etc.
>
> Sincerely,
> James Greene
>
>
>
> On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen wrote:
>
>> >> AFAIK Flash shipped with a more liberal model first, but the abuse
>> problem
>> >> was considered significant enough to tighten the model and make it more
>> >> restrictive.
>>
>> > That's correct:
>> >   - In Flash 9, you could use the
>> > `System.setClipboard<
>> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
>> > /System.html#setClipboard()>`
>>
>> Thanks for outlining the history and documentation. I think we should
>> give authors (at least) the same convenience as Flash does. Reported here:
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
>>
>> -Hallvord (in "I will try to get around to actually updating the spec
>> too"-mode)
>>
>
>

Re: Selectors: name find method and find signature


On 9/13/13 10:58 AM, Anne van Kesteren wrote:

On Fri, Sep 13, 2013 at 3:53 PM, Boris Zbarsky  wrote:

OK, fwiw I think I agree.  The next question is whether they should be
generic in the elements of the collection or not too.


I don't really follow this. Are you talking about
Element.prototype.query? That should probably mimic other methods on
Element for now. Until we figure out the branding story and
subclassing etc.


I mean whether the generic code does myarr[i].querySelectorAll() or 
whether it does CanonicalElementProto.querySelectorAll.call(myArr[i]) or 
whether it does 
CanonicalElementProto.canonicalQuerySelectorAll.call(myArr[i]), going in 
order from most generic to least generic.  Or something else.



Well you said things were broken. I was wondering what the extent of
the brokenness was.


I said underspecified, right?

I think we've covered the various underspecification bits in this thread 
already: there's the question of how to get items from the collection 
and the question of how to get new collections from the items.


-Boris

Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-09-13 Thread James Greene

Excellent.  Thank you!

Should we be including touch device events, too?  e.g. "touchend",
"pointerup", etc.

Sincerely,
James Greene



On Fri, Sep 13, 2013 at 4:12 AM, Hallvord Steen  wrote:

> >> AFAIK Flash shipped with a more liberal model first, but the abuse
> problem
> >> was considered significant enough to tighten the model and make it more
> >> restrictive.
>
> > That's correct:
> >   - In Flash 9, you could use the
> > `System.setClipboard<
> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system
> > /System.html#setClipboard()>`
>
> Thanks for outlining the history and documentation. I think we should give
> authors (at least) the same convenience as Flash does. Reported here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
>
> -Hallvord (in "I will try to get around to actually updating the spec
> too"-mode)
>

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Aymeric Vitte



Le 13/09/2013 15:11, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte > wrote:



Le 13/09/2013 14:23, Takeshi Yoshino a écrit :

Do you mean that those data producer APIs should be changed to
provide read-by-delta-data, and manipulation of data by js code
should happen there instead of at the output of Stream?


Yes, exactly, except if you/someone see another way of getting the
data inside the browser and turning the flow into a stream without
using these APIs.


I agree that there're various states and things to handle for each of 
the producer APIs, and it might be judicious not to convey such API 
specific info/signal through Stream.


I don't think it's bad to convert xhr.DONE to stream.close() manually 
as in your example 
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html.


But, regarding flow control, as I said in the other mail just posted, 
if we start thinking of flow control more seriously, maybe the right 
approach is to have unified flow control method and the point to 
define such a fine-grained flow control is Stream, not each API.


Maybe, I was not at the start of this thread too so I don't know exactly 
what was the original idea (and hope I am not screwing it up here). But 
I am not sure it's possible to define a universal flow control.


Example: I am currently experiencing some flow control issues for 
project [1], basically the sender reads a file AsArrayBuffer from 
indexedDB where it's stored as a Blob. Since we can not get delta data 
while reading the File for now, the sender waits for having the whole 
ArrayBuffer, then slices it, processes the blocks and sends them via 
WebSockets. If you implement a basic loop, of course you overload the 
sender's UA and connection. So the system makes some calculation in 
order to allow only half of the bandwidth to be used, aggregate the 
blocks until it finds out that the size of the aggregation meets the 
bandwidth requirement for the aggregated blocks to be sent every 50ms.


Then it uses a poor setTimeout to flush the data which screw up all the 
preceding calculations since setTimeout fires whenever it likes. Maybe 
there are smarter ways to do this, I was thinking to use workers so you 
can get a more precise clock via postMessages but I did not try.


In addition to the bandwidth control there is a window for flow control.

I take this example to understand if this could be better with a 
built-in Stream flow control, if so, after you have defined the right 
parameters (if possible) for the streams flow control, you could process 
delta data while reading the file and restream them directly via 
WebSockets, and this would be great but again not sure that a universal 
solution can be found.



If we're not, yes, maybe your proposal (deltaResponse) should be enough.


What is sure is that delta data should be made available instead of 
incremental ones.


[1] http://www.peersm.com

--
jCore
Email :  avi...@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Re: Selectors: name find method and find signature

On Fri, Sep 13, 2013 at 3:53 PM, Boris Zbarsky  wrote:
> OK, fwiw I think I agree.  The next question is whether they should be
> generic in the elements of the collection or not too.

I don't really follow this. Are you talking about
Element.prototype.query? That should probably mimic other methods on
Element for now. Until we figure out the branding story and
subclassing etc.

>> Anything other than these aspects?
>
> Not sure what you're asking.

Well you said things were broken. I was wondering what the extent of
the brokenness was.

-- 
http://annevankesteren.nl/

Re: Selectors: name find method and find signature


On 9/13/13 10:49 AM, Anne van Kesteren wrote:

On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky  wrote:

In any case, my real questions revolve around generic vs branded methods and
whatnot, which are not covered by those two bugs.


I think they should be generic


OK, fwiw I think I agree.  The next question is whether they should be 
generic in the elements of the collection or not too.



Because IDL doesn't really deal well with this.constructor-type stuff
and generic methods.


Sure, but that's something to fix in IDL.


Updating IDL to make that work have proper
terminology hooks is fine for me too.


Good.  That's what I'd like to see, and what should imo happen on 
public-script-coord.



The IDL specification style is a lot less error-prone to implement for
non-JS-engine-hackers than the ES specification style, for what it's worth,
since it allows implementors to work with objects that have sane behavior in
the implementation language, not whatever weird behavior the js engine API
imposes...


TC39 and like-minded people are pushing in the direction of the
platform being mostly a JavaScript library which would indeed give you
exactly those problems...


Why?

There is no reason we can't have macros for commonly used ES-style 
patterns that people can use by reference in specs.  That's supposed to 
be the purpose of WebIDL.



I'm not really sure how to reconcile those two views.


Like I just said above.


Anything other than these aspects?


Not sure what you're asking.

-Boris

Re: Selectors: name find method and find signature

On Fri, Sep 13, 2013 at 3:22 PM, Boris Zbarsky  wrote:
> In any case, my real questions revolve around generic vs branded methods and
> whatnot, which are not covered by those two bugs.

I think they should be generic, just like the methods on Array which
this object inherits from. That's why we want to return
this.constructor for queryAll too rather than just an Elements array.

>> (One even questions using IDL for this at all
>
> Why?

Because IDL doesn't really deal well with this.constructor-type stuff
and generic methods. Updating IDL to make that work have proper
terminology hooks is fine for me too.

> The IDL specification style is a lot less error-prone to implement for
> non-JS-engine-hackers than the ES specification style, for what it's worth,
> since it allows implementors to work with objects that have sane behavior in
> the implementation language, not whatever weird behavior the js engine API
> imposes...

TC39 and like-minded people are pushing in the direction of the
platform being mostly a JavaScript library which would indeed give you
exactly those problems... I'm not really sure how to reconcile those
two views.

> It's also a lot less error-prone for spec writers.  I'll note that the
> methods added here are totally underspecified at the moment.

Anything other than these aspects?

-- 
http://annevankesteren.nl/

Re: Making selectors first-class citizens

2013-09-13 Thread Francois Remy

For the record, I'm equally concerned about renaming `matchesSelector` into 
`matches`.

A lot of code now rely on a prefixed or unprefixed version of `matchesSelector` 
as this has shipped in an interoperable fashion in all browsers now.

I don't mind adding a new `matches` function that would take a Selector as an 
argument, or simply consider matchesSelector as a deprecated API and recommend 
to use Selector going forward, with a polyfill for older browsers, but I 
believe renaming `matchesSelector` at this time is a dangerous idea. The other 
option to keeping `matchesSelector` as is is to continue to ship the prefixed 
versions forever which seems a bad idea to me.

-- standardize what's implemented, implement what's standardized.

Re: Selectors: name find method and find signature


On 9/13/13 4:14 AM, Anne van Kesteren wrote:

There's two IDL bugs referenced from the specification that have
public-script-coord copied. What am I missing?


Hmm.  I didn't see those bugmails go by; maybe they got filtered out by 
my "html bugs" filters.  :(


In any case, my real questions revolve around generic vs branded methods 
and whatnot, which are not covered by those two bugs.



(One even questions using IDL for this at all


Why?

The IDL specification style is a lot less error-prone to implement for 
non-JS-engine-hackers than the ES specification style, for what it's 
worth, since it allows implementors to work with objects that have sane 
behavior in the implementation language, not whatever weird behavior the 
js engine API imposes...


It's also a lot less error-prone for spec writers.  I'll note that the 
methods added here are totally underspecified at the moment.



Defining something like
[[QueryAll]] as a thing on Element seems problematic too though, given
how Element is defined today.)


I'm not sure what you mean.

-Boris

Reminder: TTWF-Shenzhen Nov 9, F2F Meeting Nov 11-12, TP Meeting Nov 13

2013-09-13 Thread Arthur Barstow

Hi All - three threads about TPAC 2013 and WebApps' November 11-12 in 
Shenzhen.


1. WebApps meeting November 11-12:

* You Must register for the meeting 



* WebApps meeting page 
. Input on the 
agenda is of course welcome (but feel free to directly edit this page). 
I have  been thinking about setting aside some portion of Tuesday Nov 12 
for test case writing so any comments on that idea are welcome (perhaps 
all of Tuesday afternoon).


* WebApps' registration list 



2. Test the Web Forward November 9.

TTWF is hosting an event in Shenzhen on Saturday November 9. 
Registration for this event isn't open yet and I will forward that 
information when it is available.


Rebecca and the TTWF group welcome WebApps members to attend, especially 
those that can help `newbies` write tests. I believe James Graham is 
going to help with the event so I thank James in advance for his 
continued efforts! If other WebApp'ers can help, please let me know.


3. Technical Plenary meeting on Wednesday November 13.

The agenda for the Technical Plenary meeting is still a WIP but is 
roughly divided into two parts: fixed/predetermined agenda in the 
morning and unconference style parallel breakout sessions in the afternoon:


* AM Fixed Agenda 
 - if you 
have any feedback on the morning's predetermined agenda, send it to 
member-tpac-plann...@w3.org (and cc www-arch...@w3.org if you want 
Public visibility).


* PM Parallel Session - proposals for these sessions are put in the 
"Session Ideas" wiki 
. 
If you have a proposal, add it directly to this wiki document. My 
expectation is that meeting participants will be able to propose 
sessions at the meeting.


-Thanks, AB


 Original Message 
Subject:Registration for TPAC 2013 is Open
Resent-Date:Wed, 26 Jun 2013 15:55:08 +
Resent-From:
Date:   Wed, 26 Jun 2013 19:54:34 +0400
From:   ext Charles McCathie Nevile 
Organization:   Yandex
To: public-webapps WG 



Hi folks, (forwarded...)

Webapps is planning to meet at TPAC.

Registration for TPAC2013 is now open:

 TPAC 2013
 11-15 November
 Shenzhen, China
 http://www.w3.org/2013/11/TPAC/

(that page includes information about visas, and getting an invitation -
which many people will need in order to get a visa).

1) Register:
   https://www.w3.org/2002/09/wbs/35125/TPAC2013/

   NOTE: Many people are required to have a visa for entry into China.
   Please see the registration form for information about securing an
   invitation letter from Beihang University for a Chinese visa to
attend
   TPAC 2013.

2) Make your hotel reservation:
   http://www.w3.org/2013/11/TPAC/#Accommodation

   NOTE: The TPAC 2013 organizers have secured a special guest room
rate
   at the Shenzhen Wuzhou Guest House (the venue). The special rate
   expires 10 October 2013.

If you have any questions, please contact Angel Li .

--
On registration and registration fees
--

There is a daily registration fee. The per person, per day fee is:

* 60 USD if registration and payment completed by 18 October 2013;
* 120 USD otherwise.

As in the past, registration is a two-step process:

1) completing a registration form:
   https://www.w3.org/2002/09/wbs/35125/TPAC2013/

2) using a payment system. We are using a new payment system for TPAC 2013.
   Upon registration you will receive an email with payment
instructions.

   NOTE: The payment system will be available shortly; you may still
   register right away and you will be notified automatically once the
   payment system becomes available.

For more information about registration fees (including who is not
required to pay registration fees) and the payment system, see
  http://www.w3.org/2013/11/TPAC/#Registration

--
Camp-style Plenary Day
--

We plan to organize the plenary day camp-style, as we did last year.
We encourage you to propose breakout sessions in our wiki:
  http://www.w3.org/wiki/TPAC2013/SessionIdeas

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino

On Fri, Sep 13, 2013 at 9:50 PM, Aymeric Vitte wrote:

>
> Le 13/09/2013 14:23, Takeshi Yoshino a écrit :
>
> Do you mean that those data producer APIs should be changed to provide
> read-by-delta-data, and manipulation of data by js code should happen there
> instead of at the output of Stream?
>
>
>
> Yes, exactly, except if you/someone see another way of getting the data
> inside the browser and turning the flow into a stream without using these
> APIs.
>

I agree that there're various states and things to handle for each of the
producer APIs, and it might be judicious not to convey such API specific
info/signal through Stream.

I don't think it's bad to convert xhr.DONE to stream.close() manually as in
your example
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html.

But, regarding flow control, as I said in the other mail just posted, if we
start thinking of flow control more seriously, maybe the right approach is
to have unified flow control method and the point to define such a
fine-grained flow control is Stream, not each API. If we're not, yes, maybe
your proposal (deltaResponse) should be enough.

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino

Since I joined discussion recently, I don't know the original idea behind
the Stream+XHR integration approach (response returns Stream object) as in
current Streams API spec. But one advantage of it I come up with is that we
can keep change to those producer APIs small. If we decide to add methods
for example for flow control (though it's still under question), such stuff
go to Stream, not XHR, etc.

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Aymeric Vitte



Le 13/09/2013 14:23, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 6:08 PM, Aymeric Vitte > wrote:


Now you want a stream interface so you can code some js like
mspack on top of it.

I am still missing a part of the puzzle or how to use it: as you
mention the stream is coming from somewhere (File, indexedDB,
WebSocket, XHR, WebRTC, etc) you have a limited choice of APIs to
get it, so msgpack will act on top of one of those APIs, no? (then
back to the examples above)

How can you get the data another way?


Do you mean that those data producer APIs should be changed to provide 
read-by-delta-data, and manipulation of data by js code should happen 
there instead of at the output of Stream?


Yes, exactly, except if you/someone see another way of getting the data 
inside the browser and turning the flow into a stream without using 
these APIs.


Regards,

Aymeric

--
jCore
Email :  avi...@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Takeshi Yoshino

On Fri, Sep 13, 2013 at 6:08 PM, Aymeric Vitte wrote:

> Now you want a stream interface so you can code some js like mspack on top
> of it.
>
> I am still missing a part of the puzzle or how to use it: as you mention
> the stream is coming from somewhere (File, indexedDB, WebSocket, XHR,
> WebRTC, etc) you have a limited choice of APIs to get it, so msgpack will
> act on top of one of those APIs, no? (then back to the examples above)
>
> How can you get the data another way?
>

Do you mean that those data producer APIs should be changed to provide
read-by-delta-data, and manipulation of data by js code should happen there
instead of at the output of Stream?

Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

2013-09-13 Thread Hallvord Steen

>> AFAIK Flash shipped with a more liberal model first, but the abuse problem
>> was considered significant enough to tighten the model and make it more
>> restrictive.

> That's correct:
>   - In Flash 9, you could use the
> `System.setClipboard /System.html#setClipboard()>`

Thanks for outlining the history and documentation. I think we should give 
authors (at least) the same convenience as Flash does. Reported here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235

-Hallvord (in "I will try to get around to actually updating the spec too"-mode)

Re: Overlap between StreamReader and FileReader

2013-09-13 Thread Aymeric Vitte

Here for the examples: 
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0453.html


Simple ones leading to a simple Streams interface, I thought this was 
the spirit of the original Streams API proposal.


Now you want a stream interface so you can code some js like mspack on 
top of it.


I am still missing a part of the puzzle or how to use it: as you mention 
the stream is coming from somewhere (File, indexedDB, WebSocket, XHR, 
WebRTC, etc) you have a limited choice of APIs to get it, so msgpack 
will act on top of one of those APIs, no? (then back to the examples above)


How can you get the data another way?

Regards,

Aymeric

Le 13/09/2013 06:36, Takeshi Yoshino a écrit :
On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte > wrote:


Isaac said too "So, just to be clear, I'm **not** suggesting that
browser streams copy Node streams verbatim.".


I know. I wanted to kick the discussion which was stopped for 2 weeks.

Unless you want to do node inside browsers (which would be great
but seems unlikely) I still don't see the relation between this
kind of proposal and existing APIs.


What do you mean by "existing APIs"? I was thinking that we've been 
discussing what Stream read/write API for manual consuming/producing 
by JavaScript code should be like.


Could you please give an example very different from the ones I
gave already?


Sorry, which mail?

One of what I was imaging is protocol parsing. Such as msgpack, 
protocol buffer. It's good that ArrayBuffers of exact size is obtained.


OTOH, as someone pointed out, Stream should have some flow control 
mechanism not to pull unlimited amount of data from async storage, 
network, etc. readableSize in my proposal is an example of how we make 
the limit controllable by an app.


We could also depend on the size argument of read() call. But thinking 
of protocol parsing again, it's common that we have small fields such 
as 4, 8, 16 bytes. If read(size) is configured to pull size bytes from 
async storage, it's inefficient. Maybe we could have some hard coded 
limit, e.g. 1MiB and use max(hardCodedLimit, requestedReadSize).


I'm fine with the latter.

You have reverted to EventTarget too instead of promises, why?


There was no intention to object against use of Promise. Sorry that I 
wasn't clear. I'm rather interested in receiving sequence of data as 
they become available (corresponds to Jonas's ChunkedData version read 
methods) with just one read call. Sorry that I didn't mention 
explicitly, but listeners on the proposed API came from ChunkedData 
object. I thought we can put them on Stream itself by giving up 
multiple read scenario.


writeable/readableThreshold can be safely removed from the API if we 
agree it's not important. If the threshold stuff are removed, flush() 
and pull() will also be removed.




--
jCore
Email :  avi...@jcore.fr
Peersm : http://www.peersm.com
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :www.jcore.fr
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com

[Bug 23234] New: Mark document response entity body as HTML document

2013-09-13 Thread bugzilla

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

Bug ID: 23234
   Summary: Mark document response entity body as HTML document
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
  Assignee: ann...@annevk.nl
  Reporter: ann...@annevk.nl
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

And maybe also do content type and other things. Hmm...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Clipboard API: Default content in copy/cut handlers

2013-09-13 Thread Hallvord Steen

> - Cancelling the event can result in one of two things:
>  - If event.clipboardData is empty, nothing happens. The system
> clipboard does not change. Here, the spec differs from how browsers
> behave so I've chosen to document how browsers behave. Neither Firefox
> nor Chrome let you clear the contents of the clipboard by calling
> event.clipboardData.clearData(). IMO, we should update the spec to
> reflect this.

I've reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=23232 to make sure 
I don't forget this issue even though I'll mark your mail as read  now ;-)
-Hallvord

Re: Selectors: name find method and find signature