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

Closed
oojacoboo opened this Issue Jan 16, 2013 · 17 comments

Comments

Projects
None yet
5 participants

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.

Owner

JamesMGreene commented Jan 16, 2013

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

Contributor

jonrohan commented Jan 16, 2013

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.

Owner

JamesMGreene commented Jan 16, 2013

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.

Owner

JamesMGreene commented Jan 16, 2013

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.

Owner

JamesMGreene commented Jan 17, 2013

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

Owner

JamesMGreene commented Mar 26, 2013

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

Owner

JamesMGreene commented Mar 26, 2013

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

Owner

JamesMGreene commented Mar 27, 2013

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.

Owner

JamesMGreene commented Apr 9, 2013

@jonrohan Thoughts on my previous message?

Contributor

jonrohan commented Apr 10, 2013

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

JamesMGreene commented Apr 10, 2013

Agreed.

@ghost ghost assigned JamesMGreene May 7, 2013

meleyal commented May 13, 2013

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 added a commit to JamesMGreene/zeroclipboard that referenced this issue Jul 6, 2013

JamesMGreene added a commit to JamesMGreene/zeroclipboard that referenced this issue Jul 6, 2013

@ghost ghost assigned JamesMGreene Jul 6, 2013

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