Re: [selectors-api] SVG WG Review of Selectors API
On Jan 27, 2009, at 00:18, Alex Russell wrote: We just need to invent a pseudo-property for elements which can be matched by a :not([someProperty=your_ns_here]). To select SVG elements while avoiding HTML elements of the same name, a selector that prohibits the local name foreignObject between an ancestor svg element and the selector subject would be good enough. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [selectors-api] SVG WG Review of Selectors API
On Wed, 28 Jan 2009 10:55:49 +0100, Henri Sivonen hsivo...@iki.fi wrote: On Jan 27, 2009, at 00:18, Alex Russell wrote: We just need to invent a pseudo-property for elements which can be matched by a :not([someProperty=your_ns_here]). To select SVG elements while avoiding HTML elements of the same name, a selector that prohibits the local name foreignObject between an ancestor svg element and the selector subject would be good enough. That wouldn't work for the general case though, since XML elements can occur anywhere in the svg markup. For an example, see Sun's Lively kernel[1]. But it's likely that there are selectors that would work for a majority of cases. Your statement does require that namespaces are not supported in the markup where the selectors API is used, or that it's guaranteed that no such markup occurs even though it may be permitted. Also such elements may be inserted through DOM calls, making the assumption about 'foreignObject' encapsulation invalid. Cheers /Erik [1] http://research.sun.com/projects/lively/index.xhtml -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [selectors-api] SVG WG Review of Selectors API
Maybe it was already proposed, but are there any problem to just add a
new argument to querySelectors and querySelectorsAll, with namespace
bindings?
I don't mean anything like XPathNSResolver or things like that. I just
mean a ES Object, where enumerable property names are namespace
prefixes, and their values are their URI. Invalid properties (whose
name doesn't match the production for a namespace prefix in Namespaces
in XML or whose value is not an URI) are simply ignored.
That is, for any enumerable property in the new argument, a @namespace
declaration will be implied. No other information will be considered
(such as inherited bindings or @namespace declarations outside), any
prefix not bound at selector resolution will cause a NAMESPACE_ERR.
1) people consider it adequate etc: well, it is easy to do (just
{xhtm: http://www.w3.org/1999/xhtml;, svg:
http://www.w3.org/2000/svg; }) and poweful
2) don't have security issues: are there any security issues with
namespaces in general?
3) don't have undefined behaviour: as I said, it acts like an implied
sequence of @namespace, whose are fully covered (in good and bad
behaviour) by Namespaces in CSS
Hope you'll put this feature at least in version 2 of Selectors API,
or people will go back to XPath.
Giovanni
Re: [selectors-api] SVG WG Review of Selectors API
I asked that question a little ago. I was answered, and agreed, that CSS selectors are easier to understand, are already known by authors because of their use in CSS and most important they're highly optimized in UAs. 2009/1/28 Anne van Kesteren ann...@opera.com: On Wed, 28 Jan 2009 14:25:29 +0100, Giovanni Campagna scampa.giova...@gmail.com wrote: Hope you'll put this feature at least in version 2 of Selectors API, or people will go back to XPath. If that were the case, why would they switch in the first place? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Wed, 28 Jan 2009 14:32:05 +0100, Giovanni Campagna scampa.giova...@gmail.com wrote: I asked that question a little ago. I was answered, and agreed, that CSS selectors are easier to understand, are already known by authors because of their use in CSS and most important they're highly optimized in UAs. Ok. I note that in your original e-mail you did not explain why authors would go back to XPath if we did not give namespace support in the next version of the API. Do you expect that namespace usage which requires using namespaced selectors will increase significantly in the upcoming years justifying the added complexity? And if you do expect that, why? Although namespace support was dropped in part because of technical issues, not having compelling use cases is something I think we should overcome first. Because if there are no compelling use cases, making the API more complex is not worth it. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
Giovanni Campagna wrote: Maybe it was already proposed, but are there any problem to just add a new argument to querySelectors and querySelectorsAll, with namespace bindings? The original spec did contain an NSResolover argument, which was based upon the XPathNSResolver. It was dropped for technical reasons and lack of use cases. For a discussion of alternatives, see the thread beginning this message: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0115.html Hope you'll put this feature at least in version 2 of Selectors API, or people will go back to XPath. It would really help a lot if those who believe being able to resolve namespaces is an important feature, could document clear use cases that cannot be solved easily without, or would be solved more easily with, support for namespaces. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
@Anne: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) or svg not(timesheet) animation (all SVG but not SMIL animations), or select[bind], select[ref] (xforms selects) I think that those example are even easier to rewrite as svg|*[href], svg|animation, xforms|select, provided a reliable namespace binding mechanisms (the one I proposed) @Lachlan: I read all the old topic, the main points are: 1) discussion of pros and cons of available technologies (don't use functions or objects to avoid infinite loops or recursion, don't use string to avoid syntax problems), it looks that a NSResolver object (a wrapped hash map, not an interface for a js function like XPathNSResolver) is the best solutions 2) discussion of use cases for namespace resolution: authors are not required to use javascript libraries (like Anne suggests), but current workarounds are difficult, so use cases exist 3) decision to drop namespace support in current version: my proposal is not necessarily for current version, but in version 2 (or level 2) of selectors api we definetely need it.
Re: [selectors-api] SVG WG Review of Selectors API
a) authors create multiply namespaced documents, so they need a way to reliably traverse those documents (either with namespace support or not) b) svg links support attributes that xhtml links (i mean xhtml2 links, ie any element with a href) do not: modifying those attributes is a use case (for example to disable them and to create a little popup, like GMail in editing mode does) the same applies obviously for any element: different elements need a way to be selected differently. Reasons may be various: if I want to submit xform using xhr, I must differentiate between html select and xforms select (this is a concrete use case). If I want to imperatively animate xhtml links (to do something more complex than declarative animations and to avoid putting any element in a dedicated svg) i need to fetch all links (*[href]) in the xhtml namespaces. Even if there weren't use case (but there are), we should not constrain the features of language. Newer authors, with newer ideas and newer languages, will thank us if we put namespace support in selectors API. Giovanni 2009/1/28 Anne van Kesteren ann...@opera.com: On Wed, 28 Jan 2009 15:28:42 +0100, Giovanni Campagna scampa.giova...@gmail.com wrote: @Anne: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) or svg not(timesheet) animation (all SVG but not SMIL animations), or select[bind], select[ref] (xforms selects) I think that those example are even easier to rewrite as svg|*[href], svg|animation, xforms|select, provided a reliable namespace binding mechanisms (the one I proposed) Well, a) that's quite an assumption which needs to be elaborated on somehow and b) those are indeed examples of things you can select easier with namespace support but it is not at all clear why you want to do such a thing in the first place. I.e. they are not use cases. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) or svg not(timesheet) animation (all SVG but not SMIL animations), or select[bind], select[ref] (xforms selects) I think that those example are even easier to rewrite as svg|*[href], svg|animation, xforms|select, provided a reliable namespace binding mechanisms (the one I proposed) The use case should try to answer the following questions. Try to be as specific and realistic as possible, and provide links to real world examples if you can. Let's go with the first example you gave of selecting all SVG links: svg :not(foreignObject) *[href]. Note that the example selector provided won't actually work to select all SVG links, at least not in the general case. The only way that could work is like this: svg:not(foreignObject)[href], svg:not(foreignObject):not(foreignObject)[href], svg:not(foreignObject):not(foreignObject):not(foreignObject)[href], ... 1. Why is the author mixing SVG and, presumably, HTML in this case? I know there are use cases for this in general, but we should be specific about which. 2. Why does the SVG contain links? This may be partially answered by the previous question. Preumably this means that it's not meant as a purely decorative image and the links provide the user with something useful. 3. Why does the SVG image contain links using elements from a foreign namespace in addition to links using elements from its own namespace? 4. What is the author trying to achieve using a script that needs to obtain those links, and why does it only affect links from the SVG namespace, and not all links within the SVG image, including those from other namespaces within foreignObject? If you can think of any other questions, feel free to ask them and answer them. The more information we have about the use cases, the easier it will be to evaluate them and find an appropriate solution. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
2009/1/28 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) I should note that that selector doesn't actually work to select things that are not inside a foreignObject... Offhand, I see no way to do that, in fact. Why shouldn't it? 1) discussion of pros and cons of available technologies (don't use functions or objects to avoid infinite loops or recursion, don't use string to avoid syntax problems), it looks that a NSResolver object (a wrapped hash map, not an interface for a js function like XPathNSResolver) is the best solutions Would you be willing to expand on why you think that's the best solution? (Maybe it is; I'd just like to know the analysis that led to this decision.) It is the summary of the email Lachlan linked, with pros and cons of various solutions. The only argument against NSResolver (called NamespaceResolver in that email) is that we need some new IDL in the spec. It would be really nice to make progress here, since I do think that namespace support in Selectors API would be quite useful for the SVG case... -Boris It is not only SVG, it is any markup language that may be mixed to build a compound document. 2009/1/28 Lachlan Hunt lachlan.h...@lachy.id.au: Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) or svg not(timesheet) animation (all SVG but not SMIL animations), or select[bind], select[ref] (xforms selects) I think that those example are even easier to rewrite as svg|*[href], svg|animation, xforms|select, provided a reliable namespace binding mechanisms (the one I proposed) The use case should try to answer the following questions. Try to be as specific and realistic as possible, and provide links to real world examples if you can. Let's go with the first example you gave of selecting all SVG links: svg :not(foreignObject) *[href]. Note that the example selector provided won't actually work to select all SVG links, at least not in the general case. The only way that could work is like this: svg:not(foreignObject)[href], svg:not(foreignObject):not(foreignObject)[href], svg:not(foreignObject):not(foreignObject):not(foreignObject)[href], ... Again I ask the same question I asked to Boris: why svg *:not(foreignObject) *[href] is not supposed to work? 1. Why is the author mixing SVG and, presumably, HTML in this case? I know there are use cases for this in general, but we should be specific about which. Because SVG allows for greater presentation than HTML and CSS, but this greater presentation only applies to a small part of the document. Or because I have two versions of the same page, one in SVG and one in HTML, switched by CSS and media queries or JS. 2. Why does the SVG contain links? This may be partially answered by the previous question. Preumably this means that it's not meant as a purely decorative image and the links provide the user with something useful. Because SVG links follow the SVG rendering model: they're positioned, stroked, alpha blended, animated. Instead HTML links are flowed and follow the CSS rendering model. Only their container (foreignObject) is part of the SVG image. Either you put an foreignObject for each link, or you don't use HTML links. 3. Why does the SVG image contain links using elements from a foreign namespace in addition to links using elements from its own namespace? As I said earlier, SVG links are different from HTML links in that HTML is flowed. If I want to have a rich user interface with animating buttons on the top of my SVG, but I want to have some HTML content in the same image, I need HTML links. 4. What is the author trying to achieve using a script that needs to obtain those links, and why does it only affect links from the SVG namespace, and not all links within the SVG image, including those from other namespaces within foreignObject? As I said before, scripting may need those for imperative animation, usually more powerful (but less performant) than declarative one. It may need only SVG links because SVG links are completely different than HTML links. Setting a strokeColor CSS property on HTML link has no effect. If you can think of any other questions, feel free to ask them and answer them. The more information we have about the use cases, the easier it will be to evaluate them and find an appropriate solution. This is was not a complete use case, it was just an example. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/ Giovanni
Re: [selectors-api] SVG WG Review of Selectors API
Giovanni Campagna wrote: 2009/1/28 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) I should note that that selector doesn't actually work to select things that are not inside a foreignObject... Offhand, I see no way to do that, in fact. Why shouldn't it? svg xmlns=http://www.w3.org/2000/svg; g foreignObject foo xmlns= href=This is my random href attribute/ /foreignObject /g /svg The foo element matches the svg :not(foreignObject) *[href] selector. Indeed, *[href] matches the foo element, :not(foreignObject) matches the g, and svg matches the svg. It is the summary of the email Lachlan linked, with pros and cons of various solutions. Oh, ok. So that was just reiterating what had already been said. Gotcha. It is not only SVG, it is any markup language that may be mixed to build a compound document. There is a lot less of a problem with languages that don't have colliding localNames. -Boris
Re: [selectors-api] SVG WG Review of Selectors API
2009/1/28 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: 2009/1/28 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: well, assuming that an author will need to match elements across multiple namespaces, it will be easier to use XPath (that also is compatible across multiple browsers) than to use horrible workarounds like svg :not(foreignObject) *[href] (all svg links) I should note that that selector doesn't actually work to select things that are not inside a foreignObject... Offhand, I see no way to do that, in fact. Why shouldn't it? svg xmlns=http://www.w3.org/2000/svg; g foreignObject foo xmlns= href=This is my random href attribute/ /foreignObject /g /svg The foo element matches the svg :not(foreignObject) *[href] selector. Indeed, *[href] matches the foo element, :not(foreignObject) matches the g, and svg matches the svg. One point in favour of namespace support then! It is the summary of the email Lachlan linked, with pros and cons of various solutions. Oh, ok. So that was just reiterating what had already been said. Gotcha. It is not only SVG, it is any markup language that may be mixed to build a compound document. There is a lot less of a problem with languages that don't have colliding localNames. Mix HTML with SMIL and you get duplicate audio and video. Mix HTML with XForms and you get duplicate input,textarea,select,label. Is not only SVG Giovanni
Re: [selectors-api] SVG WG Review of Selectors API
Giovanni Campagna wrote: 2009/1/28 Boris Zbarsky bzbar...@mit.edu: svg xmlns=http://www.w3.org/2000/svg; g foreignObject foo xmlns= href=This is my random href attribute/ /foreignObject /g /svg The foo element matches the svg :not(foreignObject) *[href] selector. Indeed, *[href] matches the foo element, :not(foreignObject) matches the g, and svg matches the svg. One point in favour of namespace support then! The purely technical limitations are already well understood. This in itself is not a point in favour of introducing namespaces. The above problem occurs with any other kind of selector using :not() in the sequence, wanting a way to filter out a specific element from the ancestor chain. It's not just a namespace related limitation. The issue remains the lack of clear use cases demonstrating *why* the problem should be solved. That is, why should we address that particular technical limitation above? 1. Why is the author mixing SVG and, presumably, HTML in this case? I know there are use cases for this in general, but we should be specific about which. Because SVG allows for greater presentation than HTML and CSS, but this greater presentation only applies to a small part of the document. Or because I have two versions of the same page, one in SVG and one in HTML, switched by CSS and media queries or JS. This is not a use case. They're technical reasons for choosing SVG as the solution to some particular use case or problem. What is the specific use case that is being addressed? For example, this is a hypothetical use case I've made up to demonstrate what I'm looking for. (Of course, I would expect any real use case to not simply be made up like this one, but rather based on something real world authors would want to do, ideally supported by real world examples.) --- A city rail transport website wants to provide a map of the rail network. The map is drawn in a diagram style, just like the London Tube map. The map user needs to be able to zoom in and scale the map easily, and clicking on a station on the provides more information about that station and the lines that pass through it. SVG is being used because it's scalable and scripts can be used to scale it easily as the user zooms in. The linking abilities also allow the user to click on a station, and the solution is deemed to be better than the alternative using a PNG and an image map. --- 2. Why does the SVG contain links? This may be partially answered by the previous question. Preumably this means that it's not meant as a purely decorative image and the links provide the user with something useful. Because SVG links follow the SVG rendering model: they're positioned, stroked, alpha blended, animated. Instead HTML links are flowed and follow the CSS rendering model. Only their container (foreignObject) is part of the SVG image. Either you put an foreignObject for each link, or you don't use HTML links. Again, this does not answer the question of what the links are being used for. It just provides more technical details about the solution. However, note that the above example use case I provided answers both the first and second questions clearly by itself. It does not, however, answer the third or fourth. (If I knew of some use cases that answered those questions, we wouldn't be having this discussion) 3. Why does the SVG image contain links using elements from a foreign namespace in addition to links using elements from its own namespace? As I said earlier, SVG links are different from HTML links in that HTML is flowed. If I want to have a rich user interface with animating buttons on the top of my SVG, but I want to have some HTML content in the same image, I need HTML links. This does not explain why the image would use SVG elements for some links and HTML elemenets for others within the same image. As far as I can tell, the above use case I provided doesn't need to use HTML links at all, so it's probably not one that is suitable for answering the questions I asked you, nor providing justification for adding namespace support. However, I only provided it for illustrative purposes to show what a use case is. It's the responsibility of you and others who are pushing for the namespace feature to present real use cases, not mine. 4. What is the author trying to achieve using a script that needs to obtain those links, and why does it only affect links from the SVG namespace, and not all links within the SVG image, including those from other namespaces within foreignObject? As I said before, scripting may need those for imperative animation, usually more powerful (but less performant) than declarative one. It may need only SVG links because SVG links are completely different than HTML links. Setting a strokeColor CSS property on HTML link has no effect. In that case, if there are no HTML links within the image, what
Re: [selectors-api] SVG WG Review of Selectors API
On Mon, 26 Jan 2009 18:21:21 +0100, Lachlan Hunt lachlan.h...@lachy.id.au wrote: Lachlan Hunt wrote: Erik Dahlström wrote: On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt lachlan.h...@lachy.id.au wrote: == 8. Examples Please add an example such as this one: ... Then explain how to use the Selectors API to select only the svg 'font' elements and how to select only the svg font elements that have a prefix on the element. As Boris explained, and as I'm sure you're well aware, it is not possible to distinguish between elements with the same local name without using namespaces. I cannot demonstrate the impossible and have not included the example in the spec. The SVG WG disagrees with this reasoning. People will run into this problem, and it seems appropriate to give an example and to show how to work around the lack of namespace-aware selectors. Note that even if it's not possible to distinguish between the elements using Selectors API alone, the result can be filtered e.g using DOM Core methods to give a meaningful result. Another workaround could be to pass a descendant combinator selector such as svg font to check the the font element has an svg element ancestor, this would cover many of the use-cases. I will reconsider this issue shortly. Erik provided me with demo to base the example on. I have simplified it to illustrate the relevant technique and included the example within the spec. You may review the changes in the latest editor's draft. http://dev.w3.org/2006/webapi/selectors-api/#examples0 I believe this was the last issue from the SVG WG I needed to resolve. Please let me know if you are satisfied with this response, and my previous resolutions for other issues. Indeed that's the last unresolved SVG WG LC comment (having looked through the archives). We are satisfied with the current editors draft. Thank you for adding the example. This compromise resolution is acceptable. Cheers /Erik, (ACTION-2378) -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [selectors-api] SVG WG Review of Selectors API
Hi Alex, On Jan 27, 2009, at 18:13 , Alex Russell wrote: I really do loathe namespaces, but is the selectors API actually going to be this impoverished? I understand your argument, but I'm afraid you're beating a dead horse. This ship has pretty much sailed, and agreement has been reached on the current consensus. Unless you can raise a detailed and precise technical issue against the draft that hasn't been addressed before nothing you say will change the resolution. I do not doubt that you're a smart guy but given how thoroughly this issue has been whacked on already, the odds are against you. If so, I fear it will prevent the actual mixing of SVG and HTML in meaningful ways. Thankfully that is not the case. You can use the API as is with mixed documents and just ignore the namespaces. There are cases in which it will fail but those cases are largely theoretical, and can be worked around (as illustrated previously in this thread). The Web will live. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] SVG WG Review of Selectors API
Alex Russell wrote: So to recap: 1.) someone made a mistake by allowing namespaces in XML 2.) SVG makes heavy use of this feature as a way to specify many intrinsic operations for which HTML simply adds local tags (e.g., links) 3.) well intentioned attempts to unify the platform say hey! lets get everyone using the same (good enough) query language! 4.) the SVG world points out their heavy reliance on XML features 5.) we tell them to go script themselves instead of exposing an intrinsic property of tags to the extant selector syntax I really do loathe namespaces, but is the selectors API actually going to be this impoverished? If so, I fear it will prevent the actual mixing of SVG and HTML in meaningful ways. Please describe significant, concrete use cases that you believe absolutely cannot be solved using the existing API without native support for namespaces. Also, I will note that many JavaScript libraries, including Dojo, lack support for namespaces in their selector implementations. This is one reason why support for them wasn't seen as particularly important at this stage. However, I will again note that the decision has been made to proceed with this version without support for namespace prefix resolution, and to reverse the decision now would hold up the spec for several months. This will then have a direct impact on the ability to begin version 2, in which this and, IMHO, much more significant issues [1], especially the ones affecting JS libraries the most today, are likely to be addressed. [1] http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Selectors+API -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
Lachlan Hunt wrote: Erik Dahlström wrote: On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt lachlan.h...@lachy.id.au wrote: == 8. Examples Please add an example such as this one: ... Then explain how to use the Selectors API to select only the svg 'font' elements and how to select only the svg font elements that have a prefix on the element. As Boris explained, and as I'm sure you're well aware, it is not possible to distinguish between elements with the same local name without using namespaces. I cannot demonstrate the impossible and have not included the example in the spec. The SVG WG disagrees with this reasoning. People will run into this problem, and it seems appropriate to give an example and to show how to work around the lack of namespace-aware selectors. Note that even if it's not possible to distinguish between the elements using Selectors API alone, the result can be filtered e.g using DOM Core methods to give a meaningful result. Another workaround could be to pass a descendant combinator selector such as svg font to check the the font element has an svg element ancestor, this would cover many of the use-cases. I will reconsider this issue shortly. Erik provided me with demo to base the example on. I have simplified it to illustrate the relevant technique and included the example within the spec. You may review the changes in the latest editor's draft. http://dev.w3.org/2006/webapi/selectors-api/#examples0 I believe this was the last issue from the SVG WG I needed to resolve. Please let me know if you are satisfied with this response, and my previous resolutions for other issues. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
Alex Russell wrote: Can this be represented in a :not() clause somehow? Foisting more work onto script is the wrong answer. No. The SVG WG explicitly requested an example illustrating how to filter elements based on the namespace URI that works in the general case, given that there is no longer a namespace prefix resolution mechanism supported in this version of the API. I'm well aware that with the specific markup example given in the spec, the selector svgvideo would have the same result in this case, but that doesn't work for the general case, which is what the SVG WG wanted to see. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Jan 26, 2009, at 1:49 PM, Lachlan Hunt wrote: Alex Russell wrote: Can this be represented in a :not() clause somehow? Foisting more work onto script is the wrong answer. No. How about not yet? Needing to do this filtering in script is clearly a spec bug. QSA is already littered with them, but an inability to filter an intrinsic property of a tag in the query language that's native to the platform is tactable. We just need to invent a pseudo-property for elements which can be matched by a :not([someProperty=your_ns_here]). The SVG WG explicitly requested an example illustrating how to filter elements based on the namespace URI that works in the general case, given that there is no longer a namespace prefix resolution mechanism supported in this version of the API. So they obliquely pointed out a spec bug. Don't get me wrong, I'm no lover of namespaces. Frankly I think they're a bug. But SVG is stuck w/ 'em until it can find a way to evolve out of the XML ooze. Until that time, we must surely be able to do better by folks who want to try to make the platform feel unified, no? Regards I'm well aware that with the specific markup example given in the spec, the selector svgvideo would have the same result in this case, but that doesn't work for the general case, which is what the SVG WG wanted to see.
Re: [selectors-api] SVG WG Review of Selectors API
Hi, Alex- Alex Russell wrote (on 1/26/09 5:18 PM): Don't get me wrong, I'm no lover of namespaces. Frankly I think they're a bug. But SVG is stuck w/ 'em until it can find a way to evolve out of the XML ooze. LOL - evolve out of the XML ooze Until that time, we must surely be able to do better by folks who want to try to make the platform feel unified, no? That was indeed our motivation for raising the issue. We are also working with the HTML and WebApps WGs in general to unify the platform in other ways, including mixing SVG into text/html. We are also looking at decreasing unnecessary dependence on namespaces (such as potentially allowing @href to be used in the null ns (that is, not prefixed with xlink:). Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [selectors-api] SVG WG Review of Selectors API
Alex Russell wrote: On Jan 26, 2009, at 1:49 PM, Lachlan Hunt wrote: Alex Russell wrote: Can this be represented in a :not() clause somehow? Foisting more work onto script is the wrong answer. No. How about not yet? I think the more correct answer is not in this version. / Jonas
Re: [selectors-api] SVG WG Review of Selectors API
On Dec 9, 2008, at 01:06 , Lachlan Hunt wrote: Robin Berjon wrote: On Dec 8, 2008, at 17:26 , Lachlan Hunt wrote: Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html That's a shame, they should be defined for a DOM that supports XML features, especially the xml namespace. Although the xml and xmlns prefixes are predefined for use in XML, neither the Selectors spec, nor the CSS Namespace Module predefine them for use with Selectors in CSS. There is no reason why this should be any different for Selectors used in this API. If you still disagree, then I suggest you take up the issue with the CSS WG, as it would be more appropriate to address the issue in either Selectors or the CSS Namespace Module, if at all. Yes, it would be right to fix that there too, but I've long ago lost any hope of doing anything about the CSS WG's irrational-bordering-on- frothing hatred for all things even vaguely related to XML. I'd rather that the WebApps WG made up its own mind on these issues rather than hide behind someone else's bigotry. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Mon, 08 Dec 2008 20:12:11 +0100, Erik Dahlström [EMAIL PROTECTED] wrote: IMHO the spec is trying to require something that is not enforcable anyway, and might as well not mention it, but instead just describe what happens for all possible indata. Valid SVG, valid XHTML, or valid HTML are not enforced (per specification), yet are RFC 2119 MUST requirements in their respective specifications. (Though in case of scripting MUST requires solving a certain unsolvable problem, so maybe MUST is not that appropriate...) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: Doug Schepers wrote: As a high-level comment, the SVG WG would prefer to see support for namespaces in the specification. We believe that there will be an increasing amount of (X)HTML+SVG content produced, and that there are a number of cases where it would be easier for authors to have this functionality natively, instead of hacking the results of a selector query. However, we are also sensitive to the preference to get the functionality into developers' hands as quickly and interoperably as possible, and don't wish to obstruct quick adoption of this specification. As a compromise, we believe that if the NSResolver support remains removed from this specification, there should be explicit mention of workarounds (see below), and an informative note mentioning that it may be readded in a future version of the spec, to ensure that implementers set up their architecture accordingly. There are several features which will be considered for inclusion in the next version of the spec. Why should this one in particular be called out over any other requested feature? Given that NSResolvers were taken out of the spec it deserves to be called out, and the problem described. Were there any other features that were removed in this LC draft? The SVG WG have no objections to listing other features that will be added in the next version. == 1.1 Examples This script will also function correctly for a table written in XHTML markup instead of HTML. I suggest this be reworded to say something like If the above table is converted to wellformed XHTML markup then this script will function correctly on that as well. The real intention of that statment is to illustrate that the method works on the DOM, independently from any specific syntax used to create the DOM. I have rewritten it to make that more clear. Note that the script operates on the DOM and works independently from the syntax used to create the document. Thus this script will also work correctly for an equivalent table created from well-formed XHTML instead of HTML, or dynamically created and inserted into a document using DOM APIs. Thanks, that is satisfactory. == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? The group of selectors must not use namespace prefixes that need to be resolved. That also sounds like an authoring requirement. If it's an authoring requirement please mark it as informative, or as only applying to conforming applications. See http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0453.html. The implementation must first trim any leading or trailing whitespace from the value of the selectors parameter. The implementation must then process the value according to the grammar of Selectors ([SELECT], section 10). If the processing means that the whitespace-trimmed value must match the 'selectors_group' production please say so. I have addressed these two concerns by adjusting the requirements for conforming applications to state: The caller must pass a valid group of selectors that matches the selectors_group production ([SELECT], section 10) with the additional provision that leading and trailing whitespace ([SELECT], section 4) is permitted. This first part is satisfactory. This group of selectors must not use namespace prefixes that need to be resolved. What are the consequences on future versions of the spec? The SVG WG will agree to the proposed wording if NSResolvers (or equivalent) are listed as a feature to be added in the next version of the spec. Selectors are evaluated against a given element in the context the entire DOM tree in which the element is located. ...in the context of? I'm not sure how to phrase that any more clearly. It means that when evaluating a selector, all elements in the document may be taken into account, and not just those within the node's subtree. You were only missing an 'of' in the sentence there, simply adding that will be enough to satisfy this comment. This means that the object will instead contain a list of matching Element nodes that were in the document at the time the list was created. Is this time defined? I propose to reword it as follows: This means that the object will instead contain a list of matching Element nodes that were in the document at the time the method was invoked. IIRC, the original reason for saying at the time the list was created instead of what you propose was that, when the NSResolver was still part of the spec, it was possible that the nsresolver function could modify the document in
[selectors-api] Use case for passing invalid selector (was: Re: [selectors-api] SVG WG Review of Selectors API)
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? Consider the custom pseudo-classes in http://docs.jquery.com/Selectors It seems reasonable to me to just try the selector with the Selectors API and catch the exception, instead of parsing the argument manually making sure it's a valid group of selectors before passing it to the Selectors API. -- Simon Pieters Opera Software
Re: [selectors-api] SVG WG Review of Selectors API
On Dec 9, 2008, at 10:28 , Anne van Kesteren wrote: On Mon, 08 Dec 2008 20:12:11 +0100, Erik Dahlström [EMAIL PROTECTED] wrote: IMHO the spec is trying to require something that is not enforcable anyway, and might as well not mention it, but instead just describe what happens for all possible indata. Valid SVG, valid XHTML, or valid HTML are not enforced (per specification), yet are RFC 2119 MUST requirements in their respective specifications. (Though in case of scripting MUST requires solving a certain unsolvable problem, so maybe MUST is not that appropriate...) Would it make everyone happy to a) keep the MUST, b) indicate which conformance class it belongs to, and c) describe what the implementation does when handling bad input? I agree that only (c) is really vital, but (a) could be enforced by authoring/validation/ quality control/etc. tools, and (b) makes it clear to API implementers that they can skip that sentence and go eat pizza instead. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Dec 9, 2008, at 12:46 , Erik Dahlström wrote: On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: As a compromise, we believe that if the NSResolver support remains removed from this specification, there should be explicit mention of workarounds (see below), and an informative note mentioning that it may be readded in a future version of the spec, to ensure that implementers set up their architecture accordingly. There are several features which will be considered for inclusion in the next version of the spec. Why should this one in particular be called out over any other requested feature? Given that NSResolvers were taken out of the spec it deserves to be called out, and the problem described. Were there any other features that were removed in this LC draft? I think the important part of the comment is to ensure that implementers set up their architecture accordingly. Now that's a bit of a pipe dream in the general case, but there is a specific issue to do with this specific situation. See below. Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html So essentially Selectors API is a downlevel client[2]? That's an interesting question. From that section of CSS Selectors (http://www.w3.org/TR/css3-selectors/#downlevel ): down-level client will view and match element type and attribute selectors based on their fully qualified name (...). CSS selectors may be declared using an escaped colon \: to describe the fully qualified names, e.g. html\:h1 will match html:h1. And further: Note that selectors declared in this fashion will /only/ match in down-level clients. (original emphasis) So say some service I'm using sends me some piece of DOM containing evil:kitten dahut:type='tamarou'/ and a bunch more of that, with proper namespace declarations and all. I'm one sexy hacker and I want all them kittens, and the only way that works is: var cutesy = document.querySelectorAll(evil\\:kitten); So that's all fine and good, but now you crazy kids at the browser factories decide to ship us a new a wicked cooler Selectors API, that supports NSResolver (or something like that). What happens? Does my code break suddenly? Or do you detect that I'm not using an NSResolver and implement a special branch of the code to emulate dumblevel clients? Do you hack your parser so that selectors that match using \: match against the QName and the rest use namespaces (and if so what do we do with those that have neither \: nor | ?). From here it looks like a good plan for a punk rock concert, except without the music and without the beer. So if we're not going to have the fun stuff, I formally request that the spec be light on the drugs and violence, and include a discussion of its strategy to include namespace support later without breaking the above case. Please explain how providing a reference to DOM 3 XPath would be of any benefit? How would it help readers in their understanding of this spec? There are limitations in Selectors API that will force people into either doing workarounds, or to use another technology for the selection. It seems the SVG WG isn't alone in wanting to have the informative reference to DOM 3 XPath: http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 0451.html http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/ 0449.html These two could in fact be tied together into a Working with Namespaces section. My example above would have been evolution- friendly had it used D3XPath instead of hacking around Selectors' limitations. == 8. Examples Please add an example such as this one: html xmlns=http://www.w3.org/1999/xhtml; body svg xmlns=http://www.w3.org/2000/svg; font id=mysvgfont ... /font /svg font face=ArialExample/font svg:font id=anothersvgfont xmlns:svg=http://www.w3.org/2000/svg ... /svg:font /body /html Then explain how to use the Selectors API to select only the svg 'font' elements and how to select only the svg font elements that have a prefix on the element. As Boris explained, and as I'm sure you're well aware, it is not possible to distinguish between elements with the same local name without using namespaces. I cannot demonstrate the impossible and have not included the example in the spec. The SVG WG disagrees with this reasoning. People will run into this problem, and it seems appropriate to give an example and to show how to work around the lack of namespace-aware selectors. Note that even if it's not possible to distinguish between the elements using Selectors API alone, the result can be filtered e.g using DOM Core methods to give a meaningful result. Another workaround could be to pass a descendant
Re: [selectors-api] SVG WG Review of Selectors API
== Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? The group of selectors must not use namespace prefixes that need to be resolved. That also sounds like an authoring requirement. If it's an authoring requirement please mark it as informative, or as only applying to conforming applications. Aren't most W3C Recommendations intended as specifications for both implementations and authors? Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Or alternatively forward the reader to DOM 3 XPath for the cases where the Selectors API falls short. Even if hardcoded namespace prefixes are added it'd still be a good idea to link to DOM 3 XPath, since it looks like Selectors API is unable to deal with arbitrary xml markup. Do note that XPath can't deal with 'arbitrary xml markup' either as it is not turing complete. (only when combined with XSLT it is). However I do agree that having informative links to DOM 3 XPath is a very good idea as it is a very similar technology. / Jonas
Re: [selectors-api] SVG WG Review of Selectors API
Doug Schepers wrote: As a high-level comment, the SVG WG would prefer to see support for namespaces in the specification. We believe that there will be an increasing amount of (X)HTML+SVG content produced, and that there are a number of cases where it would be easier for authors to have this functionality natively, instead of hacking the results of a selector query. However, we are also sensitive to the preference to get the functionality into developers' hands as quickly and interoperably as possible, and don't wish to obstruct quick adoption of this specification. As a compromise, we believe that if the NSResolver support remains removed from this specification, there should be explicit mention of workarounds (see below), and an informative note mentioning that it may be readded in a future version of the spec, to ensure that implementers set up their architecture accordingly. There are several features which will be considered for inclusion in the next version of the spec. Why should this one in particular be called out over any other requested feature? == 1.1 Examples This script will also function correctly for a table written in XHTML markup instead of HTML. I suggest this be reworded to say something like If the above table is converted to wellformed XHTML markup then this script will function correctly on that as well. The real intention of that statment is to illustrate that the method works on the DOM, independently from any specific syntax used to create the DOM. I have rewritten it to make that more clear. Note that the script operates on the DOM and works independently from the syntax used to create the document. Thus this script will also work correctly for an equivalent table created from well-formed XHTML instead of HTML, or dynamically created and inserted into a document using DOM APIs. == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? The group of selectors must not use namespace prefixes that need to be resolved. That also sounds like an authoring requirement. If it's an authoring requirement please mark it as informative, or as only applying to conforming applications. The implementation must first trim any leading or trailing whitespace from the value of the selectors parameter. The implementation must then process the value according to the grammar of Selectors ([SELECT], section 10). If the processing means that the whitespace-trimmed value must match the 'selectors_group' production please say so. I have addressed these two concerns by adjusting the requirements for conforming applications to state: The caller must pass a valid group of selectors that matches the selectors_group production ([SELECT], section 10) with the additional provision that leading and trailing whitespace ([SELECT], section 4) is permitted. This group of selectors must not use namespace prefixes that need to be resolved. Selectors are evaluated against a given element in the context the entire DOM tree in which the element is located. ...in the context of? I'm not sure how to phrase that any more clearly. It means that when evaluating a selector, all elements in the document may be taken into account, and not just those within the node's subtree. This means that the object will instead contain a list of matching Element nodes that were in the document at the time the list was created. Is this time defined? I propose to reword it as follows: This means that the object will instead contain a list of matching Element nodes that were in the document at the time the method was invoked. IIRC, the original reason for saying at the time the list was created instead of what you propose was that, when the NSResolver was still part of the spec, it was possible that the nsresolver function could modify the document in ways that would affect which elements were matched. I could change it, but I'd prefer to get feedback from implementers about the implications of the change before doing so. If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a NAMESPACE_ERR exception ([DOM-LEVEL-3-CORE], section 1.4). Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html Additionally, doing so could have adverse affects on any future plans to
Re: [selectors-api] SVG WG Review of Selectors API
On Dec 8, 2008, at 17:26 , Lachlan Hunt wrote: Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html That's a shame, they should be defined for a DOM that supports XML features, especially the xml namespace. Or alternatively forward the reader to DOM 3 XPath for the cases where the Selectors API falls short. Please explain how providing a reference to DOM 3 XPath would be of any benefit? How would it help readers in their understanding of this spec? DOM 3 XPath solves pretty much the same problem but is more powerful, providing a reference to it will be very useful to people who want to select nodes from a DOM but bump into limitations of the Selector API. It changes nothing to normative requirements, but makes the spec more considerate towards its users, and a wee bit more useful. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? The spec still needs to describe what happens for the case where a user of the API doesn't adhere to this 'must' requirement (and yes, I believe it does). However I'm not finding many examples in w3c specs of this type of requirement so far. One example I did find was from DOM 3 Core, where the createAttributeNS method makes a requirement on applications to pass the value null for the namespaceURI parameter if they wish an attribute to have no namespace. But that's a bit different in any case. The quoted sentence from the Selectors API spec to me translates into this: The caller must pass a valid group of selectors [in order to get a return value that is of any use. Failure to do so will result in either an exception or in some empty results.] This should be rather obvious to the reader of the spec anyway. IMHO the spec is trying to require something that is not enforcable anyway, and might as well not mention it, but instead just describe what happens for all possible indata. Cheers /Erik -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [selectors-api] SVG WG Review of Selectors API
Doug Schepers wrote: Please add an example such as this one: html xmlns=http://www.w3.org/1999/xhtml; body svg xmlns=http://www.w3.org/2000/svg; font id=mysvgfont ... /font /svg font face=ArialExample/font svg:font id=anothersvgfont xmlns:svg=http://www.w3.org/2000/svg; ... /svg:font /body /html Then explain how to use the Selectors API to select only the svg 'font' elements Can't be done at the moment. Could be done with NSResolver or similar. and how to select only the svg font elements that have a prefix on the element. Also can't be done (and that will continue to be the case pretty much no matter what happens in terms of NSResolver or similar functionality, since Selectors knows nothing about the qualifiedName, only the namespace and localName). -Boris
