How can I find an element I can't see so I can position it correctly? - css-position

I've got an element it's position: absolute, and left:0;
As soon as I put in top:0; it disappears. I know it's there somewhere but I can't work out where. I tried increasing top by 10px at a time and decreasing by -10px at a time but it doesn't show up.
Is there any way I can see where it is positioned on the page easily so I can work out what I am doing wrong and bring it into view?

I don't know why left: 0; worked and top: 0; caused a problem but I added position: relative; to the parent which allowed me to see my element and position it.

Related

Positioning in Slimbox

Slimbox is working perfectly for me with one exception... my slideshows often open way to low. The positioning is effected by any scrolling already done on the page. Every time the page is scrolled a bit, the slideshow opens lower than it had previously for the same page. Scroll down the page much and the show can be completely out of sight.
lbCenter and lbBottomContainer in the CSS control the positioning, but I can't find how to adjust them accurately. The default is:
#lbCenter,
#lbBottomContainer {
position: absolute;
z-index: 9999;
overflow: hidden;
background-color: #fff;
}
In an old thread here, I found suggestion for adding:
top: 30px !important;
As long as !important is included, this does work but with a significant caveat; the caption is moved from below to above the image and covers some of it. ( And !Important doesn't seem like an ideal solution )
How can I adjust the positioning of both while keeping the caption below the image?
This one was on me. My links included href="#" as some others required. The # caused the page to scroll to the top even as the slide show opened where the link was located.
<a href="#" onclick="show('homes')">
Eliminating the hash tag resolved it.

Safari Browser z-index or Transform CSS Property Issue - Elements Not Visible / Backgrounded

I've got an issue with visibility of HTML elements in Safari (Mobile and Desktop) not rendering in the foreground that I've spent at least 8 hours of dedicated troubleshooting on trying to address.
The concept I'm after seems very simple; I'm trying to display a couple of labels (<p>'s and <a>'s within a <div> that is position:absolute;. I'm leveraging a 3rd party Javascript coverflow that is forcing the absolute positioning but I'm willing to make any modifications needed to get this working.
I naturally assumed this was a z-index issue that was only effecting Safari but there are no rendering issues in Chrome, IE, Edge, and Firefox including Android mobile devices.
The issue can easily be reproduced on www.bibleanthem.com when looking at the media coverflow from iOS/Safari and likely macOS; for a brief second while it is initially loading, the elements are visible and then the album artwork moves to the foreground. You can also see a slight hint of the '+1' badge on the corner at the lower edge of the album artwork. You can even click where the two invisible buttons are and interact with the document (e.g. play song immediately or add to playlist).
What I've Tried
Changing (and IIRC dropping entirely) transform usage from each Coverflow item (see "Additional Detail" section below for an important note)
z-index changes (including absurdly large values like 10000000000000)
Changing position to fixed, relative, sticky for the parent div
Changing position to fixed, relative, sticky for child elements
Changing display between block and inline-block
Changing overflow on most elements in the hierarchy
Additional Detail
I've seen issues in the past with Safari not playing nicely with transform; that could be the issue here and the symptoms are very similar to my past experiences but I haven't been able to fix the issue. This is where I'd guess the problem actually resides.
Rendered HTML for each Coverflow item
<div style="position: absolute; display: block; overflow: visible; left: 0px; top: 0px; margin: 0px; padding: 0px; max-width: none; max-height: none; border: none; line-height: 1; background-color: transparent; backface-visibility: hidden; -webkit-font-smoothing: antialiased; text-rendering: optimizeLegibility; width: 95px; transform: translate(142px, 119px); opacity: 1;"><p class="largeLabel"><i class="fa fa-list-ol"></i><span class="badge">+1</span><i class="fa fa-play play-btn-adjust"></i></p><p class="smallLabel"><span class="title-cf-main">Song Title</span><br><span class="title-cf-artist">Artist Title</span><br><span class="title-cf-verse">Acts 17</span></p></div>
How To Reproduce
Visit www.bibleanthem.com from desktop or mobile Safari and notice how the album artwork takes foreground positioning over the label/text.
Desired End State
The blue background label, song title, artist title, and verse title should be visible above the album artwork in the coverflow (as seen in non-Safari browsers)
Thank you in advance for any assistance you can provide. I can't tell you how much I'd appreciate addressing this issue!
Try setting the z-index on the div instead of the label. If you create a fiddle I'll play around with it a little more.

Check if a WebElement (covered due to CSS) is visible to the user

In the following code, I have two <div> tags that display different colored columns, one red, one green:
<html>
<body>
<style>
html, body {
height: 100%;
}
#red {
width:50%;
background: #f00;
height: 100%;
}
#green {
width: 250px;
background: #0f0;
height: 100%;
}
</style>
<div id="red">
</div>
<div id="green">
</div>
</body>
</html>
When it is displayed, the red div tag completely covers the green div tag due to the percentage width of the red area being greater than the pixel width of the green. (You can see this on JFiddle)
The problem I'm having is that in Selenium, I can't find a way to programmatically verify whether or not the green div is visible to the user. Trying greenDivWebElement.isDisplayed() returns true with the above code, despite the fact that the user cannot see it.
I did discover that doing greenDivWebElement.click() does reveal that the green div is not visible as the following error is thrown:
org.openqa.selenium.WebDriverException: unknown error: Element is not clickable at point (133, 361). Other element would receive the click: <div id="red">...</div>
However, this solution won't work for me in the real world because the sort of things I want to check the visibility of do something when clicked and while I want to make sure that they are visible to the user, I don't want for them to be clicked.
So how can I check if a WebElement is visible to the user if it is covered due to CSS?
I ran into a similar requirement recently. I do not have the complete solution implemented yet but at a high level these are the steps I am taking. To verify element A is not overlapped by any other element
Get the element in question, bind the click() event of the element to a function that does nothing.
Click on 9 points of the element - center; top: left, center, right; middle: left, right; bottom: left, center, right. Selenium clicks on an element at the center point by default. The other points can be calculated by DOM positioning of the element and then moving to the respective points.
Wrap the call block in step 2 in a try/catch to check for Element not clickable... exception.
If an exception is thrown, element is overlapped by another at one of the click points.
The challenge here is definitely the bind/unbind of the click event. For my particular case it is straight forward using JQuery to achieve the binding.
One other way I initially thought of handling the click problem is to disable Javascript in the driver before running the test. But of course this approach will only work if there is no JS trickery involved in rendering page elements.
Part two of the challenge is the granularity of the click points. 8 points along the edges usually works but if there is overlap outside of the click points then the number of click points has to be bumped up.

