Today, the Web Notifications WG[1] has published a Last Call Working Draft of
the Web Notifications specification:
http://www.w3.org/TR/2013/WD-notifications-20130912/
We're targeting October 24 as the end date for the LC review period.
During the review period, the Web Notifications WG
Isaac said too "So, just to be clear, I'm *not* suggesting that browser
streams copy Node streams verbatim.".
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.
Could you please
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
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here.
-Boris
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> Why is that needed? If we just want this to be generic and all, it seems
> simplest to say that they just get the "length" of "this", then run a counter
> from 0 to length, for each value [[Get]] that property, then [[Invoke]]
> "querySelectorAl
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22997
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 9/12/13 1:09 PM, Domenic Denicola wrote:
Hmm, the issue is, this internal-properties thing is pretty prevalent in ES6
generally. All the built-ins can now be subclassed, and the mechanism in the
spec for that is by giving them internal data properties that are initialized
by their @@create,
On 9/12/13 11:19 AM, Boris Zbarsky wrote:
On 9/12/13 10:27 AM, Anne van Kesteren wrote:
http://dom.spec.whatwg.org/ now includes these methods as well as the
new Elements return value
I would appreciate some discussion on public-script-coord about the IDL
stuff you're making up here.
And in
On Thu, Sep 12, 2013 at 10:58 PM, Aymeric Vitte wrote:
> Apparently we are not talking about the same thing, while I am thinking
> to a high level interface your interface is taking care of the underlying
> level.
>
How much low level stuff to expose would basically affect high level
interface d
On 9/12/13 12:38 PM, Domenic Denicola wrote:
One idea we had for this was as outlined in the gist at [1], where they try to call some
internal "[[QuerySelectorAll]]"-like method of things contained within it
Why is that needed? If we just want this to be generic and all, it
seems simplest to
On Sep 12, 2013 2:16 AM, "Garrett Smith" wrote:
>
> FWD'ing to put my reply back on list (and to others)...
>
> On Sep 11, 2013 6:35 AM, Anne van Kesteren wrote:
>
> As far as I can tell Element.prototype.matches() is not deployed yet.
> Should we instead make selectors first-class citizens, just
On 9/12/13 12:57 PM, Domenic Denicola wrote:
That sounds cool too! I was just concerned it wouldn't be optimizable enough.
I think it depends on what you mean by "enough".
Getting properties out of an array is much faster in script (e.g.
self-hosted) than it is via the C++ API, at least for S
WebApps - the Web Notification WG asked WebApps to review their
September 12 LCWD of Web Notifications:
<http://www.w3.org/TR/2013/WD-notifications-20130912/>
Individual WG members are encouraged to provide individual feedback.
If anyone in WebApps wants to propose an official WG re
The LCWD of File API is http://www.w3.org/TR/FileAPI/
LC comment period is till October 24 2013 -- comments strongly encouraged!
-- A*
On Aug 16, 2013, at 8:35 AM, Arthur Barstow wrote:
> Arun proposed (see below) WebApps publish a Last Call Working Draft of File
> API and this is a Call for C
[ Bcc public-sysapps ; comments from SysApps are welcome ]
This is a Request for Comments for the 12 September 2013 Last Call
Working Draft of File API:
<http://www.w3.org/TR/2013/WD-FileAPI-20130912/>
The comment deadline is October 24 and all comments should be sent to
the public-w
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
> I think it depends on what the "internal properties" bit is and how flexible
> it's supposed to be.
> For example, if in this case the basic operation would be to check for a C++
> Element instance and then call some C++ method with that instance
> And in particular, the spec as written now doesn't clearly define the
> behavior of query() or queryAll(). Presumably they would be defined in some
> generic way (such that they can run with any object as "this"), but it's not
> obvious what that generic way is in this case. This seems like
gument? Especially if you can create your own instances of
> that Array subclass (and you will) it does not seem necessary at all.
Discussing this further, including with Lachy, it turns out we all
agree that is not needed.
http://krijnhoetmer.nl/irc-logs/whatwg/20130912 has the relevant
discussion
Apparently we are not talking about the same thing, while I am thinking
to a high level interface your interface is taking care of the
underlying level.
Like node's streams, node had to define it since it was not existing
(but is someone using node's streams as such or does everybody use the
ches("div").
Thanks for bringing that up here Robin. I added
Element.prototype.matches() to the specification:
http://dom.spec.whatwg.org/#dom-element-matches
See http://krijnhoetmer.nl/irc-logs/whatwg/20130912#l-365 for why it
does not have the refNodes argument anymore.
--
http://annevankesteren.nl/
20 matches
Mail list logo