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="Arial">Example</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 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.
It would also be useful to mention the backslash escaping mechanism
for downlevel clients[2].
My thoughts exactly, and again it seems like fodder for the same
section.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
