Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

`position:absolute` placement doesn't work for `position:fixed` elements #79

Closed
oojacoboo opened this Issue · 17 comments

5 participants

@oojacoboo

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.

@JamesMGreene

Do you have any suggestion on how you'd prefer to work with it in that scenario?

@jonrohan
Owner

Our find position method may be a bit naive, we could look into making it better.

@oojacoboo

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.

@JamesMGreene

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.

@oojacoboo

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.

@JamesMGreene

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.

@oojacoboo

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.

@JamesMGreene

@jonrohan: FYI, I know that our [inherited] _getStyle method has some major flaws, will send PR or tell you more later.

@JamesMGreene

The referenced pending PR (#114) should fix this.

@JamesMGreene

The referenced Issue #127 includes a test page, which might be useful as this issue does not.

@JamesMGreene

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:

  1. Making the Flash object also use position:fixed when placing it over fixed elements (and reverting to position:absolute whenever we aren't); or
  2. attaching a handler for scroll (and probably resize) events

I'm thinking Option 1 is less likely to have additional missed edge cases popping up later.

@JamesMGreene
Owner

@jonrohan Thoughts on my previous message?

@jonrohan
Owner
  1. is a way better option, trying to introduce scroll code would be a bad idea, too many edge cases.
@JamesMGreene

Agreed.

@JamesMGreene JamesMGreene was assigned
@meleyal

Any progress on this? Specifically accounting for scroll offsets. For now we've patched our version with the changes from 1adc269 (reverted in 4719749).

@JamesMGreene JamesMGreene referenced this issue from a commit in JamesMGreene/zeroclipboard
@nwah nwah Use 'getBoundingClientRect' to get element position and dimensions.
Closes #114.
Fixes #79.
Fixes #119.
Fixes #166.
Fixes #167.
Fixes #149.
b1be91a
@JamesMGreene JamesMGreene referenced this issue from a commit in JamesMGreene/zeroclipboard
@nwah nwah Use 'getBoundingClientRect' to get element position and dimensions.
Closes #114.
Fixes #79.
Fixes #119.
Fixes #166.
Fixes #167.
Fixes #149.
30f3a5d
@JamesMGreene JamesMGreene closed this issue from a commit
@nwah nwah Use 'getBoundingClientRect' to get element position and dimensions.
Closes #114.
Fixes #79.
Fixes #119.
Fixes #149.
Fixes #166.
Fixes #167.
a96a0f0
@JamesMGreene JamesMGreene was assigned
@nickretallack

I also have this problem. How can I get a version of ZeroClipboard that has this fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.