Re: [SelectorsAPI] Selector detection needed?

To be honest, I was just introducing a proposed API to generate discussion, which it has. I never said it was the best solution for the issue, just a solution. Browsers don't typically throw syntax errors when they run into selectors that aren't supported, they usually ignore them. An unsupported selector technically isn't a syntax error at all, it's an implementation issue. The browser may even recognize the selector and just not use it.

I don't want to have to wrap every call to querySelector() or querySelectorAll() in a try-catch that adds overhead and unnecessary complexity. I believe some way to query the support level for a selector is much more elegant solution. I know the one I proposed was heavy-handed, I'm sure there are better ways to deal with it.

The selector set is finite so adding constants to represent each doesn't seem like a bad idea (if necessary). They could be implemented as a bitmask. I also don't see why I should have to try a complete CSS query when all I really want to know is if the given selector is supported. Perhaps vendors will implement it incorrect, but they could also implement the entire spec incorrectly.

Throwing errors makes it difficult to determine if there was an actual syntax error because the CSS query was mistyped or if it's the browser not supporting something. Allowing browsers to just state what selectors they support could really aid in development.

-Nicholas

----- Original Message ----
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: www-style@w3.org
Sent: Monday, April 7, 2008 4:23:05 PM
Subject: Re: [SelectorsAPI] Selector detection needed?


* Daniel Glazman wrote:
>> For which I would naturally call the methods on an empty document or
>> an isolated element. Quite frankly even then this is a lot nicer then
>> doing something like
>> 
>>  if (document.supportsSelector(DocumentSelector.CSS_TYPE_SELECTOR) &&
>>      document.supportsSelector(DocumentSelector.CSS_CHILD_COMBINER))
>>    ...
>> 
>> As has been suggested initially in this thread.
>
>Wow. I just cannot believe what I read above. Wow.

Since this list is for technical discussion only, let me expand on what
I've said before. Using numerical constants is a bad idea, I've already
mentioned that it does not work with selectors from dynamic sources and
fails for more complex selector support queries. I could add that tests
like the one above are very verbose and require substantial lookup and
copy and paste effort, worst of all is of course that we'd have to make
new constants for every pseudo-class we add, and make a policy for how
to query for vendor-specific ones.

documents.supportsSelector("A > B") does not have any of these problems,
so if you'd add such a function, you'd use this syntax instead. Now that
you can implement with, say,

  Document.prototype.supportsSelector = function(s) {
    try { document.createElement("tmp").querySelector(s,
      function(prefix) { return "ns"; }) }
    catch (e) { return false; }
    return true;
  }

yourself, which is none of overly verbose, slow, or difficult. Clearly
I prefer this over having to lookup numerous constants online, and since
so far I only came up with a single and rather exotic use case for this,
it's difficult to see why the specification should enable some other
approach. If anyone has good use cases or arguments relative to this
matter, they are most welcome to share them on public-webapi@w3.org.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com


      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

Received on Wednesday, 9 April 2008 03:30:50 UTC