I can see from console.logs that the variable is updating every second. But the {{variable}} in the HTML isn't. If I select the text it updates, or if the container div is animated the variable updates.
In the .ts I have a
ngOnInit() {
this.ref.detectChanges();
}
and I tried calling this.ref.detectChanges() every second when I update the variable.
All of the {{}} are not being updated until something else happens. A *ngIf displays something, or a CSS animation is triggered. No errors in the console.
CSS animation for the drawer :
.moveOutProductDrawer{
left: -250px;
animation: scootch 0.3s forwards;
}
#keyframes scootch {
100% { left: -250px !important; }
}
And in another part of the .ts I'm changing the height and width directly.
Has anyone experienced this before? Does the presence of CSS animation mess with Angular?
For some reason, when I change how the window is positioned into the center of the screen, everything is back to normal.
.bigFlexcontainer{
/* display: flex;
align-items: center;
justify-content: center; */
position: relative;
width: 100%;
height: 100%;
}
with position relative and no more flex, the variables are updating correctly and all is well. Probably shouldn't matter, but in this case it solved the problem.
I have a block with .cube class - which implement a red cube.
.cube {
position: absolute;
top: 50px;
left: 50px;
width: 20px;
height: 20px;
background: red;
transition: .3s opacity;
}
And pseudo-selector :before with a "border" around it (actually it's just more larger cube around .cube class).
.cube::before {
position: absolute;
top: -10px; left: -10px;
right: -10px; bottom: -10px;
content: '';
background: black;
z-index: -1;
}
On :hover I change my opacity in .cube class.
.cube:hover {
opacity: .5;
}
The question is: why .cube class on hover is disappears, in turn, it is not "under" :before. Where it?
Here is JSFiddle. Thanks!
.cube {
position: absolute;
top: 50px;
left: 50px;
width: 20px;
height: 20px;
background: red;
transition: .3s opacity;
}
.cube::before {
position: absolute;
top: -10px; left: -10px;
right: -10px; bottom: -10px;
content: '';
background: black;
z-index: -1;
}
.cube:hover {
opacity: .5;
}
<div class="cube"></div>
Paulie_D was right! The stacking context is being affected. Check this out here for more information:
https://www.w3.org/TR/css3-color/#transparency
I decided to modify your example to show what's going on a bit more easily. I must say, you don't see browser stacking context coming into play this way every day! (Sorry)
Here's what I've done:
Extended the duration of the original transition
Added a transition of a different time to differentiate each direction of the interim change.
Changed the color from black to cyan to help with visual color changes (A brighter color will help one see the difference between 'above' and 'below' in stack
Added a reduced opacity style to the (presently) cyan colored :before element.
Here's the fiddle:
https://jsfiddle.net/c5d5thhk/
Instructions: Mouse over the box. Please Note:
the change in color relative to the timing of the relevant transition.
that the appearance in color (affected by opacity) never truly finishes changing back to its initial state (until an end-'flick' at the very end of the transition) when coded like this. This is because the inherent change in stacking context is never allowed to return back to the initial state smoothly as the transition commands. This is why I've changed the coloring to cyan and added the opacity rules that I have.
Don't forget: ::before is inherently before the rest of the element in source order. It may help to see this fiddle with ::before changed to ::after to help demonstrate the other side of the fence. https://jsfiddle.net/c5d5thhk/1/
And yes, there is some buggy behavior on several browsers for this demo; sometimes the transition never allows the stacking context to return to its initial order, even when the opacity has finished its course in the transition's entire duration of 3s (3 seconds) - if this gets in the way of your testing, play around with the mouse a bit; the agitation should cause it to resolve within a few moments if it doesn't on its own.
Edit:
Just saw that the MDN has a much clearer breakdown than the W3C (surprise, surprise) on how the stacking context goes. Check it out here:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
Also, check this out for influencing stacks:
https://developer.mozilla.org/en-US/docs/Web/CSS/isolation
Edit 2: (added comment)
Here's a bit more information. As for your repeated question, your red box's box model is behind the black box. However, because of the rendering process taken to address transparency, it isn't shown in your example when the opacity style is engaged. In other words: even though the black box has a reduced opacity where one expects to have any content behind it revealed, the red box will still not be shown because of the process taken for the alpha channel. If you'd like to learn more about this, try running this with an SVG.
I have a problem regarding CSS3's transitioning. As seen in the snippet of my CSS file below, I have made a footer slide up whenever it is toggled active (I do this using jQuery).
Whenever it becomes active, it pushes the content of the website upwards until it finishes its transition, at which point the content slides back down. It looks like the page expands, but this should not happen because of the position attribute. Why is this happening?
Thanks in advance for any help.
.footer {
height: 130px;
width: 100%;
position: absolute;
bottom: -130px;
background-color: #333;
transition: bottom 250ms ease-out;
}
.footer-active {
bottom: 0;
}
I found a solution to the problem. It seems whenever the element moves, the window will automatically scroll to the element's position. I fixed the problem by inserting overflow: hidden into the html's and body's CSS rule.
Any idea why this isn't working? The default style in CSS is opacity = 0. Not only does the opacity not change in the div I want to appear, but when the mouse goes over the link it doesn't even show it as being a link. (it works well when I use "visibility" instead of the opacity property, but it causes blinking due to the action triggering the "onmouseout" event)
<a href="#" onMouseOver=" document.getElementById('pop_up1').style.opacity = 1" onMouseOut="document.getElementById('pop_up1').style.opacity = 0">
Here's the CSS:
#pop_up1 {
opacity: 0;
position:fixed;
width: 100%;
height: 100%;
z-index: 2;
text-align: center;
}
Oh wait, I think I see the problem. Even though the #pop_up1 div is invisible it is still over all the links and thus nothing is registered by the mouse at all. Is there a way to solve this problem?
"Oh wait, I think I see the problem. Even though the #pop_up1 div is
invisible it is still over all the links and thus nothing is
registered by the mouse at all. Is there a way to solve this problem?"
-- use display:none instead of opacity to hide it, like
#pop_up1 {
display:none;
position:fixed;
width: 100%;
height: 100%;
z-index: 2;
text-align: center;
}
I've been building a website in Safari, and I've just tested it in Firefox and my fixed navigation elements are behaving as if they're position is absolute.
#navigation {
display: block;
width: 100%;
height: 50px;
position: fixed;
left: 0px;
bottom: 0px;
text-align: center;
z-index: 99000;
}
This is the CSS I have for the primary navigation wrapper (it's a bottom nav.). In Webkit, it works perfectly: that is, it sticks to the bottom of the window regardless. In firefox, it positions itself at the end of the tags, so, for example, on a long page, I'd have to scroll down just to see it. It is acting as if it's absolute.
I also have a sidebar navigation.
.slidebar {
display: block;
position: fixed;
left: -1px;
top: -1px;
width: 1px;
height: 100%;
overflow: hidden;
-webkit-transition: all 300ms ease;
-moz-transition: all 300ms ease;
-o-transition: all 300ms ease;
-ms-transition: all 300ms ease;
transition: all 300ms ease;
z-index: 99998;
}
This sidebar is also acting as if it's absolute - that is, it is positioning itself off the screen properly, but it's elongating <body> and thus the horizontal scrollbar appears. The height: 100%; is also responding to the <body> height and not the window height, so, for example, my <header> has a top margin of 20px, and the slidebar observes that margin too (the body has 0 margin). Likewise, instead of the height: 100%; ending at the bottom of the window, it ends at the bottom of the <body>, factoring in the footer's bottom margin.
I cannot understand for the life of me why this is happening. Element inspection shows all the properties are loading fine, and in Chrome and Safari it works. It worked initially, and it worked the last time I even edited either navigation, but it has since stopped working since I built other, irrelevant, parts of the site.
http://www.upprise.com/demo.php - click the Envelope icon to see the sidebar
I had the exact same problem, turns out the following CSS property of a parent element was causing the problem.
transform: translate3d(0px, 0px, 0px);
Through the process of elimination I was able to determine that having the following in my body was causing all the problems with fixed divs in Firefox:
-o-backface-visibility: hidden;
-moz-backface-visibility: hidden;
-webkit-backface-visibility: hidden;
backface-visibility: hidden;
I had originally added this code to prevent flickering in certain CSS transitions throughout the site, but I guess I'll have to add it to each individual class now.
It appears that some browsers will will apply fixed positioning relative to the window, while Firefox is applying it relative to the <body />. You need to make your body 100% tall:
body {
height: 100%;
}
But the margin from your .header is collapsing outside of the body element. Change this:
margin: 25px auto;
to this:
margin: 0 auto; /* updated - thanks JoshC */
padding: 25px auto;
I solved the issue by moving the element that uses position: fixed; out of its original parent element that uses transform: translateX(-50%);.
Thus...
<div class="transformed-container">
<div="fixed-element"></div>
</div>
...became...
<div class="transformed-container"></div>
<div class="fixed-element"></div>
Two things led me to this conclusion:
#Pankaj's answer shows that the translate value can cause an issue.
#Wildhoney's comment to another answer references an explanation of the underlying cause: http://meyerweb.com/eric/thoughts/2011/09/12/un-fixing-fixed-elements-with-css-transforms/
The problem seems to be in your body, i've added width:100%; height:100%; and overflow:hidden; to it in my fire fox and it looked just fine, except for the bottom menu-bar that went half of it's height over the bottom.
Not sure why the browsers were rendering differently, though the solution is pretty simple. You need to give the parent elements (html/body) a height of 100% in order to fill the entire page. It seems like FF rendered the fixed elements at the bottom of the contents as opposed to the bottom of the window. Adding the following will make it work across browsers:
html, body {
height: 100%;
}
In addition, you should also use padding on .header element as opposed to a margin. This will solve another issue.
.header {
margin: 0 auto; /* use a value of 0 rather than 25px */
padding: 25px 0;
}
I tested all this in the browser, it will work in FF now. It should also render properly in Chrome and others.
I needed to remove some css classes from the superior container of the fixed-on-scroll element that had a transition, from the animateCSS library.
$(window).on('scroll', function () {
if (distance <= 65) {
$('#my-contaniner').removeClass('animated fadeInLeft'); //delete problematic classes for FF
Add your code
});
Maybe it helps
After 5 hours of debugging, if you are using tailwindcss and you have drop-shadow-* (pay attention it's not shadow-*) class on one of your parent elements, it will cause the fixed elements within that element to act like they're absolute positioned.
Not sure why that is happening, maybe due to fact that tailwindcss is using lots of combined CSS variables.
Here's an example of what gets generated with tailwindcss drop-shadow-* utility, seems like filter property on one of the parent elements causes the same unexpected behaviour as transforms:
.drop-shadow-lg {
--tw-drop-shadow: drop-shadow(0 10px 8px rgba(0, 0, 0, 0.04)) drop-shadow(0 4px 3px rgba(0, 0, 0, 0.1));
filter: var(--tw-filter);
}