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.
Related
I have the following CSS classes:
.genre_element {
background-color: none;
}
div.genre_element:has(input[type="checkbox"])::before {
content: "\002B";
transition: transform .3s ease-in-out;
}
div.genre_element:has(input[type="checkbox"]:checked) {
background-color: #ff9400;
transition: all .2s;
}
div.genre_element:has(input[type="checkbox"]:checked)::before {
content: "\2713";
transform: rotate(-360deg);
transition: transform .3s ease-in-out;
}
This is supposed to show a checkmark unicode character and add a bg-color to inputs as long is they are checked and add a plus character when they are unchecked. When they are unchecked they automaticaly revert back to the color I set in the genre_element {} class, which is none.
This works as expected in Edge, Chrome and Opera, but in Firefox I can't get it to work. I used caniuse.com to check my class for browser compatibility and enabled the layout.css.has-selector.enabled flag.
This fixes part of the problem as it displays the correct style that the buttons need to have when they are checked, but I cannot uncheck them. Clicking on them has no effect.
This is how the parent divs of the buttons look like before enabling the flag:
This is how they look like after enabling the flag; unchecking does not work:
This is how they look like in Chrome, Edge and Opera (desired outcome) after unchecking them:
Since enabling the flag causes the buttons to look like they are supposed to in their checked state, I am assuming that both the ::before and the :checked are supported by Firefox (which corresponds to the information on caniuse.com and which I could confirm by looking into the developer console) but something else is causing the buttons to not work properly in firefox.
As a last resort I tried out adding this pseudo-class checking for the negation of the checked condition:
div.border_div_in_scrollbox:has(input[type="checkbox"]:not(:checked)) {
background-color: none;
transition: all .2s;
}
But this didn't fix the problem.
P.S.: After playing around a bit more I got firefox to show the desired state, but it is very buggy. Only sometimes after I select the input with the selector tool from the developer console, after I have unchecked it, does it change to the state it should have, but itt is not consistent at all. This is how it looks like (I made the original inputs visible again to make debugging easier):
According to w3.org :before and :after pseudo-elements can not be used with input elements they can only be used with container elements like div or span you can wrap input element with div/span then use :before on div/span.
for more information
can-i-use-a-before-or-after-pseudo-element-on-an-input-field
From what i can see on caniuse.com the :has() selector does not work with Firefox at all.
Had the same issue last week also and still looking for a :has() work around.
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.
HTML:
<p>Hover</p>
CSS:
p::after {
content: " here";
transition: all 1s;
}
p:hover::after {
font-size: 200%;
color: red;
}
Live demo: http://jsfiddle.net/SPHzj/13/ (works in Firefox and Chrome)
As you can see, I've set up CSS transitions on the ::after pseudo-element of the paragraph. Then, when the paragraph is hovered, two new styles apply for the pseudo-element which are transitioned.
This works in Firefox and Chrome, but not in IE10. My reasoning was that IE doesn't understand the p:hover::after selector, as it works in IE if you set the hover on an ancestor element, e.g. div:hover p::after - live demo: http://jsfiddle.net/SPHzj/14/.
However, this is not the case, as IE is indeed able to understand that selector. The trick is to define a p:hover {} rule as well. (Discovered by #maxw3st.)
p:hover {}
This rule can be empty. The mere presence of this rule will make the transitioning work in IE10.
Live demo: http://jsfiddle.net/SPHzj/15/ (also works in IE10)
What's going on here? Why does IE require that rule to be present in order for transitions to work on the pseudo-element? Should this be considered a bug?
Appears to be a Regression
This does appear to be a legitimate regression in Internet Explorer 10. As indicated on MSDN, since Internet Explorer 7 users have been able to target the hover state of any element , and not only a.
Curiously I tried the :active pseudo-class, and this appears to work as expected. Further establishing that this is a regression, you can see that by changing this to an a element, the transition takes place as expected (since historically, a and :hover go hand-in-hand).
Optional Work-Arounds
There are only a few solutions that I can think of at this point (while waiting for this to be fixed):
Use the empty p:hover {} fix.
Modify your markup to target ::after on a child of the p.
Modify the selector to use combinators.
The first item is that which you specified in your question, and is very attractive given its simplicity. In fact, you could use :hover{} and get the same results (probably the best solution).
The second item is also do-able, but a little less desirable since it requires modifying the markup, which is not always possible, and to be frank, a bit silly.
The last option is somewhat interesting. If you modify the selector to be based on sibling relationships, it magically begins to work again. For instance, suppose we have multiple elements in the body:
<h1>Hello, World</h1>
<p>This is my first paragraph. it does not animate.</p>
<p>This animates, with a pseudo-element.</p>
We can now use combinators to target the second paragraph:
p+p:hover::after {}
This selector will match any paragraph following a paragraph though, which isn't desirable. At this point we could consider :nth-child, or :nth-of-type to further specify which paragraph we want, even using the general sibling combinator:
h1~p:nth-of-type(2):hover::after {} /* Targets second <p> nearest <h1> */
But more ideally we would target with a class:
h1~.hoverme:hover::after {} /* Targets <p class="hoverme"> */
A Two-Char Solution?
One step further, maybe you don't want to be locked down explicitly providing a general sibling tag. You could also use the Universal Selector:
*~.hoverme:hover::after {} /* Targets <p class="hoverme"> among siblings */
This requires that the p tag have siblings, which is typically expected. Very rarely does a document consist of nothing more than a single paragraph tag.
I understand that these aren't ideal, but they are a means to an end for now. Let's hope to see this resolved in future releases of Internet Explorer.
Strangely, the effect will work on a <a> link rather than a paragraph tag.
It certainly appears to be an IE10 bug or regression. Fortunately, you've found a nice fix.
This same phenomenon popped up when I tried adding a rule to change the cursor to a pointer. However, cursor: pointer; has to be included in the pseudo's parent, it can't be used to target just the pseudo's content string in IE10.
http://jsfiddle.net/maxw3st/SPHzj/22/ uses a div as a container, http://jsfiddle.net/maxw3st/7sBVC/ uses the p:hover workaround. Adding the div was suggested by #simevidas, and works fine for the transition, just not the pointer. The pointer only seems to appear in IE10 when it is applied to the parent of the pseudo-element.
Issue
Using the following just simply doesn't work properly in -webkit- and -moz- browsers:
#exampleElement {
background-color: red; /* For example */
}
#exampleElement ::selection {
color: black;
background-color: white;
}
Result: WebKit- and Blink-powered browsers
In Chrome, Opera, and Safari, ::selection's background-color renders as if it was 50% alpha but the font colour is correct.
Chrome 29.0.1547.62:
Opera 15.0.1147.130:
Safari 5.34.57.2:
Result: Gecko-powered browsers
In Firefox, the entire ::selection rule is ignored. ::selection's background-color just happens to be white due to #exampleElement's dark background-color (thanks to #BoltClock for noticing that)
Firefox 22.0:
Result: Trident-powered browsers
In Internet Explorer, (would you believe) everything is rendered perfectly.
Internet Explorer 10.0.9200.16660:
Is this just a flaw of these rendering engines / browsers or are there -webkit- and -moz- alternatives that I'm unaware of?
I've saved an example of this on jsFiddle, for people to see: http://jsfiddle.net/BWGJ2/
According to quirksmode.org, -webkit-selection and -moz-selection are indeed available. I just tested it with Chrome (18) and Firefox (13) and can confirm that it works with Firefox, but I didn't have success with -webkit-selection on Chrome (it ignored it), and according to this SO question it doesn't exist (and the answer says that ::selection should also work on all browser, but doesn't for me, too).
As already metioned in this answer, Chrome forces the selection to be transparent, but you can work around this using
background:rgba(255, 255, 255, 0.99);
For more details, checkout the linked answer by tw16
Furthermore, this works for me on FF:
::selection { /* stuff */ }
::-moz-selection { /* stuff */}
But this does not:
::selection, ::-moz-selection { /* stuff */ }
But maybe this is not related to ::selection but does apply on all pseudo elements, couldn't find an answer to that.
There are browser-dependent versions. The version you're using was the standard CSS3 way, but then it got dropped from the spec. I dunno about its browser support...
And something else to consider: An ID-based CSS selector might "outweigh" a pseudoclass-based selector, resulting in the ID-based CSS always taking precedence. So try adding !important to your ::selection style to make sure it's always used when applicable.
Hope that helps!
What rule do you need to enable styling of disabled elements in IE8? I have the code below now. It that works fine under IE7, but not on IE8. IE8 just give me plaint wihte background. Why?
input[disabled], input:disabled, textarea[disabled], textarea[disabled="disabled"], textarea:disabled {
background:#EBEBE4;
}
the :pseudo class in the selector is tripping up IE8!
you have to ungroup these selectors if you absolutely have to use those CSS3 pseudo classes;
If there's a selector in the ruleset that IE8 doesn't understand it's ignoring the whole thing - this is common in IE8 with CSS3 pseudo classes
e.g. If you separate them out and remove the pseudo :disabled parts of the selector completely - you'll see the first example below works for all, whereas the second one still works except for IE7
input[disabled], select[disabled], textarea[disabled] {background-color: #0f0;} /* lime green - works in IE7+ and modern browsers */
input[disabled="disabled"], select[disabled="disabled"], textarea[disabled="disabled"] {background-color:#ff0;} /* yellow - IE8+ and modern browsers */
the color (as opposed to background-color) issue pointed at in another answer is not the cause of your issue, but it wouldn't help if you were also trying to change the color ;)
Another option is to add a disabled class and style it:
input.disabled, textarea.disabled{
background:#EBEBE4;
}