CfC: Event Namespaces Removed
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. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [selectors-api] Summary of Feature Requests for v2
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 discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. Note that what makes the strong, em selector (which apparently some libraries support) hard to support spec-wise is that that is not in fact valid CSS syntax. It's certainly possible to define behavior for it, it's pretty clear to me how it's intended to work, but it would mean specifying our own syntax. However if supporting commaseparated queries is critical for libraries then I see no other choise. We'll one way or another have to specify our own syntax, though it can be heavily based on the productions in the Selector spec. I think we can define an algorithm for turning an implicitly scoped pseudo-selector like strong, em into a proper selector using :scope -- in this case :scopestrong, :scopeem. We could either have an API entry point that takes a scoped pseudo-selector, defined as transforming to a real selector plus establishing a scope node, or just present the algorithm as an option for libraries that want to expose pseudo-selector syntax. Indeed, it's certainly possible. I'd like to find out if we can get away with not doing that though. I'm curious to get feedback on how far just having a :scope pseudo-class gets us. / Jonas
RE: [selectors-api] Summary of Feature Requests for v2
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
behavioural/delegation implementations, and judge the merits
of various optimizations. There has f ex already been mention
of caching parsed selectors.
Best regards
Mike
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
check whether the event target element matches a given
selector. So it
would be something like:
if (evt.target.matchesSelector(.fooinput.bar)) {
...
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf
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 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Wednesday, September 23, 2009 6:15 PM To: Marcin Hanclik Cc: Arthur Barstow; public-webapps Subject: Re: [widgets] Draft Agenda for 24 September 2009 Voice Conf On Wed, Sep 23, 2009 at 4:36 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi, One more comment to the below: There is one use case not handled by the below scenarios: In case the width/height are dropped on the Widget interface, the widget would not know the initial dimensions. E.g. in Win32 each new window get WM_SIZE event with the initial width/height. However, I am not sure whether we should mandate the ResolutionChangedEvent to be used for the initial viewport size. So I would opt for keeping the ResolutionChangedEvent, dropping width/height on the ResolutionChangedEvent, and keeping width/height in the Widget interface. I'm still confused as to why we can't keep both. Is it because of redundancy? -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [selectors-api] Summary of Feature Requests for v2
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().
It was discussed a couple of days ago in IRC. It's based on the
functionality provided and needed by javascript libraries.
Garrett Smith wrote:
Lachlan Hunt wrote:
div2.matchesSelector(:scope~div, div1);
The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.
A function to get an actual Selector object would allow the program to
creating a cached matcher.
var selector = QuerySelector.create(div.panel);
var isPanel = selector.matches(event.target);
That's an interesting concept. We could perhaps define something like this:
Interface DocumentSelector {
Selector createSelector(DOMString selector, [Element scopeElement,
[boolean impliedScope]]);
}
Interface Selector {
boolean matches(Node element);
}
And overload the querySelector() and querySelectorAll() methods to also
accept a Selector object as the selector parameter.
createSelector would allow the browser to parse and compile the selector
and store it, much like createExpression does in DOM 3 XPath. If a
contextElement is provided, then that element is defined as the Scope
Element that matches the :scope pseudo-class. If impliedScope is set to
false, the the browser treats it as an ordinary selector. If it's set
to true, then it's treated as an implicitly scoped selector that needs
to be pre-parsed into a valid selector and imply the presence of :scope
(like em, strong).
A possible extension to consider would be to also allow scopeElement to
be specified as an array or NodeList of elements, such that :scope will
match any of the elements in the elements in the array, instead of
limiting it to just one.
Scripts can then do this:
var selector = document.createSelector(em,strong, elm, true);
Or this:
var selector = document.createSelector(h1+:scopea, [elm1, elm2,
elm3], false);
And then pass that selector to querySelector*() like
document.querySelectorAll(selector)
And matchesSelector is handled like this:
document.createSelector(input[type=checkbox]).matches(evt.target);
John Resig wrote:
Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.
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 out:
filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector(someselector); });
(That could also work with the above Selector.matches() proposal)
If I can do:
document.querySelectorAll.call([document.getElementById(node1),
document.getElementById(node2)], div span); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).
So this means that defining the API directly on NodeLists wouldn't
handle the use cases dealing with arrays of elements, so the
NodeList.querySelectorAll() idea is out.
Perhaps on the Selector interface described above, we could also define:
Interface Selector {
boolean matches(Node element);
NodeList querySelector(DOMArray nodes)
NodeList querySelectorAll(DOMArray nodes)
}
(where nodes either accepts an Array or a NodeList containing a
collection of Document, Element or DocumentFragment nodes)
Then when these methods are run, they iteratively run querySelector() or
querySelectorAll() on each of the nodes in the collection, using the
selector and then return the result as a NodeList containing the union
of unique elemenets in document order.
e.g.
var selector = document.createSelector(input);
selector.querySelectorAll([elm1, elm2, elm3]);
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
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 chime in on the
details on what is needed for making really efficient
behavioural/delegation implementations, and judge the merits
of various optimizations. There has f ex already been mention
of caching parsed selectors.
The benefit to that is that the selector text is parsed once, so
something like:-
document.onmouseover = function(ev) {
if(ev.target.matchesSelector(.infotip)) { /*...*/ }
};
could probably be made more efficient as:-
var selector = QuerySelector.create(.infotip);
document.onmouseover = function(ev) {
if(selector.matches(ev.target)) { /*...*/ }
};
The type of context where a QuerySelector object would be useful are
described above. That could be abstracted to a factory pattern that
uses selector to match nodes in a delegated event and lazily construct
a wrapper.
QuerySelector could be extended to have properties:
readonly attribute boolean valid
StaticNodeList match(in HTMLElement contextNode)
Garrett
Re: [selectors-api] Summary of Feature Requests for v2
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 querySelectorAll(). It was discussed a couple of days ago in IRC. It's based on the functionality provided and needed by javascript libraries. Sorry, I forgot to provide the link. The relevant discussion is spread out quite a bit throughout this log, beginning here. http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l- I've highlighted the relevant parts. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
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 it tries to create it. Otherwise, it will be valid. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [progress events] editorial fixes and module
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 +1100, Charles McCathieNevile cha...@opera.com wrote: Please review and send brickbats, comments, etc. ... 3. The description for the totalArg parameter of initProgressEvent says ... the value of this parameter is not a non-negative number Why not just say ... the value of this parameter is a negative number ...? (redundant double negative removal). All agreed and fixed. I'll put out another version in a few days that includes all these changes. The loadedArg parameter has the same not a non-negative number double-negative that should probably be fixed. Fixed. Also, the two operations defined in the IDL are missing the semi-colon after the argument list as required by WebIDL. Fixed. I would also like to know which module the ProgressEvent interface will end up in, so I can generate Java bindings appropriately. For now I'm assuming it will go into org.w3c.dom.events since that seems to be the appropriate place IMO. Yes, that makes sense to me... And finally, is there a timeline for pushing this spec forward? It hasn't been touched for the last 5 months, and I would like to see this spec move somewhere rather than die a death of apathy like so many specs have... even a publication from editor's draft to a new WD would be better than nothing :) Yes. I want to get last call out at or before TPAC, so will be trying to get it done... cheers and thanks Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [AE] Last Call comments (2): discovery localization
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 URI. If the implementation supports the window object, then it possible. How? window.location will return widget:///foo.html irrespective of whether the runtime loaded /foo.html or /locales/fr/foo.html. Ah, ok. Yes, forgot about that. Well, the best we can do is give the lang list that the UA is using? Ideas? is this really important? I can see it being useful to know where stuff is being loaded from instead of having to guess where a resource was loaded from. I wouldn't call it important enough that it would have to happen in v1. Basic functionality would be to expose the UA's known preferred locales, but I don't think that's for us to define (it seems like a perfect candidate for the navigator object). If you want to make it useful in our model you need to be able to find the locale of a given resource, which in turn requires a uriToLocale() method. I think that it's a lot of work for something that won't be used (though of course that could be said of pretty much the entire locale system :~). Maybe in v2 we can improve this (e.g. also with a setLocale() call so widgets can expose a UI to change language) but for the time being I'd recommend not doing it — the cost-benefit ratio isn't worth it and we shouldn't do something just for completeness' sake, we're not in the elegance business. -- Robin Berjon - http://berjon.com/
Re: XHR request state vs provisional responses
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? That might become interesting once extensions such as http://tools.ietf.org/html/draft-decroy-http-progress-00 ever get deployed... 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. -- Robin Berjon - http://berjon.com/
Re: [selectors-api] Summary of Feature Requests for v2
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 delegation library creators chime in on the
details on what is needed for making really efficient
behavioural/delegation implementations, and judge the merits
of various optimizations. There has f ex already been mention
of caching parsed selectors.
The benefit to that is that the selector text is parsed once, so
something like:-
document.onmouseover = function(ev) {
if(ev.target.matchesSelector(.infotip)) { /*...*/ }
};
could probably be made more efficient as:-
var selector = QuerySelector.create(.infotip);
document.onmouseover = function(ev) {
if(selector.matches(ev.target)) { /*...*/ }
};
I would be surprised if an implementation didn't create an internal
lookup table keyed off the selector text.
At Risk - 24 September 2009 Voice Conf
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 today. -- Robin Berjon - http://berjon.com/
Re: XHR request state vs provisional responses
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 able to see them, there's little incentive to define useful 1xx headers (such as, as recently discussed, for progress reports on long-running requests). BR, Julian
Re: [selectors-api] Summary of Feature Requests for v2
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 achieved with a single querySelectorAll(). It was discussed a couple of days ago in IRC. It's based on the functionality provided and needed by javascript libraries. Sorry, I forgot to provide the link. The relevant discussion is spread out quite a bit throughout this log, beginning here. http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l- I've highlighted the relevant parts. 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 until we can create arbitrary NodeLists.
Re: CORS redirect behavior proposal
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 the Sec-From header, Mark Nottingham advocated using commas to separate the origins to better align with other HTTP headers. That would also allow multiple headers to be used I think. Since Access-Control-Allow-Origin needs to have an identical value to the Origin header I do not think that would work well. Well, it would probably work, but would make all the processing a lot more complicated than it needs to be. (I'd prefer it to just be a simple string comparison.) What order would be best there? I think the simplest thing is to list the origins in the order in which the user agent encounters them (with adjacent duplicates removed). That sounds reasonable. This is more or less on what I'm planning to go with (will wait a day or so with specifying to allow for feedback) unless someone has a better idea that keeps things relatively simple and works with the preflight result cache. That sounds reasonable to me. I don't quite understand all the constraints we get from the preflight cache, but the rest sounds fine. We do not really get constraints, but it just does not work with redirects at the moment. To explain this: BAR redirects to BAZ BAR and BAZ grants FOO access Now when FOO requests BAR a cache entry is stored for BAZ. However, the next time FOO requests BAR the cache entry for BAZ is not used. I guess to make this work a series of request URLs has to be stored rather than just the final one. In addition origin has to become a list too. And even with this I'm afraid I'm still missing a lot of subtle things. Deferring this to later seems acceptable though so I'll leave that out for now. (Unless someone comes up with a design that does consider all these things.) -- Anne van Kesteren http://annevankesteren.nl/
RE: [widgets] Draft Agenda for 24 September 2009 Voice Conf
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 they are related to orientation event. Rotation may probably provide more info (e.g. more exact angles etc.), though. The VM interfaces draft is quite buggy now, but we could start discussing it as well (e.g. orientation is not defined). Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, September 23, 2009 1:56 PM To: public-webapps Subject: [widgets] Draft Agenda for 24 September 2009 Voice Conf Below is the draft agenda for the September 24 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2009/09/17-wam-minutes.html -Regards, Art Barstow Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration = 90 minutes Zakim Bridge = +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN = 9231 (WAF1); IRC channel = #wam; irc://irc.w3.org:6665 Confidentiality of minutes = Public Regrets: Marcos, Marcin, Josh Agenda: 1. Review and tweak agenda 2. Announcements a. News/summary from the Widget Testing event http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 3. Widget Interface spec: proposal to publish LCWD #2 http://dev.w3.org/2006/waf/widgets-api/ 4. Access Requests Policy (WARP) spec: comment period ended Sept 20; review comments http://dev.w3.org/2006/waf/widgets-access/ http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- access-20090804/ 5. URI Scheme spec: status of LC publication http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ 6. View Modes Media Features spec: proposal to publish FPWD http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html 7. View Modes Interfaces spec: Arve (from IRC) the bit that troubles me is rotation http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html 8. AOB Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
[widgets] Draft Minutes for 24 September 2009 Voice Conference
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 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 24 Sep 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1199.html See also: [3]IRC log [3] http://www.w3.org/2009/09/24-wam-irc Attendees Present Arve, Jere, AndyB, Frederick, Art, Steven, Benoit Regrets Josh, Marcin, Marcos, Robin Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]News/summary from the Widget Testing event 4. [8]widget Interface spec: 5. [9]WARP spec: proposal by Dom to change uri attribute to urlpattern; 6. [10]URI Scheme spec: status 7. [11]VM Media Features spec: proposal to publish FPWD 8. [12]AOB * [13]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 24 September 2009 Review and tweak agenda AB: draft agenda was posted on Sep 23 ( [14]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/11 99.html ). During the widget Interface topic we will record the recent exchanges between Marcos and Marcin as well as the origin thread from Scott Wilson as a way of capturing ongoing discussions but we won't deep dive on them given Marcos will not be here today. [14] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1199.html Arve: since Marcin and Marcos aren't here, we should probably drop the VM-I spec today AB: agree ... so given all of the Regrets, we will have a short call today Announcements AB: any short annoucements? [ None ] News/summary from the Widget Testing event AB: a widget testing event was held Sep 21-23 ( [15]http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 ). Does anyone have a summary or news they can share? ... since none of the event's participants are here today, we'll skip this [15] http://www.w3.org/2008/webapps/wiki/TestWorkshop2009 widget Interface spec: AB: Marcin and Marcos continue to discuss this thread ( [16]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 17.html ). ... Marcin and Marcos continue to discuss this thread ( [17]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 08.html ). ... the last email in this thread is from Scott ( [18]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 20.html ). One question here is origin of a widget versus instance of widget. ... given Marcos isn't here today, we will drop this now but please continue to discuss this on public-webapps [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1217.html [17] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1208.html [18] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1220.html WARP spec: proposal by Dom to change uri attribute to urlpattern; AB: Dom proposed ( [19]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 02.html ) the access element's uri attribute be changed to urlpattern citing some related work done by the POWDER WG. Any comments? [19] http://lists.w3.org/Archives/Public/public-webapps/ 2009JulSep/1202.html Arve: I'm unsure ... technically, he's probably right ... I agree it describes a URL pattern ... but I am skeptical to this change AB: given Marcin isn't here today, we will drop this now but please reply to this proposal on public-webapps JK: Dom had another suggestion and that was just pattern ... I prefer pattern to urlpattern Arve: let's take this to the mail list ... I need to do some investigation as I can't reach the POWDER document right now URI Scheme spec: status AB: without Robin here today, we'll skip this for today VM Media Features spec: proposal to publish FPWD AB: last week we agreed that today we consider if the VM-MF spec was ready for FPWD ( [20]http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html ). Marcin responded earlier today ( [21]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 52.html ) that he votes for FPWD. ... since then, Robin submitted some comment ( [22]http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/12 54.html ). Robin, are any of these mandatory before
Re: skipping and ignoring
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 where skip was intended. That's not a very strong versioning approach. If the second element is not taken into account, then we have a potential problem with forward compatibility. Let's imagine that we have v2 out, for which the following is correct: content uri='http://berjon.com/cool-widgets/dahut'/ content src=perfectly-good-start-file.html/ Clearly the desired behaviour is for v2 runtimes to process the first, and v1 runtimes to fallback to the second. IMO the correct behavior would be for src attributes to take URIs and for the second to be skipped. However, I'm sure you can dream up other examples. Yes, I can. The only ever use the first, even if b0rked behavior is based on HTML's behavior (particularly the title element). I'm happy to break ranks with HTML parsing if that is what the WG thinks would be best. However, it's a pretty big change to the parsing model, but if it future proofs us, then it might be worth it. HTML has that behaviour to unify the mess that browsers are — there's a rationale there. We don't have to stick to the same thing because we really don't have that baggage. And thankfully this affects not at all the parsing model, but only processing — which is a lot easier. Furthermore I'm not convinced it's a change — we'd have to ask implementers which one they picked. The same issue applies to other elements that refer to the skip/ ignore distinction. We believe that some editorial improvements to those definitions would be welcome. Agreed. I'll work on improving those but that depends on if we change the parsing behavior or not to match what you suggested above. The definitions need to be improved either way. I don't have a strong opinion as to whether the change should go through or not so long as it's clarified. The modification concerns cases that aren't all that common. I have a preference for the more versioning-friendly approach of just skipping (which is also slightly simpler to implement since you don't need to remember anything). But if it risks being considered substantial I don't want it. -- Robin Berjon - http://berjon.com/
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 develop guidance on developing web APIs, and the W3C HTML WG would apply that guidance in HTML5. Meanwhile, I would encourage members of ECMA TC 39 who are aware of specific issues to open bug reports: http://www.w3.org/Bugs/Public/ And I would encourage members of the HTML WG who are interested in this topic to read up on the following emails (suggested by Brendan Eich): https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. Would it be possible to summarise the known issues in an email (or on a wiki page or something)? I read those threads and it was unclear to me which specific points are considered outstanding problems with the HTML5/WebIDL specs.
Multimodal Interaction WG questions for WebApps (especially WebAPI)
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 XMLHttpRequest and Server-sent Events to our use cases and we're hoping to get some comments/feedback/suggestions from you. Here's a brief overview of how Multimodal Interaction and WebAPI specs might interact. The Multimodal Architecture [1] is a loosely coupled architecture for multimodal user interfaces, which allows for co-resident and distributed implementations. The aim of this design is to provide a general and flexible framework providing interoperability among modality-specific components from different vendors - for example, speech recognition from one vendor and handwriting recognition from another. This framework focuses on providing a general means for allowing these components to communicate with each other, plus basic infrastructure for application control and platform services. The basic components of an application conforming to the Multimodal Architecture are (1) a set of components which provide modality-related services, such as GUI interaction, speech recognition and handwriting recognition, as well as more specialized modalities such as biometric input, and (2) an Interaction Manager which coordinates inputs from different modalities with the goal of providing a seamless and well-integrated multimodal user experience. One use case of particular interest is a distributed one, in which a server-based Interaction Manager (using, for example SCXML [2]) controls a GUI component based on a (mobile or desktop) web browser, along with a distributed speech recognition component. Authoring Applications for the Multimodal Architecture [3] describes this type of an application in more detail. If, for example, speech recognition is distributed, the Interaction Manager receives results from the recognizer and will need to inform the browser of a spoken user input so that the graphical user interface can reflect that information. For example, the user might say November 2, 2009 and that information would be displayed in a text field in the browser. However, this requires that the server be able to send an event to the browser to tell it to update the display. Current implementations do this by having the brower poll for the server for possible updates on a frequent basis, but we believe that a better approach would be for the browser to actually be able to receive events from the server. So our main question is, what mechanisms are or will be available to support efficient communication among distributed components (for example, speech recognizers, interaction managers, and web browsers) that interact to create a multimodal application,(hence our interest in server-sent events and XMLHttpRequest)? [1] MMI Architecture: http://www.w3.org/TR/mmi-arch/ [2] SCXML: http://www.w3.org/TR/scxml/ [3] MMI Example: http://www.w3.org/TR/mmi-auth/ Regards, Debbie Dahl MMIWG Chair
Re: Multimodal Interaction WG questions for WebApps (especially WebAPI)
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 applicability of specific WebAPI specs such as XMLHttpRequest and Server-sent Events to our use cases and we're hoping to get some comments/feedback/suggestions from you. Here's a brief overview of how Multimodal Interaction and WebAPI specs might interact. The Multimodal Architecture [1] is a loosely coupled architecture for multimodal user interfaces, which allows for co-resident and distributed implementations. The aim of this design is to provide a general and flexible framework providing interoperability among modality-specific components from different vendors - for example, speech recognition from one vendor and handwriting recognition from another. This framework focuses on providing a general means for allowing these components to communicate with each other, plus basic infrastructure for application control and platform services. The basic components of an application conforming to the Multimodal Architecture are (1) a set of components which provide modality-related services, such as GUI interaction, speech recognition and handwriting recognition, as well as more specialized modalities such as biometric input, and (2) an Interaction Manager which coordinates inputs from different modalities with the goal of providing a seamless and well-integrated multimodal user experience. One use case of particular interest is a distributed one, in which a server-based Interaction Manager (using, for example SCXML [2]) controls a GUI component based on a (mobile or desktop) web browser, along with a distributed speech recognition component. Authoring Applications for the Multimodal Architecture [3] describes this type of an application in more detail. If, for example, speech recognition is distributed, the Interaction Manager receives results from the recognizer and will need to inform the browser of a spoken user input so that the graphical user interface can reflect that information. For example, the user might say November 2, 2009 and that information would be displayed in a text field in the browser. However, this requires that the server be able to send an event to the browser to tell it to update the display. Current implementations do this by having the brower poll for the server for possible updates on a frequent basis, but we believe that a better approach would be for the browser to actually be able to receive events from the server. So our main question is, what mechanisms are or will be available to support efficient communication among distributed components (for example, speech recognizers, interaction managers, and web browsers) that interact to create a multimodal application,(hence our interest in server-sent events and XMLHttpRequest)? I believe WebSockets could work a lot better than XHR or server-sent events. IM would be a WebSocket server and it would have bi-directional connection to modality components. -Olli [1] MMI Architecture: http://www.w3.org/TR/mmi-arch/ [2] SCXML: http://www.w3.org/TR/scxml/ [3] MMI Example: http://www.w3.org/TR/mmi-auth/ Regards, Debbie Dahl MMIWG Chair
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 TC39 for discussion. On these and other topics, there is no need to wait for the TPAC, discussion can begin now on the es-discuss mailing list. - - - The current WebIDL binding to ECMAScript is based on ES3... this needs to more closely track to the evolution of ES, in particular it needs to be updated to ES5 w.r.t the Meta Object Protocol. In the process, we should discuss whether this work continues in the W3C, is done as a joint effort with ECMA, or moves to ECMA entirely. 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Probably the best thing to do is to provide detailed technical review of Web IDL via the W3C process. - - - 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 develop guidance on developing web APIs, and the W3C HTML WG would apply that guidance in HTML5. Meanwhile, I would encourage members of ECMA TC 39 who are aware of specific issues to open bug reports: http://www.w3.org/Bugs/Public/ And I would encourage members of the HTML WG who are interested in this topic to read up on the following emails (suggested by Brendan Eich): https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). - - - There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html . I'm not sure what the other concerns about execution scope are - seems hard to discuss fruitfully without more detail. - - - We should take steps to address the following willful violation: If the script's global object is a Window object, then in JavaScript, the this keyword in the global scope must return the Window object's WindowProxy object. This is a willful violation of the JavaScript specification current at the time of writing (ECMAScript edition 3). The JavaScript specification requires that the this keyword in the global scope return the global object, but this is not compatible with the security design prevalent in implementations as specified herein. [ECMA262] Wasn't ES5 fixed to address this? I know the feedback was passed along. Regards, Maciej
Re: [selectors-api] Summary of Feature Requests for v2
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
out:
filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector(someselector); });
(That could also work with the above Selector.matches() proposal)
Array.filter() will meet the need of filtering
NodeLists/StaticNodeLists/Arrays of Elements - sure - but it won't meet the
need of NodeList.querySelectorAll (especially if that works with an
array-like collection of DOM elements).
Right, but I'm dealing with that as an entirely separate issue, which I
disucssed later on in that email.
Basic filtering of nodelists is bug 5864, which I've resolved WONTFIX
for now because the functionality doesn't seem too desirable or beneficial.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
The issue you're discussing is bug 7707, which is still open.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
The problem is that when you have multiple collections of DOM elements and
you wish to reduce them to a single collection it ends up being a very
expensive task. The steps are as follows:
- The collections must be merged together into a single array of DOM
elements.
- The elements must be sorted to be in document order.
- Duplicate elements must be removed from the collection.
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 more generic API for being able to easily merge and sort
NodeLists/Arrays of elements.
Option A saves the step of having to run the queries on each individual
element manually and just returns a merged and sorted collection of
unique elements. But it's limited to running selector queries, rather
than any other getElementsBy*() method to obtain the results.
Option B is more generic in that it could potentially merge and sort any
set of NodeLists, and those NodeLists could be obtained by any method,
but would still require running the queries on each element individually
to obtain the the lists that then need to be merged.
Both options present an issue with sorting, since they could result in
lists that contain both connected and disconnected elements, and the
sort order for connected elements in relation to disconnected elements
would need to be defined.
Option B seems potentially harder to define and possibly implement,
especially if you want to be able to sort merge NodeList objects with
Array objects. Since Arrays aren't limited to just containing DOM
Nodes, the issue of what to do with other types objects and how to sort
them along with the Nodes is complicated.
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 my previous mail falls into Option A. Would it
address this issue adequately? Specifically, defining
document.createSelector() and a Selector interface that allows running a
query like this:
var elements = [...] // Some Array (or NodeList) of Elements
var selector = document.createSelector(em, strong);
var list = selector.querySelectorAll(elements);
This is equivalent to iterating over the elements array, running
elements[i].querySelectorAll(em, strong) on each, and then
merging/sorting all of the results into a single collection.
If there was a merge/sort/unique method it would drop the need for having a
NodeList/Array.querySelectorAll.
Whether we should go for the extra complexity required for this really
depends on the use case you're trying to address. Do you just need to
merge NodeLists that are all obtained via querySelector methods, or do
you need to merge any random NodeLists or Arrays that could be obtained
via querySelector*() or getElementsBy*(), or wherever else.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
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 until we can create arbitrary NodeLists. It would simplify the issues that John described in his last e-mail, but the exact use cases aren't entirely clear which is making finding and determining the most appropriate solution difficult. I'm hoping John can answer this question. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
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 more generic API for being able to easily merge and sort NodeLists/Arrays of elements. Option A saves the step of having to run the queries on each individual element manually and just returns a merged and sorted collection of unique elements. But it's limited to running selector queries, rather than any other getElementsBy*() method to obtain the results. Option B is more generic in that it could potentially merge and sort any set of NodeLists, and those NodeLists could be obtained by any method, but would still require running the queries on each element individually to obtain the the lists that then need to be merged. Both options present an issue with sorting, since they could result in lists that contain both connected and disconnected elements, and the sort order for connected elements in relation to disconnected elements would need to be defined. Option B seems potentially harder to define and possibly implement, especially if you want to be able to sort merge NodeList objects with Array objects. Since Arrays aren't limited to just containing DOM Nodes, the issue of what to do with other types objects and how to sort them along with the Nodes is complicated. B is a subset of A. You need B in order to implement A. Ideally we could have both options (A for the obvious cases where you already have a NodeList and which to do another query against the results, which would be faster than manually going through the results and doing B). Whereas B is needed in its own right (as I outlined before). 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 my previous mail falls into Option A. Would it address this issue adequately? Specifically, defining document.createSelector() and a Selector interface that allows running a query like this: var elements = [...] // Some Array (or NodeList) of Elements var selector = document.createSelector(em, strong); var list = selector.querySelectorAll(elements); This is equivalent to iterating over the elements array, running elements[i].querySelectorAll(em, strong) on each, and then merging/sorting all of the results into a single collection. Not a huge fan of that - it seems really backwards. 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, strong); createNodeList would create a NodeList holding the DOM nodes in document order (with duplicates removed). Since it's a proper NodeList we could then use qSA to find the elements that we want. 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 would be much faster than using Array.filter or some other method.) If there was a merge/sort/unique method it would drop the need for having a NodeList/Array.querySelectorAll. Whether we should go for the extra complexity required for this really depends on the use case you're trying to address. Do you just need to merge NodeLists that are all obtained via querySelector methods, or do you need to merge any random NodeLists or Arrays that could be obtained via querySelector*() or getElementsBy*(), or wherever else. The latter, absolutely. These results could be coming from anywhere - and could even be coming from non-query methods (like the aforementioned .parents() method in jQuery which does its own ancestor traversal). --John
Re: CORS redirect behavior proposal
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 takes place an origin is added to the origin chain if it is not the same as the last origin that was added. The Access-Control-Allow-Origin header needs to be identical to the value of the Origin header, octet-for-octet. Let me know if I missed anything or if the draft is unclear. On Thu, 24 Sep 2009 13:17:09 +0200, Anne van Kesteren ann...@opera.com wrote: That would also allow multiple headers to be used I think. Since Access-Control-Allow-Origin needs to have an identical value to the Origin header I do not think that would work well. Well, it would probably work, but would make all the processing a lot more complicated than it needs to be. (I'd prefer it to just be a simple string comparison.) What order would be best there? I think the simplest thing is to list the origins in the order in which the user agent encounters them (with adjacent duplicates removed). That sounds reasonable. -- Anne van Kesteren http://annevankesteren.nl/
[Bug 7720] New: Redundant definition of openDatabase methods
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
Status: NEW
Severity: normal
Priority: P2
Component: Web Database
AssignedTo: i...@hixie.ch
ReportedBy: nikunj.me...@oracle.com
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
There seems to be no difference between the openDatabase methods defined in
WindowDatabase and WorkerUtilsDatabase.
It is possible to restructure these interfaces differently so that there is
less redundancy. My proposal is the following IDL:
[Supplemental, NoInterfaceObject]
interface DatabaseAsyncOpen {
Database openDatabase(in DOMString name, in DOMString version, in DOMString
displayName, in unsigned long estimatedSize, in optional DatabaseCallback
creationCallback);
};
Window implements DatabaseAsyncOpen;
[Supplemental, NoInterfaceObject]
interface DatabaseSyncOpen {
DatabaseSync openDatabaseSync(in DOMString name, in DOMString version, in
DOMString displayName, in unsigned long estimatedSize, in optional
DatabaseCallback creationCallback);
};
WorkerUtils implements DatabaseSyncOpen;
WorkerUtils implements DatabaseAsyncOpen;
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 in understanding other specs (like HTML5). Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse- engineering. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-2-Core/ -- Yehuda On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com wrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark- glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch- all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html . Thanks for the links, I was aware of these but hadn't read them. Mandatory try-locks in JS, just say no. I'm not sure what the other concerns about execution scope are - seems hard to discuss
Re: [selectors-api] Summary of Feature Requests for v2
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 elements. B) A more generic API for being able to easily merge and sort NodeLists/Arrays of elements. Option A saves the step of having to run the queries on each individual element manually and just returns a merged and sorted collection of unique elements. But it's limited to running selector queries, rather than any other getElementsBy*() method to obtain the results. Option B is more generic in that it could potentially merge and sort any set of NodeLists, and those NodeLists could be obtained by any method, but would still require running the queries on each element individually to obtain the the lists that then need to be merged. B is a subset of A. You need B in order to implement A. 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 elements in the collection, saving the results from each. 3. Merge and sort all elements into a single NodeList, removing duplicates. In order to understand which of those steps need to be optimised by the browser with new APIs, it would help if you could explain some typical tasks, or use cases, that would need to perform any or all of those steps. In particular, what type of task would lead to there being more than one Array and/or NodeList to be used as input to step 2? What type of task would require executing the same selector query over a whole collection of elements? And what task would require the results of those to be merged into a single list? 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 my previous mail falls into Option A. Would it address this issue adequately? Specifically, defining document.createSelector() and a Selector interface that allows running a query like this: var elements = [...] // Some Array (or NodeList) of Elements var selector = document.createSelector(em, strong); var list = selector.querySelectorAll(elements); This is equivalent to iterating over the elements array, running elements[i].querySelectorAll(em, strong) on each, and then merging/sorting all of the results into a single collection. Not a huge fan of that - it seems really backwards. Could you elaborate? Another alternative would be to implement the merge/sort/unique method and have it return a NodeList (which would, then, have qSA). The collection of elements (step 1, above) input into the qSA step (step 2) wouldn't need to be a sorted list. Technically, it doesn't even necessarily have to be a merged list if the API allows multiple arrays and/or nodelists to be provided. It will have no effect on the result. The important point seems to be that a collection of elements can be provided somehow and that the implementation can execute the query on each distinct element in that collection. How exactly that is done is just an API design issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 solve the problem? Probably. Do you have a specific proposal? Regards, Maciej -- 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 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). Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-2-Core/ -- Yehuda On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com wrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark- glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads:
Re: [selectors-api] Summary of Feature Requests for v2
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 my machine (a year-plus old laptop) That is probably many times faster, and can probably be much more liberal, than an optimized browser running on a mobile device with 128 MB RAM.
Re: [selectors-api] Summary of Feature Requests for v2
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 working with the devs at Mozilla to get an implementation landed. Already have a test suite in place. And we have a patch :) So this should be available in Firefox 3.6 I hope. 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 ] -Sam
Re: [selectors-api] Summary of Feature Requests for v2
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, than an optimized browser running on a mobile device with 128 MB RAM. Did I imply it's slow? I just listed approximate hardware so that the times can be placed in some sort of context. that said, note that on a mobile device with 128 MB of RAM the RAM is a lot more likely to be a problem than the CPU in some ways. Running out of memory is strictly worse than being a little bit slower. So a lookup table may be more of a loss than a win, depending. -Boris
Re: [selectors-api] Summary of Feature Requests for v2
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 it... ;) -Boris
Re: [selectors-api] Summary of Feature Requests for v2
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 elements in the
collection, saving the results from each.
3. Merge and sort all elements into a single NodeList, removing
duplicates.
In order to understand which of those steps need to be optimised by the
browser with new APIs, it would help if you could explain some typical
tasks, or use cases, that would need to perform any or all of those steps.
In particular, what type of task would lead to there being more than one
Array and/or NodeList to be used as input to step 2?
var foo = document.querySelectorAll(div.foo);
// do stuff with the divs...
var bar = document.querySelectorAll(div.bar);
// do stuff with the divs...
var items = document.createNodeList(foo, bar).querySelectorAll(ul.items);
// do stuff with the items...
Alternatively, in jQuery we would be doing something like this:
var foo = $(div.foo);
// do stuff with the divs...
var bar = $(div.bar);
// do stuff with the divs...
var items = foo.add( bar ).find(ul.items);
// do stuff with the items...
The important thing here is that:
1) There is only one sub-query being done.
2) That all the ul.items are being aggregated into a single collection, in
document order.
What type of task would require executing the same selector query over a
whole collection of elements?
The most important case is where there's additional filtering being done.
For example, in jQuery you can do:
$(div.foo)
.bind(click, function(){})
.find(span)
.addClass(foo);
This reduces the total number of query operations down to two if it was
possible to run it against a complete collection.
And what task would require the results of those to be merged into a single
list?
The case where $(div).parents() is done, for example. This is a custom
query where we return a set of ancestor elements for each of the divs. This
is not something that I would expect the Selectors API to support but the
case of merging those results, sorting them, and uniqueing them is taking
place and is very costly.
To explain what I mean, let's look at a simple DOM:
html
body
div id=one
div id=two/div
/div
/body
/html
$(div).parents() should return:
[ html, body, div#one, div#two ]
naturally if this query is being done on two elements the result set will
need to be merged/sorted/uniqued before it can be returned.
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 my previous mail falls into Option A. Would it
address
this issue adequately? Specifically, defining document.createSelector()
and
a Selector interface that allows running a query like this:
var elements = [...] // Some Array (or NodeList) of Elements
var selector = document.createSelector(em, strong);
var list = selector.querySelectorAll(elements);
This is equivalent to iterating over the elements array, running
elements[i].querySelectorAll(em, strong) on each, and then
merging/sorting
all of the results into a single collection.
Not a huge fan of that - it seems really backwards.
Could you elaborate?
Right now we have
(Document|Element|DocumentFragment).querySelectorAll(selector) - this makes
sense - you're going from your base root and finding sub-elements using the
selector.
You're proposing sticking the selector some place else and using the
selector as the root, sort of, then passing the collection of elements as
some sort of filter? It's completely backwards.
Another alternative would be to implement the merge/sort/unique
method and have it return a NodeList (which would, then, have qSA).
The collection of elements (step 1, above) input into the qSA step (step 2)
wouldn't need to be a sorted list. Technically, it doesn't even necessarily
have to be a merged list if the API allows multiple arrays and/or nodelists
to be provided. It will have no effect on the result. The important point
seems to be that a collection of elements can be provided somehow and that
the implementation can execute the query on each distinct element in that
collection. How exactly that is done is just an API design issue.
Sure - but we can kill two birds with one API stone. Having a
document.createNodeList gives us merge/sort/unique (yay!) and it makes
NodeList.querySelectorAll and NodeList.matchesSelector doubly-useful (yay! -
since they can now be used for normal NodeLists and for array-like
collections, thanks to createNodeList).
--John
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). The converse of all these problems would arise if the spec became an ECMA spec. I'm not advocating that, personally -- I'm explicitly encouraging some kind of collaboration across an artificial divide. 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 requiring every TC39 member to join w3c (if possible). Any TC39 members whose employers can't join could perhaps become Invited Experts to the W3C Web Applications Working Group, if that facilitates review. Do we have to agree on where the spec ends up before collaborating? I hope not, especially since it seems likely both ES specs and W3C ones may need to contain sub-specs that hook together, possibly involving common pieces duplicated among the specs. We already have a spec in progress and it already has a home, so starting the conversation with a suggestion to move the work elsewhere struck me as odd and potentially disruptive. We could recommend avoiding catch-alls as a best practice. However, many legacy DOM interfaces require catch-all behavior, so it can't be completely eliminated. If we want to restrict host objects to what WebIDL allows, but not break the Web, then catch-all getters and putters have to be among the things it allows. The problem is containing the old patterns, heading off the temptation to use them in new APIs. That would probably best be done via a recommendation not to use catchalls in new APIs (in the Web IDL spec perhaps). Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? Yes, linearization of multiply-inherited interfaces (and multiple interfaces that are present but not inherited) is something that could use careful review and a better design. When I said these are largely Web IDL issues I mean not directly issues for the HTML Working Group. I did not mean to imply that TC 39 shouldn't have input - it should. There's probably a better future beyond prototype chains, and I think the odds of finding that world and colonizing it are greater if we collaborate somehow. The current situation is making the best of de-facto standards, rationalizing what's out there. Indeed, because the variance in what's out there makes life more difficult for authors. I expect it's not possible to get rid of prototypes from ECMAScript DOM bindings given the constraints of Web compatibility. Possibly TC39 members need to do the main work on mixins, and then propose something coherent for WebIDL to bind to. But I know of folks not active in TC39 or not even Ecma mebmers, who are able to participate in the public HTML5 lists (and of course in whatwg.org), who do want mixins a la Ruby modules in JS, and their input would help us make some kind of progress. But this separation of producers and consumers is artificial, and it may miss critical information not expressed in mythical waterfall requirements docs one might imagine the parties exchange. Systems RD benefits from mixing up the experts and opening the silos to cross disciplines, interest areas, programming audiences, and less defensible boundaries to-do with standards body politics. The current division of labor between core language (Ecma) and DOM/ WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But obviously some things have fallen through the cracks (multiple globals, split windows, execution rules). I think we are in agreement that collaboration would enable a better outcome here. All I meant to do is to point out the proper W3C Working Group for coordination. The term I used was execution model. scope is a mis- transcription. Are there specific issues other than the concurrency model for storage APIs? There
Re: [selectors-api] Summary of Feature Requests for v2
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 is mozMatchesSelector. I bet we'd both love to rename it... ;) Indeed. The fact that mozilla was implementing it and picked a vendor prefixed name for the time being was part of what encouraged me to implement it last night. So, thanks! -Sam
Re: [selectors-api] Summary of Feature Requests for v2
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 my previous mail falls into Option A. Would it address this issue adequately? Specifically, defining document.createSelector() and a Selector interface that allows running a query like this: var elements = [...] // Some Array (or NodeList) of Elements var selector = document.createSelector(em, strong); var list = selector.querySelectorAll(elements); This is equivalent to iterating over the elements array, running elements[i].querySelectorAll(em, strong) on each, and then merging/sorting all of the results into a single collection. Not a huge fan of that - it seems really backwards. Could you elaborate? I had the same reaction as John, though quite possibly for different reasons. Currently we have an API like node.querySelector(selector). Your proposed API is selector.querySelector(node). That seems backwards compared to existing API. Quite possibly a namechange would make things better though. / Jonas
Re: [selectors-api] Summary of Feature Requests for v2
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, strong); createNodeList would create a NodeList holding the DOM nodes in document order (with duplicates removed). Since it's a proper NodeList we could then use qSA to find the elements that we want. 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. 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 would be much faster than using Array.filter or some other method.) Are you sure that Array.filter would result in a significant perf hit? What with recent jitting and stuff it would be great if we don't have to rely on making everything a native method, but can rely on javascript to do part of the work without taking too much of a perf hit. / Jonas
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 possible to say that this stuff is *only* for implementors. I'd prefer if it were also readable for those trying to use the specification. My inclination would be to address this by improving the current Web IDL spec, or to write an informative primer style document to accompany it. I also think some of the complexity of the Web IDL spec can probably be removed without losing anything important - I think it offers some constructs that are not used by any spec relying on it. - Maciej -- Yehuda On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote: 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 solve the problem? Probably. Do you have a specific proposal? Regards, Maciej -- 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 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). Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre- WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-2-Core/ -- Yehuda On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com wrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark-glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype
Re: [selectors-api] Summary of Feature Requests for v2
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 huge issue - if a NodeList is coming in then we can assume that it's already containing unique results and is in document order. 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)). 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 would be much faster than using Array.filter or some other method.) Are you sure that Array.filter would result in a significant perf hit? What with recent jitting and stuff it would be great if we don't have to rely on making everything a native method, but can rely on javascript to do part of the work without taking too much of a perf hit. I can guarantee that it'll be slower than doing it natively - especially so in Internet Explorer 8.next (the more that they do under the covers the faster we can provide results). --John
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 Thu, Sep 24, 2009 at 5:02 PM, Brendan Eich bren...@mozilla.com wrote: Are invited experts time-bound in some way? We learned in Ecma that experts were to be invited to one meeting only. In general, no. There is a time limit mentioned in #4 above, but that is just for exceptional circumstances, ones that are not likely to apply in this situation. - Sam Ruby
Re: [selectors-api] Summary of Feature Requests for v2
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 sorted using quicksort or some such. But the constant here is not actually a constant. The time required to compare the DOM positions of two nodes is very much dependent on the DOM, though clearly bounded above for a given DOM. Last I checked, it's not that hard to produce situations in both Gecko and Webkit (haven't looked at the Trident and Presto source, so can't comment on those) where each such position comparison is O(N) in number of nodes in the DOM (though that usually involves having a very shallow DOM with a single node that has lots of kids). So it's not that hard to end up with O(N^2) or worse behavior for sorting an array of nodes. Of course that's true whether the sort is done in JS or in C++. But it might be worth thinking about use cases here and whether they can be addressed in ways that don't involve sorting node arrays. -Boris
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 below: http://www.w3.org/2004/08/invexp.html It depends on the nature of the employer, and the reason they are unable to join. Historically there have been Invited Experts in W3C Working Groups who are employed by such organizations as universities or small start-ups. We even have some in the HTML Working Group. So it would probably be more accurate to say it depends and that it may be subject to the judgment of the W3C Team. Regards, Maciej
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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. Unfortunately, no. See #2 and #3 below: http://www.w3.org/2004/08/invexp.html It depends on the nature of the employer, and the reason they are unable to join. Historically there have been Invited Experts in W3C Working Groups who are employed by such organizations as universities or small start-ups. We even have some in the HTML Working Group. So it would probably be more accurate to say it depends and that it may be subject to the judgment of the W3C Team. I've discussed the specific case with the W3C, and it is the case that in the judgment of the W3C Team, the answer in this specific case is no. You, of course, are welcome to try again in the hopes of getting a different answer. Regards, Maciej - Sam Ruby
Re: [AE] Last Call comments (1)
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 is origin of a widget preferable to instance of widget? Admittedly, I'm also confused:( My understanding was that the origin of the widget made it unique. This assumption was based on the authority part of a widget URI being a UUID. We may need to fall back to traditional instance identification instead of relying on the origin. However, the Widget URI scheme palms off origin to the type of the start file (i.e., if HTML5, then use HTML5 rules for deriving origin from the widget URI; If SVG, the use the SVG rules to derive the origin, and so on However, it is unclear if, for instance, SVG knows how to do that). I've CC'd Robin to clarify. This could be important as some conformance statements relate to the concept, e.g: Upon getting the preferences attribute, the user agent must return a Storage object that represents the storage area for the origin of a widget. If origin of a widget is not a sensible concept for the UA (as opposed to widget instance), does this fail conformance? How would you test for it for the UA anyway? Testing is easy: run two widget instances from the same kind (e.g., two clocks), and make sure that the preference for each widget don't interact (again, based on the assumption that origin makes them unique). Clock A: origin - widget://abc123/ Clock B: origin - widget://foobar/ I agree, however, this breaks down when using HTTP because you need to use either many iframes (potentially different origin to host document, but same origin for multiple instance) or a div (same origin as host document). Hence, I we still require a solution for establishing instance identity. Kind regards, Marcos On 23 Sep 2009, at 17:10, Marcos Caceres wrote: 5.4 How to handle multiple instances of the same widget? As far as I remember it was to be moved to WURIv2, but it seems important in the context of preferences. No, it's not important. They are bound to the origin of a widget as defined in WURI, and the origin of a widget is universally unique. Hence, preferences are unique and not shared. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comments on API spec: Storage areas and Origin
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 Areas
A storage area is a data-store that is unique for the origin of a widget,
which a user agent can use to store string-based key-value pairs.
The storage area must be unique to the instance of a widget. Otherwise this
will lead to widget instances overwriting each others' preference settings,
or exposing personal preferences to other users who happen to be using the
same type of widget. (There's a discussion of this on the list somewhere).
Yes, this is certainly true in a HTML context.
However, given the definition of origin in the document, the current text may
be a problem:
The universally unique identity of a widget represented as a URI,
established via the rules defined in the [Widgets-URI] specification.
Now by widget do the spec actually mean the widget instance, or what you
might think of as the widget's class or prototype?
Widget instance is always the assumption. Yes this needs to be more
clear in the spec. However, this does not solve the identity crisis.
The latter would seem to be the case given a read of the Widgets URI scheme
draft [1], in which case, the Origin is not going to work for associating a
storage area unless the UA is single-user and doesn't allow widgets to be
instantiated multiple times.
This is not necessarily true (or how I had envisioned it would work).
As with my last email, instances would have a unique authority.
However, I'm now fearing that this is not correct.
(E.g. Apache Wookie (Incubating) mints a UID when a widget is instantiated
for a particular user in a particular application context (e.g. user bob
puts the weather widget onto their profile page), and uses this UID to
associate a storage area with the widget instance. The widget id URI as found
in config.xml-id is used along with application context and user data to
generate the hash for the UID. Now, is Wookie's UID the origin as far as
AE is concerned, or is it the canonical widget id?)
The widget id declared in the configuration document has no
relationship whatsoever to the instance identifier (or the unique
origin of a widget). Consider the widget id as the canonical name
of the widget, which is persistent across versions.
So either origin needs clarification as referring to widget instances, or
storage areas need to be defined in terms of instances and not necessarily
the origin - in which case the dependency of the AE spec on [1] can be
removed.
Agreed. This will require some thought. Either:
1. each instance gets its own identifier through the widget URI scheme.
2. each instance gets its own identifier as an implementation detail
- however, the storage is bound to the unique identifier.
In any case, it's pretty clear what we are trying to achieve in terms
of requirements. A specification must:
1. provide a means to (implicitly) identify an instance of a widget.
2. application preferences must only be bound to that instance (thus
not shared across two running widgets).
In 1, I say implicit in that I don't see any real use case for the
author accessing the actual identifier.
It would be like, in JavaScript, doing the following:
widgetA = {};
widgetB = {};
alwidgetA === widgetB; //false
Kind regards,
Marcos
[1] http://www.w3.org/TR/widgets-uri/
--
Marcos Caceres
http://datadriven.com.au
Re: [WARP] uri attribute is confusing
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 that attribute name). FWIW, I like either. There may be lessons to be taken in designing these patterns from POWDER http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect the POWDER expressivity needs are much greater than what is needed here. Dom -- Marcos Caceres http://datadriven.com.au
Re: [selectors-api] Summary of Feature Requests for v2
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 query on each node, and then merge sort the results. That's not a huge issue - if a NodeList is coming in then we can assume that it's already containing unique results and is in document order. 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)). Note that we'd have to do the same work that a JS implementation that uses Node.compareDocumentPosition. The only win if we have to sort is that we wouldn't be crossing the JS-C++ bridge as much. The actual computations would be exactly the same. 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 would be much faster than using Array.filter or some other method.) Are you sure that Array.filter would result in a significant perf hit? What with recent jitting and stuff it would be great if we don't have to rely on making everything a native method, but can rely on javascript to do part of the work without taking too much of a perf hit. I can guarantee that it'll be slower than doing it natively - especially so in Internet Explorer 8.next (the more that they do under the covers the faster we can provide results). One could argue that microsoft should just shape up and supply a modern JS engine ;) In all seriousness though. It'd be nice to get data here. I'm wary of adding APIs that are there just to work around slowness in implementations, unless the wins are significant. Once we've added an API we have to maintain it until the end of time, long after performance improvements have made them obsolete. There's definitely cases when this makes sense to do, however it'd be nice with data to back up that this is one of those times. / Jonas
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 Group, if that facilitates review. Unfortunately, no. See #2 and #3 below: http://www.w3.org/2004/08/invexp.html It depends on the nature of the employer, and the reason they are unable to join. Historically there have been Invited Experts in W3C Working Groups who are employed by such organizations as universities or small start-ups. We even have some in the HTML Working Group. So it would probably be more accurate to say it depends and that it may be subject to the judgment of the W3C Team. I've discussed the specific case with the W3C, and it is the case that in the judgment of the W3C Team, the answer in this specific case is no. You, of course, are welcome to try again in the hopes of getting a different answer. I didn't know that there was a specific case driving this concern. I thought this was a general worry about, e.g., university researchers. I would not ask the W3C Team to reconsider specific cases where they have already rendered a judgment. Regards, Maciej
Re: [selectors-api] Summary of Feature Requests for v2
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 would be much faster than using Array.filter or some other method.) Are you sure that Array.filter would result in a significant perf hit? What with recent jitting and stuff it would be great if we don't have to rely on making everything a native method, but can rely on javascript to do part of the work without taking too much of a perf hit. I can guarantee that it'll be slower than doing it natively - especially so in Internet Explorer 8.next (the more that they do under the covers the faster we can provide results). One could argue that microsoft should just shape up and supply a modern JS engine ;) In all seriousness though. It'd be nice to get data here. I'm wary of adding APIs that are there just to work around slowness in implementations, unless the wins are significant. Once we've added an API we have to maintain it until the end of time, long after performance improvements have made them obsolete. There's definitely cases when this makes sense to do, however it'd be nice with data to back up that this is one of those times. Btw, i got word from our JS engine guys that using Array.map/Array.filter has bad performance behavior in firefox right now (it makes you fall off trace). So if you run any perf tests it'd probably be better not to use those functions, which is probably a good idea anyway given that I don't think they work in all browsers yet. / Jonas
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark- glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html . Thanks for the links, I was aware of these but hadn't read them. Mandatory try-locks in JS, just say no. I'm not sure what the other concerns about execution scope are - seems hard to discuss fruitfully without more detail. The term I used was execution model. scope is a mis-transcription. We should take steps to address the following willful violation: If the script's global object is a Window object, then in JavaScript, the this keyword in the global scope must return the Window object's WindowProxy object. This is a willful violation of the JavaScript specification current at the time of writing (ECMAScript edition 3). The JavaScript specification requires that the this keyword in the global scope return the global object, but this is not compatible with the security design prevalent in implementations as specified herein. [ECMA262] Wasn't ES5 fixed to address this? No, nothing was changed in ES5 and it is not clear without more discussion with various experts active in whatwg, w3, and Ecma what to do. Since you asked, I think you make the case that we should collaborate a bit more closely. I know the feedback was passed along. Yes, but describing the
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com wrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark-glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html . Thanks for the links, I was aware of these but hadn't read them. Mandatory try-locks in JS, just say no. I'm not sure what the other concerns about execution scope are - seems hard to discuss fruitfully without more detail. The term I used was execution model. scope is a mis-transcription. We should take steps to address the following willful violation: If the script's global object is a Window object, then in JavaScript, the this keyword in the global scope must return the Window object's WindowProxy object. This is a willful violation of the JavaScript specification current at the time of writing (ECMAScript edition 3). The JavaScript specification requires that the this keyword in the global scope return the global object, but this is not compatible with the security design prevalent in implementations as specified
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 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). Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-2-Core/ -- Yehuda On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com wrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark-glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work together to convert these concerns into actionable suggestions for improvement. There was extensive recent email discussion of local storage locking on the wha...@whatwg.org mailing list. We could continue here if it would be helpful. I'm not sure it's useful to discuss in person without being up to speed on the email discussion. Here are some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html . Thanks for the links, I
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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. I'd prefer if it were also readable for those trying to use the specification. -- Yehuda On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote: 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 solve the problem? Probably. Do you have a specific proposal? Regards, Maciej -- 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 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). Its utility is in providing a way to specify API behavior in a way that is consistent between specifications, language-independent, and reasonably concise. It's true that it adds an additional thing you have to learn. That's regrettable, but there are a lot of details that need to be specified to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many details undefined, leading to problematic behavior differences among browsers and a need for mutual reverse-engineering. Regards, Maciej [1] http://www.w3.org/TR/DOM-Level-2-Core/ -- Yehuda On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.comwrote: 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 target languages. Much of it is defined by Web compatibility constraints which would be outside the core expertise of TC39. Some of us on TC39 have lots of Web compatibility experience :-P. 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 artificial standards body divide may very well be needed. The rest of this message convinces me it is needed. One problem with inviting review via the W3C process is getting attention and following too many firehose-like mailing lists. es-disc...@mozilla.org is at most a garden hose, which is an advantage. Another problem is that not all Ecma TC39 members are W3C members (their employers are not members, that is). There are transparency problems on both sides, IMHO. People in dark-glass houses... https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html and the rest of that thread https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html (not the transactional behavior, which is out -- just the interaction with Array's custom [[Put]]). https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html on an ArrayLike interface with references to DOM docs at the bottom https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html about a WebIDL float terminal value issue. It seems like these are largely Web IDL issues (to the extent I can identify issues in the threads at all). TC39 members, Mark Miller articulated this yesterday, hope to restrict host objects in future versions of the JavaScript standard from doing any nutty thing they like, possibly by collaborating with WebIDL standardizers so that instead of anything goes for host objects, we have only what WebIDL can express. Catch-all magic where host object interfaces handle arbitrary property gets and puts are currently not implementable in ES -- this may be possible in a future edition, but even then it will carry performance penalties and introduce analysis hazards. We hope to steer ES bindings for WebIDL-expressed interfaces away from catch-all patterns. Beyond this tarpit, we're interested in the best way to linearize multiply-inherited WebIDL interfaces onto prototype chains, or whether to use prototype chains at all -- or in the seemingly unlikely event ES grows first-class method-suite mixins, binding WebIDL inheritance to those. We would welcome use-cases and collobaration, at least I would. Who knows what better system might result? There are larger (and less precise concerns at this time) about execution scope (e.g., presumptions of locking behavior, particularly by HTML5 features such as local storage). The two groups need to work
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 requiring every TC39 member to join w3c (if possible). Any TC39 members whose employers can't join could perhaps become Invited Experts to the W3C Web Applications Working Group, if that facilitates review. Are invited experts time-bound in some way? We learned in Ecma that experts were to be invited to one meeting only. Do we have to agree on where the spec ends up before collaborating? I hope not, especially since it seems likely both ES specs and W3C ones may need to contain sub-specs that hook together, possibly involving common pieces duplicated among the specs. We already have a spec in progress and it already has a home, so starting the conversation with a suggestion to move the work elsewhere struck me as odd and potentially disruptive. I've been writing my own opinion, qualified that way. Other TC39 members should opine. I really don't want to grab a spec from w3c, even if there is some concern about expertise being split awkwardly. I'm interested in fixing the split, not where the spec or specs end up. ISO and Ecma will insist on some degree of self-contained status for the ES specs. We refer to Unicode and IEEE-754 but for foundational things like the global object(s) and the execution model. There's probably a better future beyond prototype chains, and I think the odds of finding that world and colonizing it are greater if we collaborate somehow. The current situation is making the best of de-facto standards, rationalizing what's out there. Indeed, because the variance in what's out there makes life more difficult for authors. I expect it's not possible to get rid of prototypes from ECMAScript DOM bindings given the constraints of Web compatibility. Yes, the foreseeable future wants backward compatibility. But we might find a better binding for new APIs, and possibly recast old ones (minus old stuff that is not actually used much) in new, more usable clothing. If ES5 has requirements on this that match ES3, then it has a requirement that Firefox, Safari and Chrome (and I think Opera?) are all violating, and likely will continue to violate for the foreseeable future. That seems like a problem. (Unless we convince ourselves that the split global object pattern somehow doesn't actually violate the ECMAScript spec.) It's a violation, for sure, but no one will be struck down by lightning. We can live with it a bit longer. Well, it seems bad to me for the spec to state a requirement that won't be followed. Yes, it's bad. Now what? Specifying more about multiple global objects would be good, but I think it's not a case where current browser behavior violates the ECMAScript spec, so it's not really the same issue. Multiple globals as in frame or window objects, probably not. Although IE does some very strange dynamic scoping in its window.eval implementation, or did -- see http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.x_working_docscache=cachemedia=resources:jscriptdeviationsfromes3.pdf This is not going to be standardized, so it's an IE bug to fix (if not fixed already). There are edge cases to do with split windows and whether you get exceptions or !== true results, but these are the real multiple global objects issue I had in mind. Even ignoring multiple frames or windows, just a single WindowProxy with more than one Window global object is outside the ES specs, which do not admit more than one global object. WindowProxy and Window go a step beyond multiple globals, of course, splitting each global in two (or one proxy and one or more globals under navigation with cached history). Do we need a WindowProxy in the core language? I'm not sure, but if not then there has to be some other way of specifying how |this| in global code binds to the outer window rather than the inner (Ecma global). We didn't try to make something up here for ES5. ECMAScript could just allow host embeddings to make the outermost scope chain entry be something other than the global object. That's backward: the outermost scope chain object must be the ES global object, what HTML5 types in WebIDL as a Window. It's the WindowProxy for that Window (and others forward and back in session history) that must be bound to |this| in global code, contrary to ES. The main downside is that this is more loose than is needed and could technically allow crazy unreasonable things. This is not tenable -- the WindowProxy is shared among multiple globals and possibly cross-origin scripts loaded in multiple globals. Those globals not current but rather back and forward in the same WindowProxy's
Re: [selectors-api] Summary of Feature Requests for v2
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 .bar .baz selector and destroying the selector object before returning in Gecko takes about 80% of the overhead (that is, not walking the tree and doing selector matching) time of a querySelector() call. Or, in numbers, about 5.5us per call. Webkit's time for executing my testcase is comparable, though I can't tell how much of their time is selector parsing. 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. If you're doing less than 1,000 calls that involve selectors api per second, the selector-parsing time is probably not that relevant. But I don't know what the use cases are here. -Boris Take a event-delegation system that uses matchesSelector. Every event that it handles will walk the event path trying element.matchesSelector with every registered handler. e.g. There are twenty registered click handlers and a click event occurs on an element ten levels deep. There could be 20 * 10 = 200 calls to matchesSelector. Or 400 if the system simulates capture phase as well. Or take a framework that adds enhancements to HTML elements based on selectors. The framework wants to handle dynamic insertion to / removal from the page, so every DOMNodeInserted / DOMNodeRemoved (or equivalent) it will call querySelectorAll for all registered enhancements to see if there is any work to do.
Re: CORS redirect behavior proposal
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 Origin header is a U+0020-separated list of origins. Each time a redirect takes place an origin is added to the origin chain if it is not the same as the last origin that was added. The Access-Control-Allow-Origin header needs to be identical to the value of the Origin header, octet-for-octet. Let me know if I missed anything or if the draft is unclear. I've updated draft-abarth-origin to match (and switched the header name back from Sec-From to Origin): http://www.ietf.org/id/draft-abarth-origin-03.txt Thanks, Adam
Re: [selectors-api] Summary of Feature Requests for v2
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 check whether the event target element matches a given
selector. So it would be something like:
if (evt.target.matchesSelector(.fooinput.bar)) {
...
}
In case it isn't obvious, we may want to check every element in the
event path. i.e. all ancestors of evt.target.
If matchesSelector could be called with a context element then it would
become a more powerful version of compareDocumentPosition(). It is also
more limited because you can't do preceding-siblings.
Examples
I'll use the :scope pseudo-class, although :context would be a better name.
elt.matchesSelector(:scope *, context); // descendant
elt.matchesSelector(:scope * *, context); // descendant but not child
elt.matchesSelector(:scope ~ *, context); // following-sibling
elt.matchesSelector(:scope ~ * *, context); // nephew (child of a
following-sibling)
I would probably use it if it was there, but wouldn't complain if it
wasn't.
Re: [selectors-api] Summary of Feature Requests for v2
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 various bins in a data structure to make matching faster. In practice this means that you don't have to actually match most nodes against most selectors when computing the set of rules that match a given node. This makes sense because you're guaranteed that every time a node is inserted into the DOM you will have to match it against every single one of those selectors. https://developer.mozilla.org/en/Writing_Efficient_CSS has a description of the setup. I believe Webkit has something similar. Again, I can't speak to Trident or Presto. In the querySelector(All) case, the browser has no way to know that the selector will ever be reused. In practice, the native implementations were enough faster than what they were replacing, even without any particularly fancy optimizations, that simplicity was judged more important than squeezing every bit of performance out. At least in Gecko's case. If we get to the point where they're being a bottleneck again, that will likely be revisited. Take a event-delegation system that uses matchesSelector. Every event that it handles will walk the event path trying element.matchesSelector with every registered handler. e.g. There are twenty registered click handlers and a click event occurs on an element ten levels deep. There could be 20 * 10 = 200 calls to matchesSelector. Or 400 if the system simulates capture phase as well. 200 calls would equate to ~1ms of selector parsing time in the the case of Gecko. For a click event, that's not terrible. Or take a framework that adds enhancements to HTML elements based on selectors. The framework wants to handle dynamic insertion to / removal from the page, so every DOMNodeInserted / DOMNodeRemoved (or equivalent) it will call querySelectorAll for all registered enhancements to see if there is any work to do. This could be much more of a problem. I'd want be interested in what the actual performance is like in this situation. Remember, the selector-parsing time was just the overhead; the real time usage is walking the DOM and doing the matching. For matchesSelector this is much less significant, of course, but for querySelectorAll it's likely to be the dominating factor (gut feeling; if someone wants to measure that would be welcome). I also wonder how well XBL or something like that would handle cases like this... This setup (matching every node in a subtree against a set of selectors) is really not that well served by any of the APIs described here. It's much closer to the CSS use case and would benefit from similar optimizations. Note that I don't have anything against exposing parsed selector objects in JS. I don't think it would be that difficult to implement it. I'm just not sure whether the added complexity is really needed, and whether it's the best solution for the use cases. Maybe it is; I'm just gathering data. This is not exactly my area of expertise. -Boris
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 won't be attending TPAC, but I am sure some useful discussions will come out of the meeting between those TC 39, Web Apps and HTML WG people who can attend. I will be in Mountain View from Saturday for 11 days (for SVG stuff), so I could probably find some time to meet with interested people if that's deemed to be a good idea. Some general responses to questions raised in this thread: • I agree that a better solution for the multiple inheritance problem is needed. • Web IDL is somewhat poorly written at the moment, so it would indeed be good to make it easier to follow. I do think the spec is aimed at implementors rather than authors, though. I look forward to increased collaboration with the ECMA folks on the spec!
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 item(in unsigned long index);
readonly attribute unsigned long position;
unsigned long add(in any data, in DOMString title);
void remove(in unsigned long index);
void clearUndo();
void clearRedo();
};
I almost forget that I'm looking at something most widely implemented in a
dynamic language when I look at that. Since this is most likely to be
implemented in terms of ECMAScript, why not provide an ECMAScript reference
implementation?
-- Yehuda
On Thu, Sep 24, 2009 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote:
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 possible to say that this stuff is *only*
for implementors. I'd prefer if it were also readable for those trying to
use the specification.
My inclination would be to address this by improving the current Web IDL
spec, or to write an informative primer style document to accompany it. I
also think some of the complexity of the Web IDL spec can probably be
removed without losing anything important - I think it offers some
constructs that are not used by any spec relying on it.
- Maciej
-- Yehuda
On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak m...@apple.com wrote:
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 solve the problem? Probably. Do
you have a specific proposal?
Regards,
Maciej
-- Yehuda
On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak m...@apple.comwrote:
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 in understanding other specs (like HTML5).
Its utility is in providing a way to specify API behavior in a way that
is consistent between specifications, language-independent, and reasonably
concise. It's true that it adds an additional thing you have to learn.
That's regrettable, but there are a lot of details that need to be specified
to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many
details undefined, leading to problematic behavior differences among
browsers and a need for mutual reverse-engineering.
Regards,
Maciej
[1] http://www.w3.org/TR/DOM-Level-2-Core/
-- Yehuda
On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.comwrote:
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 target languages. Much of it is defined by Web compatibility
constraints which would be outside the core expertise of TC39.
Some of us on TC39 have lots of Web compatibility experience :-P.
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 artificial standards body divide may very
well be needed. The rest of this message convinces me it is needed.
One problem with inviting review via the W3C process is getting
attention and following too many firehose-like mailing lists.
es-disc...@mozilla.org is at most a garden hose, which is an advantage.
Another problem is that not all Ecma TC39 members are W3C members (their
employers are not members, that is).
There are transparency problems on both sides, IMHO. People in
dark-glass houses...
https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread
https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).
https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
on an ArrayLike interface with references to DOM docs at the bottom
https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
about a WebIDL float terminal value issue.
It seems like these are largely Web IDL issues (to the extent I can
identify issues in the threads at all).
TC39 members, Mark
Re: ECMA TC 39 / W3C HTML and WebApps WG coordination
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 {
readonly attribute unsigned long length;
getter any item(in unsigned long index);
readonly attribute unsigned long position;
unsigned long add(in any data, in DOMString title);
void remove(in unsigned long index);
void clearUndo();
void clearRedo();
};
I almost forget that I'm looking at something most widely
implemented in a dynamic language when I look at that. Since this is
most likely to be implemented in terms of ECMAScript, why not
provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure
ECMAScript, since they need to tie into the browser implementation and
system APIs. So a reference implementation in ECMAScript is not
possible.
What this interface definition actually specifies is some constraints
on how the implementation of this object is reflected to ECMAScript.
For example, this method must convert its second parameter to a string
using a particular algorithm, and the prose description of the
method's behavior assumes that has been done, and the return value
promises to be a positive integer:
unsigned long add(in any data, in DOMString title);
This method converts its one parameter to a number, and performs
truncation and range checks according to some standard rules, and will
for example raise an exception if a negative number is provided:
void remove(in unsigned long index);
It would be tedious to spell out all those details for every such
method, either in prose or in ECMAScript code - that interface
definition would be replaced by something 5-10 times as long.
Another thing to keep in mind - although ECMAScript is the primary
target language for the IDL interfaces in Web technology
specifications, it is quite common to expose these interfaces in Java,
and is desirable for various applications to be able to provide them
in languages such as Python, C++, Objective-C, and Ruby. Thus, we need
a language-independent formalism to define the interfaces, even though
the ECMAScript bindings are the most important.
And finally, even though the snippet of Web IDL you cited is very much
aimed at authors, I think it's pretty easy to understand the practical
upshot for ECMAScript programmers, without understanding the details
of Web IDL. It's pretty clear what attributes and methods you can use,
and what kind of parameters you should provide. For those who care
about the full details, you only have to learn Web IDL once, and it's
not a very big syntax. It's sort of like learning EBNF to understand
grammar definitions. The extra conciseness is worth the cost of an
extra formal syntax to learn, in my opinion.
Regards,
Maciej
Re: [selectors-api] Summary of Feature Requests for v2
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 the selectors in various bins in a data structure to make matching faster. In practice this means that you don't have to actually match most nodes against most selectors when computing the set of rules that match a given node. This makes sense because you're guaranteed that every time a node is inserted into the DOM you will have to match it against every single one of those selectors. https://developer.mozilla.org/en/Writing_Efficient_CSS has a description of the setup. I believe Webkit has something similar. Again, I can't speak to Trident or Presto. In the querySelector(All) case, the browser has no way to know that the selector will ever be reused. In practice, the native implementations were enough faster than what they were replacing, even without any particularly fancy optimizations, that simplicity was judged more important than squeezing every bit of performance out. At least in Gecko's case. If we get to the point where they're being a bottleneck again, that will likely be revisited. Take a event-delegation system that uses matchesSelector. Every event that it handles will walk the event path trying element.matchesSelector with every registered handler. e.g. There are twenty registered click handlers and a click event occurs on an element ten levels deep. There could be 20 * 10 = 200 calls to matchesSelector. Or 400 if the system simulates capture phase as well. 200 calls would equate to ~1ms of selector parsing time in the the case of Gecko. For a click event, that's not terrible. No. It will be negligible compared to everything else that has to be done. Or take a framework that adds enhancements to HTML elements based on selectors. The framework wants to handle dynamic insertion to / removal from the page, so every DOMNodeInserted / DOMNodeRemoved (or equivalent) it will call querySelectorAll for all registered enhancements to see if there is any work to do. This could be much more of a problem. I'd want be interested in what the actual performance is like in this situation. Remember, the selector-parsing time was just the overhead; the real time usage is walking the DOM and doing the matching. For matchesSelector this is much less significant, of course, but for querySelectorAll it's likely to be the dominating factor (gut feeling; if someone wants to measure that would be welcome). I also wonder how well XBL or something like that would handle cases like this... This setup (matching every node in a subtree against a set of selectors) is really not that well served by any of the APIs described here. It's much closer to the CSS use case and would benefit from similar optimizations. XBL (and standard DOM implementations) is what we want. Note that I don't have anything against exposing parsed selector objects in JS. I don't think it would be that difficult to implement it. I'm just not sure whether the added complexity is really needed, and whether it's the best solution for the use cases. Maybe it is; I'm just gathering data. This is not exactly my area of expertise. -Boris Thanks for that perspective. My main concern was that we don't create parsed selectors in JS (at least not for performance reasons).
[selectors-api] Matches Selector Interface
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 easier to define, but otherwise, no normative changes. I also fixed up the IDL for the NodeSelector interface to match the current WebIDL requirements. I made these changes to the level 1 spec too. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Scoped Selectors
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 behave as if there was a selector that matched the context node. e.g. In JQuery: $(+p, elm); This would select the p element that is a sibling of elm. 2. It would be useful to be able to check if an a given element matches a selector in relation to a specified reference element (:scope). For example, check if an event target is a sibling of a specific element, and if the parent element has a specifc class name set. e.g. Matches the selector: .foo:scope~input[type=text] This may be particularly useful for event delgation. 3. Obtain a collection of elements based on their relation to more than one specified reference elements. e.g. Query to the document to obtain elements matching :scope+span, where :scope is intended to match any of the elements in a specific collection. This would be simpler than iterating all of the nodes in the collection, running the query on each of them and then merging the results. *Problems* 1. Need a way to allow the browser to parse implicitly scoped selectors beginning with combinators and imply the presence of :scope before each in the group. 2. Need to allow :scope to be used within the selector strings, and specify one or more scope elements that will be matched by :scope. This needs to be useable with all of the querySelector(), querySelectorAll() and matchesSelector() methods, or others with equivalent functionality. 3. Ideally, there would be an easy, reliable way for scripts to test if the implementation supports scoped selectors (at least, implicitly scoped selectors. Those using :scope could only be discovered by capturing the SYNTAX_ERR exception) For legacy browsers that don't, they can fall back to their own selector engines. *Possible Solutions* 1. Define a Selector object that can be used to parse and store a selector, and which can handle pre-parsing the selector and specifying the scope elements upon creation. This selector object can then be passed anywhere that accepts a selector string. (This is basically part of the createSelector() and Selector interface proposal from earlier). 2. Add parameters to the querySelector(), querySelectorAll() and matchesSelector() methods for: a. Indicating whether the selectors parameter should be processed with an implied scope. b. Specifying one or more reference elements that would match :scope. 3. Create new scoped versions of the existing methods that accept one or more reference elements that would match the implied scope. Add an optional parameter to the existing querySelector*() methods that would Allow one or more reference elements to be specified to match the explicit use of :scope in the selector. Option 2 doesn't provide an easy way to detect browser support. Option 3 creates an additional queryScopedSelector*() and matchesScopedSelector() methods, but this could get quite verbose if we also add equivalent NS methods to handle the namespace issue, to both the scoped and non-scoped versions. This would create an unreasonable number of different methods that would make understanding the API quite complex. Option 1 is syntactically messy, and requires the creation of a new object just to handle a scoped selector, even if that selector is only used once. I'm not sure which alternative would be best, and I'm kind of hoping there's a 4th alternative I haven't thought of yet that can address the use cases easliy enough. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Progress Events - Credits Edits
* 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 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [widgets] Widgets URI scheme... it's baaaack!
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 working group to get their code debugged, it's what happens when real people write code on their own. Sure, some people will write really bad code. I just don't think we have to accommodate all of them. Of course, but the above piece of code isn't bad at all. It gets the job done, and it's not more generic than one has reason to expect it to be, especially with web development background. What we're accommodating are expectations of interoperability and least surprise — in my book that hardly qualifies as catering to really bad code. Am I missing something? The code will only work on implementations which use http URIs and with a local domain. How many of them do that? If not all, then that is bad code. Let us assume that we don't at all say what is returned by the many attributes that normally expose URIs. What regex would you just as easily have written to match an unspecified value? Here are some samples from several implementations given an image linked to as /img/dahüt.svg: A: http://magic.local/img/dahüt.svg B: file://mushroom.local/img/dahüt.svg C: file:///img/dahüt.svg D: file:///C|/img/dahüt.svg E: \\myphone\img\dahüt.svg F: C:\MY DOCUMENTS AND SETTING\MY USERS\MY MARKB\MY DOCUMENTS\MY WIDGETS\MY ARSE\DAH~1.VML G: http:///img/dah%FCt.svg H: cool-product:/img/dah%u0055%u0308t.svg I: inode:DEADBABEC0EDBEEF J: many more things... Some of those aren't URIs, and some aren't hierarchical. Of the others, [:/]//?*/(.*$) should cover it. Sure, but in the absence of any indication from the specification, why should implementers use a URI there? In fact, one could make the case that it makes better sense to pick something that cannot I guess I missed your qualification; Let us assume that we don't at all say what is returned by the many attributes that normally expose URIs. I don't understand why you'd want to do that. I thought we just finished agreeing that we need to identify things with URIs. I'll note in passing that your regex doesn't take into account cases that might expose the query string in some implementations and not in others. Would you consider it to be really bad code? Certainly one could construct a more robust regex than yours, but it's a lot better to provide the means for implementations to be interoperable from the start rather than having to document which hacks work everywhere. [..] But if it would simplify things, I wouldn't be averse to a getBaseURI() call. I'm not sure what exactly that would cover, and how it would help. It would permit a developer to easily turn a URI into a relative path. Let's imagine we say nothing and you're an implementer: what would you do? Everyone in this discussion understands that introducing new schemes should be done with caution — what I don't understand is what architectural value you are seeing in not using URIs to identify resources, encouraging non-interoperable solutions, or sweeping the issue under the rug by delegating to a special name instead of a scheme. I'm not doing any of those things AFAICT. I encourage resources to be identified by URIs. I just don't see a need to tell implementations what their URIs should look like, other than to say they should be hierarchical for obvious reasons. Should they include query strings? Should? No. But if there's a good reason to use them I don't see why it should be prohibited. Fragments? Ditto. Can they contain UTF8 characters? URIs can't contain non-ASCII UTF8 of course, but escaping issues are well understood (if inconsistently implemented). What are the security implications of reusing an existing scheme with a magic name (given that it could be highjacked)? The same implications there's always been. This is a case where saying less only bring more problems. If we were to go your suggested route of telling implementations everything about what the URIs should look like except what the scheme would be, what we'll end up specifying is a URI scheme without a scheme name You say that saying less can bring problems, and I agree that what I'm proposing is to say very little, but then you say I'm telling implementations everything about what the URIs should look like? I'm a bit confused about your complaint, as those sound contradictory to me. . Apart from scoring a perfect Montesquieu on the Mint New URI Schemes With A Trembling Hand, I'm not sure that it buys us much that simply providing implementers with information that they've been asking for doesn't. Well, there are good reasons to avoid new URI schemes as RFC 4395 describes. Minting a new one is *always* the most expedient thing to do - which is
Re: [selectors-api] Summary of Feature Requests for v2
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) That is probably many times faster, and can probably be much more liberal, than an optimized browser running on a mobile device with 128 MB RAM. Did I imply it's slow? I just listed approximate hardware so that the times can be placed in some sort of context. No, you did not say it is slow. I'm saying that your laptop is probably a lot more powerful than a mobile device with a browser, such as Blackberry9000. Do you agree with that? that said, note that on a mobile device with 128 MB of RAM the RAM is a lot more likely to be a problem than the CPU in some ways. Running out of memory is strictly worse than being a little bit slower. So a lookup table may be more of a loss than a win, depending. An internal cache for matchesSelector (a lookup table) would be an implementation detail, wouldn't it? The idea for QuerySelector.create is the result would be an object that the program could hang on to. It would not be recreated and garbage collected each time. element.matchesSelector would be recreated and collected each time. The QuerySelector puts selector-related behavior on the selector, not related to nodes. For example a match method could match a selector from a context node: selector.match( contextNode ); A hand-rolled UserPanel might want to have a delegating listener to check to see if an LI was selected from a list. So, the delegating listener would be applied to each Panel instance, checking to see when an item was selected. Garrett
