Visible based on stack

[Kevin Peno]

This may be a question more than a bug or feature request.

As far as I can tell, your system determines the fraction visible based on the bounding box (window, parent element, etc). However, if there were two items within the same viewport stacked on one another, how would your system handle it?

Also, is it possible to set out own viewbox? For example, a 1x1 pixel box under the mouse cursor. Then use that box to determine which element is visible within it?

[Lars Jung]

Currently only two dimensions are supported, z-index isn't taken into account. So I'm afraid it's not the real visibilty in that sense that is computed. Only x and y bounds are used for calculation.

As for mouse related tasks there will be some methods in the next release (next week).
For the specific feature you're asking there is no automated solution. But you might find those methods useful:

jQuery.fracs( rect: Rect, [viewport: Rect] ): FracsResult
jQuery.fracs( element: HTMLElement, [viewport: Rect] ): FracsResult

Hope that was a bit helpful...

[Kevin Peno]

Thanks for the fast reply!

Unfortunately I wish determining the stack was as simple as z-index. :P

You pretty much have to process the entire hierarchy to really understand where an element lays in the stack based on block display, float, inline display, positioned elements ordered by z-index, and, even after all that, determining whether any of the above creates new stacking order and where. (See a good write-up here: http://timkadlec.com/2008/01/detailed-look-at-stacking-in-css/)

So, I've been hopelessly trying to find something that does this already for me so I don't have to write something myself.

Background
I'm trying to build a grid based game in html that allows you to drop elements in various locations. Unfortunately, for this to work, I need to know if the drop zone is actually visible at the time (specifically if one drop zone is above and.or not blocked by another another). This wouldn't be a problem if I wasn't dragging an element because I could just use onmouseenter and onmouseleave, but I don't think not dragging an element makes sense in my use case.

[Lars Jung]

Didn't had time to read the article yet, but I think it's not so hard to realize. You just have to follow the path of offset parents and group elements accordingly before sorting by the z-index.

As for your problem (if I got you right) I think it would be best to handle it with drop zones like jQuery UI does...

[Kevin Peno]

I hope I'm not making a discussion forum out of this issue, but rather providing you with information on the issue should you choose to implement it in the future :)

I assume you mean jQuery UI's droppables. All they are doing is looping through a list of "drop zones" to find the first one that is acceptable. They suffer the visibility problem as well.

I'd take a look at that article when you get a chance. Unless I'm missing something, following the parent path will not always work because it is the stacking contexts that will matter. In order to find where a specific element falls within stack you will need to find all of the stacking contexts that affect it. This includes ones that aren't directly related, but still effect visibility (an absolutely positioned element with z-index set to > 0 later in the DOM)

Some notes:

• z-index is only defined when it is explicitly defined, otherwise it is "auto". z-index could be defined in error by putting it in the CSS on a non-positioned element.
• Let's not forget the "extra" visibility effecting things: display: none;, visibility: hidden, overflow (beyond the box?), clip (box clamped down?), transform (box rotated, resized, distorted?).
• Pseudo elements appear to be impossible atm because they are not part of the DOM

For a plugin to totally account for visibility it will likely have to traverse the entire DOM and re-organize it (or label each element) into a layout stack per CSS Layout rules.

[Lars Jung]

Hi Kevin,

I didn't forget about you. Just have some busy weeks right now. I'll keep you updated as soon as I find time to work on fracs again!

Thanks for all the input, looks very challenging!
Lars

[Barney Carroll]

A performance-intensive (but procedurally feasible) method of determining how much of an element is covered would be iterating each visible pixel (as determined by the current code), and testing document.elementFromPoint(x,y) for that pixel.

It sounds grim, but it's by far and away better than interpreting the z-index (and opacity!) stack, positions of each such element, etc.

[Lars Jung]

I don't think that I will put work into this request so I finally close it now, sry.