So, it uses position absolute, adds the element at the bottom of the DOM under the body. This doesn't work if you're setting the "button" within a fixed position element.
Do you have any suggestion on how you'd prefer to work with it in that scenario?
Our find position method may be a bit naive, we could look into making it better.
check out what zclip, the jquery plugin, is doing. They're doing it exactly how I would. Basically you add it tot he same level the current "button" is. So, find the parent element of the "button" and append it. Then add position: relative; to the parent, position: absolute; to this flash container. One other thing that I'd do that zclip doesn't do so well, is copy over all the css and possibly disable the original "button". I'm not huge on the disable, but, preserving hover states and the like is pretty important. Currently that piece is pretty hacky.
I've tried positioning in a relative fashion before with a similar clipboard injector. IMHO, it wasn't the right way to go as it risks messing with the application of CSS rules as well as possibly putting it into an invalid spot in the markup (e.g. as a child of an "ul", "tr", etc.). Also, changing the parent node's style is arguably a huge "no-no" in my book.
@jonrohan: Anything to add, or any different opinions? Am I wrong and/or being too harsh about relative positioning here?
We can make the normal hovers work, I've done that before. It's actually what I realized post-PR would've been a better solution for #27.
James, good points. I don't see how there would be an invalid location within the markup though. If you have an anchor or a button in your code, it's going to be within a valid parent. You'd be putting this element at the same level. So there aren't any issues there.
Regarding the position: relative on the parent... How about specifying the "container". This would be the relative container parent to use. It would be for adding position: relative and for appending this flash container. I've seen js plugins do this. For instance, plupload does this, but for other reasons.
I think at least with this method, you're able to control what gets set as relative and it allows this plugin to work. Currently I can't use this, I'm actually using the zclip plugin based on this b/c it handles the positioning in a more accurate fashion.
ZeroClipboard isn't limited to only gluing to anchors or buttons, it can be glued to any element. Ergo, the user can shoot themselves in the foot (with the sibling-DOM-placement technique) if they choose to glue it to an element that can't support an object/embed tag as a valid sibling.
I see. So then, allow them to specify the "container". That solves the issue all around. It could even be an optional property of the object passed.
@jonrohan: FYI, I know that our [inherited] _getStyle method has some major flaws, will send PR or tell you more later.
The referenced pending PR (#114) should fix this.
The referenced Issue #127 includes a test page, which might be useful as this issue does not.
Notably mentioned in #128 is the problem of scrolling the page with a fixed element that is glued to and actively being hovered over.
This will need to be solved by either:
I'm thinking Option 1 is less likely to have additional missed edge cases popping up later.
@jonrohan Thoughts on my previous message?
Any progress on this? Specifically accounting for scroll offsets. For now we've patched our version with the changes from 1adc269 (reverted in 4719749).
Use 'getBoundingClientRect' to get element position and dimensions.
I also have this problem. How can I get a version of ZeroClipboard that has this fixed?
Use the latest beta version: https://github.com/zeroclipboard/ZeroClipboard/releases/tag/v1.2.0-beta.3