FWD'ing to put my reply back on list (and to others)...
On Sep 11, 2013 6:35 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
var sel
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/
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
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 if you're interested
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 a
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,
[ 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-webapps@w3
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
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 response
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
On Sep 12, 2013 2:16 AM, Garrett Smith dhtmlkitc...@gmail.com wrote:
FWD'ing to put my reply back on list (and to others)...
On Sep 11, 2013 6:35 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
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 Thu, Sep 12, 2013 at 10:58 PM, Aymeric Vitte vitteayme...@gmail.comwrote:
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
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 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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22997
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
Status|NEW |RESOLVED
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]]
querySelectorAll on it.
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
On Fri, Sep 13, 2013 at 5:15 AM, Aymeric Vitte vitteayme...@gmail.comwrote:
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
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
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 would
21 matches
Mail list logo
