The wordpress theme I have, NeoBeat is causing my logo at top to be blurry.
My site is earthcry.net
The CSS for the image above is
opacity: 1;
position: absolute;
top: 50%;
left: 0;
-webkit-transform: translateY(-50%);
-ms-transform: translateY(-50%);
transform: translateY(-50%);
It's actually being caused by this css here which is reducing the size and causing the blur:
#qodef-page-header .qodef-header-logo-link img {
display: block;
margin: auto 0;
width: auto; // Comment this out or delete
max-height: 100%; // Comment this out or delete
-webkit-transition: opacity .3s ease;
-o-transition: opacity .3s ease;
transition: opacity .3s ease;
}
If you get rid of those, it shows at it's intended size.
This is actually a relatively common issue with using the (relatively old hat) method of vertical centering with absolute positions. A quick search here, The Goog, The duck site, etc, will show many results for "blurry <element> with transforms`.
The easiest and most pragmatic way to deal with this is to not use the "absolute/50%/transform -50%" method to center elements, and upgrade to using flex, align-items: center and justify-content: center. There's all sorts of hacky ways to fix the blur, but you'll need to cycle through them and find which works for you (basically, it's being perfectly centered in a 69px tall element so it's got half a pixel on each side of center to deal with that it can't place, so it aliases it.)
However, with all of that said, it looks like you don't actually need a centering mechanism at all.
All you need to do is remove the actual position overrides and transforms. Here's your logo as it stands (it seems to be correct on mobile).
If you instead just used:
opacity: 1;
position: absolute;
It would look just fine:
Just remove the top, left and vendor-prefixed transform: translateY and you should be good to go.
(The previews in the answer may be blurry, click on them to open them up though, I promise the latter one is crisp, lol)
Related
CSS transition property is only working in one direction on <details> tag -- when opening. No transition when closing. I've tested on Chrome & Firefox.
To add, on Chrome, the opening transition only works once.
details
position: relative
ul
position: absolute
bottom: 100%
left: 0
height: 300px
display: flex
flex-direction: column
transition: transform 0.3s ease-in-out
transform-origin: bottom
transform: scaleY(0)
&[open]
ul
transform: scaleY(1)
The details tag works by instantly showing and hiding its contents. When you close it, the contents immediately disappear so no transition is witnessed.
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 am trying to create a box with a jagged edge, that can actually be used as a HTML element should be, and can resize etc.
Finally got my head around border-image, got it looking nice, and then when I rotate it, it gets a gap between the border-image and the main fill:
I googled it, and found an answer on SO telling someone to set
-webkit-backface-visibility: hidden;
This cleared it up, but obviously only in webkit browsers.
I tried using -moz-backface-visibility as well, but it didn't clear the issue up in Firefox.
Any suggestions?
jsFiddle
e: I actually thought I may be able to fix it by setting a background color, and then setting the background-clip to padding-box, but honestly it just left me in the same position.
One trick that fixes the problem both in Webkit and FF is setting perspective (instead of backface visibility)
.box.one {
-webkit-transform: perspective(999px) rotate(1deg);
-moz-transform: rotate(1deg);
-ms-transform: rotate(1deg);
-o-transform: rotate(1deg);
transform: perspective(999px) rotate(1deg);
}
fiddle
Adding an after pseudo class with negative margin seems to fix the Firefox issue.
.rough:after {
content: "";
display: block;
margin: -1px;
height: 302px;
background: black;
}
Fiddle demo: http://jsfiddle.net/Wkk7W/3/
Note that the display:block seems to be an essential part of my hack/fix.
Update: Depending on your plans for content inside the div, that exact example might not suit. However, I think the concept could be tweaked depending on your requirements - e.g. using a 3px wide black border instead of a background fill, and using position:absolute to allow other text to be layered on top of the box.
Gonna answer myself, because this solution actually covers my needs of it being "as a html element should be, and can resize etc", even though I developed this solution from Grants answer.
http://jsfiddle.net/Wkk7W/6/
Set the element to position:absolute, then give it a pseudo element with:
content: "";
display: block;
position: absolute;
top: 0;
width: 102%;
margin: -1px 0 0 -1%;
height: 102%;
background: black;
z-index: -1;
This way it keeps the elements width and height, z-index: -1 to put it behind the text. It might not require the display:block, i didn't check.
There are still a few tiny gaps but they are basically impossible to cover and I am happy with it the way it is.
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);
}
I am trying to implement a CSS-based animation involving a single Unicode character:
HTML
<div class="spinner">⊗</div>
CSS
.spinner {
display: inline-block;
font-size: 42pt;
margin: 50px;
animation: spin 0.5s infinite linear;
}
#keyframes spin {
to { transform: rotate(360deg); }
}
* I've omitted the vendor-specific prefixes in this example.
However, when I view the page in my browser (Firefox 20.0), the character is slightly off-center, resulting in a "wobbly" animation.
You can see it live here: http://jsfiddle.net/bBaVN/77/
How can I completely center the character?
Proof of Concept using SVG
Consider the following:
<div class="wrap">
<span class="spinner">
<svg {...many other attributes...} class="logo">
...path code...
</svg>
</span>
</wrap>
See the fiddle: http://jsfiddle.net/audetwebdesign/3G3U7/
I found a SVG version of the symbol at:
http://www.fileformat.info/info/unicode/char/2297/index.htm
I had to take the SVG, open it in Adobe Illustrator and then reset the view port (bounding box?) using object->artboards->fit to artwork bounds.
I then saved as SVG and then cut-paste the <svg> block into the demo, and finally, I added the class="logo" attribute to the <svg> tag.
For styling, I used the following CSS:
.spinner {
display: block;
width: 50px;
height: 50px;
position: relative;
top: 75px;
left: 75px;
animation: spin 1s infinite linear;
}
.logo {
display: block;
width: 50px;
height: 50px;
}
I set the display type to block for both .logo and .spinner, and both have the same height and width (use a square box for best results.
Seems to work. The hardest part was learning how to set up the SVG inline image. I found the following reference useful: http://css-tricks.com/using-svg/
You could set the line-height to 45px on .spinner, this will ensure that the containing span element is as high as it is wide. Here's a jsFiddle. Now there is a little less movement, but it still doesn't look like it is not moving around at all.
Another way to get it to rotate around the center of character instead of around the center of the containing span would be to play around with -vendorspecificprefix-transform-origin. You could set it to rotate around another point e.g. setting it to: 23px 34px would set the x and y coordinates for the point to rotate around.
I think the fact that it still looks like it moves around a little bit might be due to the character not being rendered as a perfect circle, you could try rendering it in a different font, changing point sizes of the font, or even turning text-rendering: optimizelegibility; on or off might make a difference there.
The default value for -vendorspecificprefix-transform-origin is 50% 50%, this suggests that if you make sure that the character inside the element is perfectly centered, and you set the animation on the containing element, it should rotate exactly around the the center, and then playing with -vendorspecificprefix-transform-origin would only make things worse.
Another thought I'm having, by setting the point size of the text to 42pt, the width of the containing span becomes 45px, now 50% of that would be 22.5px, maybe it would work if you made the point size of the text a bit bigger, or just set the width and the height of the containing span to 46px, then 50% would be 23px, which might make the difference with the current movement.
Update:
I was able to get it to be centered perfectly in Chrome (and in FireFox) by using a mono-space font Courier, manually setting the line-height, height and width of the span to center the character, and then forcing the character to look more like a circle by moving it over by 0.5px using -webkit-transform: translate().
.spinner {
display: inline-block;
font-size: 42pt;
line-height: 50px;
height: 46px;
width: 46px;
margin: 50px;
-webkit-animation: spin 1s infinite linear;
-moz-animation: spin 1s infinite linear;
-ms-animation: spin 1s infinite linear;
-o-animation: spin 1s infinite linear;
animation: spin 1s infinite linear;
font-family: courier;
}
#-webkit-keyframes spin {
from { -webkit-transform: rotate(0deg) translate(0.5px, 0px)}
to { -webkit-transform: rotate(360deg) translate(0.5px, 0px)}
}
I think the fact that I need 2 jsFiddle's to demonstrate for different browsers kind of answers the question about if you should be doing it this way, I think the differences in font-rendering between browsers will ensure that you can't do this reliably without browser detection.