WebKit just kept annoying me very much: upon page load it would animate a transition from the initial , browser-default, value. I had something like
a:link {
color: black;
-webkit-transition: color 1s;
}
but it would fade in from color: blue! Other properties weren't affected by the FOUC, only the transitions.
Unfortunately it is super hard to reproduce, I couldn't manage to jsfiddle it. My (admittedly edge) case is setup like so:
a "dev" version: a bunch of <script />s and <style type="text/less" />s
a production version: scripts and styles H5BP-style concat'ed & minified (first lessced, respectively)
the FOUC would only show up in situation 2, but that stopped after I inlined the #imports of some stylesheets with #font-faces. A workaround, but it
So I guess this must have something to with load times/order?
Anybody ever encountered something like this? (I guess not.)
At the very least, maybe someday somebody will run into this problem, and find this useful.
If I had to guess, I'd say it's because you've put your transition before your color. By doing it that way, you've assigned the transition while the link is the default color (blue), then told it to change color (in theory).
Try putting your transitions last to keep them from transitioning from the browser default values.
Related
I'm building a site locally (so I can't show it here) that has elements that apply mix-blend-mode: screen; when hovered on. They're images within slides in a slideshow that I'm using Slick for. When I implement Slick to run the slides, the blend mode stops applying when hovering over the elements. From what I found last night, this is a common issue with Slick.
https://community.shopify.com/c/Technical-Q-A/Mix-blend-mode-breaks-after-scolling-Brooklyn-theme/td-p/593470
The person in the above link seems to have the same issue, but the proposed solution didn't work for me because I'm not using the slick theme, and therefore not using theme.scss.
It seems as though transform: inherit !important; might be the solution, but I'm not sure how to implement it as I don't understand how the transform is being overridden by Slick.
css 3d transforms break mix blend mode, fortunately slick still runs ok without it
but you need to add this to your CSS
.slick-slider .slick-track,
.slick-slider .slick-list {
transform: inherit !important;
}
and the no-transform rule to the js initializer
$(".slider").slick({
useTransform: false
});
I was trying to make a "multi-row" sprite CSS animation (insipred by this: http://codepen.io/simurai/pen/vmhuJ), only to find that Firefox doesn't support background-position-x or -y.
The lack of -x/-y is discussed at length here: https://bugzilla.mozilla.org/show_bug.cgi?id=550426, and a proposed solution (background-position-y doesn't work in Firefox (via CSS)?) is to use CSS variables, which were recently introduced in Firefox.
However, it doesn't look like updating CSS variables from animation #keyframes is supported?
...
background-position: var(--bgX) var(--bgY);
...
/*Here, CSS variables don't work:*/
#keyframes move-y {
from {
--bgY: 0px;
}
to {
--bgY: -670px;
}
}
Here is a JSFiddle (note: Firefox only): http://jsfiddle.net/phoj0kq5/
I added flickering borders to the animation just to make sure it's running, but the crab doesn't snap its fingers.. Am I using CSS variables wrong, or do they simply not support animation?
Edit
Updated fiddle which actually works in Chrome (still not in Firefox): http://jsfiddle.net/phoj0kq5/1/
This is not a solution, but a workaround that should help:
Since you cannot show a part of the image dynamically when cols and rows are changing one at a time, try using only one column or row of image parts.
When only one line of sub-images is used, you should be able to set the viewed part with background-position: X 0; while X is your offset per image. You will need to edit the image file you are showing to achieve this.
So change the layout of subimages in the image file form:
☺☺☺☺
☺☺☺☺
☺☺☺☺
to:
☺☺☺☺☺☺☺☺☺☺☺☺
As i said, this is not a solution to the problem itself and rather a workaround, but it should work fine on all browsers. However, Mozilla should implement the -x/-y attributes or fix the CSS-variable issue in animations. Until then, i don't see a proper solution for this.
It seems like overriding text colors (blue in this case) aren't being used/recognized until a user either hovers over the text or resizes the window.
I thought I fixed this situation by changed the transition property so it's set on hover/active like so:
.grey-tab {
.transition(none);
&:hover, &.active {
.transition(all .2s ease);
}
}
But, after lots of clicking, it's still broken. In the past, I have used a terrible solution to fix the issue, by applying a delayed CSS3 transform to the text, which triggers a redraw. But I'd like to fix the real problem, as this keeps popping up in Angular projects.
Twitter conversation regarding issue:
https://twitter.com/KMuncie/status/573583334703521793
Thanks for any help you can offer!
Chrome v41.0.2272.101
It seems that using ng-href alone is the issue. There's 2 solutions to this rendering issue:
Use ng-href with a blank href="#" or...
Use only href (which is against ng conventions)
Unfortunately Nish's href="#" solution didn't work for me, and I don't want to use href, nor the display-hack keyframe.
My <a> tags were black in Safari, instead of grey. Using a <span> tag inside the <a> fixed the issue for me.
I'm using jQuery Mobile to develop some html5 apps, and its a real pain to manually override every single small thing that gets applied to elements on hover, focus and active.
Is there some way to disable the application of these effect, across the board?
If there only were a way to do something like this in CSS?
*:focus, *:hover, *:active {
return; // this would stop any css effects on these events to be applied
}
You can "disable" some styles pretty easily but most will just be a ton of cat and mouse for you to make sure there's no styling applied.
You will need to cover specificity cases if something like an anchor tag might have cursor: pointer and text-decoration: underline as defaults while most other styles will not have this.
Although I recommend against this, if you need to make sure this works will least amount of work you can try adding the !important after each property like below:
*:hover {
outline: none !important;
}
In case you're looking for a "clean" slate to start with, you can use Normalize, and this will reset most of your styles and help them look nice in case browsers are styling them.
I'm trying to remove the blue "halo" outline that form elements have in Firefox on OS X. Using CSS, I can remove the halo in Safari on OS X, via:
input {
outline: none;
}
But this seems to have no effect in Firefox, nor does the -moz-outline property.
Another option, that takes care of all of the 'halo' is this:
*:focus {outline: none;}
I guess you could add an !important if you wished, but I haven't run into the need yet.
:focus {outline:none;}
::-moz-focus-inner {border:0;}
I'm going out on a limb since I don't have OSX to test it... but does removing the border work?
input {
border: 0;
}
I believe the style of all the form elements are stored in the forms.css file. In OS X, I think it is located here:
/Applications/Firefox.app/Contents/MacOS/res/forms.css
You may want to browse through that file and see if there is any obvious CSS that is affecting the appearance you are seeing. For example, on Windows the input element has -moz-appearance: textfield;, which I couldn't find any documentation on, so perhaps there is some "native" -moz-* style on those fields that is controlling the glow, something you could possibly override.
The other thing to try might be to override everything in that file by changing the input definitions to input2 or something (after making a copy of course). Then you can see if you can get the glow to stop at all by manipulating the default CSS.
Once you've determined you can make it stop (if you can), you can add styles back in a bit at a time until you find the one that causes the effect you don't want. You can probably speed up that process by eliminating styles from your testing that obviously aren't related (e.g. - line-height: normal !important; is almost certainly not responsible for a blue glow around the fields).
Maybe you have an active user style sheet in your machine creating this behaviour. Some add-ons do this (to make the focus more obvious).
Look into the firefox's chome forder (in your user files)
Alternatively try with
input {outline: none!important;}
Also
The Stylish plugin has a style for this, maybe you have it installed?
There are greasemonkey script that do this. If you have it installed, disable it
They both take precedence over the !important attribute.
So: you have several places to look into
* User stylesheets
* Stylysh
* greasemonkey
* anothes add-on
One of those must be forcing the outline
I went through the various suggestions made here, but none seemed to be able to fully address the problem. By defining a custom border style, i.e.
border: 1px solid #000;
I'm able to get rid of the focus halo, but this obviously alters the look of the input element. border-style: inset; seems to most closely resemble the "native" look, but it's still not quite right, so as far as I can tell right now, you can either suppress the halo, or have a natural looking input.
I believe this is what you are looking for:
input:focus { outline: none; }