I have just noticed strange behavior of semi-transparent text with negative letter-spacing in Chrome. Basically, this CSS leads to darker intersections:
div {
opacity: .5;
letter-spacing: -.2em;
}
Here's the screenshot:
Is there any CSS instruction to handle with this, so intersections will look the same in different browsers? Screenshot was made in Win Chrome 76.0.3809.100 (64-bit)
Fiddle → https://jsfiddle.net/yakunins/gcatnksh/
Looks more like bug in Chrome — https://bugs.chromium.org/p/chromium/issues/detail?id=1006140
Related
I was goofing around with the ::placeholder pseudoelement on Codepen (Chrome 59.0.3071) when I noticed something odd. (please see my JSFiddle)
In brief, this CSS should not enable a transition of the ::placeholder color over 2s:
input::placeholder {color:red;transition:2s;}
input:hover::placeholder {color:green}
Using Firefox, there is no color transition over a 2 second interval on hover (this appears to be correct according to this section of a W3C spec and this section of a different one - follow the thread to the ::first-line pseudo-element), but instead there is an immediate color transition to green;
However, the same JSFiddle using Chrome does show a ::placeholder color transition over a period of 2 seconds, which according to the specs, appears to be incorrect.
Is this a bug in this version of Chrome (and if so, is it being addressed?) or is this an indictment of my lack of understanding of CSS?
Currently, it seems that Gecko's and Webkit's implementations are very
similar. The set of allowed rules are slightly different and the
default styling isn't the same but those are clearly solvable issues.
-- From http://lists.w3.org/Archives/Public/www-style/2013Jan/0283.html
Non-standard This feature is non-standard and is not on a standards
track. Do not use it on production sites facing the Web: it will not
work for every user. There may also be large incompatibilities between
implementations and the behavior may change in the future.
-- From https://developer.mozilla.org/en/docs/Web/CSS/::-moz-placeholder
Only the subset of CSS properties that apply to the ::first-line
pseudo-element can be used in a rule using ::placeholder in its
selector.
-- From https://developer.mozilla.org/en-US/docs/Web/CSS/::placeholder
But apparently both Chrome and Firefox apply no transitions for ::first-line, as is evident through this JSfiddle I made.
Also while I was searching on the net for answers, I found that the transition property for ::placeholder was working in an older version of Firefox with vendor prefixes which simply reconfirms the line from spec,
behaviour may change in the future.
Here's the code for the JSfiddle.
input::-webkit-input-placeholder {
color: red;
transition: 2s;
}
input:hover::-webkit-input-placeholder {
color: green
}
p::first-line {
color: red;
transition: 2s;
}
p:hover::first-line {
color: green
}
<input placeholder="Sup">
<br />
<p style="display:inline-block">This is the first line.</br> Check it out</p>
I couldn't find it in the w3c docs.
It looks like it used to work in some older Firefox versions.
A workaround with css could be:
input[placeholder]{color:red; transition:color 2.1s;}
input:focus[placeholder]{color:blue}
Which works in Chrome and Firefox.
I've noticed a strange issue with CSS transitions in MS Edge.
Basically if you have a transition, between hover states for example, but the styles defined for those hover states are over-written in the CSS cascade, Edge will switch to the over-written styling for the duration of the transition, then switch back.
The issue is described fairly well here too:
https://www.webmasterworld.com/css/4791912.htm
I have also created a pen demonstrating the problem:
http://codepen.io/powerbored/pen/OWqXRw
a {
transition: all 2s ease-in;
color: orange;
}
a div {
color: lightblue;
// displays in light blue in all browsers except during transitions in Edge
}
a:hover {
color: red;
}
I know Edge isn't exactly a great browser but I what I'd really like to see is an explanation of what is actually happening here and why it could be happening.
There's something about transition-property: all that's causing the descendant element to inherit the animated value during the transition, instead of keeping its specified value indefinitely, in Microsoft Edge. This appears to be so specific to Microsoft Edge's implementation of CSS transitions, that even Internet Explorer behaves correctly, and it only occurs when transition-property is all — if you specify only the properties that need transitioning, Microsoft Edge behaves correctly.
That's all I can tell you. Well, that, and the obvious fact that this is incorrect behavior.
I can't find any info on this issue in Google, because every result is about the default purple a:visited color. That is NOT the issue here. The issue is with Chrome's default anti-aliasing, on some systems blue text shows up as blueish-purple. If I change the anti-aliasing to -webkit-font-smoothing: antialiased it keeps the correct color, but then the fonts are radically different between Chrome and Firefox. The blue color I'm using is the client's color, so it cannot change to purple like this. I'm hoping somebody has a fix for this.
Here are screenshots from tests I've done:
EDIT: Just to clarify, this has nothing to do with the default a:visited link color. My blue color is being inherited, but Chrome's anti-aliasing is causing the text to appear purple. Here's an example: http://jsfiddle.net/yvjjxfqt/
It gets solved (at least in my system) setting a transform in the element
a {
color: #1967b1;
display: block;
}
a:nth-child(2) {
transform: rotateX(0deg);
}
This is a link
This is a link
I guess that the rendering in the gpu doesn't have this problem
This is how it looks in my system
Another way to solve it seems to be using opacity
a {
color: #1967b1;
opacity: 0.99;
}
This is a link
I was wondering if someone can confirm that Chrome doesn't support transitioning the letter-spacing property. I wasn't able to find any documentation on this, but it doesn't seem to be working: http://jsfiddle.net/gjJwz/
That example works as expected for me in Firefox, but in Chrome 28.0.1500.95, the change is abrupt (no transition). I'm testing on Windows 7.
Just increase your `letter-spacing and you'll see it
a:hover {
letter-spacing: 50px;
}
http://jsfiddle.net/gjJwz/1/
Um, it works fine for me, I'm using the same version of chrome. Keep in mind that you can't gradually get to 1px of letter spacing, it would have to be a bigger value to ease in.
I have areas on my site where text is rotated 45degrees and unfortunately rendering of that text is messed up sometimes. For example, it looks relatively ok on linux using FF and chrome, however, it looks awful on the same browsers on windows. However, IE 9-10 renders that rotated text perfectly. Is there any way to overcome this messed up text?
Here's an example:
example
.wrap {height:200px; width:200px; position: absolute; top:100px;left:100px;-webkit-transform: rotate(45deg);-moz-transform: rotate(45deg);-o-transform:rotate(45deg);-ms-transform:rotate(45deg);transform:rotate(45deg);}.test1 {background: green; width:150px; height:30px; color:white;text-align: center;line-height:30px;font-family:arial; font-size:12px;font-weight:bold;}
P.S. I cannot use images to replace text, I need rotated dynamic text instead.
Thanks
See Wonky text anti-aliasing when rotating with webkit-transform in Chrome.
The answer there recommends amending your transformation with an additional transform that triggers the 3-D processing:
-webkit-transform: rotate(.7deg) translate3d( 0, 0, 0);
In addition to the fix offered there, there are a few other tricks used for cleaning up webfont rendering (see How To: Clean Up Chrome and Safari's Webfont Rendering). Try adding a barely perceptible text-shadow (may or may not work):
text-shadow: rgba(255,255,255,0.01) 0 0 1px;