Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 12:28 AM, Martin Kadlec bs-ha...@myopera.com wrote: Only reason why XPath is dead on the web is because there is not (yet) easy way to use it. It's worth noting that XPath in browsers is XPath 1.0 which doesn't have a smooth evolutionary path to XPath 2.x, so browser XPath is an evolutionary dead end unless forked on a different evolutionary path than W3C XPath. Even though XPath might be very important to its user base, in the big picture it isn't the kind of Web platform feature that would generate a lot of Web developer mindshare if a browser vendor invested in it. Chances are that investments in CSS always have a higher return on investment (in terms of Web developer mindshare) than investments in XPath. In this situation, I expect there to be no enthusiasm for polishing what's an evolutionary dead end (XPath 1.0) or for launching something incompatible that'd require a lot of up-front work (XPath 2.x) while still having to support the existing evolutionary dead end. Furthermore, XPath 2.x would be a slippery slope towards dependencies on XML Schema. Even though it's an optional feature, it's prudent to leave a wide safety margin around optional features. Otherwise, there's a risk of getting sucked into implementing bad optional features anyway. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. It's really clear in actual usage: someElement.is(div a:first-child); Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
[Bug 14900] New: note about checking origin attribute of MessageEvent
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14900 Summary: note about checking origin attribute of MessageEvent Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: Server-Sent Events (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: vic99...@yandex.ru QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org http://www.html5rocks.com/en/tutorials/eventsource/basics/#toc-security Authors should check the origin attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites. That warning is especially relevant for window.postMessage() messages and not so much EventSource and WebSocket and this should be marked in the spec. see http://krijnhoetmer.nl/irc-logs/whatwg/2022#l-381 -- 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: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 22/11/11 7:14 PM, Roland Steiner wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com mailto:wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 tel:718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Funnily enough, I've just been talking to the DOM5 and DOM6 API designers and they said almost exactly the same thing.
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com
mailto:wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325 tel:718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason not
to go with it?
IMHO 'is' seems awfully broad in meaning and doesn't very well
indicate that the parameter should be a selector. Inasmuch I like
.matches better.
Also, FWIW, an 'is' attribute on elements was/is in discussion on
this ML as one possibility to specify components.
Funnily enough, I've just been talking to the DOM5 and DOM6 API
designers and they said almost exactly the same thing.
On the the theme, Be short, are there issues with .has?
if(node.has('[role=button]')) node.is='button';
Re: XPath and find/findAll methods
On Nov 22, 2011, at 09:17 , Henri Sivonen wrote: On Tue, Nov 22, 2011 at 12:28 AM, Martin Kadlec bs-ha...@myopera.com wrote: Only reason why XPath is dead on the web is because there is not (yet) easy way to use it. It's worth noting that XPath in browsers is XPath 1.0 which doesn't have a smooth evolutionary path to XPath 2.x, so browser XPath is an evolutionary dead end unless forked on a different evolutionary path than W3C XPath. That's a strawman. Who cares if XPath 2.x is a failure if XPath 1.0 addresses the use cases that the OP has? Martin took the time to write to us to say that he'd like to see XPath supported. All he gets for his trouble is a bunch of rhetorical grandstanding about XPath being dead, condescension for not using CSS, a history lesson about battles long lost, and an invocation of XML Schema, which let's face it is the closest it gets to making a Godwin point on a Web mailing list. And then we wonder why people think the standards world is hostile to developers? Has anyone considered the option that Martin might actually not be, you know, stupid and ignorant, but might actually have use cases for XPath that he'd like to see addressed? I know that asking that question might risk challenging the dogma according to which there are no use cases for XPath, so that it's a lot more convenient to pile up against it first. But hey, maybe, just maybe, we shouldn't be in the dogma business. Besides, something really reeks here. If XPath is dead, why does it require the combined might of James Robinson, Marcos Càceres, Tab Atkins, and Henri Sivonen (I'm not counting Yehuda who actually replied with a rather neutral assessment) to gang up against a simple, polite suggestion? So let's start again and do it right this time. Martin: what are your use cases for XPath that aren't addressed with the current support for CSS Selectors? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [Widgets] WidgetStorage interface
On Monday, November 21, 2011 at 11:19 PM, Marcos Caceres wrote: On Monday, 21 November 2011 at 21:42, Robin Berjon wrote: On Nov 21, 2011, at 18:08 , Marcos Caceres wrote: As part of LC, I've received quite a bit of offline feedback that because of some issue in Webkit, it's difficult for implementers to reuse the WebStorage interface in a widget context: the problem is that Widget's use of Web storage slightly modifies some of the behaviour of the storage methods (e.g., some things are read only and throw exceptions). The way around this is to define a WidgetStorage interface that allows for the specific behaviour defined in the Widget spec. I don't mind the change, but can you provide more details about why it's a problem with WebKit? I'm told that Web Storage in Webkit is locked up tight so you can't extend it. If it was due to problems with what was done in the spec(s), we should document those to make sure we don't make the same mistakes again. Yes. Simple rule: if you change the behaviour of an interface even slightly, sub-class it. Let me clarify a little bit here, because it's bugging me. Usually, an object can take an interface and implement new custom behavior without any problems (interfaces generally are supposed to decuple interaction from implementation… as it's done in Java… with, say implements Runnable). However, in this particular instance, it seems that it's not possible to reuse an interface in this way (maybe it's some C thing, or maybe Storage is not actually defined as an interface but as an object).
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
Complexity and discussions about combinators seem to have prevented it from
getting into any draft despite lots of +1s. It is really different from
the rest of the selectors that exist today which are optimized like crazy
so it requires more in term of implementation than most to keep performance
sane. As yet I think (for the same reasons) no one has implemented
selectors 4 subject which is simpler than :has.
On Nov 22, 2011 5:06 AM, Charles Pritchard ch...@jumis.com wrote:
**
On 11/22/11 1:56 AM, Sean Hogan wrote:
On 22/11/11 7:14 PM, Roland Steiner wrote:
On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/21/11 11:31 AM, Tab Atkins Jr. wrote:
1) Make sense.
2) Not break existing content.
3) Be short.
.matches
.is
I like .is, the name jQuery uses for this purpose. Any reason not to go
with it?
IMHO 'is' seems awfully broad in meaning and doesn't very well indicate
that the parameter should be a selector. Inasmuch I like .matches better.
Also, FWIW, an 'is' attribute on elements was/is in discussion on this
ML as one possibility to specify components.
Funnily enough, I've just been talking to the DOM5 and DOM6 API designers
and they said almost exactly the same thing.
On the the theme, Be short, are there issues with .has?
if(node.has('[role=button]')) node.is='button';
Re: XPath and find/findAll methods
On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com wrote: Hello everyone, I've noticed that the find/findAll methods are currently being discussed and there is one thing that might be a good idea to consider. Currently, it's quite uncomfortable to use XPath in javascript. The document.evalute method has lots of arguments and we have to remember plenty of constants to make it work. IE and Opera support selectNodes method on NodePrototype, which is really useful, but what's the point in using it when it doesn't work in FF/Chrome/Safari. Maybe FF/Chrome/Safari should add support for selectNodes? -- Simon Pieters Opera Software
Re: XPath and find/findAll methods
On Tue 22 Nov 2011 01:05:18 PM CET, Simon Pieters wrote: On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com wrote: Hello everyone, I've noticed that the find/findAll methods are currently being discussed and there is one thing that might be a good idea to consider. Currently, it's quite uncomfortable to use XPath in javascript. The document.evalute method has lots of arguments and we have to remember plenty of constants to make it work. IE and Opera support selectNodes method on NodePrototype, which is really useful, but what's the point in using it when it doesn't work in FF/Chrome/Safari. Maybe FF/Chrome/Safari should add support for selectNodes? Right, one of the issues with XPath is that the DOM3 XPath API is without doubt the worst API on the web platform. With a sane API there might be more demand for XPath since it can be used for things that the CSSWG are unlikely to ever allow in selectors for performance reasons. As Simon points out, there is even a preexisting API that does more or less the right thing and is implemented in IE and Opera.
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 13:05:18 +0100, Simon Pieters sim...@opera.com wrote:
On Mon, 21 Nov 2011 20:34:14 +0100, Martin Kadlec bs-ha...@myopera.com
wrote:
Hello everyone,
I've noticed that the find/findAll methods are currently being
discussed and there is one thing that might be a good idea to consider.
Currently, it's quite uncomfortable to use XPath in javascript. The
document.evalute method has lots of arguments and we have to remember
plenty of constants to make it work. IE and Opera support selectNodes
method on NodePrototype, which is really useful, but what's the point
in using it when it doesn't work in FF/Chrome/Safari.
Maybe FF/Chrome/Safari should add support for selectNodes?
The way IE has implemented selectNodes/selectSingleNode doesn't make it
much XPath conformant, although their API is only available in XML
documents created using a xml element or an ActiveXObject.
By default IE does a prefix match. If you call
document.getProperty('SelectionLanguage') it returns 'XSLPattern'. You'd
need to do document.setProperty('SelectionLanguage', 'xpath') to use real
XPath and need you'd need to do
document.setProperty('SelectionNamespaces', 'xmlns:a=foo xmlns:b=bar')
to map the prefixes to a namespace.
Then the IE API looks like
* Element.selectNodes/selectSingleNode(expression)
* Document.selectNodes/selectSingleNode(expression, contextNode)
Opera has implemented the API with some clear differences.
* obviously, the expression are always XPath
* both Element and Document provide the contextNode
* namespace resolver in the second argument. It is of the same kind as
the one used in the DOM 3 XPath API
So it looks like
* Element.selectNodes/selectSingleNode(expression, namespaceResolver)
* Document.selectNodes/selectSingleNode(expression, namespaceResolver)
Neither Gecko nor Webkit have anything remotely related.
I think the API should steer in Opera's direction, with the remarks that
the namespace resolver should be supported, and that the API should return
other returns types than just Node, because XPath expressions can return
strings and integers.
Re: XPath and find/findAll methods
On Tuesday, 22 November 2011 11:50 AM, Robin Berjon ro...@berjon.com wrote: So let's start again and do it right this time. Martin: what are your use cases for XPath that aren't addressed with the current support for CSS Selectors? -- Robin Berjon - http://berjon.com/ - @robinberjon Thank you for support. In my opinion, there are two use cases for XPath: 1) It's much harder to write the CSS selector e.g.: CSS: article div:nth-child(2) input[type=text], article div:nth-child(2) input:not([type]), article div:nth-child(2) input[type=color]; XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)]; 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; e - ... Anyway, mostly when I use XPath instead of CSS selectors it's because of XPath axis - the ability to go not just deeper but also higher in the element tree. XPath can also work with any node, not just elements. There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other. Cheers, Martin
Re: XPath and find/findAll methods
On 2011-11-21 20:34, Martin Kadlec (BS-Harou) wrote: Hello everyone, I've noticed that the find/findAll methods are currently being discussed and there is one thing that might be a good idea to consider. Currently, it's quite uncomfortable to use XPath in javascript. The document.evalute method has lots of arguments and we have to remember plenty of constants to make it work. IE and Opera support selectNodes method on NodePrototype, which is really useful, but what's the point in using it when it doesn't work in FF/Chrome/Safari. My idea is to combine querySelector/All and selectNodes methods. This combination - find/findAll - would make using XPath much easier and it might give a good reason to lot's of programmers to use it instead of querySelector/All although it's going to be newer technology. This idea seems similar to how JQuery used to support both Selectors and XPath in the same API [1]. Support was subsequently removed in 1.2, and at the time moved to an XPath Compatibility Plugin [2]. However, the link to the actual plugin page now returns a 404, and I can't find that plugin or any replacement elsewhere. This seems to suggest that support for XPath was not considered important enough for its continued maintenance. Are there any other popular libraries that do still offer XPath APIs, or is there any data showing that authors really want to use it? [1] http://docs.jquery.com/DOM/Traversing/Selectors#XPath_Selectors [2] http://docs.jquery.com/Release:jQuery_1.2#XPath_Compatibility_Plugin -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Widgets] WidgetStorage interface
Yes. Simple rule: if you change the behaviour of an interface even slightly, sub-class it. Let me clarify a little bit here, because it's bugging me. Usually, an object can take an interface and implement new custom behavior without any problems (interfaces generally are supposed to decuple interaction from implementation… as it's done in Java… with, say implements Runnable). However, in this particular instance, it seems that it's not possible to reuse an interface in this way (maybe it's some C thing, or maybe Storage is not actually defined as an interface but as an object). Or then it's an implementation problem, and there is little point changing the specification ? I don't see how a new interface object would make programming its behavior more easy.
Re: XPath and find/findAll methods
On Nov 22, 2011, at 13:31 , Lachlan Hunt wrote: Are there any other popular libraries that do still offer XPath APIs, or is there any data showing that authors really want to use it? Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support (in 11.62 IIRC). It might be useful to know how long it was before that was spotted. Can anyone comment? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 13:42:36 +0100, Robin Berjon ro...@berjon.com wrote: Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support Which regression ?
Re: XPath and find/findAll methods
On 2011-11-22 13:31, Martin Kadlec (BS-Harou) wrote: In my opinion, there are two use cases for XPath: 1) It's much harder to write the CSS selector e.g.: CSS: article div:nth-child(2) input[type=text], article div:nth-child(2) input:not([type]), article div:nth-child(2) input[type=color]; XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)]; There was a proposal to handle this. input:-moz-any([type=text], [type=color], :not([type])) The current draft of Selectors 4 includes :matches(), though, which can partially handle that case, excluding :not([type]), which would have to be left separate. input:matches([type=text], [type=color]), input:not([type]) 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; Are such features really useful and desired by authors, and if so, is it possible that they could instead be introduced as features in Selectors? Anyway, mostly when I use XPath instead of CSS selectors it's because of XPath axis - the ability to go not just deeper but also higher in the element tree. XPath can also work with any node, not just elements. Could you describe a clear use case where this is useful for your needs? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: XPath and find/findAll methods
On 11/22/11 7:31 AM, Martin Kadlec (BS-Harou) wrote: CSS: article div:nth-child(2) input[type=text], article div:nth-child(2) input:not([type]), article div:nth-child(2) input[type=color]; XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)]; How about: CSS: article div:nth-child(2) input:any([type=text], :not([type]), [type=color]) (modulo the continuing bikeshedding about calling it :any vs :matches)? I fully expect this to be available before any sort of XPath changes in UAs. 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; Indeed. This seems to be the primary use case for XPath. -Boris
Re: XPath and find/findAll methods
On 11/22/11 8:05 AM, Lachlan Hunt wrote: The current draft of Selectors 4 includes :matches(), though, which can partially handle that case, excluding :not([type]), which would have to be left separate. That seems like a bug in :matches() that just needs fixing if it's meant as a replacement for :any(). -Boris
Re: XPath and find/findAll methods
On Nov 22, 2011, at 14:03 , João Eiras wrote: On Tue, 22 Nov 2011 13:42:36 +0100, Robin Berjon ro...@berjon.com wrote: Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support Which regression ? I believe it's called DSK-350606 and/or CORE-42716. I don't believe I have access to check for this myself. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 6:50 AM, Lachlan Hunt wrote: Last time we had this discussion, you had a desire to keep the name prefixed until the refNodes and :scope stuff was implemented [1]. What's the status on that now? The status is that I've given up on the :scope discussion reaching a conclusion in finite time (esp. because it sounds like people would like to change what it means depending on the name of the function being called) and would be quite happy to ship an implementation that only takes one argument. Web pages can use .length on the function to detect support for the two-argument version if that ever happens. Any obvious problems with that plan? I believe the one-argument version is pretty clear in implementation terms, except for the name bit. -Boris
Re: XPath and find/findAll methods
On Nov 22, 2011, at 14:05 , Lachlan Hunt wrote: On 2011-11-22 13:31, Martin Kadlec (BS-Harou) wrote: 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; Are such features really useful and desired by authors, and if so, is it possible that they could instead be introduced as features in Selectors? I think that everyone would be pretty much happy if Selectors added all that's missing in XPath — in other words, no one cares much about syntax. Traditionally though, this has been rejected for (IMHO genuine) performance reasons). ISTR someone talking of the possibility of having Selectors, and then a subset that would be Selectors for CSS but at that point you have to wonder why not just use what we already have? Also, I think it would create a fair bit of confusion. A classic UC that Martin missed above is //text(). Anyway, mostly when I use XPath instead of CSS selectors it's because of XPath axis - the ability to go not just deeper but also higher in the element tree. XPath can also work with any node, not just elements. Could you describe a clear use case where this is useful for your needs? A typical example is generating the current section + subsection number, which works nicely with a combination of count(), ancestor::, and preceding::. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Adding methods to Element.prototype
On Tue, 22 Nov 2011 03:58:32 +0100, Ojan Vafai o...@chromium.org wrote: I think this is the only sane solution to this problem. Lets split up the Element interface. I think an IDL annotation would work better from a specification perspective. E.g. [NoScope]. Otherwise we'd need to do this interface split for each element type where we add new attributes. -- Anne van Kesteren http://annevankesteren.nl/
Re: XPath and find/findAll methods
On Tue, 22 Nov 2011 14:15:59 +0100, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 14:03 , João Eiras wrote: On Tue, 22 Nov 2011 13:42:36 +0100, Robin Berjon ro...@berjon.com wrote: Such data is notoriously hard to come by, but just as a data point: I know that Opera recently introduced a regression in its XPath support Which regression ? I believe it's called DSK-350606 and/or CORE-42716. I don't believe I have access to check for this myself. Thank you. Seems it was caused by the new html parser but hardly something too serious.
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 4:16 AM, James Graham jgra...@opera.com wrote: Right, one of the issues with XPath is that the DOM3 XPath API is without doubt the worst API on the web platform. With a sane API there might be more demand for XPath since it can be used for things that the CSSWG are unlikely to ever allow in selectors for performance reasons. As Simon points out, there is even a preexisting API that does more or less the right thing and is implemented in IE and Opera. I believe there's a decent chance that we'll sprout a batch processers selectors spec or profile of the existing spec to handle things that are too expensive for normal CSS but perfectly fine when run in JS. On Tue, Nov 22, 2011 at 4:31 AM, Martin Kadlec bs-ha...@myopera.com wrote: 1) It's much harder to write the CSS selector e.g.: CSS: article div:nth-child(2) input[type=text], article div:nth-child(2) input:not([type]), article div:nth-child(2) input[type=color]; XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)]; This can be done easily using functionality in the new Selectors 4 draft: article div:nth-child(2) input:matches([type=text], :not([type]), [type=color]) 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; (a) can't be done in current CSS, largely for performance reasons, though as I say above to James, there's a good chance we'll sprout a profile of the Selectors spec that allows some things that are fine in JS but not in CSS. (b) can be done with :nth-child(29 - n) if you're on the child or sibling axises. The functionality of using position() on the other axises can't be matched directly with Selectors, but if you're doing JS it's trivial to do a slice to get the ones you want. (c) is not doable, because Selectors only deals with elements, which *have* attributes. Again, though, one can trivially get at the with javascript once you've selected the elements. (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) Anyway, mostly when I use XPath instead of CSS selectors it's because of XPath axis - the ability to go not just deeper but also higher in the element tree. XPath can also work with any node, not just elements. There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other. They solve the same set of use-cases in the same way, with the only difference being relatively minor abilities of each. That definitely makes them rivals. ^_^ We don't need two selection mechanisms with substantially different syntaxes. XPath may be useful as a source of more ideas to pull into Selectors, but that's it. ~TJ
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 12:18 AM, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 12:14 AM, Roland Steiner rolandstei...@chromium.org wrote: On Tue, Nov 22, 2011 at 14:19, Yehuda Katz wyc...@gmail.com wrote: Yehuda Katz (ph) 718.877.1325 On Mon, Nov 21, 2011 at 8:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 11:31 AM, Tab Atkins Jr. wrote: 1) Make sense. 2) Not break existing content. 3) Be short. .matches .is I like .is, the name jQuery uses for this purpose. Any reason not to go with it? IMHO 'is' seems awfully broad in meaning and doesn't very well indicate that the parameter should be a selector. Inasmuch I like .matches better. It's really clear in actual usage: someElement.is(div a:first-child); Please don't grab is! This is the property/attribute we want to use to identify components: div is=foobarf/div ... div.is == 'foobarf' :DG Also, FWIW, an 'is' attribute on elements was/is in discussion on this ML as one possibility to specify components. Cheers, - Roland
Re: XPath and find/findAll methods
On Nov 22, 2011, at 17:05 , Tab Atkins Jr. wrote: On Tue, Nov 22, 2011 at 4:16 AM, James Graham jgra...@opera.com wrote: Right, one of the issues with XPath is that the DOM3 XPath API is without doubt the worst API on the web platform. With a sane API there might be more demand for XPath since it can be used for things that the CSSWG are unlikely to ever allow in selectors for performance reasons. As Simon points out, there is even a preexisting API that does more or less the right thing and is implemented in IE and Opera. I believe there's a decent chance that we'll sprout a batch processers selectors spec or profile of the existing spec to handle things that are too expensive for normal CSS but perfectly fine when run in JS. Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis... d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects the a parent of a div, not divs that have parents containing an a. There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other. They solve the same set of use-cases in the same way, with the only difference being relatively minor abilities of each. That definitely makes them rivals. ^_^ We don't need two selection mechanisms with substantially different syntaxes. XPath may be useful as a source of more ideas to pull into Selectors, but that's it. Right, because since we have something that works why not invent another! Makes perfect sense to me. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
On 11/22/11 12:29 PM, Robin Berjon wrote: d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects thea parent of adiv, notdivs that have parents containing ana. Yes, that's what Tab's selector selects too. The '!' after the 'a' is important there. -Boris
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 17:05 , Tab Atkins Jr. wrote: On Tue, Nov 22, 2011 at 4:16 AM, James Graham jgra...@opera.com wrote: Right, one of the issues with XPath is that the DOM3 XPath API is without doubt the worst API on the web platform. With a sane API there might be more demand for XPath since it can be used for things that the CSSWG are unlikely to ever allow in selectors for performance reasons. As Simon points out, there is even a preexisting API that does more or less the right thing and is implemented in IE and Opera. I believe there's a decent chance that we'll sprout a batch processers selectors spec or profile of the existing spec to handle things that are too expensive for normal CSS but perfectly fine when run in JS. Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis... I'm much less concerned about that than I am about authors having to learn an entirely different selection syntax which is 90% identical in functionality, just to get that 10% functionality on occasion. d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects the a parent of a div, not divs that have parents containing an a. Ah, I see. I misread the XPath. In that case, this isn't *yet* doable in Selectors, but we plan to eventually support complex selectors in :matches(), at which point you can do: :matches(:scope a) div Or with a different syntax: :has(a) div That should match the XPath example now, if I understand you correctly. There are definitely lots of cases when CSS selectors are much more powerful than XPath. Mainly when there are many of class names and ids involved. And that is why I think that XPath and CSS selectors are not rivals - they are exactly the opposite, they complement each other. They solve the same set of use-cases in the same way, with the only difference being relatively minor abilities of each. That definitely makes them rivals. ^_^ We don't need two selection mechanisms with substantially different syntaxes. XPath may be useful as a source of more ideas to pull into Selectors, but that's it. Right, because since we have something that works why not invent another! Makes perfect sense to me. I know you're being somewhat hostile because you like XPath and we're essentially saying ignore XPath, it's dead, but still, you're arguing badly. The web platform has a single selection syntax that has won without question. If it lacks some abilities, extending it is almost certainly better for both implementations and authors than pulling in a completely different selection syntax that is *almost* identical in functionality but happens to include those abilities that were lacking. If this were any other pair of technologies, I highly doubt you'd be able to make yourself argue that having two gratuitously different syntaxes that authors have to regularly switch between based on the exact property they want, and which can't be used together in any simple way, is a good situation for us to create. That's almost a textbook example of valuing spec authors over everyone else. ~TJ
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
+ian since this wording is actually in the HTML spec. I'm not sure how exactly this should be specced. DOM4 could specify the two interfaces and HTML could use those definitions? On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/21/11 9:58 PM, Ojan Vafai wrote: I think this is the only sane solution to this problem. Lets split up the Element interface. I'm not attached to these names, but something like ElementExposed and Element. Element inherits (mixins?) ElementExposed and only the methods on ElementExposed are exposed to the on* lookup chain. This is somwhat backwards. In particular, expandos almost certainly need to be exposed on the on* lookup chain for backwards compat. So more precisely, only the properties and methods that are NOT on ElementExposed (nor on any other DOM APIs elements implement at the moment) are missing from the on* lookup chain. I agree that all new methods and properties we add should go in this set. How to structure this in spec terms is a good question. Hmmm. I wasn't thinking of expandos. We'll definitely need to keep supportting that. :( ElementExposed would have everything that is currently on the Element API and all new methods would go on Element. You could imagine that over time we could figure out the minimal set of APIs required by web compat to leave on ElementExposed and move everything else to Element. This exercise doesn't seem to be worthwhile. What would be the benefit? The fewer properties that are exposed this way, the smaller the quirk is. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. In fact, we should do this for form and document as well. Yes. -Boris
Re: [Web Intents] Task Force Mailing List set up
+cc:public-webintents -bcc:public-webapps -bcc:public-device-apis We'll have a wiki, though we're still working out the details on that end; it's particularly rough right now during the US holidays. I'll make sure to get back to the public-webintents list once the wiki and group are set up properly. For now I'm very keen to hear your ideas, and I think the public-webintents ML is a fine place to hash out your thoughts. Thanks, James On Mon, Nov 21, 2011 at 6:03 AM, Giuseppe Pascale giusep...@opera.comwrote: Great, thanks for moving this forward. Question: are we going to have also a wiki or will we re-use one of the wiki from dap and/or web-apps? I'm trying to flash out some thoughts around home discovery VS web intents and a wiki is a simple tool to outline some ideas. /g On Fri, 18 Nov 2011 18:05:46 +0100, James Hawkins jhawk...@google.com wrote: The Web Intents Task Force is starting to take shape! If you'd like to be a part of shaping this API, please involve yourself by joining the new mailing list. A W3C mailing list has been set up: http://lists.w3.org/Archives/**Public/public-web-intents/http://lists.w3.org/Archives/Public/public-web-intents/ To subscribe to this mailing list, send an email to public-web-intents-request@w3.**org public-web-intents-requ...@w3.orgwith the subject 'subscribe'. We've created a group for the TF: http://www.w3.org/2000/09/**dbwg/details?group=50861**public=1http://www.w3.org/2000/09/dbwg/details?group=50861public=1, though it's just a placeholder for now since the logistics of the group have not been worked out completely yet. I'll let you know once I know more. I'm in the process of uploading the draft of the API to w3.org; I'll send a message to public-web-intents once that's complete. Thanks, James -- Giuseppe Pascale TV Connected Devices Opera Software
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( -Boris
Re: Adding methods to Element.prototype
On Tue, Nov 22, 2011 at 5:28 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 22 Nov 2011 03:58:32 +0100, Ojan Vafai o...@chromium.org wrote: I think this is the only sane solution to this problem. Lets split up the Element interface. I think an IDL annotation would work better from a specification perspective. E.g. [NoScope]. Otherwise we'd need to do this interface split for each element type where we add new attributes. Sounds find to me. I'd prefer to have the annotation be [Scope] though. The default when adding new attributes should be to not scope them.
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... That's true for a large percentage of developers for sure, but most web developers I've talked to about this are surprised to learn about this behavior and have never (intentionally) depended on it. In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I've been trying to get some data on this, but I haven't had much success. I'll report back if I do. But even if I get data, it'll be for specific names, not a generic what do pages do in on* handlers, so it wouldn't actually help resolving this expando question. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) -Boris
Re: XPath and find/findAll methods
On Nov 22, 2011, at 18:31 , Boris Zbarsky wrote: On 11/22/11 12:29 PM, Robin Berjon wrote: d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects thea parent of adiv, notdivs that have parents containing ana. Yes, that's what Tab's selector selects too. The '!' after the 'a' is important there. Wait, I thought I'd grasped the gist of S4 but now you're confusing me :) My reading of Tab's selector is that it matches the a in adiv//a. What Martin's XPath matches is the div in sectiondiv/pa//p/section (amongst many other variants). It's all div's whose parents have an a descendent. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 11:38 AM, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 18:31 , Boris Zbarsky wrote: On 11/22/11 12:29 PM, Robin Berjon wrote: d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects thea parent of adiv, notdivs that have parents containing ana. Yes, that's what Tab's selector selects too. The '!' after the 'a' is important there. Wait, I thought I'd grasped the gist of S4 but now you're confusing me :) My reading of Tab's selector is that it matches the a in adiv//a. What Martin's XPath matches is the div in sectiondiv/pa//p/section (amongst many other variants). It's all div's whose parents have an a descendent. Pretty sure that Boris misunderstood your comment. I did too, at first, since I wasn't sure which example you were referring to. ^_^ You are correct on both counts. a! div matches a elements with a div child. To match the XPath selector, you need something more like *:matches(:scope a) div, which isn't yet a valid selector, but is roughly in line with how we want to extend :matches() in the future. ~TJ
Re: XPath and find/findAll methods
On Nov 22, 2011, at 18:57 , Tab Atkins Jr. wrote: On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon ro...@berjon.com wrote: Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis... I'm much less concerned about that than I am about authors having to learn an entirely different selection syntax which is 90% identical in functionality, just to get that 10% functionality on occasion. Developers will need to learn new syntax for new features anyway, and when you don't need the new stuff you can still use CSS anyway. I don't see how this is an argument. d - //div[parent::*//a]; In that case, this isn't *yet* doable in Selectors, but we plan to eventually support complex selectors in :matches(), at which point you can do: :matches(:scope a) div Or with a different syntax: :has(a) div Interesting. Do you have syntax examples for other typical selectors like //text() or //*[starts-with(name(@*), data-mylib-)]? It would be good to compare. Right, because since we have something that works why not invent another! Makes perfect sense to me. I know you're being somewhat hostile because you like XPath and we're essentially saying ignore XPath, it's dead, but still, you're arguing badly. I don't care about XPath, I care about getting stuff done. And by done, I mean preferably before I reach retirement age. One the one hand we have a solution that works today and can be made simple to use with minor tweaking. The time required to bang this API into shape is measured in months, definitely less than a year. Then I can get the sort of tree manipulation that I need, and I can stop pestering you. I think that works out great for all involved. Instead of this you're proposing some experimental, as-yet-undrafted, potentially-done-someday extension syntax to CSS that could, perhaps, address some of the use cases. If you're willing to put your arse on the line that the CSS WG can deliver a version of Selectors that matches XPath for functionality by TPAC next year, then by all means go ahead. But somehow, I don't believe that's the case, and I don't believe you do either. I don't care about syntax or overlap purity. I care about features. I don't care that the CSS WG has a deeply held grudge against XPath and will go to all extremes to admit that it might actually be useful. I care about being pragmatic and delivering functionality in a timely fashion and will take what's available. I don't care about standards wars and the battles you so fondly mention. I don't know what you mean by winning when you have authors coming to you asking for features that you are not delivering on. I care about getting those nodes, and what I call a win is when I can do so without hacking my way around the browser or loading KBs of libraries to do so. So, can you tell me again why we should prefer CSS WG-approved purity in some indeterminate future over something that works pretty much now? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 12:02 PM, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 18:57 , Tab Atkins Jr. wrote: On Tue, Nov 22, 2011 at 9:29 AM, Robin Berjon ro...@berjon.com wrote: Are you not concerned at the flood of puzzlement brought about by having the same language that supports different features at different places in the same runtime? I can already tell that I will get it wrong on a regular basis... I'm much less concerned about that than I am about authors having to learn an entirely different selection syntax which is 90% identical in functionality, just to get that 10% functionality on occasion. Developers will need to learn new syntax for new features anyway, and when you don't need the new stuff you can still use CSS anyway. I don't see how this is an argument. Come on, Robin, you're being unreasonable. You and I both know there's a huge difference between new features require small amounts of new syntax and oh look, it's an entirely different language. d - //div[parent::*//a]; In that case, this isn't *yet* doable in Selectors, but we plan to eventually support complex selectors in :matches(), at which point you can do: :matches(:scope a) div Or with a different syntax: :has(a) div Interesting. Do you have syntax examples for other typical selectors like //text() or //*[starts-with(name(@*), data-mylib-)]? It would be good to compare. Text nodes aren't selectable, though there's a recent request against the Selectors spec (tracked in bugzilla) to allow selecting them. I think it's a reasonable suggestion. The bug suggests doing this through a ::paragraphs pseudo-element. I thought that your second example was doable in Selectors 3, but then I remembered that the prefix-matching functionality is for values, not attribute names. Nobody has yet suggested that be supported. Right, because since we have something that works why not invent another! Makes perfect sense to me. I know you're being somewhat hostile because you like XPath and we're essentially saying ignore XPath, it's dead, but still, you're arguing badly. I don't care about XPath, I care about getting stuff done. And by done, I mean preferably before I reach retirement age. One the one hand we have a solution that works today and can be made simple to use with minor tweaking. The time required to bang this API into shape is measured in months, definitely less than a year. Then I can get the sort of tree manipulation that I need, and I can stop pestering you. I think that works out great for all involved. Instead of this you're proposing some experimental, as-yet-undrafted, potentially-done-someday extension syntax to CSS that could, perhaps, address some of the use cases. If you're willing to put your arse on the line that the CSS WG can deliver a version of Selectors that matches XPath for functionality by TPAC next year, then by all means go ahead. But somehow, I don't believe that's the case, and I don't believe you do either. I don't care about syntax or overlap purity. I care about features. I don't care that the CSS WG has a deeply held grudge against XPath and will go to all extremes to admit that it might actually be useful. I care about being pragmatic and delivering functionality in a timely fashion and will take what's available. I don't care about standards wars and the battles you so fondly mention. I don't know what you mean by winning when you have authors coming to you asking for features that you are not delivering on. I care about getting those nodes, and what I call a win is when I can do so without hacking my way around the browser or loading KBs of libraries to do so. So, can you tell me again why we should prefer CSS WG-approved purity in some indeterminate future over something that works pretty much now? Robin, you're familiar with XPath. You look at it and go Oh, neat, it has all the features I need!. I'm not. I look at it and go Oh, look, somebody took a subset of Selectors, gave it a different syntax for some reason, and then added some new stuff. I can't use the new Selectors stuff with the new XPath stuff, though, and now I have to remember two different syntaxes for the basic stuff. I am a sad tab.. I am quite certain that my position is closer to that of the average author than yours. Look at the platform as a whole. There is *no way* to justify having two completely separate mechanisms for accomplishing the exact same thing unless you're planning on replacing one with the other. Attempting to develop both Selectors and XPath in browsers at the same time, without plans to merge them, is undeniably a bad thing for authors and for the platform. This is not about theoretical purity. It's not about history, either (I came into the CSSWG too late to experience any of the battles you remember). It's about producing the best API for authors and the future, because I intend to
Re: XPath and find/findAll methods
* Tab Atkins Jr. wrote: I know you're being somewhat hostile because you like XPath and we're essentially saying ignore XPath, it's dead, but still, you're arguing badly. The web platform has a single selection syntax that has won without question. When Robin starts referring to himself in the third person, pretends to represent some newspeak web platform and claims it's without question that he is right, then you could probably say he is arguing badly. Such sad attempts at manipulating the debate, and discouraging participation by people who might disagree, usually come from elsewhere though. If it lacks some abilities, extending it is almost certainly better for both implementations and authors than pulling in a completely different selection syntax that is *almost* identical in functionality but happens to include those abilities that were lacking. If this were any other pair of technologies, I highly doubt you'd be able to make yourself argue that having two gratuitously different syntaxes that authors have to regularly switch between based on the exact property they want, and which can't be used together in any simple way, is a good situation for us to create. That's almost a textbook example of valuing spec authors over everyone else. Selectors are even less expressive today than what was proposed at the time Robin brought this issue up the first time on www-style, over a de- cade ago, as far as document structure is concerned. The main thing the CSS Working Group has done since was printing some Selectors Fan shirts. I am not sure who that is valuing, but it's neither authors nor users. Your argument about languages is interesting of course. If you want to set styles statically, you use CSS syntax, but if you want to do so dy- namically, you have to use JavaScript syntax once you leave the trivial feature set of CSS syntax. Maybe using JavaScript syntax for both would be better, so authors don't have to learn a whole new language? Authors might actually agree if they see future style sheets full of variables, mixins, media queries, feature detection rules, plus their jQuery codes to fill the styling gaps, that JSSS should have been the way to go. -- 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: XPath and find/findAll methods
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 2:13 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Tab Atkins Jr. wrote: I know you're being somewhat hostile because you like XPath and we're essentially saying ignore XPath, it's dead, but still, you're arguing badly. The web platform has a single selection syntax that has won without question. When Robin starts referring to himself in the third person, pretends to represent some newspeak web platform and claims it's without question that he is right, then you could probably say he is arguing badly. Such sad attempts at manipulating the debate, and discouraging participation by people who might disagree, usually come from elsewhere though. If it lacks some abilities, extending it is almost certainly better for both implementations and authors than pulling in a completely different selection syntax that is *almost* identical in functionality but happens to include those abilities that were lacking. If this were any other pair of technologies, I highly doubt you'd be able to make yourself argue that having two gratuitously different syntaxes that authors have to regularly switch between based on the exact property they want, and which can't be used together in any simple way, is a good situation for us to create. That's almost a textbook example of valuing spec authors over everyone else. Selectors are even less expressive today than what was proposed at the time Robin brought this issue up the first time on www-style, over a de- cade ago, as far as document structure is concerned. The main thing the CSS Working Group has done since was printing some Selectors Fan shirts. I am not sure who that is valuing, but it's neither authors nor users. Your argument about languages is interesting of course. If you want to set styles statically, you use CSS syntax, but if you want to do so dy- namically, you have to use JavaScript syntax once you leave the trivial feature set of CSS syntax. Maybe using JavaScript syntax for both would be better, so authors don't have to learn a whole new language? This is moot. Virtually all authors already know CSS ;) Authors might actually agree if they see future style sheets full of variables, mixins, media queries, feature detection rules, plus their jQuery codes to fill the styling gaps, that JSSS should have been the way to go. -- 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/
[Component Model] Decorator Challenges
This is a continuation of the Component Model discussion at TPAC, focusing on decorators (see definition here: http://wiki.whatwg.org/wiki/Behavior_Attachment). The design goal for decorators can summarized as follows: allow runtime (dynamic) application and unapplication of presentation (and possibly behavior, associated with the presentation) to a DOM element, regardless of the current state of the element, in a way that’s performant (both in memory and time space), and intuitive for today’s Web developers. The problem with decorators is not their application, but the unapplication. If the decorator maintains state, this requirement of unapplication creates a difficulty of understanding when the state matters, when it no longer does, and even whether it’s the same state/instance as the one you left just a moment ago. For example, running script inside of the decorator forces the decorator’s author to follow rules of engagement that differ from those in typical script development -- in non-obvious ways: * registering an event listener with any DOM node outside of the decorator produces undesirable effect of a listener sticking around even after the decorator is unapplied. * using setInterval/setTimeout/XHR, or anything that exits event loop produces an expectation of code running after the decorator is unapplied. * even just storing state inside of a decorator is challenging; in situations where decorator is unapplied/reapplied quickly (like matching a hover pseudoclass), the state is lost without any warning. Even if we attempt to separate the state of a decorator from the element and its document using an iframe- or worker-like machinery, we’ll still have similar issues of managing decorator instances that are no longer relevant, but don’t know that yet -- in addition to the performance costs of such high-isolation approach. One way to remove some state uncertainty could be to pool all decorators instances and reuse them on reapplication, rather than creating new instances. Unfortunately, this means that the decorators may never be reclaimed, which also impacts performance characteristics. We could explicitly prevent the decorator from ever having a state or being able to change it. This places a set of unorthodox (at least from author’s perspective) constraints on the DOM tree, created by the decorator. All of these constraints stem from the need to halt DOM changes in a decorator shadow subtree and include not allowing: * script elements, * contenteditable, * inline event handlers, * custom elements, etc. Conceptually, this type of arrangement is the one of DOM projection, where there’s only one instance of the decorator’s shadow DOM subtree in existence, and each application is just a rendering of that DOM tree. While the barrier for fully grokking the frozen-state DOM could be high for authors, this is probably the highest-performing solution, since application and unapplication of a decorator is just a matter of building and tearing down a box tree. All approaches mentioned here have their drawbacks, and it appears we either needs to invent something better or play the game of picking lesser evils. Personally, I am leaning slightly toward the projected DOM solution, because it yields fewer surprises for authors (it either works or it doesn’t -- right away) and enables nice performance. Thoughts and comments are appreciated. The gist of this email is also here: Also here: http://wiki.whatwg.org/wiki/Component_Model:_Decorator_Challenges :DG
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 11:52 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Nov 22, 2011 at 11:38 AM, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 18:31 , Boris Zbarsky wrote: On 11/22/11 12:29 PM, Robin Berjon wrote: d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects thea parent of adiv, notdivs that have parents containing ana. Yes, that's what Tab's selector selects too. The '!' after the 'a' is important there. Wait, I thought I'd grasped the gist of S4 but now you're confusing me :) My reading of Tab's selector is that it matches the a in adiv//a. What Martin's XPath matches is the div in sectiondiv/pa//p/section (amongst many other variants). It's all div's whose parents have an a descendent. Pretty sure that Boris misunderstood your comment. I did too, at first, since I wasn't sure which example you were referring to. ^_^ You are correct on both counts. a! div matches a elements with a div child. To match the XPath selector, you need something more like *:matches(:scope a) div, which isn't yet a valid selector, but is roughly in line with how we want to extend :matches() in the future. I really don't think that selectors can ever compete with the expressiveness of XPath. Consider the following expression: //div[count(.//span) 6][count(.//span[@data-foo = ../@data-bar]) mod 2 = 1] This expression finds all div elements which has at least 6 span descendants and where an odd number of those span elements have a data-foo attribute equal to its parents data-bar attribute. It is obviously trivial to add arbitrary additional complexity to this expression. Trying to do the same thing in Selectors will just result in a incomprehensible mess. At the same time, XPath can't ever compete in expressiveness to Javascript. Finding all div elements with a data-foo attribute that contains a prime number is not possible in XPath but trivial in javascript. I'm not convinced that it's worth investing in XPath. At least not beyond the low-hanging fruit of making most of the arguments to .evaluate optional. But I think trying to make selectors compete in expressiveness with XPath is a loosing battle. / Jonas
Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: The fewer properties that are exposed this way, the smaller the quirk is. I think the problem is that from web developers point of view the quirky behavior is _not_ exposing properties. Certainly in the short term... That's true for a large percentage of developers for sure, but most web developers I've talked to about this are surprised to learn about this behavior and have never (intentionally) depended on it. In the long term, since we have to expose all expandos, I suspect that not exposing properties will continue to be seen as the quirky behavior. Note, by the way, that having to expose expandos (including expandos on prototypes) but not new built-in properties might make for some fun spec-work (e.g., what happens when the standard adds a property but then some page overrides it on the prototype with a different property definition: should the page-defined value be exposed?). Again, some decent data on what pages actually do in on* handlers would be really good. I have no idea how to get it. :( I've been trying to get some data on this, but I haven't had much success. I'll report back if I do. But even if I get data, it'll be for specific names, not a generic what do pages do in on* handlers, so it wouldn't actually help resolving this expando question. I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) This is a feature that is definitely causing severe pain to the platform since it's putting constraints on APIs that we can add to our main data model, the DOM. It would be really awesome if we could figure out a way to fix this. I'd say the first step would be to evaluate if we actually need expandos. And be prepared to break a few pages by removing support for them. If we can agree to do that, then it's likely that we can create a small object which forwards a short list of properties to the form element (likely including the dynamic list of form element names) and only put that object in scope. / Jonas
Re: XPath and find/findAll methods
On Tue, Nov 22, 2011 at 4:08 PM, Jonas Sicking jo...@sicking.cc wrote: I really don't think that selectors can ever compete with the expressiveness of XPath. Consider the following expression: //div[count(.//span) 6][count(.//span[@data-foo = ../@data-bar]) mod 2 = 1] This expression finds all div elements which has at least 6 span descendants and where an odd number of those span elements have a data-foo attribute equal to its parents data-bar attribute. It is obviously trivial to add arbitrary additional complexity to this expression. Trying to do the same thing in Selectors will just result in a incomprehensible mess. At the same time, XPath can't ever compete in expressiveness to Javascript. Finding all div elements with a data-foo attribute that contains a prime number is not possible in XPath but trivial in javascript. I'm not convinced that it's worth investing in XPath. At least not beyond the low-hanging fruit of making most of the arguments to .evaluate optional. But I think trying to make selectors compete in expressiveness with XPath is a loosing battle. I agree with everything you say. I believe there are still things that XPath can do that we can pull into Selectors, but we definitely don't want the whole thing. XPath's notion of axis switching allows for a lot more power in a consistent notation than what you can get with Selectors. This is why I support .find() and NodeArray (or whatever it gets called), because they make it *really easy* to mix together Selectors and JS for essentially the same effects. Rather than having to add document.querySelectorAll(A :something-super-complex() B) we can just do document.findAll(A).filter(complex-function).findAll(B) ~TJ
Re: XPath and find/findAll methods
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 4:08 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 22, 2011 at 11:52 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Nov 22, 2011 at 11:38 AM, Robin Berjon ro...@berjon.com wrote: On Nov 22, 2011, at 18:31 , Boris Zbarsky wrote: On 11/22/11 12:29 PM, Robin Berjon wrote: d - //div[parent::*//a]; (d) can be done with the new subject indicator in the Selectors 4 draft: a! div (syntax pending, but that's the general idea) I think that the example you show selects thea parent of adiv, notdivs that have parents containing ana. Yes, that's what Tab's selector selects too. The '!' after the 'a' is important there. Wait, I thought I'd grasped the gist of S4 but now you're confusing me :) My reading of Tab's selector is that it matches the a in adiv//a. What Martin's XPath matches is the div in sectiondiv/pa//p/section (amongst many other variants). It's all div's whose parents have an a descendent. Pretty sure that Boris misunderstood your comment. I did too, at first, since I wasn't sure which example you were referring to. ^_^ You are correct on both counts. a! div matches a elements with a div child. To match the XPath selector, you need something more like *:matches(:scope a) div, which isn't yet a valid selector, but is roughly in line with how we want to extend :matches() in the future. I really don't think that selectors can ever compete with the expressiveness of XPath. Consider the following expression: //div[count(.//span) 6][count(.//span[@data-foo = ../@data-bar]) mod 2 = 1] The flip side of this is representing certain common HTML idioms in XPath (like find me an element with the class 'foo' or even find me an element with the class 'foo' that is an already-visited link). This expression finds all div elements which has at least 6 span descendants and where an odd number of those span elements have a data-foo attribute equal to its parents data-bar attribute. It is obviously trivial to add arbitrary additional complexity to this expression. Trying to do the same thing in Selectors will just result in a incomprehensible mess. At the same time, XPath can't ever compete in expressiveness to Javascript. Finding all div elements with a data-foo attribute that contains a prime number is not possible in XPath but trivial in javascript. I'm not convinced that it's worth investing in XPath. At least not beyond the low-hanging fruit of making most of the arguments to .evaluate optional. But I think trying to make selectors compete in expressiveness with XPath is a loosing battle. / Jonas
Re: XPath and find/findAll methods
Yehuda Katz (ph) 718.877.1325 On Tue, Nov 22, 2011 at 4:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Nov 22, 2011 at 4:08 PM, Jonas Sicking jo...@sicking.cc wrote: I really don't think that selectors can ever compete with the expressiveness of XPath. Consider the following expression: //div[count(.//span) 6][count(.//span[@data-foo = ../@data-bar]) mod 2 = 1] This expression finds all div elements which has at least 6 span descendants and where an odd number of those span elements have a data-foo attribute equal to its parents data-bar attribute. It is obviously trivial to add arbitrary additional complexity to this expression. Trying to do the same thing in Selectors will just result in a incomprehensible mess. At the same time, XPath can't ever compete in expressiveness to Javascript. Finding all div elements with a data-foo attribute that contains a prime number is not possible in XPath but trivial in javascript. I'm not convinced that it's worth investing in XPath. At least not beyond the low-hanging fruit of making most of the arguments to .evaluate optional. But I think trying to make selectors compete in expressiveness with XPath is a loosing battle. I agree with everything you say. I believe there are still things that XPath can do that we can pull into Selectors, but we definitely don't want the whole thing. XPath's notion of axis switching allows for a lot more power in a consistent notation than what you can get with Selectors. This is why I support .find() and NodeArray (or whatever it gets called), because they make it *really easy* to mix together Selectors and JS for essentially the same effects. Rather than having to add document.querySelectorAll(A :something-super-complex() B) we can just do document.findAll(A).filter(complex-function).findAll(B) This is essentially the same API we have in jQuery. I can confirm that allowing selectors to be mixed in with JavaScript traversal and filtering, possibly via additional selectors, does in fact alleviate the need for additional selectors. I can't think of the last time someone asked jQuery for new custom selectors, and we *do* have the infrastructure for it. ~TJ
Re: XPath and find/findAll methods
* Tab Atkins Jr. wrote: Come on, Robin, you're being unreasonable. You and I both know there's a huge difference between new features require small amounts of new syntax and oh look, it's an entirely different language. I can't make heads or tails of the 'nth' syntax despite implementing it a number of times, I always have to look up which direction '~' goes, I can't imagine what `a! div` or `:matches(:scope a) div` might match, and `:has(a) div` requires a good bit of meditation. If I go to the draft, it tells me that `:matches(:scope a) div` isn't even valid. When I learned XPath, I already knew . from file paths, it stands for the context you are in, .. is for the context one level above, / is the root, parent and child are separated by /, and I knew from many programming languages that + is addition, | is union, list[3] refers an element in a list, * is a wildcard, [@price 30] is a Where query. It doesn't really matter that the languages are different, what matters is how they differ, how they are constructed, what experience learners may already have, what tools are available that could aid them, and so on. The underlying argument that `:nth-last-of-type(+3n - 2)` is easier because authors have used `#header` in the past is rather silly. Robin, you're familiar with XPath. You look at it and go Oh, neat, it has all the features I need!. I'm not. I look at it and go Oh, look, somebody took a subset of Selectors, gave it a different syntax for some reason, and then added some new stuff. I can't use the new Selectors stuff with the new XPath stuff, though, and now I have to remember two different syntaxes for the basic stuff. I am a sad tab.. I am quite certain that my position is closer to that of the average author than yours. This is rather a matter of I need to make this query but browsers I care about don't all support making it with css selectors. I am glad I can't use XPath either because that option would make me sad. I don't think there is much interest in browsers adopting XPath 2.0, it would be a slow and buggy mess that would take many years to sta- bilize across browsers and platforms, as is usual for everything they attempt to implement, but you are not going to beef up selectors so they could somehow compete with the expressiveness of XPath without making the syntax even worse than it already is; and I rather doubt it would be a good idea to have advanced selectors only for scripting. For authors it would be much better to standardize the .selectNodes and .selectSingleNode methods and then find scripting means to combine them, like being able to compute the difference between two node sets with a simple call. Microsoft, with LINQ to XML, language additions to C#, and the generic IEnumerable extension methods have made a rather palatable DOM and JavaScript alternative in this spirit, with XPath support of course, but you wouldn't need it so often there. In some ways, selectors there can look more like JSSS... -- 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: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On Tue, Nov 22, 2011 at 4:12 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai o...@chromium.org wrote: On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/22/11 12:57 PM, Ojan Vafai wrote: I was hoping that we could have a fixed small list of properties that the spec says are exposed. Maybe that's too ambitious and doesn't actually buy us much though. Given the expando situation, I'm not sure that approach works at all. :( Well, it would be a small list + expandos. :) This is a feature that is definitely causing severe pain to the platform since it's putting constraints on APIs that we can add to our main data model, the DOM. It would be really awesome if we could figure out a way to fix this. I'd say the first step would be to evaluate if we actually need expandos. And be prepared to break a few pages by removing support for them. If we can agree to do that, then it's likely that we can create a small object which forwards a short list of properties to the form element (likely including the dynamic list of form element names) and only put that object in scope. Yes! I don't know how we can test this without just pushing out a release that does this and seeing what breaks though. Ojan
[indexeddb] error value of open request after aborting VERSION_CHANGE transaction inside an onupgradeneeded handler
What should be the value of the error attribute on the open request after a VERSION_CHANGE transaction is aborted? We're thinking it should be AbortError independent of whether the transaction is aborted programmatically or due to a system failure. Do you guys agree? Israel
Re: XPath and find/findAll methods
On 11/22/2011 05:30 AM, Lachlan Hunt wrote: On 2011-11-22 14:09, Boris Zbarsky wrote: On 11/22/11 8:05 AM, Lachlan Hunt wrote: The current draft of Selectors 4 includes :matches(), though, which can partially handle that case, excluding :not([type]), which would have to be left separate. That seems like a bug in :matches() that just needs fixing if it's meant as a replacement for :any(). Actually, I'm mistaken. The spec says that :matches() can't be used within :not(), rather than the other way around. There's a number of arbitrary restrictions in Selectors 4 in the :matches() and :not() definitions, which are there mainly to limit implementation complexity and I'm happy to remove if requested. The full definition is :matches() - matches the selector in its argument :not() - does not match the selector in its argument where any valid selector list [1] is a valid argument to :matches() and :not(). Combined with an IAmTheSubjectOfTheSelector indicator, this would allow matching against pretty much any tree pattern. (It's called :matches() rather than :any() because in the full version, it can be useful to use it with only one complex selector, i.e. without commas. And then the word any doesn't make as much sense, imho.) [1] I split out the term selector into a number of more specific terms, because it was getting really confusing. http://dev.w3.org/csswg/selectors4/#selector-list
