Shim .querySelector and .querySelectorAll

[scothis]

Attempt to utilize common query engines if available (sizzle, jquery, dojo, etc), or fall back to loading sizzle if another engine is unavailable.

There may be issues with load order and detection of a query selector engine...

[briancavalier]

Definitely worth discussing, but could also be a slippery slope into other DOM-related polyfills. @unscriptable will have a better idea of where the dragons be. One question is whether the intent of poly is to go beyond ECMAScript to the DOM or other host-specific facilities. I guess we've kinda already done that with the setImmediate polyfill, which is pretty useful regardless of the host env.

If we decide do it, we can isolate it in poly/dom, poly/dom/querySelector, etc. and let people load it as needed.

Another interesting angle is that this could do away with the need for the wire/*/dom variants.

[unscriptable]

If we decide to do DOM, I suggest we limit our supported browsers to IE8+. IE6-7 can't shim the DOM using only JavaScript.

I like the idea of creating a poly/dom convenience module that loads the dom-related polyfills.

We could use AMD configs to tell poly/querySelector what to do.

// use a "standardized" abstraction like dojo or jquery
curl({ queryEngine: "dojo/query" });
curl({ queryEngine: "jquery" });

// a pre-existing global function. does this make any sense?
curl({ queryEngine: myGlobalQueryFunc }); 

What should the absence of any config information indicate? To load sizzle? Probably not. Not unless we can make it brain-dead easy for users to do has-ified builds using cram.js. Otherwise, mobile browsers will be loading sizzle despite not needing it.

[briancavalier]

My main worry still is "when do we stop"? We could polyfill the DOM all day and still not have a "complete" solution. If we can put a reasonable box (still useful to devs, but doesn't kill us to implement/support it) around the parts of the DOM we'll polyfill, I'm cool with that.

[scothis]

Yea, you want to be very specific about the portions of the DOM that are being polyfilled. Avoiding a poly/dom module in favor of specific portions of the DOM that are supported, e.g. poly/dom/querySelector.

Trying to polyfill all of the DOM will require significantly more effort and may, or may not, be a reasonable goal. Rather than worry about where you stop, instead ask 'is this useful for developers?' Everything else should be a balance of resources and priority.

[unscriptable]

Trying to polyfill all of the DOM will require significantly more effort and may, or may not, be a reasonable goal. Rather than worry about where you stop, instead ask 'is this useful for developers?' Everything else should be a balance of resources and priority.

Is shimming .querySelector and .querySelectorAll useful for developers?

[scothis]

@unscriptable Query selectors are one of the major reasons developers start using dojo/jquery. I'd always prefer to use a standard API over a proprietary one.