Hi, DOM3 Events fans-
After much discussion, and having looked for compelling reasons for
keeping them (especially content, implementations, or other
specifications), I have now removed event namespaces from the DOM3
Events specification.
On Wed, Sep 23, 2009 at 9:57 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event delegation library creators chime in on the
details on what is needed for making really efficient
Hi Marcos,
I'm still confused as to why we can't keep both. Is it because of redundancy?
Yes. My personal opinion is that one source of the same information would be
enough. It could be a kind of optimization.
Thanks,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 |
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single querySelectorAll().
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson mike...@hotmail.com wrote:
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event delegation library creators
Lachlan Hunt wrote:
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single
Garrett Smith wrote:
QuerySelector could be extended to have properties:
readonly attribute boolean valid
StaticNodeList match(in HTMLElement contextNode)
What's the valid property for? It seems redundant. If the selector
isn't valid, then the factory method should throw an error when
On Tue, 11 Aug 2009 23:33:04 +0200, Kartikaya Gupta
lists.weba...@stakface.com wrote:
On Mon, 29 Dec 2008 17:24:03 +1100, Charles McCathieNevile
cha...@opera.com wrote:
On Mon, 29 Dec 2008 13:33:35 +1100, Kartikaya Gupta
lists.weba...@stakface.com wrote:
On Mon, 29 Dec 2008 11:30:42
On Sep 23, 2009, at 16:07 , Marcos Caceres wrote:
Robin Berjon wrote:
On Sep 21, 2009, at 20:08 , Marcos Caceres wrote:
5.1
Localization
Shall it be possible for the widget to programmatically discover
the
localization path it was loaded from (section 9 of PC)?
Yes, you can check its
On Sep 23, 2009, at 16:20 , Anne van Kesteren wrote:
On Tue, 25 Aug 2009 17:34:18 +0200, Julian Reschke julian.resc...@gmx.de
wrote:
was it ever discussed to expose information from provisional HTTP
responses (http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.1
) to clients?
Garrett Smith wrote:
On Thu, Sep 24, 2009 at 12:02 AM, Mike Wilson mike...@hotmail.com wrote:
Yes, the base for event delegation is certainly something
like that. I just wanted to make clear that the main reason
for adding this functionality (IMO) is event delegation.
I'll let event
On Sep 23, 2009, at 13:55 , Arthur Barstow wrote:
Below is the draft agenda for the September 24 Widgets Voice
Conference (VC).
My voice doesn't seem to work today, which makes telcons hard. I'll do
my best to get my actions done, and might be there in IRC, but I'm not
really top form
Robin Berjon wrote:
...
I don't think exposing HTTP 1xx status codes has been discussed before.
Actually I recall them being discussed (I think it was at the Rabat f2f)
and there being quick consensus that exposing them wasn't useful.
...
It's a chicken-and-egg problem. If clients aren't
Lachlan Hunt wrote:
Lachlan Hunt wrote:
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
On Wed, 23 Sep 2009 17:56:05 +0200, Adam Barth w...@adambarth.com wrote:
On Wed, Sep 23, 2009 at 5:34 AM, Anne van Kesteren ann...@opera.com
wrote:
For simple cross-origin requests Origin would be a space-separated list
of origins indicating the redirect chain.
When we used this syntax for
Hi Art, All,
I will not be able to attend the call today, since I will be traveling (it just
confirm it).
Ad 6.
I have committed the document with your proposed modifications.
I would vote for FPWD to start the open discussion.
Ad 7.
I do not know the details of Arve's issues, but I assume
The draft minutes from the September 24 Widgets voice conference are
available at the following and copied below:
http://www.w3.org/2009/09/24-wam-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 1 October 2009
On Sep 23, 2009, at 16:51 , Marcos Caceres wrote:
But instead of ignored it says skipped — and it's not clear
whether skipped has the same meaning.
Good point. The second must not be processes because it is not the
first. It don't matter that is serviceable. It might just be that I
used ignore
Sam Ruby wrote:
A concern specific to HTML5 uses WebIDL in a way that precludes
implementation of these objects in ECMAScript (i.e., they can only be
implemented as host objects), and an explicit goal of ECMA TC39 has been
to reduce such. Ideally ECMA TC39 and the W3C HTML WG would jointly
Hello WebApps WG,
The Multimodal Interaction Working Group is working on specifications
that will support distributed applications that include inputs from
different modalities, such as speech, graphics and handwriting. We
believe there's some applicability of specific WebAPI specs such
as
On 9/24/09 4:51 PM, Deborah Dahl wrote:
Hello WebApps WG,
The Multimodal Interaction Working Group is working on specifications
that will support distributed applications that include inputs from
different modalities, such as speech, graphics and handwriting. We
believe there's some
On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
To help prime the pump, here are four topics suggested by ECMA
John Resig wrote:
Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries.
I believe this would be handled using the Array.filter() method, with a
callback that checks if the selector matches the element, as Jonas pointed
Sean Hogan wrote:
http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l-
I couldn't see where it was needed, only that it was possible in jQuery.
I still can't think of any NodeLists that this could usefully be applied
to that couldn't be achieved with a single querySelectorAll(). At least
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique elements.
B) A
I have now specified the approach we discussed:
http://dev.w3.org/2006/waf/access-control/
For simple requests redirects are followed. For other cross-origin
requests they are the equivalent of a network error. The Origin header is
a U+0020-separated list of origins. Each time a redirect
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7720
Summary: Redundant definition of openDatabase methods
Product: WebAppsWG
Version: unspecified
Platform: All
URL: http://dev.w3.org/html5/webdatabase/#databases
OS/Version: All
On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
Maybe this would be a good opportunity to revisit the utility of
WebIDL in specifications (as formal specifications were re-examined
for ES-Harmony). The WebIDL spec is pretty large, and I personally
have found its use a confounding factor
John Resig wrote:
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique
On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:
Is it really true that WebIDL and the vague way DOM2 was described
are the only two options? Surely that's a false dilemma?
I'm not saying those are the only two options. I'm explaining how
WebIDL solves a problem. Are there other ways to
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/24/09 6:29 AM, Sean Hogan wrote:
I would be surprised if an implementation didn't create an internal
lookup table keyed off the selector text.
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on
On Sep 23, 2009, at 8:37 PM, Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 8:17 PM, John Resig jere...@gmail.com wrote:
Quick Summary of my opinions:
Matches Selector: Super-super useful - critical, in fact. We're not
able to
remove jQuery's selector engine until this is implemented. I'm
On 9/24/09 2:17 PM, Garrett Smith wrote:
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu wrote:
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old laptop)
That is probably many times faster, and can probably be much more
liberal,
On 9/24/09 2:36 PM, Sam Weinig wrote:
WebKit now also has an implementation of Element.matchesSelector() (we
are calling ours webkitMatchesSelector for the time being).
[https://bugs.webkit.org/show_bug.cgi?id=29703]
Right. The Gecko one is mozMatchesSelector.
I bet we'd both love to rename
Not quite. It depends what's being done and which steps need to be
performed and how. AIUI, there are 3 major steps involved here.
1. Obtain a collection of Elements. This could be in one or more
Arrays and/or NodeLists, depending on th.
2. Iteratively execute a selector query on all
On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:
On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:
On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
Probably the best thing to do is to provide detailed technical
review of Web IDL via the W3C process.
Expertise on both sides of the
On Sep 24, 2009, at 11:39 AM, Boris Zbarsky wrote:
On 9/24/09 2:36 PM, Sam Weinig wrote:
WebKit now also has an implementation of Element.matchesSelector()
(we
are calling ours webkitMatchesSelector for the time being).
[https://bugs.webkit.org/show_bug.cgi?id=29703]
Right. The Gecko one
On Thu, Sep 24, 2009 at 11:21 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
It would be great to have a separate, standalone, function that handles
these merge/sort/unique operations for collections of DOM elements
(especially if they're disconnected from the document!).
The proposal from
On Thu, Sep 24, 2009 at 8:59 AM, John Resig jre...@mozilla.com wrote:
Another alternative
would be to implement the merge/sort/unique method and have it return a
NodeList (which would, then, have qSA).
For example:
document.createNodeList([ ... some elements ... ]).querySelectorAll(em,
On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:
I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be
My concern with this API is that it forces the implementation to
always sort the array, even if already sorted, and then do a merge
sort on the individual results from querySelectorAll. It would be
faster to simply run the query on each node, and then merge sort the
results.
That's not a
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become Invited
Experts to the W3C Web Applications Working Group, if that facilitates
review.
Unfortunately, no. See #2 and #3 below:
http://www.w3.org/2004/08/invexp.html
On
On 9/24/09 5:09 PM, John Resig wrote:
It's only if it's an array that we have to do the dance. Even in the
case where the array of results is already in document order the sort
will be incredibly fast (O(N)).
O(N) in number of nodes in the array, and that assumes that the array is
not being
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become
Invited
Experts to the W3C Web Applications Working Group, if that
facilitates
review.
Unfortunately, no. See #2 and #3
Maciej Stachowiak wrote:
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become Invited
Experts to the W3C Web Applications Working Group, if that facilitates
review.
2009/9/23 Scott Wilson scott.bradley.wil...@gmail.com:
Hmm, I raised this one too.
I can't see how the origin handles instances exactly, and the concept of
origin doesn't seem all that relevant to our implementation anyway - it
looks more like something for browser makers to worry over?
Why
continuing on from last email
2009/9/16 Scott Wilson scott.bradley.wil...@gmail.com:
I haven't seen any comments yet on this issue?
(This may just be me misunderstanding the intended meaning of origin in
this context.)
On 19 Aug 2009, at 11:42, Scott Wilson wrote:
sue:
5. Storage
2009/9/23 Dominique Hazael-Massieux d...@w3.org:
Hi,
The attribute uri on the access element in WARP is somewhat
misleading - what it takes is more a URL pattern than a URI. I would
suggest renaming it in urlpattern or just pattern (unless there are
already many implementations that rely on
On Thu, Sep 24, 2009 at 2:09 PM, John Resig jre...@mozilla.com wrote:
My concern with this API is that it forces the implementation to
always sort the array, even if already sorted, and then do a merge
sort on the individual results from querySelectorAll. It would be
faster to simply run the
On Sep 24, 2009, at 2:37 PM, Sam Ruby wrote:
Maciej Stachowiak wrote:
On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
Any TC39 members whose employers can't join could perhaps become
Invited
Experts to the W3C Web Applications Working
On Thu, Sep 24, 2009 at 2:41 PM, Jonas Sicking jo...@sicking.cc wrote:
If this is how it's implemented it actually becomes really useful to
have
the NodeList-based element filtering.
document.createNodeList([ ... some elements ...
]).filterSelector(em,
strong)
(Since this
On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:
It seems like this is a Web IDL issue. I don't see any reason for
Web IDL to move to ECMA. It is a nominally language-independent
formalism that's being picked up by many W3C specs, and which
happens to have ECMAScript as one of the
Maybe this would be a good opportunity to revisit the utility of WebIDL in
specifications (as formal specifications were re-examined for ES-Harmony).
The WebIDL spec is pretty large, and I personally have found its use a
confounding factor in understanding other specs (like HTML5).
-- Yehuda
On
Is it really true that WebIDL and the vague way DOM2 was described are the
only two options? Surely that's a false dilemma?
-- Yehuda
On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak m...@apple.com wrote:
On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
Maybe this would be a good
I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be possible to say that this stuff is *only*
for implementors.
On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:
This may be difficult for many reasons, but where the spec ends up
is less important to me (and if you make me choose either-or, I
prefer w3's RF to Ecma's RAND on first principles) than that we
have good collaboration without
Boris Zbarsky wrote:
On 9/24/09 6:29 AM, Sean Hogan wrote:
I would be surprised if an implementation didn't create an internal
lookup table keyed off the selector text.
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old
laptop) parsing the .foo
On Thu, Sep 24, 2009 at 9:00 AM, Anne van Kesteren ann...@opera.com wrote:
I have now specified the approach we discussed:
http://dev.w3.org/2006/waf/access-control/
For simple requests redirects are followed. For other cross-origin requests
they are the equivalent of a network error. The
Lachlan Hunt wrote:
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve
this? If I understand correctly, event delegation just needs to be
able to
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores the selectors in
Hi everyone.
Sam Ruby:
At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.
I'm travelling at the moment, so apologies for the delay in replying.
Unfortunately I
That sounds reasonable. There are really two issues. One is that there are
parts of WebIDL that are unused. Another is that the parts of the spec
themselves are fairly arcane and very implementor-specific. Consider:
interface UndoManager {
readonly attribute unsigned long length;
getter any
On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that
there are parts of WebIDL that are unused. Another is that the parts
of the spec themselves are fairly arcane and very implementor-
specific. Consider:
interface UndoManager {
Boris Zbarsky wrote:
On 9/24/09 6:45 PM, Sean Hogan wrote:
That is surprising. Does the CSS engine do the same? If the CSS engine
doesn't store the parsed selector then it probably doesn't matter for JS
calls either.
In Gecko the CSS engine stores the parsed selector. In addition, it
stores
Hi,
I have checked in the first copy of Selectors API Level 2, and have
defined the matchesSelector() API.
http://dev.w3.org/2006/webapi/selectors-api2/#matchtesting
Everything else in the spec is currently identical to level 1. I had to
do some minor shuffling around to make things
Hi,
I'm trying to find a suitable solution for the scoped selector
issues, but figuring out what the most suitable API is proving challenging.
*Use Cases*
1. JS libraries like JQuery and others, accept special selector strings
beginning with combinators. e.g. em,+strong. These libraries
* Charles McCathieNevile wrote:
More to the point, Bjoern, what is your preferred spelling?
The proper spelling of my name is explicitly specified in RFC 4329.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
On Tue, Sep 15, 2009 at 7:26 AM, Robin Berjon ro...@berjon.com wrote:
The regex could just as easily have been written to exclude the
authority component of the URI. Do you have a better example?
It could have, but it wasn't — interoperability isn't what happens when
people write to a W3C
On Thu, Sep 24, 2009 at 11:38 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/24/09 2:17 PM, Garrett Smith wrote:
On Thu, Sep 24, 2009 at 6:06 AM, Boris Zbarskybzbar...@mit.edu wrote:
Gecko doesn't. Webkit doesn't.
I just checked really quickly, and on my machine (a year-plus old laptop)
70 matches
Mail list logo