Opacity change during a transition flickers in Safari

I have a composited div (it has translate3d) with an opacity transition:
#bad {
background-color: red;
-webkit-transition: opacity .5s linear;
-webkit-transform: translate3d(0, 0, 0);
}
If I change its opacity while transition is undergoing, it will flicker in Safari.
The flicker happens about once in three seconds and is akin to a white flash.
There is no such problem in Chrome.
Scroll up and down in this fiddle to see what I mean.
The problem does not seem to be limited to opacity—changing -webkit-transform while its transition is undergoing has a similar effect: once in a while the element is rendered in one of the transition's final states.
The problem goes away if I remove -webkit-transform but unfortunately that's not an option right now.
Can I fix this in Safari by some other means?
The problem is changing property values and adding animations need to happen at the same time.
A race condition not present in OSX 10.5 was introduced when Core Animation was rewritten in C++. I learned this when my experiments with additive animation developed the same flicker. I found the workaround to be Core Animation's kCAFillModeBackwards. I also found the same workaround was effective for CSS Transitions by hacking up my own fork of WebKit, with emphasis on the hacking part. But conjecture doesn't help WebKit devs and I didn't want to annoy them any further. I do think the problem is with Core Animation, not WebKit. I'm guessing that they should use the same CFTimeInterval derived from a single call to CACurrentMediaTime throughout any given CATransaction.
Unlike transitions, CSS animations do allow for fill modes. It might be difficult to reproduce transition behavior, but that is one option. In particular, the challenge would be replacing interrupted animations with new ones that begin where the previous left off. In other words, it's easy to animate from opacity of 0 to 1 or 1 to 0, but what happens if the user wants to start when current animated progress is at 0.577564? This might require manually modifying the #keyframes style rule, not an easy task.
Then there is the question of the appropriate animation-fill-mode. Normally you wouldn't want to perform layout using forward filling animations, you'd use the CSS properties themselves. But in this case it might be simple enough to not set the underlying value, instead use only a forward filling CSS animation that gets replaced but never removed when finished. The alternative is setting the underlying value via element.style and at the same time adding a backwards filling CSS animation.
Of course, the flicker also does not happen if WebKit doesn't use Core Animation. By far the easiest way to prevent the flicker in your case is to not enable hardware acceleration.
Instead of:
-webkit-transform: translate3d(100px, 100px, 0);
try:
-webkit-transform: translate(100px, 100px);
http://jsfiddle.net/z6ejt/9/
In my case I found 3 actions that solved the same problem:
I needed to fade in an image on the ready event, tried with the jQuery animation but the image was flickering on OSX Safari.
Solved with these actions:
1) Analyze the CSS and delete all transition rules applied on the image, they seem to conflict with the animation command.
I had this rule
img {
/*DON'T COPY !!!*/
-webkit-transition:all 0.2s ease-in-out;
-moz-transition:all 0.2s ease-in-out;
-ms-transition:all 0.2s ease-in-out;
-o-transition:all 0.2s ease-in-out;
transition:all 0.2s ease-in-out;
/*DON'T COPY !!!*/
}
I deleted it.
2) Add this CSS rules to the element you need to fade in:
display: none;/*initial state modified by the fadeIn function*/
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
-webkit-font-smoothing: antialiased;
-webkit-transform-style: preserve-3d;
-webkit-transform: translateZ(0);
3) Use the jQuery function "fadeIn" and don't use the command ".animate({opacity: 1} ecc..".
These actions resolved the flickering problem on OSX Safari .
This seems like a bug in CoreAnimation.
Kevin Doughty blogged about it and provided a simple fiddle to reproduce it.
I am not certain, but I believe it is caused by a Core Animation bug rdar://problem/12081774 a.k.a. the flash of un-animated content.
[...]
I believe the Safari transition flicker is directly related to the bug I filed. The workaround is to use a Core Animation fillMode of kCAFillModeBackwards or kCAFillModeBoth. It seems like there is something wrong with animation timing, where a property value change and an animation started on that property within the same transaction don’t actually begin at the same time. A backwards fill solves this by extending the effect of the late starting animation to be applied before its actual start time.
Kevin also reported this as #115278 in WebKit and tried to tackle it but from my understanding he didn't proceed with this and the patch wasn't accepted.
Of course it's not a real answer (doesn't solve the problem) but at least it explains the problem.
The following CSS fix the transition flicker on safari
* {
-webkit-backface-visibility: hidden;
}

Referring to a class's height in less

I just got into LESS this morning. It's a lot nicer to write than pure css, BUT it would really solve a big headache for me if it was possible to refer to attribute from classes within classes...
Say I have
#El1
{
width: 100%;
}
I'd like to do something like
#El2
{
position: absolute;
width: 100%;
top: #El1.height;
bottom: 0;
}
So #El1 can size itself whichever way it wants and #El2 can be positioned beneath it and fill the entire remained for the viewport.
Not matter how hard I google I can't find anything to seem to indicate that this is possible. From how I understand the processing of the stylesheet takes place on load, my hunch is that this can't be done, because the height of El1 isn't known by the time the css rules are processed. But just on the off chance that there is a way to do this, I thought I'd ask... so is there any way that this can be done?