This is moot now that NSResolver is gone from selector-api, but…
Boris Zbarsky:
The way I see it, all current impls should throw something if
more than one arg is passed
Lachlan Hunt:
Which exception should be thrown? Is this something I should
define in this spec, or is it
Lachlan Hunt wrote:
The way I see it, all current impls should throw something if more
than one arg is passed
Which exception should be thrown? Is this something I should define in
this spec, or is it something for WebIDL or some other spec to deal with?
Honestly, I don't care much on that
Lachlan Hunt wrote:
The developers implementing this in Opera has given me feedback saying
that this shouldn't throw an exception because JS allows additional
arguments to be passed to any method, including other DOM APIs, like
getElementById(), etc. Is there a good reason why this should
Boris Zbarsky wrote:
Lachlan Hunt wrote:
The developers implementing this in Opera has given me feedback saying
that this shouldn't throw an exception because JS allows additional
arguments to be passed to any method, including other DOM APIs, like
getElementById(), etc. Is there a good
On Wed, 20 Aug 2008 08:26:30 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Lachlan Hunt wrote:
The way I see it, all current impls should throw something if more
than one arg is passed
Which exception should be thrown? Is this something I should define in
this spec, or is it something for
Jonas Sicking wrote:
Boris Zbarsky wrote:
Of course not throwing on extra arguments is indeed the easy path to
implementation (and is what Gecko will be shipping, it looks like), so
as long as you can live with the results as a spec writer it's all
good by me.
I think we should follow
Unfortunately I don't think we can change how XPath parses things since
there is already code out there that might rely on the current behavior.
Might be worth looking into though.
I don't want to worry about xpath, although that misfeautre bite me hard :)
Chaging the behavior how I
João Eiras wrote:
Unfortunately I don't think we can change how XPath parses things
since there is already code out there that might rely on the current
behavior. Might be worth looking into though.
I don't want to worry about xpath, although that misfeautre bite me hard :)
Chaging the
Hi !
I vote for having a new light weight object to completely replace the
current NSResolver, and then apply it to other DOM specs namely the XPath
DOM.
I had some of the problems we're discussing with the XPath DOM API, and
obviously the same apply here.
I exposed my problems at the
João Eiras wrote:
Hi !
I vote for having a new light weight object to completely replace the
current NSResolver, and then apply it to other DOM specs namely the
XPath DOM.
I had some of the problems we're discussing with the XPath DOM API, and
obviously the same apply here.
I exposed my
João Eiras wrote:
On , Jonas Sicking [EMAIL PROTECTED] wrote:
João Eiras wrote:
Hi !
I vote for having a new light weight object to completely replace
the current NSResolver, and then apply it to other DOM specs namely
the XPath DOM.
I had some of the problems we're discussing with the
Boris Zbarsky wrote:
Lachlan Hunt wrote:
Given that IE, Webkit and Opera seem to be in favour of dropping
NSResolver, if Mozilla will agree, I'm more than happy to do so
OK. We talked it over, and this sounds like the best way going forward
for now.
I have stripped all requirements from
On Wed, 16 Jul 2008 13:43:06 +0200, Lachlan Hunt
[EMAIL PROTECTED] wrote:
I have stripped all requirements from the spec relating to resolving
namespace prefixes using an NSResolver. Although it still has the
requirement to throw a NAMESPACE_ERR when namespace prefixes that need
to be
Lachlan Hunt wrote:
Although it still has the requirement to throw a NAMESPACE_ERR when
namespace prefixes that need to be resolved are encountered
http://dev.w3.org/2006/webapi/selectors-api/
In theory it might be better to throw NOT_SUPPORTED_ERR so going
forward you can distinguish
Lachlan Hunt wrote:
Given that IE, Webkit and Opera seem to be in favour of dropping
NSResolver, if Mozilla will agree, I'm more than happy to do so
OK. We talked it over, and this sounds like the best way going forward
for now.
-Boris
On Mon, 14 Jul 2008 21:30:18 +0200, Boris Zbarsky [EMAIL PROTECTED] wrote:
Anne van Kesteren wrote:
How do I select all the inline SVG images on the page?
div svg, p svg
though it's not quite as thorough as your solution.
Offhand, you're missing td, span, body to cover any sort of
16 matches
Mail list logo
