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
Björn Höhrmann · ·
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · 

Received on Monday, 7 April 2008 23:23:51 UTC