Are there ways to remove the sliding and fading effects from Firefox as an end user when I visit web pages that use such javascript effects?
When some element is inserted into the DOM, the elements after it are slided down. This is a graphical effect, that is very time and bandwith consuming when someone is viewing over a remote connection (terminal server, citrix, remote X, nx) It would just be OK to see the page in it's new shape without the sliding and many intermediate states.
Maybe there is a setting for this already (about:config)?
There are greasemonkey scripts for most popular sites to streamline the interface and eliminate such annoyances. There is no way to disable it in general because it is not a single feature but an emergent result of a combination of otherwise benign features.
To clarify that last bit... Each individual javascript function used for these animations (that is, timers and element size/placement manipulation) has legitimate uses. It is only the combination of them that is a problem, and they can be combined with other operations in myriad ways. Some sort of heuristic could possibly identify likely-annoying animations in websites at large, but individual fixes targeting specific sites (or site frameworks, all jquery sites use the same animation code, etc) will be far more effective and efficient.
I'd look into the NoScript extension for firefox- it will disable all javascript on every site, and can then be turned on for a site-by-site basis.
https://addons.mozilla.org/en-US/firefox/addon/722
Try this extension:
Disable Transitions and Animations
Today when you open a menu it often "slide" for 0.2 second or links
change color by a slow fading... Those effect are made with CSS3
animations/transition and can be heavy or reduce the website
accessibility. With this extension transition are instantaneous.
Related
All in the title.
I want to do whatever will be fastest.... I would think that 5 CSS generated circles would load faster than having to load an external image, whether its a sprite or not... but I'm looking for somebody who's more educated to offer an opinion!
The circles (to scale, presently generated with CSS):
http://puu.sh/3VZHO.png
First to answer your question as to which is faster... The CSS solution is quicker. But why?
The first reason CSS is faster is because of HTTP Requests.
Every time you have, let's call it an object, that object has to be loaded from the server. To do this the browser must send an HTTP request to the server for said file, the server has to check if you have permissions to access said file, if you do, it retrieves it's location, and sends it back to the browser. This happens multiple times and takes hundredths of a second to perform. Seems pretty quick, but the more of these you have to perform the slower your site will become.
CSS is fastest because the CSS for those 5 circles is contained inside one file style.css
The multi-circle image sprite is slower than CSS because now, not only does the server have to send you style sheet for the rest of the site, it also has to send the your image sprite. Think of this as ordering a quantity of 2 of the exact same thing from amazon from the same seller. Amazon will package both items into one big box because its cheaper. Where ever possible you want to piggy back things like this because it's "cheaper" on load times.
As a further explanation, if you were to load the 5 circles all as separate graphics, 5 individual jpgs/pngs/gifs etc. This would take EVEN longer because it would have to perform 6 HTTP Request as opposed to 2, or even 1 (the css solution).
The second reason CSS is faster is because of shear file-size.
Let's assume the CSS for your circles has 8 lines of CSS code for each circle, that's 40 total lines. That represents just bytes of information compared a couple kilo bytes. To put that better into perspective you are talking 100-400 bytes compared to 4,000-8,000 bytes.
The clear winner? CSS
Other Considerations
That said... There are other factors which should weight in on your decision. Not all browsers support border-radius. See this link for details on what does support border-radius: Can I Use
Since IE8 and below does not support border-radius anyone using IE8 or earlier will render your circles as boxes instead. You can help this along by using something like Modernizr to fill in some of those gaps. But now, even if you use a build of Modernizr that helps only border-radius, you've added 7+kb of data and an extra HTTP Request with this file, which sort of defeats your purpose. That is of course unless there are other things you can use Modernizr for other than border-radius, or if you have a lot more utilizing border-radius than just those 5 circles. Suddenly the extra data and HTTP request can be easily justified.
Ultimately your decision should be based on your target audience. What browser are they most likely to be using, if they are mostly using IE9+, Chrome, Firefox etc. Then go for it. If a significant number of your visitors are IE8 and below you should consider providing a fallback. For example using that image sprite for IE8 and below only.
It all depends also in your needs.
I think the border-radius is not rendered correctly in old IE versions, so...maybe the image sprite is the best solution. But I repeat it all depends. Maybe your clients are in a place where internet is slow (css is best) or maybe they won't update their IE and are stuck in IE6 or 7 (sprites).
You could use both, using one stylesheet for IE with sprites and one for css border-radius.
Check the paint times via the chrome dev tools.
Should give you a good idea.
B
I'm working on a site with lots of CSS3 transitions (which are hardware accelerated) and high memory objects (for example, an array of 39 objects, each containing the full html source for a typical online news article) and I'm noticing some very choppy/jittery scrolling, which I've been unable to debug.
I've kept these high memory objects out of the DOM, which should prevent them from affecting DOM performance, however, I can't help but think that they are still having a negative effect. I don't have code samples to post because I'm unsure of whether this is even an issue.
Please go to this site (Orange) and click on an article tile. In the reader div that pops up over the page, try scrolling as you normally would. Does it feel choppy/jittery? Do you have any suggestions on how to improve this?
CSS3 transitions, opacity, text and box-shadows and the like are certainly known to impact rendering speeds. In fact, even sites with heavy use of text-shadow alone can cause choppy scrolling on the average computer. Combining this with heavy use of javascript seems like a recipe for choppy web browsing.
edit: The loading animation on the o in orange is pretty awesome!
Yes, that's jittery. A page with a lot of Javascript will do that and frameworks like jQuery won't help at all. I'd recommend recoding as much as you can without using jQuery and passing it through JSLint (http://www.jslint.com/).
Try using Chrome's developer tools too to get an idea of what the bottleneck is.
Try disabling Javascript too and seeing if it's any better. If it isn't, then you know where your problem lies.
I noticed StackOverflow appears to be targeting screen resolution widths of 1024px or more. I also checked Amazon, NBC, MSN, & AOL which target more lay users, and they all appear to be targeting the same width.
Is 1024px the current recommended width for web apps targeting the largest cross-section of users who use default monitor resolution/browser size?
Use liquid layout. Then you can easily accommodate everyone from ~800 to ~1600 width, and with a bit more work and care even lower-resolution devices too. This also gives users #1024 some leeway to zoom the page if they find the text too small.
Remember there'll be things like netbooks which don't have the big screens we expect today. You can get away with a horizontal scrollbar, but if you have to scroll the page just to get the main body of text in, you're lost.
Before sounding so condescending, you may want to read up on the modern user base. Netbooks. PDAs. Smartphones. Smartbooks (you do know what those are, being very sophisticated, right?). Programmers who have their screen in portrait orientaton. People who stack their windows side by side. Kiosks.
UPDATE As per conversation with John, I edited the question to change the tenor a bit to reflect his original intent. However, the original paragraph that I wrote is still true- I haven't seen the latest statistics but the days of "90% of users have AxB resultion/window size on their browser" are probably forever gone, what with wide screen laptops and mobile devices. Makes life more exciting for UI designers :)
Having said that, to develop a really usable web site, you need to couple flowing layout with, ideally, ability to use portlets and portal framework (think My Yahoo), so people can choose the page layout most comfortable for them.
make a good use of 960.gs and you will set everything that you need to start a good web site :)
(source: balexandre.com)
The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are two variants: 12 and 16 columns, which can be used separately or in tandem.
960 GS it's a lovely start, doing web or images, they have a complete template for almost any good design program (Photoshop, Ilustrator, Fireworks, InDesign, etc) as well a CSS generator and a Grid Overlay to help you with the website.
I use it and it's fantastic! check out the demo
Nettuts has a tutorial and video. WooThemes wrote a post entitled “Why we love 960.gs” and use it as a starting point for their WordPress themes. Spanish speakers can also check out tutorials by Jepser Bernardino and Miguel Angel Alvarez.
Unsophisticated? I think that's a bit of a rude way to describe the unwashed masses. I suppose every one and their dog has a 1024px width monitor now thanks to the likes of dell and others...
The maximum I would consider targeting as my "base" is 1280x1024, but I would be much more likely to go 1024x768.
That said, in my current projects I try to do a liquid layout with a min-width of 800 to accomidate netbooks and usually a max-width of around 1000px (970 usually). Of course, I also have the luxury of designing for myself, so I have the privilege of telling IE6 users that they should upgrade, which makes the liquid layouts much easier to design.
Summary:
Design with your browser's inner dimensions set to 1250x668 to satisfy 92.7% of users.
I like being stats-driven. To this end, W3Schools has a nice Browser Display Statistics page, which they update periodically with new statistics on how common each screen resolution is.
As of January 2015, 92.7% of browsers visiting W3Schools pages were attached to displays larger than 1024x768, though 39.3% of all displays were limited to 768 pixels in height (or lower), mostly due to the 33% of them having 1366x768 displays.
Unfortunately, W3Schools measured screen resolution rather than the inner dimensions used for rendering web page content. It'd be real nice to get stats on users' window.innerWidth and window.innerHeight instead.
Because we don't have these, we have to reserve room for window decorations that may be larger than our own, as well as browser widgets that may further take away from the space dedicated to rendering a web site. Additionally, not all users browse the web in a maximized web browser, though I think we can ignore that if we assume lower-resolution displays will have maximized browsers.
Windows 7 seems the biggest offender at eating up screen real estate, with what I'm measuring as 30-40px for the task bar (I had to search for a screen shot, as I don't run Windows). Firefox with titlebar, menubar, bookmarks toolbar, and status bar eats another 159px while the slimmer modern FF only consumes 64px. Let's use the slim version and assume around 100px of vertical space will be lost. Maximized browsers don't appear to consume any extra horizontal space, so you really only need to account for the scroll bar, but I'd reserve a few pixels for window edges just in case, bringing us up to 30px.
A few years ago (when I did more web design than I do today), I'd size my own browser to an inner size of 800x550 and made sure that most pages would not have scroll bars. Nowadays, it looks like that can be expanded to around an inner size of 1250x668.
You can check your inner size by putting this in your location bar:
javascript:alert(window.innerWidth + "x" + window.innerHeight)
Those values are read-only; you used to be able to run something like this to resize your inner dimensions, but (thanks to abusive advertisers) it no longer works:
javascript:window.resizeTo(window.outerWidth-window.innerWidth+1250,window.outerHeight-window.innerHeight+668)
One parting note: Just because you're assuming a certain size doesn't mean you shouldn't ensure that your site still works at smaller resolutions. The page can be ugly, but it must be functional!
I have an idea to implement a deep zoom type interface hosted in a browser for sports training data (speed, distance, heart rate etc.) However, rather than images I actually want to zoom into a hierarchy of information. For example, the initial display would contain a grid of years - hover over 2008, for example, and spin the mouse wheel (or click) will zoom into that year but during the zoom I want 2008 to fade out and be replaced with a calendar of months. Again zoom into a month and the months are replaced with the months calendar, zoom into a day and you finally see a chart with the training data plotted on it. All the time only dates with actual data would be highlighted in some fashion.
My question is whether this would even be possible and whether anyone has seen examples of this already. I'm imagining that most of the time the next level of information could be cached in the browser (in fact, because this is calendar-based, I can calculate most of that and cache the dates to be highlighted.) I could also zoom into an empty chart whilst an Ajax thread is fetching the data to display.
I've never tried anything like this before and I'm especially interested in whether DHTML would be capable of this sort of zoom (I suspect not and I would have to resort to Silverlight) and whether the Ajax execution would be uninterrupted whilst the browser rendering thread is kept busy zooming.
For Deep Zoom on images in JavaScript/Ajax there's the excellent Seadragon Ajax library by Microsoft Live Labs.
If you're looking into smooth and interactive zooming on content besides images such as text, video & vectors, have a look at the open source OpenZoom SDK I've developed over the last couple of months.
You probably could not achieve very smooth zooming with an javascript/ajax type interface, but a zoom interface would be possible. The pragmatic ajax book has a great chapter on implementing a Google maps clone. Theres no need for the technique to be restricted to zooming in and out of tiled images. The image elements can just as easily be any HTML you want. A fade effect could be applied to the zoom operation so when you move up and down a layer you get something similar to what you described. I recommend grabbing the book (Its a pragmatic programmers book, so theres a cheap and immediately downloadable PDF version available. Read the chapter, think about the techniques and then see if you think its practical for your vision. good luck.
Seadragon Ajax continues to evolve and is now OpenSeadragon:
http://openseadragon.github.io/
I've also been keeping a list of various zooming technologies, many of which use JavaScript:
https://github.com/iangilman/zooming
I don't believe ajax or dhtml are good solutions for what you are trying to achieve. I think flash/flex or silverlight may be the best option.
Check out the "scale" effect in jQuery. Here's a link. I haven't used it myself, but it might be able to do what you want. You'd have to swap out some content for different content at the right point, or your html would get too big.
See here: http://code.google.com/p/ie7-js/
Does anyone have any experience or remarks about this javascript? Is it worth including? Do you recommend it?
I know many people, myself included that are using various IE hacks to get transparent PNG support. THis looks like a little bit more help, and as long as it works, and the size is fairly small, I wouldn't see much against using it.
I've used it before, and my results are mixed. Those scripts cause IE to churn for a bit on page load. Basically, you have to think of it as iterating through Elements and stylesheet rules to apply "fixes" for areas that are deficient in that particular rendering engine. In some cases, depending on how complicated your markup or stylesheets are, that can take a bit of time and you will see the browser hang.
That said, if you can trade off that performance cost, you will save development time as you'll spend less time hacking around IE6 quirks; IE7/IE8 will provide enough missing functionality that you can avoid certain edge cases, can develop using standards better (min-width/min-height, multiple className selectors, etc.), and certain rendering issues will disappear.
However, if you just need 24-bit transparent PNG support, use a tool built for that. Including IE7/IE8.js for PNG support alone is like pounding in a nail with a tank. Use DD_belatedPNG for that.
It works, but its worth keeping in mind that ie7.js and ie8.js do much more than provide transparent PNG support. Even with the transparent PNG support, its worth keeping in mind that transparent background images cannot be tiled (repeated) using background-repeat or positioned using background-position. This hinders any ability to use CSS rollovers using background-position. I've only used it on one site I've done, and now that I'm updating the site I can't remove the ie8.js because if I do the entire website breaks layout in IE. I don't believe I'll be using it in the future, and instead rely on simple CSS hacks or simply allow my sites to "degrade gracefully" in IE6.
I know that there are some tools for fixing the transparent PNG problem which are more flexible than this. For instance, the jQuery plugin ifixpng2 will support background position, which ie7-js doesn't do.
As long as you are aware of exactly what it fixes, I would say go for it. I'm not sure about this lib exactly, but some libs get very expensive if you have a large DOM, as they tend to hook in HTC file base behaviors on EVERY DOM Element. This causes the dreaded "Loading x of y" status bar message to flash constantly on the initial load, and any newly generated DOM content.
well its beautiful and works grate way u can use cs3 features like li:hover. we did lost of project last time using ie8.js and it works great way.