Calculating viewport offsets

[Ian Beck]

I'm pondering submitting a new function to core that makes it easier to calculate the viewport position for a given DOM node (makes absolutely positioning a floating Popup relative to a specific node easier, for instance), and was wondering if people could take a look at my code and let me know if you have any suggestions. Here's what I've got working currently:

https://gist.github.com/ae3109fe326c1f6ef247

Any suggestions are welcome! I'm not sure if the enyo.dom object is the best place for this function (and the name could definitely use some love, too), but it seems to be working pretty well with a somewhat complicated setup that utilizes Panels (and thus CSS transform offsets in addition to normal offsets).

Ian

[Kevin Schaaf (Palm GBU)]

Line 24: I think should be "top += …"

To confirm: this looks similar to Control:getBounds(),  except that it takes into account scroll and translate (all the way up the DOM), and provides right/bottom properties as well.  Perhaps "getViewportBounds()" on Control would be a more consistent place to put it, unless you need to use it outside the context of a Control as a true utility function?

There appear to be inconsistencies between browsers in how offetParent is returned w.r.t. display and position attributes:

https://developer.mozilla.org/en-US/docs/DOM/element.offsetParent

Which really just means that you only get consistent values across browsers when all parent nodes are visible— something to watch out for as far as when you run your positioning code, given it's possible things are hidden when rendered() is called.

Those are my initial reactions, let's see if Ben or Mark or any of the others have an opinion.

--
You received this message because you are subscribed to the Google Groups "Enyo Development" group.
To post to this group, send email to enyo-dev...@googlegroups.com.
To unsubscribe from this group, send email to enyo-developme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/enyo-development/-/iQ2PsuE5-FYJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ian Beck]

Good catch; line 24 is fixed.

I put this on enyo.dom because for my use case I'm calculating an arbitrary DOM node that is not represented by a control (it's the target of a tap event inside another control, but the DOM element is injected using innerHTML, so Enyo doesn't have anything built up for it). This may be an extremely edge-case type of scenario, though, which is why I wanted to float the whole idea here (I can always implement this as a utility function just for my project instead of contributing it to core). It is like getBounds, except that its intent is to be useful for positioning things (like temporary floating popups) near elements that may be nested within multiple layers of hierarchy, scrolled content, etc. Attaching the function to Control makes sense to me (just it wouldn't be useful for my individual use-case).

I haven't done any cross-browser testing yet, but I'm not sure if having a hidden ancestor matters much; if an ancestor of the control is hidden, then the control itself isn't visible and can't be interacted with, either, which seems like an unlikely scenario for someone to want to position something near it.

Ian

[Ian Beck]

Hey folks,

The more I work with and think about this function, the more I think I'm not approaching it the right way. Specifically, I'm not convinced any longer that `calcViewportPositionForNode` is generically useful enough to merit inclusion in core.

How would you feel about switching to `calcNodePosition(inNode, relativeToNode)` instead? If `relativeToNode` is not specified, it would default to the current behavior (measuring the element relative to the viewport) and if it is then the measurement is relative to the given node.

The benefit of this is that it's useful both for positioning elements near a specific element in a floating div (e.g. a popup with floating set to true) as per my original effort, but can also be used for absolutely positioning elements within a shared `position: relative` parent.

It would certainly be possible to leave `calcViewportPositionForNode` as a stub function that just passes things along to `calcNodePosition` in that case, but frankly since this code hasn't made it into a tagged version yet I'm inclined to suggest just dropping my original method all together.

I've updated the gist with the code for this approach that I have working locally; if this change makes sense to you guys, I'll submit a pull request:

https://gist.github.com/ae3109fe326c1f6ef247

Ian

[Ben Combee]

This does sound more generically useful.  Given that we've not yet released a version with this function, now's the time to update behavior.

--
You received this message because you are subscribed to the Google Groups "Enyo Development" group.
To post to this group, send email to enyo-dev...@googlegroups.com.
To unsubscribe from this group, send email to enyo-developme...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/enyo-development/-/JxxbfFc6jsoJ.