I've got a problem with zooming into a masked element.
You can take a look at my jsfiddle example: https://jsfiddle.net/1a7nb5my/9/ (you can see it lagging on the top left corner).
This works fine in Safari, Chrome etc, but not in Firefox.
This is what I'm doing:
.test
{
-webkit-mask-size: 100% 100%;
}
.test.active
{
-webkit-mask-size: 100000px 100000px;
}
Firefox starts lagging once the mask gets too large.
This also slows down the rest of my page as it happens, so even if it doesn't look too bad in this example, it's kind of a big problem for me.
I can't come up with any other solution to this problem other than increasing the mask size, so if anyone has other ideas on how to solve this problem I'd be happy to try them.
Solutions on how to fix the lagging in Firefox are also appreciated.
Thank you for any hint and help in advance.
Edit:
I found a workaround, which does not lag: https://jsfiddle.net/5sv7j1ck/7/
Using scale on the mask and inverting the scale on the background, is possible but you can see the mask getting pixelated although it's an SVG.
Here is a fiddle:
http://jsfiddle.net/e80fen4p/2/
EDIT: You can just highlight all of the result div and you'll see the colors change back to what they should be. I'm guessing there isn't a fix for this. If its that easy to "fix" it just by highlighting it, it probably isn't a problem with the code.
Basically it works as intended in IE11 and chrome and Firefox, but if you do this fiddle in IE10, you'll notice when the child div slideToggles, the background color starts over in the child div rather than extending to include the child div as it expands.
If you try this fiddle in IE10 you should see what I mean. It will look normal in all other browsers.
I'm wondering if there is anything I can do to modify my CSS code to make it work properly in IE10 also.
I've tried:
background-image: -ms-linear-gradient(top, #FFFFFF 0%, #A4A4A4 100%);
but it still doesn't do anything different in IE10.
The normal way I use it is
background: linear-gradient(#FFFFFF, #A4A4A4);
which works in IE11 and all the other browsers. It seems its just IE10 that is throwing me through a loop.
The weird part is, if i open Developer tools and highlight any of the div's,the colors reset and look like they are supposed to look when the div is expanded. That, to me, says its clearly a bug with how IE10 is displaying it on its first run of the code.
Anything I can do or is it just IE10 people are gonna see it slightly different. This bug doesn't stop my code from working or the webpage from being useable just makes it look weird.
I added:
height: 100%;
margin: 0;
background-repeat: no-repeat;
background-attachment: fixed;
and it started working.
its not perfect and it isn't exactly the same, but at least its working.
The difference is when its minimized (slideToggled) it only shows the top of the div's colors, it doesn't show the full gradient in the minimized div but that isn't a big deal, just cosmetic. It's better than what it was doing.
I have a hover effect that when it is triggered, the box enlarges. Only issue i have is that the text seems to blur during the transition and then goes sharp again when 'transformed'.
Before posting on here i decided to have a research and came across this post which seems to be the issue with mine as well:
How to force re-render after a WebKit 3D transform in Safari
http://duopixel.com/stack/scale.html
I have applied their answer to my build and still the blurred effect happens. I have provided a link below and if anyone could advise me with what i have is possible to resolve that would be great!
eg of transition code:
-moz-transform:scale(1.05,1.05);
http://jsfiddle.net/VcVpM/1/
While it's not equivalent, setting the width, height, left, top, font-size attributes in the :hover works without the blurring on Chrome.
.cta:hover {
width: 500px;
height: 500px;
font-size: 400%;
}
The only other work-around "might" be to use animation #keyframes and set a decent amount of them ~5 or 10, it might force a correction of the blurring between each keyframe.
I found this on CSStricks.com:
It appears if you set your transforms to also use
translate3d( 0, 0, 0)
it can fix it, but it does cause fonts to be a bit blurry on rotate/transform. See here: http://codepen.io/WillsonSmith/pen/4/2
I use Jquery and needed my slider's H3 tags to be fixed. Larger text wasn't blurry for me.
I wrote the line
$("#slider1_container").find("h3").css("-webkit-transform", "translate3d(0,0,0)").css("-webkit-text-stroke", "0.15px");
and that fixed it best for me. I needed the -webkit- in front of my transform. I don't know why, as others said not to use it. I uploaded an image of the way it looked with some different settings.
EDIT:
We're in Chrome 19 now, and this still isn't fixed. Just a clarification: this happens in Chrome on Windows, not Linux or Mac. I think it has to do with Cleartype. Google, please fix this.
I've been using CSS3 text-shadow to emulate IE9's font smoothing on other browsers. Basically I've just set the text-shadow of a container's text to the container's background. You can see the behavior by setting text-shadow on a largish font element in anything lower than Chrome 14.0.833. The text looks smooth. Remove the text-shadow and the font looks jagged.
However, in Chrome 14.0.833 (UPDATE: appears it's also "broken" in 14.0.834) this no longer works. The text-shadow property still works, but not in the way it did before. You can see the behavior here (just load it up with diff. Chrome versions)
It seems as if in the older Chromes the text shadow began inside the text just a little and then spread out - which is perhaps why the text-shadow hack worked. In the newer Chrome, it appears the text shadow starts just outside the text, which is why it won't work. See what I mean here.
My question is basically: Is this a bug? Which is expected behavior, if either? Are there any other font smoothing workarounds I can use?
The W3C's spec didn't seem to say what the intended behavior is, though I did see that perhaps I should be using text-outline (which is kinda unsupported, which defeats the purpose)
Okay, i've spend quite a bit of time on this and this is what it comes down to: It's a bug.
First of all, -webkit-font-smoothing:antialiased; only works for Mac, not Windows.
I'm on Windows7, I've created a layered Pixlr image with screen shots of a JSfiddle I made that had 4 different elements with different text-shadow applied to each. You can clearly see that text-shadow has changed since Chrome13 and Chrome 14.0.835. I had to switch between the Beta and Dev channel a couple of times because I messed up, uninstalling etc. ugh.
Download the layered Pixlr image file I made from:
http://dl.dropbox.com/u/7353877/Chrome-text-shadow-v13-v14_0_835.pxd
Then go to http://pixlr.com/editor/ and choose to open file from computer, open the file.
Now in Pixlr, zoom in to the four rows of text, in the layers panel on the top layer click the checkbox and uncheck it, then check it again, do it over and over and see how drastic the change to text-shadow is.
This should be submitted as a bug. A link back to this page could be used to show the effect, if needed.
JSfiddle (The JSfiddle I used in the screenshots)
http://jsfiddle.net/nicktheandroid/Xkp9q/
I put a piece of pie in the microwave an hour and a half ago.... it's cold :(
Well, I've figured it out, sorta. Annoying since I set a bounty, but whatever.
I'm fairly certain this is not a bug and it is expected behavior - especially since we've seen a few more iterations of Chrome and it's stayed the same.
A few different methods work. I wrote up a bit for my blog, you can see the full article here, but here's the bulk of it:
First, I tried the -webkit-text-stroke:1px #000 where #000 is the
color of the text. But this style is meant for use where the color of
the text is different from the stroke, for a nice text-outline. When
both are the same color, it looks...odd. I'm not sure why; I'm no
font-rendering expert. You can see the behavior in the picture after
the article.
Next I tried a simple text-shadow:#000 0 0 1px where #000 is the same
color as the text. Due to the same Chrome 14.0.833+ problem, this
still leaves the font looking somewhat jagged. It's better than just
plain text, however.
Next I tried a combined the two attempts above. This looks a little
bit better, but it bulks up the text as it essentially adds 2 pixels
to the thinkness of the text.
Lastly, I tried applying two text-shadows: text-shadow:#000 0 1px 1px,#000 0 -1px 1px > > where #000 is the color of the text. What this does is
apply two text shadows, one of which is pushed down a little and the
other pushed up. This way, the text shadow covers the jagged edges. It
bulks up the text a little but definitely smooths it out.
Depending on the size of your text, different methods work. Smaller
(but still jagged) text could use the text-shadow, larger text could
use the shadow/stroke method, and very large text could use the
dual-shadow method. Of course the larger the text the less noticeable
the extra few pixels become. You can see all the different methods
here
text-shadow: transparent 0px 0px 0px, #000 1px 2px 1px;
OR
text-shadow: transparent 0px 0px 0px, rgba(0,0,0, 0.75) 1px 2px 1px;
Tested and works fine in different versions of Opera, Chrome, Safari & Firefox.
-webkit-font-smoothing:antialiased;
might work for you
YES! I've found a solution for this problem. It's weird, but it works for me.
So, to make it work, put this style on the element you want to smooth:
-webkit-border-bottom-left-radius: 1px;
text-shadow: 0px 0px 1px rgba(0, 0, 0, 0.01);
overflow: hidden;
I've put up a sample HTML file with just this style so you can quickly test it.
This was indeed how a lot of webfonts (Google Webfonts and also highly professional fonts from Typekit etc.) looked in Firefox (left) and Google Chrome (right) on Windows systems (and eventually elsewhere too). No joke! To clarify this: The only browser that completely messed up Google Webfonts was Google’s browser Chrome. How sick is that ? In 2013 Opera browser has switched it’s rendering engine to webkit (=the rending engine in Chrome), so this problem exists in Opera too.
more : http://www.dev-metal.com/fix-ugly-font-rendering-google-chrome/
I am pulling my hair out on this one.
We're just about done with the development of an overhaul to our site. As a last step, we're trying to wrap up all the glyphs and icons into a sprite. They're all transparent .png's so the sprite is too. It appears that if a background comes from a sptire, IE distorts it. If it comes from the original file, it does not. FF and Chrome are fine either way.
I am looking at the orignal image and the sprited version side-by-side with grids to see that the pixels are identical. I have counted the pixels in the sprite many times to ensure I'm using the right coordinates. My CSS looks like this:
XXbackground: url(sprite.png) no-repeat 0px -837px; /* lozRedRedSpacer */
background: url(lozRedRedSpacer.png) no-repeat;
The 'XX' lets me toggle back and forth. With the single-file version, it looks perfect: . The sprite-version looks like this: . It looks like it is 'squished' both vertically and horizontally. This does not happen in FF or Chrome.
Any ideas?
EDIT I was able to strip out most of the noise and post an example here. I've added notes to the example to describe my problem.
Thank you so much for taking the time to look at this!
UPDATE We've since replaced these 'overlapped divider images' with CSS pseudo-classes that REALLY do overlap and the zooming issue seems to have gone away. Of course now we have new problems - IE8 gets the z-order wrong and IE7 doesn't understand psuedo-elements at all. But at least the markup is simpler and the zooming issue is gone.
It turns out my problem was caused by IE's 'zoom' feature. Without any zoom, everything looks great like the other browsers. Even 150% or 200% looks good. But 125%, where I had it, causes this distortion. It happens in IE7 and IE8.