Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Margins calculation #28

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Margins calculation #28

wants to merge 1 commit into from

Conversation

oceangravity
Copy link

Hi bro!, your plugin is awesome, thanks!

In some cases, some elements with margin don't get the exact for distance calculation because element's margin.

I've included a transparent way to do this, please, check it out.

Thanks.

… the calculation for outerHeight() and outerWidth() functions.

Also, we need to subtract 'margin-left' for x and 'margin-top' for y, on this way we keep the positions for each area.
@gilmoreorless
Copy link
Owner

Hi, thanks for the contribution! I'd like to understand your use case a bit better to get more context – why do you need margins taken into account?

I'll explain my position on the matter at the moment. When I wrote this library, I deliberately excluded margins from the calculations. The primary reason for this was simple (and perhaps naïve): The use cases of the product I was building at the time. Our users got contextual selections based on the element that was visually closest to where they were clicking. Margins are by definition invisible and were therefore excluded, as they really only contribute to the position of an element, not its dimensions. This is also reflected in the DOM Element.getBoundingClientRect() method, which doesn't include margins.

There are some other concerns I have with including margins in the calculations:

  1. Margin collapsing could produce some confusing results. For example, picking a point that's within the collapsed margin areas of two elements would be calculated as "touching" both elements, when visually it's between them.
  2. Elements with display: inline will still report their top/bottom margin when inspected, but the margin is not applied. This throws out the calculations and requires checking the display property's value for every element.

Additionally, the way this PR is currently written (as a base change rather than a new option), it's a breaking change. Anyone using it at the moment is relying on the calculations not including margins. Having it suddenly include margins could cause interesting bugs.

It's entirely possible that you have a use case I haven't considered so far, so I'd like to know more about what you're after.

Cheers,
Gil

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants