It'd be nice to be able to pass jquery selector results into Client about zeroclipboard

[jonrohan]

We do have a class query selector built in, so you are not required to use ids

any of these will work

ZeroClipboard.Client(".clipboard-buttons")

ZeroClipboard.Client("button")

ZeroClipboard.Client("button:first-child")

[jonrohan]

I don't know if I want to start down the path of adding specific lines for libraries, but what would be great, that this point brings up, is the ability to pass in dom elements. @JamesMGreene what do you think?

[tjdhome]

Right, but the problem is that the widgets often start with some context which is NOT expressible as a string. The selectors which you handle all assume that they can be fully expressed via a selector string.

Since jquery selector results can usually be treated as an array, a simple test for an extra property (.jquery) seemed fairly innocuous- especially for the benefit gained. I suppose a test fore '.length' would be fine too and more general. But, passing in dom elements would be fine too.

[JamesMGreene]

I was a bit worried about requests like this and #60 when we went the query/selector route. Honestly, I feel like we'd be better off for maintenance if we only accepts element arrays (and maybe a single element) and let people manage their own selectors ahead of time.

[jonrohan]

Actually #60 just merged, which may solve this problem? Since you can use a non-string context now. @tjdhome

[JamesMGreene]

This would also avoid:

• Additional feature requests to offer full Sizzle selector support without Sizzle.
• Selector "bugs" being filed when users try advanced Sizzle queries without Sizzle (i.e. because Sizzle supports more advanced queries (and contexts) than querySelectorAll does).
• Excessive type checking and logic branch overhead.
• Forcing users to requery for result sets they already have retrieved via jQuery, etc.

[jonrohan]

I could see the benefit of dropping the selector part. It's pretty common that people have libraries already installed. So it would end up being like this.

ZeroClipboard.Client(already_queried_elements);

[jonrohan]

@JamesMGreene we would need to come up with another solution for this https://github.com/jonrohan/ZeroClipboard/blob/master/src/javascript/ZeroClipboard/client.js#L39

[jonrohan]

I guess document.getElementById would work

[jonrohan]

I'm gonna create a PR to move the discussion there. closing this issue

[JamesMGreene]

Also see my comment on #60. :-\

[tjdhome]

One [last?] thought- accept either a list of elements/selector-expression or a function which returns a list of dom elements.

[domchristie]

For me, it's a choice between:

a) making jQuery a dependency, and therefore supporting the various ways of querying elements, or …
b) just support element arrays (or single elements), leaving the task of selecting elements up to the user

When I was going through the API docs, and saw that I could use CSS selectors, I almost assumed it would behave like jQuery selectors (which is why I submitted #60).

[JamesMGreene]

What @domchristie just described is exactly what I'm talking about: someone starts reading docs, sees CSS selectors, assumes they can use the full-blown Sizzle selector engine that they all know and love, try an advanced Sizzle selector, then file a bug when it doesn't work as expected.

I'm thinking it would be best to pull in the reigns early on and switch to just accepting only an Element array... otherwise prepare for a trip down the rabbit hole. 👎

[JamesMGreene]

In other words: we're shipping an awesome library for clipboard injection, not DOM querying or manipulation. Let's keep those concerns separate so we can focus on enhancing our own library rather than importing half of Sizzle. 👍

[jonrohan]

I'm thinking it would be best to pull in the reigns early on and switch to just accepting only an Element array... otherwise prepare for a trip down the rabbit hole.

Agreed, I've started a branch so we can see what it might look like. Should we throw an error or return null if users still try and submit a query string?

[JamesMGreene]

Seems like throwing a TypeError would be warranted in that situation, for both the Client constructor and the glue and unglue methods.