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.
Related
Using contact forms 7 on my Wordpress site development and I noticed the buttons were different for mobile devices, so after searching I found the solution of -webkit-appearance: none; which I applied to the element input.wpcf7-form-control.wpcf7-submit.
The style has been applied because it shows up when I inspect the element, but nothing has changed on mobile devices.
Should I have applied it to a different element?
You should try this code instead :
input.wpcf7-form-control.wpcf7-submit {
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
}
Consider adding !important if it still not working.
sorry for the super late answer.
The class seems to be correct indeed.
Temani's answer is also a good suggestion for wider browser compatibility.
However, sometimes, even being supported by browser like Safari, the use of the prefixed -webkit- has no effect.
So, I'm going to give you two answers:
For the case of a submit input -your case-, you can simply give the background and border properties you want and that will overwrite the browsers default css properties. No need of the appearance property. But you will probably need to define each status of the button including :active and :hover
For Check boxes and radio buttons a workaround to the problem is hiding the input with visibility: hidden and using :before and/or :after to create an alternative check or radio which will also need a visibility: visible property. You can use the :checked:before selector to apply different appearances to each status
Note: remember :before and :after associated to an input will only work in Chrome and Safari and only together with the property appearance: none
Hope this helps
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.
Can anyone help me make this Chrome CSS code cross platform? It doesn't work properly in Firefox or at all in IE8. I really appreciate the help, thanks for reading.
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
EDIT - Here is the page with the code suggested below, where the issue persists in Firefox. All text on the page should fade in at intervals, but sometimes random parts are appearing without the fade. If it works fine the first time, try refreshing and you'll see what I mean. The page is an output from Twine, and the modified CSS is right at the bottom. Thanks again.
Example HTML page with inconsistent fade ins in Firefox
You just need to throw some browser vendor-prefixes in there.
Based on the current support of transition, you just need -webkit, -moz, and -o:
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;
-moz-transition: 1s;
-o-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
You won't have support in IE9 and lower.
Usually for these experimental features (so in general, if you're not sure about it, look it up) it's best to look up if it's supported by the browser. Since transitions are not completely supported by all major browsers, you need to add the prefix for all browsers that don't fully support it yet. So, according to MDN's Browser support list, and Statcounter's browser usage stats, you should have the following:
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-o-transition: 1s;
-webkit-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
Since both webkit browsers don't have a generally used version that doesn't fully support it without prefix, and firefox doesn't need a prefix, this should work. The problem you're having shows that you've not updated your firefox in a while, and if you're going to test how your site looks in other browsers, I strongly suggest making sure you've got the up-to-date version. Firefox already supports the syntax without -moz- prefix since version 16, and it's at version 26 now (with 25 being the most commonly used at the moment).
Of course if you really want to support even the browsers that almost nobody even uses anymore due to automatic updating (such as Firefox <16), you should indeed like Zach Saucier (deleted his answer) JoshC says also include the -moz- prefix. The -ms- prefix is not needed at all though, since every version of IE that does support transitions also supports it without needing that prefix.
EDIT: added -webkit- for Android/Blackberry default browser.
Extra bit (after seeing added dropbox link)
Considering the dropbox link, what I think is causing it is this: Firefox is still animating the first element when the second shows up, so it doesn't restart the animation.
This could explain why it happens randomly: it only happens when Firefox has a few milliseconds of lag, and firefox continues playing the animation for the second item from the starting point of the second animation. This is likely caused by the fact that your items are nested, so the animation of the first row would be inherited by the animation of the second row, and so forth.
Since your animation length is 0.5 seconds exactly, and the interval between showing elements is also 0.5 seconds exactly, if there is the slightest bit of lag this cause these problems. I suggest putting a tiny extra space between showing each element (perhaps 10 or 50ms or so), or changing the items from a nested method to a sibling method. So, instead of this:
<div class="body content">
<span class="first">500ms
<span class="second">500ms
<span class="third">500ms
<span class="fourth">500ms</span>
</span>
</span>
</span>
</div>
Use this:
<div class="body content">
<span class="first">500ms</span>
<span class="second">500ms</span>
<span class="third">500ms</span>
<span class="fourth">500ms</span>
</div>
So, instead of appending the spans to the current span, append it to the parent element .body.content. I would give you a demo, but your script looks really quite complicated (probably because it's generated by something), so you'll have to try doing that yourself. You could also try putting a tiny bit of extra space between each item's animation starts and see if that fixes it.
Once again I am going to tell you that css3 is still work in progress.So if you want to invoke the css rules then use the vendor prefix provided by their browsers.Note that Internet Explorer 9, and earlier versions, does not support the transition property.
-moz- for firefox use
-webkit- for safari and chrome because both uses the same browser engines
-ms- for microsoft
-o- for opera
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;/*for chrome and safari*/
-moz-transition: 1s;/*for firefox*/
-ms-transition: 1s;/*for ie*/
-o-transition: 1s;/*for opera*/
transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
Sometimes it appears helpful to make certain page elements only visible on e.g. hovers. An example is stackoverflow's "feedback - Was this post useful to you?"-widget. As those elements might be crucial to the interface, such a show-on-hover-feature should be a progressive enhancement or, in other terms, unobtrusive and degrade gracefully.
The usual way appears to be employing javascript, e.g. hiding the elements and making them available when a parent element is hovered. The reason for that choice might be :hover is not support for all elements especially in legacy browsers, thereby forbidding you to hide elements in the first place up to css2. (for a js/jQuery example cf. jquery showing elements on hover)
I wonder if you can achieve such a feature safely* with pure css3, using :not(:hover) and :hover, not affecting older browsers. As far as I can see, the requirement is that every browser supporting :not() must support :hover for all elements. According to the following sources, that appears to be the case
http://www.quirksmode.org/css/contents.html
http://kimblim.dk/css-tests/selectors/
Example implementation: http://jsfiddle.net/LGQMJ/
What do you think? Any objections or other sources?
*by safely I mean the browser should always show all elements as a last resort.
Your solution looks alright for CSS3. There isn't anything I can think of to improve your solution for modern browsers as the opacity property will never be applied by browsers that don't support it anyway.
There is literally no other browser besides IE6 and NN4 (and older) without support for :hover on elements other than a. As implied in your question, all browsers that support :not() are known to also fully support :hover.
That said, you end up leaving IE7 and IE8 missing out on the hover effect, the latter of which is still quite prevalent. You're probably looking to support IE6 as well, but here's a solution that I believe will address these concerns, if you need it:
Omit :not(:hover) altogether so your first selector becomes less specific rather than equally specific to your second selector with :hover, and you can reach out to IE7 and IE8 which don't support :not() but do support :hover on all visual elements:
div span.question {
opacity: 0;
}
div:hover span.question {
opacity: 1;
}
Use the visibility property instead of the opacity property to reach out to IE7 and IE8 which don't support CSS3 opacity:
div span.question {
visibility: hidden;
}
div:hover span.question {
visibility: visible;
}
Keep in mind that visibility: hidden will make an element invisible to mouseovers as well, but in this case you're applying it to a child element, so the parent will remain visible to mouseovers.
Use CSS2/3 combinators that IE6 doesn't support but IE7 and IE8 do (child >, adjacent sibling +, general sibling ~) to hide both rules from IE6. This borders on "hacky", but your situation is one where the child combinator > fits very well, so it can be integrated organically rather than hacked in like the famous html > body filter:
div > span.question {
visibility: hidden;
}
div:hover > span.question {
visibility: visible;
}
Updated fiddle