John Resig wrote:
Libraries already parse selector queries anyway. And some of them
add non-standard selectors and presumeably will continue to do so.
I don't think it is an issue.
However the parsing only happens after the selector has been passed to
the native querySelectorAll
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 6:00 PM, Sean Hogan shogu...@westnet.com.au wrote:
Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been
On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:
On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au
wrote:
*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860
This has been discussed extensively in the past. Basically, the
idea is
that the selector
Level 3.
http://dev.w3.org/2006/webapi/selectors-api-testsuite/
The baseline tests in the first file are a subset of all the tests in
the second. To create it, I basically removed any test using a selector
introduced in Selectors 3 without modifying other tests.
I've also begun to add tests
Lachlan Hunt wrote:
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.
I'm glad to try to figure that out, if you
Boris Zbarsky wrote:
Lachlan Hunt wrote:
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.
I'm glad to try to
Lachlan Hunt wrote:
Both Minefield and Webkit trunk are failing those tests for me. I have
all but one commented out just so it would make my debugging easier (see
lines 287 to 292 in 002.html).
Oh, I'd just missed the one failing test. Showing only failing tests
helped!
I just checked
On Sun, 19 Jul 2009 08:05:32 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
I was wondering if the test suite for selectors-api to could be modified
to include #FF (uppercase) as a valid red value in addition to
(255, 0, 0), #ff
On Mon, 20 Jul 2009, Kartikaya Gupta wrote:
On Sun, 19 Jul 2009 08:05:32 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
I was wondering if the test suite for selectors-api to could be modified
to include #FF (uppercase) as a valid red
On Sat, 18 Jul 2009, Kartikaya Gupta wrote:
I was wondering if the test suite for selectors-api to could be modified
to include #FF (uppercase) as a valid red value in addition to
(255, 0, 0), #ff, and red. This doesn't seem to be specced
anywhere, and our implementation retuns
On Wed, 24 Jun 2009 14:58:17 +0200, Arthur Barstow art.bars...@nokia.com
wrote:
Lachlan,
On Jun 17, 2009, at 8:15 AM, ext Lachlan Hunt wrote:
Hi,
In order to complete the transition of Selectors API to CR, there
were a number of things that needed to be done, following the call
I realise it's too late, but I thought I'd add my +1 anyway.
I like Gavin's suggestion of selectElement() / selectElements()
getElement() / getElements() could also have been used for consistency
with the existing element selection function names.
. oh well. :-)
P.S. Could someone point me
On Fri, 19 Jun 2009 19:12:35 +0200, Ian Hickson i...@hixie.ch wrote:
On Fri, 19 Jun 2009, Robin Berjon wrote:
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations
of
*all* the tests, except those stemming
On Jun 20, 2009, at 1:39 AM, Charles McCathieNevile wrote:
That's true. THe question is whether a REC makes it easier to get a
new interoperable implementation. And it's open, as far as I can see.
Assuming we have implementation of everything, twice, and that for
everything we have at
Boris Zbarsky:
If the return value of lookupNamespaceURI is |undefined|, should that
stringify to or undefined? Same question for |null|.
Note that I'm not sure there's an obvious way to annotate this in web
idl yet.
Cameron McCormack:
Yeah, there’s no way to specify this at the
Hi Lachlan,
On Jun 17, 2009, at 14:15 , Lachlan Hunt wrote:
*CR Exit Criteria*
I propose the following as the CR exit criteria:
At least two interoperable implementations of each feature,
dependent upon the following conditions:
* Each individual test in the test suite must pass in at
then we're already there.
Yeah, I have this Ecmascript implementation that only supports
variable declarations (with a few bugs). But I swear it supports the
Selectors API!
Seriously though, as I explained during the last meeting it's up to
the WG to reach consensus on the exit criteria
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations
of
*all* the tests, except those stemming from a lack of support for
CSS?
I was advised to set the requirements low so that it would be easier
to
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations of
*all* the tests, except those stemming from a lack of support for CSS?
I was advised to set the requirements low so that it would be easier to
proceed past CR. With these requirements, we can get past
On Fri, 19 Jun 2009, Robin Berjon wrote:
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations of
*all* the tests, except those stemming from a lack of support for CSS?
I was advised to set the
Hi,
In order to complete the transition of Selectors API to CR, there
were a number of things that needed to be done, following the call for
consensus we had in April/May.
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0471.html
1. Write CR Exit Criteria
2. Write updated
] is a sufficiently
complete test suite for the editor's draft version 1.97[2] of Selectors
API
[1]
http://github.com/jeresig/selectortest/blob/4827dedddaea6fa0b70cfdaadeeafef0d732a753/index.html
[2]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev
On Wed, 15 Apr 2009, Charles McCathieNevile wrote:
So we have a new call for consensus on each of four questions:
Should we make Erik's proposed changes[1] to the test suite?
Should we add Hixie's first test[2]?
Should we add Hixie's second test[3]?
Do we need tests as described by
around the time I stopped being the active editor
of the specification.
Er, indeed. Those seem to be discussion of ElementTraversal.
I was pretty sure I'd raised the same issue with Selectors API, but
the W3C list search is crappy enough that I can't find the posts...
In fact, the only
. That was long after this was initially discussed
though. And also around the time I stopped being the active editor
of the specification.
Er, indeed. Those seem to be discussion of ElementTraversal.
I was pretty sure I'd raised the same issue with Selectors API, but
the W3C list search is crappy
I wish to comment on the recommendation that NodeLists returned by
the selectors API will be static.
I feel this removes one of the great benefits of live collections,
that is, that once a collection is created, it is automatically
updated by the browser itself. This provides
On Mon, 23 Mar 2009 11:32:56 +0100, Robert Green rg...@iinet.net.au
wrote:
I have been told that the reason for not having live collections is for
performance, but I find that hard to understand. The current live
collections are much faster than their native javascript emulations, I
can't
On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Just as a point of record, I believe browser implementors were split on
the issue (e.g. I think in Gecko live performance would be as good, if
not better in many cases, as non-live performance. I said so at the
time
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 14:49:17 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Just as a point of record, I believe browser implementors were split
on the issue (e.g. I think in Gecko live performance would be as good,
if not better in many cases, as non-live performance.
On Mon, 23 Mar 2009 15:00:49 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Anne van Kesteren wrote:
Interesting. I recall only hearing back from WebKit and Opera at the
time I made the initial decision.
I recall that feedback as well, but assumed that this was the usual
issue of some
of the
specification.
Er, indeed. Those seem to be discussion of ElementTraversal.
I was pretty sure I'd raised the same issue with Selectors API, but the
W3C list search is crappy enough that I can't find the posts... In
fact, the only thread on the matter I can find is the ACTION-87
discussed though.
And also around the time I stopped being the active editor of the
specification.
Er, indeed. Those seem to be discussion of ElementTraversal.
Oops.
I was pretty sure I'd raised the same issue with Selectors API, but the
W3C list search is crappy enough that I can't find
On Wed, 04 Mar 2009 11:00:43 +0100, Charles McCathieNevile cha...@opera.com
wrote:
Hi folks,
as a result of the great work by many, it seems we have all the things in
place to move the Selectors API specification directly to Proposed
Recommendation. In order to do so, we need to demonstrate
Hi,
The Selectors API test suite is missing tests for the namespace
selectors |foo and *|foo. Since they don't have prefixes that need
to be resolved, they should be supported even without an NSResolver.
See brief IRC discussion about this:
http://krijnhoetmer.nl/irc-logs/whatwg/20090312#l
Alexey Proskuryakov wrote:
12.03.2009, в 17:19, Lachlan Hunt написал(а):
WebKit has a bug with the |foo selector.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28
Opera and Firefox pass
This is actually a difference in createElementNS(null, p) vs.
createElementNS(, p)
Alexey Proskuryakov wrote:
This is actually a difference in createElementNS(null, p) vs.
createElementNS(, p) behavior. I don't know whose bug it is, but in
Firefox and Opera, empty and null namespace arguments both result in
null namespace for the created element.
Interesting question. DOM
12.03.2009, в 18:01, Boris Zbarsky написал(а):
Make of this what you will. But as I recall, the change in the XML
Namespaces section was meant precisely to ensure that in JS passing
for all namespace URIs would work exactly like passing null.
Sounds like webkit either implements
]
Probably not, though I suspect that Gecko won't implement this any time
soon; certainly not until WebIDL stabilizes more. It requires some
pretty nontrivial changes.
For the Selectors API as far as I can tell it's trivial to implement, no?
Just put the APIs on the other interfaces directly
Ian Hickson wrote:
For the Selectors API as far as I can tell it's trivial to implement, no?
Just put the APIs on the other interfaces directly.
That fails for non-JS embeddings of Gecko, for various reasons. So no,
pretty nontrivial.
-Boris
Boris Zbarsky:
Ah, that wasn't the case last I checked. And again, there's no
specification I can find that requires it.
Ian Hickson:
WebIDL defines the class name and ECMAScript requires the [object foo]
serialisation, if I'm not mistaken.
If I'm wrong and it's not required yet, then
Cameron McCormack:
You can require a certain [[Class]] value at the moment with Web IDL, if
you use the [PrototypeRoot] extended attribute.
And I forgot to mention that since the Object prototype object is
required to be in the prototype chain, that its toString would give the
“[class X]”
it.
002-002 is explicitly required by the IDL block in Selectors API
This is the dependency on WebIDL I was talking about.
and I think there's no controversy over that particular requirement
Probably not, though I suspect that Gecko won't implement this any time
soon; certainly not until WebIDL
Hi Lachy, all
a couple of trivial editorial things for the spec, next time you revise it
(hopefully for publication as PR :) ) - no need to make any changes while
we are reviewing the spec anyway.
1. Copyright should be 2006-2009
2. Please add a note to the status section saying that some
Hi folks,
as a result of the great work by many, it seems we have all the things in
place to move the Selectors API specification directly to Proposed
Recommendation. In order to do so, we need to demonstrate that we have
implementations which prove the spec can be implemented
On Wed, 4 Mar 2009, Charles McCathieNevile wrote:
[...] To clarify that, this is a call for consensus on the following
question:
The test suite by John Resig, 2009-02-19 version[1] is a sufficiently
complete test suite for the editor's draft version 1.97[2] of Selectors
API
[1
Ian Hickson wrote:
http://www.hixie.ch/tests/adhoc/dom/selectors/002.html
Given the state of WebIDL, it's not clear to me that the test 002 of
this test is necessarily required by the spec as it stands. For that
matter, it's not clear to me that test 001 is.
Also, I would like to ask
out.
However, I don't think the things tested in 002 are controversal. In
particular, all the UAs have converged on the behaviour tested by 002-001
for other objects, 002-002 is explicitly required by the IDL block in
Selectors API and I think there's no controversy over that particular
to
DOMException.SYNTAX_ERR). Having said that, I understand the desire to be
precise and test not only the Selectors API but also the WebIDL binding
dependencies that go with it.
Current pass rate: 47.4%
Best possible current pass rate (excluding WebIDL issues): 1241 tests (57.3%)
Best possible
Travis Leithead wrote:
I went through the test results in IE8 just to see what the breakdown
was and thought I'd pass this info along.
Thanks for this analysis, it's very informative.
1 - Actual Selectors API bugs
288
Yes, I'm satisfied with all the changes (although I still think it's useless
and a bit risky of minor discrepancies to define document order when DOM Level
3 Core is already normatively referenced), thank you for being so responsive
and for the entirety of your effort on this spec.
This makes
from
the IDL and added a note advising implementers that WebIDL defines how to
handle null and undefined.
http://dev.w3.org/2006/webapi/selectors-api/#nodeselector
Given the current WebIDL draft, this means they stringify to null and
undefined, respectively.
--
Lachlan Hunt - Opera Software
. But I
don't know. I've CC'd Rune, one of our developers, who can comment on
whether or not we could or would make the change.
Should be easy to make that change for the selectors api, at least.
--
Rune Lillesveen
Senior Core Developer
Opera Software ASA
to undefined unless overridden, and
I would suggest Selectors API to use that behaviour, too.
The following are reasons we ended up with the spec defining to stringify it
to the empty string instead of undefined.
Initially, the spec didn't define any explicit behaviour, implicitly relying
Jonas Sicking wrote:
On Fri, Feb 13, 2009 at 5:23 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
e.g.
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg}
return uri[ns];
}
For resolving the default namespace, this would return
Charles McCathieNevile:
If anyone objects to this approach (which saves some administrative
work and some time), please speak up...
Web IDL is still a WD. At some point before Rec, I guess selectors-api
would need to block on Web IDL progressing. What point should that be?
--
Cameron
. At some point before Rec, I guess selectors-
api
would need to block on Web IDL progressing. What point should that
be?
PR? There does not actually seem to be a requirement in the W3C
Process document that e.g. a Recommendation cannot normatively
reference a Working Draft by the way
On Sat, 07 Feb 2009 12:54:03 +0100, Marcos Caceres
marcosscace...@gmail.com wrote:
Hi John,
On Fri, Feb 6, 2009 at 10:00 PM, John Resig jere...@gmail.com wrote:
Opera supports publishing this spec as a CR - and if we can get a test
suite and interop report in time, in going for a PR
to undefined is much more widely implemented:
http://mcc.id.au/2009/01/string-handling/string-handling
If that does end up being the more common behaviour, I’ll change the
default in Web IDL to be to stringify to undefined unless overridden,
and I would suggest Selectors API to use
Firefox appears to have some issues that might related to the API, though I
haven't investigated the cause of those yet, so I don't know for sure.
Unfortunately, IE8 can't run John's tests because it relies on some DOM2
features that aren't yet supported, so the testing framework would need
recommendation?
I'm not sure what I think of this, if so, Perhaps the test should be
testing that selectors API returns the same results as CSS selector
matching instead of testing that particular selectors which might become
valid CSS in the future are unsupported. That way, if at some point
Hey Lachlan,
thanks for tracking this down.
On Feb 13, 2009, at 14:23 , Lachlan Hunt wrote:
But now that the NSResolver has been removed, the consistency
reasoning no longer really applies. The benefit to debugging still
sort-of does, but it is certainly debatable.
Given that adding
On Thu, Feb 12, 2009 at 8:14 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Lachlan Hunt wrote:
Firefox appears to have some issues that might related to the API, though
I haven't investigated the cause of those yet, so I don't know for sure.
On John Resig's tests in particular, every single
in Web IDL to be to stringify to undefined unless overridden,
and I would suggest Selectors API to use that behaviour, too.
--
Cameron McCormack ≝ http://mcc.id.au/
Jonas Sicking:
An alternative would be to not mention behavior for undefined at all
and let it be whatever the default is for WebIDL once that spec makes
up its mind. It seems more important to me to behave consistently with
other methods than to have any specific behavior for undefined.
Cameron McCormack wrote:
If that does end up being the more common behaviour, I’ll change the
default in Web IDL to be to stringify to undefined unless overridden,
For what it's worth, that's what the current WebIDL draft says in any case.
-Boris
On Thu, Feb 12, 2009 at 4:14 PM, Cameron McCormack c...@mcc.id.au wrote:
Boris Zbarsky:
On John Resig's tests in particular, every single failure in Gecko is
due to a violation of this part of the API:
Undefined=Empty
This is using a WebIDL syntax from a working draft that we don't
Jonas Sicking:
Still not sure that I understand that chart. As I read it, firefox for
the namespaceURI parameter of DOMImplementation.createDocument treats
undefined as null (hence the 'N' in the second column). However I
would have really expected us to treat undefined as the string
On Thu, Feb 5, 2009 at 2:21 AM, Charles McCathieNevile cha...@opera.com wrote:
[1] http://dev.w3.org/2006/webapi/selectors-api/
I've been meaning to read this for months. sorry for the delay, i
expect none of my comments are significant, but i enjoy reading and
writing
This specification
for checking for interface
support, or for obtaining implementations of interfaces, using
feature strings. ([DOM-LEVEL-3-CORE], section 1.3.6) A DOM
application can use these methods, each of which accept feature and
version parameters, using the values Selectors-API and 1.0
(respectively).
I believe
Hi John,
On Fri, Feb 6, 2009 at 10:00 PM, John Resig jere...@gmail.com wrote:
Opera supports publishing this spec as a CR - and if we can get a test suite
and interop report in time, in going for a PR straight away.
Is this a different test suite from the one published here:
Jonas Sicking wrote:
So do I, and most likely the rest of mozilla.
Seconded.
-Boris
Resig's tests [1], into the test suite.
I started writing one [2], but it's not yet finished. I will be making
time to work on it very soon, as it has now become a priority.
[1] http://ejohn.org/apps/selectortest/
[2] http://dev.w3.org/cvsweb/2006/webapi/selectors-api-testsuite/
--
Lachlan
Opera supports publishing this spec as a CR - and if we can get a test suite
and interop report in time, in going for a PR straight away.
Is this a different test suite from the one published here:
http://ejohn.org/apps/selectortest/
http://github.com/jeresig/selectortest/tree/master
Or is it
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
this is a call for consensus to move the Selectors API [1] to Candidate
Recommendation,
Opera supports publishing this spec as a CR - and if we can get a test
suite and interop report
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com
wrote:
Hi folks,
this is a call for consensus to move the Selectors API [1] to Candidate
Recommendation, following the end of the last call.
[1] http://dev.w3.org/2006/webapi/selectors-api/
One minor fix
So do I, and most likely the rest of mozilla.
/ Jonas
On Thu, Feb 5, 2009 at 4:55 AM, Charles McCathieNevile cha...@opera.com wrote:
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile
cha...@opera.com wrote:
Hi folks,
this is a call for consensus to move the Selectors API [1
Charles McCathieNevile:
this is a call for consensus to move the Selectors API [1] to Candidate
Recommendation, following the end of the last call.
+1
--
Cameron McCormack ≝ http://mcc.id.au/
Hi folks,
this is a call for consensus to move the Selectors API [1] to Candidate
Recommendation, following the end of the last call. The disposition of
comments[2] has no formal objections, and I believe all substantive issues
are resolved - the only outstanding one is whether i18n
, implementation and shipping
deadlines, and market pressures. That's reality.
But please stop pretending that there are no use cases for namespace
support, or that the use cases that are raised are insufficient, to be
addressed by the Selectors API. That's not reality.
People want to mix markup
methods of the NodeSelector interface.
Please let me know if you are satisfied with this response. You can
review the changes in the latest editor's draft.
http://dev.w3.org/2006/webapi/selectors-api/
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Phillips, Addison wrote:
Assuming for a moment that CSS3 does not resolve the problem with
Unicode normalization in selectors, users of selectors-api will be
potentially surprised by the results in certain circumstances
involving denormalized selectors.
I have discussed this with my co
Krzysztof Maczyński wrote:
I'm not familiar with XPath's usage of the term. Please explain why this
is a problem for two completely orthogonal specs to define the same term
with different meaning?
Well, it's potentially confusing, I can easily imagine e.g. myself
having to say context node
Lachlan,
Thanks for replying quickly; I'll do the same, since it probably matters much
more to you, process-wise.
I have changed it to the
plural node’s subtrees. Is that acceptable?
Yes, perfectly. But this still isn't formally applicable in all cases:
The term document order means a
Phillips, Addison wrote:
However, I18N feels that our two WGs can construct a useful,
informative, small, and relatively-painless bit of text to allow you
to proceed. Please let us know if you think this an appropriate way
to address this issue or if we can assist in any way to help you guys
Not having written it just yet... :-)
Assuming for a moment that CSS3 does not resolve the problem with Unicode
normalization in selectors, users of selectors-api will be potentially
surprised by the results in certain circumstances involving denormalized
selectors. Implementers will also
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
].
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
at least in version 2 of Selectors API,
or people will go back to XPath.
Giovanni
+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
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
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
version, but in version 2 (or level 2)
of selectors api we definetely need it.
(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
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
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
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
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
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.
Phillips, Addison wrote:
Dear Webapps WG,
I am writing on behalf of the I18N Core WG who discussed the Selectors
API WD in our call of 3 December [1].
We reviewed the Selectors API working draft. In reviewing this draft,
we did not find any internationalization issues in the text
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
301 - 400 of 496 matches
Mail list logo
