I've been working with some basic animations lately and trying to follow good web practices at the same time. The problem I'm encountering is image flicker when not using a preset css method to hide the element before the page loads.
It's very easy to prevent the flicker by just hiding the element with my normal css and then revealing it with javascript, but that seems to me a horrible practice if someone has javascript disabled.
Should I use the HTML5 feature of putting <noscript> tags in the header and then use a separate style sheet to set the opacity and position to the final settings for users without javascript? Is that the most elegant solution?
I've started using the greensock (gsap) library to TweenLite.from, since I can just set everything to the final state in the css, but I get a slight image/text flicker the first time the page is loaded. I like this solution because I can set all of the css as it will be for someone with no javascript, and it allows me to easily animate from a point, to an existing point, instead of working backwards like I have to do with Javascript or jQuery. But, there's still that image flicker which isn't really acceptable. Would a page preloader solve this?
What is the generally agreed upon practice for this these days? I'm also worried about SEO and the consequences of setting stuff to visibility: hidden or display:none and then animating it in. Does the Google spider read javascript?
Here's an example of the screen flicker and animations I'm talking about.
Have a look at HTML5 Boilerplate and Modernizr.
http://html5boilerplate.com/
http://modernizr.com/
It ships with a smart solution to see if a client has JavaScript enabled in CSS.
By default a class no-js is applied to HTML tag and it is then replaced by js by Modernizr. That way you can qualify your CSS selectors accordingly.
Example CSS:
.no-js .foo { }
.js .foo { }
This should execute fast enough that clients with enabled JavaScript don't see the no-js styles.
References:
What is the purpose of the HTML "no-js" class?
https://github.com/Modernizr/Modernizr/blob/master/src/setClasses.js#L9
Related
I have a simple blog that i'm developing using create-react-app (using react-scripts#next to get CSS Modules support).
Repo
Demo
The problem i'm having is the CSS hover transitions are very laggy and slow. I previously implemented this interface using Node EJS templates and everything was snappy and fast.
I'm thinking the problem maybe has to do with the PostSummary component receiving new props and re-rendering constantly, but all the props appear to be static once they're loaded.
I checked the Chrome performance tab and it said the majority of the cycles were being used by paint time (and not load time).
Very confused, anything I can test to resolve the issue?
When you have animations that you know will fire, it's good practice to use the will-change rule, to help the browser be more efficient.
Adding the following rule improves performance in Chrome substantially:
will-change: transform, box-shadow, z-index;
Also, check out this article. It provides AWESOME tricks to help improve the performance and animations on your website.
https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108
One thing I see is that on hover you're changing the z-index. That has a possibility of slowing things down, so just be mindful when using any of the positioning rules. The transform: translate rules are much more performant than top, left, right, bottom, z-index. Not sure if you can get around using z-index or not with your design, but it's good to keep it in mind anyways.
Animating large images will cause performance issues. The first image in your example is: width: 5264px; height: 3393px;. Optimize the images for web and they should load quicker and animate smoothly.
Consider animating text and pure HTML elements, but try to avoid animating large images.
When you resize an image by transitioning it has to render the image multiple times during the transition and is very "expensive".
For a while a bookmarklet I made extensive use of has been broken for me in Firefox. It may apply to other browsers, but I only use it in Firefox.
The bookmarklet in question is "hide visited" from squarefree.
Since this wasn't working (properly) I decided to have at it myself and ended up with this:
javascript:(
function(){
var css=document.createElement('style');
css.type='text/css';
var styles='a%3Avisited{display%3Anone !important}';
css.appendChild(document.createTextNode(styles));
document.getElementsByTagName("head")[0].appendChild(css);
})();
Broken up into several lines for readability, otherwise unmodified from what I'm using.
The thing is, it does append the inline stylesheet to the head, it just never alters the look of the links. Once I remove the :visited (or %3Avisited as it appears here), however, the stylesheet IS applied to links and they are hidden, though obviously the hiding is done regardless of their visited-state at this point.
Bottom line here is that I believe there is a problem with :visited, and flipping the bool for layout.css.visited_links_enabled in about:config, predictably, does nothing as this simply removes styling from visited links wholesale. This is undesirable. :)
It is probably worth noting that the squarefree bookmarklet still appends its stuff to the head, it simply has no effect either.
I am at a loss. What have I missed, and is it at all possible to hide visited links via a bookmarklet anymore?
The behavior of :visited was changed a couple of years ago due to security reasons ... while your code (and the squarefree bookmarklet) might work on older browsers, you won't be able to get the same impact in latest versions of the browsers
A note from https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/
Visited links can only be different in color: foreground, background, outline, border, SVG stroke and fill colors. All other style changes either leak the visitedness of the link by loading a resource or changing position or size of the styled content in the document, which can be detected and used to identify visited links.
Other useful references:
http://www.azarask.in/blog/post/socialhistoryjs/ - what was the security problem (and its creative use)
http://dbaron.org/mozilla/visited-privacy - approach for the fix
For CSS, you can try for something like:
a:visited {
color: white !important; /* It would hide the text if the background is white too */
/* or some better css approach for your requirement */
}
I know that you cannot find out which links have been visited with javascript anymore. This was done to protect user privacy. For security purposes, I believe that even attempting to style, or create styles for, visited links will not work in any current major browser.
For security reasons browsers have taken steps to prevent the "visited" status of links from being read by JavaScript. This means that any style you apply to ":visited" via CSS will not be registered in the DOM.
You can change things like color and text-decoration (probably), and the user will see the change on screen, but the result will not be readable to JS.
Why won't it apply "display:none"? Because if the browser were to remove the link from the page, this could alter the layout of the page, such as the height of a div, and provide a potential side channel for determining which links have been visited or not. For that reason "display:none" will not be applied.
The best solution I can suggest for your goal is to change the link color to match the background color, or perhaps modify the opacity.
I want my main logo to change when mousing over.
I understand there are several ways to achieve this, and was wondering what's the best way for stability, browser compatibility, efficiency - and ease to setup.
Some ways I've found are:
Javascript (jQuery) replacement of the "src" attribute.
CSS using backgrounds and "hover"
Any more?
What's best?
Bottom line
For content-ful images, you want to have the src in the HTML markup. You want to use the Javascript solution and put the rollover image in an attribute.
For content-less images UI elements, especially ones that are common across the site or duplicated, a straight CSS solution would be the best (so you don't have to re-declare the image locations at each invocation). Among the CSS solutions, sprites are the best since they don't require preloading overhead.
The Javascript solution
HTML:
<img src="/img/one.jpg" data-rollover="/img/two.jpg" />
In jQuery:
$(function(){
$('img.rollover').hover(function(){
var e = $(this);
e.data('originalSrc', e.attr('src'));
e.attr('src', e.attr('data-rollover'));
}, function(){
var e = $(this);
e.attr('src', e.data('originalSrc'));
}); /* a preloader could easily go here too */
});
Sample implementation: http://jsfiddle.net/dtPRM/1/
Benefits: It's easy; it makes sense; it works with minimal additional markup once you have your library set up.
Downsides: Requires Javascript and overhead of loading the jQuery library.
Probably the best option. If your user is using a browser where rollovers are relevant (probably the case), they have the Javascript capabilities to run this option. The folks who have intentionally turned Javascript off for some reason will clue in if you leave a little <noscript> note saying that they may not get the full featureset.
The CSS solution: Best
HTML:
<div id="img1" />
CSS:
div#img1 {
height: 400px;
width: 300px;
background: url('http://dummyimage.com/600x400/000/fff') no-repeat top left;}
div#img1:hover {
background-position: top right;}
Sample implementation: http://jsfiddle.net/dtPRM/5/
Personally, I think that for content-ful images, this is an even worse option than the CSS + two background images solution. You're separating the HTML markup from the semantic value of the display.
If you're using content-less images like UI elements, though, this is the best solution in my opinion.
The CSS solution: Also okay
Another CSS option is available that doesn't involve background images (preferred among the CSS solutions if you want to have the image tags in the HTML, like for semantically meaningful images).
<div class="rollover">
<img class="rollover" src="http://dummyimage.com/600x400/000/fff" />
<img class="" src="http://dummyimage.com/600x400/fff/000" />
</div>
CSS (I use the :not pseudo-selector here, but it's pretty easy to avoid using it; I also think I got the classnames semantically backwards):
div.rollover img:not(.rollover) {display: none;}
div.rollover:hover img:not(.rollover) {display: inline;}
div.rollover:hover img.rollover {display: none;}
Sample implementation: http://jsfiddle.net/dtPRM/2/
Benefits: Semantically sensible compared to the previous CSS solution of putting all the information the stylesheet.
Downsides: Extraneous markup needed.
Comment: This one may automatically pre-load depending on whether the browser calls for it.
Bottom line: A decent fallback if option (1) is unavailable because you absolutely need IE2 compatibility or non-JS support.
The CSS unsolution: Stay away
I mention this only because you mentioned it in the question. I wouldn't use it.
HTML:
<div id="img1" />
CSS:
div#img1 {
height: 400px;
width: 600px;
background: url('http://dummyimage.com/600x400/000/fff') no-repeat top left;}
div#img1:hover {
background-image: url('http://dummyimage.com/600x400/fff/000');}
Sample implementation: http://jsfiddle.net/dtPRM/4/
Benefits: Widely compatible; all you really need to support is background images and hover.
Downsides: Semantically weird to put images in CSS and to centralize it there. Makes future modifications more difficult. That being said, if you have a scenario that warrants a rollover image, there's a good chance it may be a non-content image (e.g., a UI element), in which case CSS would be semantically (perhaps) even more suitable than a regular image. See the note on sprites below.
Other downsides: You'd have to be careful to declare image height and width (a good practice anyway, but it may get cumbersome when you just want to get things done). Users viewing on mobile browsers that may treat CSS background images unusually.
Even more downsides: If you want to layer a preloader on top of it, you're going to be using Javascript and somehow selecting the rollover-able elements, and at that rate, you may as well use Javascript for everything.
Bottom line: Don't use this for content-ful images. If you must stay away from Javascript, use sprites for UI elements and the alternate solution for semantically meaningful images.
#btn{
width:100px; height:100px;/*the dimensions of your image*/
background:url(bird.png) left top no-repeat;
}
#btn:hover{
background-position:left bottom;/* pixel references can be used if prefered */
}
Using an image like this:
Note: Avoid JS image replacements as you will incur a short image load time if images are not cached before.
Hope this helps bro!
W.
CSS using backgrounds and "hover"
Use CSS sprites, in other words combine both images into one and then use css :hover to shift the image.
One advantage of using CSS is that it'll work even if JavaScript is turned off.
One advantage of using a single image is it'll avoid the extra HTTP request.
See: http://css-tricks.com/css-sprites/
Tools to help generate image and CSS:
http://csssprites.com/
http://css-sprit.es/
You should use a :hover CSS rule.
CSS by far. Though you may want to precache your image with javascript.
Image rollovers using 'sprites' List a part - sprites CSS
Use CSS sprites and the :hover psuedo-class in CSS. Here's why:
Switching image source either through JS or through the CSS will cause a "blink" on the first mouse-over while the new image is downloaded by the browser. If you use the sprite, it's just one image that changes position, so no blink.
A single image reduces HTTP requests, making the site load faster in general.
It works if the user has JavaScript disabled.
It's supported by all browser types (desktop, anyways, phone browsers without a :hover state don't count for this anyways).
More information: http://css-tricks.com/css-sprites/
$('#div1').hover(function(){
this.style.color='white';
},function(){
this.style.color='black;
});
or
$('#div1').onmouseover()...
$('#div1').onmouseout()...
I see a flash website with some eyecathing buttons with flash effect which I want to have with jQuery if possible here is the link of website -> http://www.goodthinking.com.ph/ .. any tips or sample if can this possible done using jquery code.. . thanks in advance.. .
Yes you could build something close, but with less browser support. The puzzle pieces could be stored as background images on <div/> elements, then the divs could be positioned to "fit" as puzzle pieces, yet still be move-able by animating their position properties with a custom jQuery $.animate({}). The noise could be played on :hover with an <audio/> element in browsers that support it, and the flip effect could be achieved using a 3D transform, typically done by adding and removing CSS classes that define webkit animation keyframes.
You should seriously consider, however whether a whizz-bang effect actually helps people find the content on the website, or gets in the way. If you do want the effect and can design it in such a way that it degrades in browsers that don't support the effect, or all of the effects, then you have a cross-browser solution that is not the same everywhere, but doesn't penalize all users either by requiring they have a browser plugin.
Is it possible? Probably yes.
Would I recommend doing it with jQuery or javascript? No.
Is there a problem to using javascript for styling content?
My website requires javascript. There is this text on my website that I want vertically centered. The text could be either 2 lines or 3 lines long. With javascript I could vertically center it pretty easily. The CSS ways to vertically center it seem complicated and include IE hacks.
So, is there a downside to me using javascript for this styling, considering I have already decided that my website will require javascript?
The downside is that if you have any long-running page, say an ad fails to load, etc hanging the document.ready event...your styling wouldn't be applied until the document completed rendering and the javascript then ran. (Note: This assumes your script fires in the ready event, usually the case since you'd want the elements to be there)
Basically you'd get a flash of non-styled content in the case of anything delaying the ready event. Whether that matters, up to you, but personally I'd stick to CSS where possible.
Sometimes using JavaScript for seemingly simple styling is unavoidable; if I have to use JavaScript in this kind of scenario I just try to make it degrade as well as possible, ensuring that whilst a user without JavaScript doesn't get the full experience from the website, they don't get a bad one either.
I'd personally use display: table-cell, and vertical-align:middle. Then in IE8+ and all other browsers it's centered, in older ones it won't be, but generally things like vertically aligned text aren't that vital to the design anyway.
I don't think there is a downside. If you say it's going to be easier and considering that JavaScipt is the de facto client side language, go for it. Just make sure it'll work on modern browsers...
Just a point: CSS is meant to be used to do this kind of work, but it's not a rule. There are exceptions as is your case.