As I understand from the formal definition, parallax effect happens when some images move at a different speed than the others thus creating the illusion that the slower moving ones are relatively behind the faster ones. And there are these kind of webpages where the background moves at a faster pace than the content. But I see that pages with background images having background-position:fixed are also given as examples of the parallax effect. (e.g. http://www.w3schools.com/howto/howto_css_parallax.asp) Is this a misconception in terms of the definition of parallax?
Parallax is a word that comes from the sciences that means "a displacement or difference in the apparent position of an object viewed along two different lines of sight, and is measured by the angle or semi-angle of inclination between those two lines." Often when you're measuring volumes of liquid in beakers, you record the volumes as every individual viewing them sees them (because of their individual parralax) and take the average of them to record in a scientific experiment.
The effect of parallax is often used on the web to create the illusion of depth. One of my favourite examples of this is www.jessandruss.us. There are MANY ways to achieve the effect of parallax on the web, and using fixed positioning can be one way of doing that :)
Related
I have already read
What is the difference between SVG and HTML5 Canvas?
&&
https://en.wikipedia.org/wiki/Canvas_element#Canvas_versus_Scalable_Vector_Graphics_.28SVG.29
So i am aware of the basic differences, but i was wondering if anyone had encountered any practical difference between the two within the context of ggvis and shiny apart from SVG inability to deal with NA's in the data
The short answer:
SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.
DIVs are okay but clunky and have awful performance loading at large numbers.
Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.
The long answer:
HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.
SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects
Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.
A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.
Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.
I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:
I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.
I added 100,000 nodes to each of my two tests. They performed quite differently:
The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.
The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)
Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)
There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).
Conclusion:
SVG is probably better for applications and apps with few items (less than 1000? Depends really)
Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.
I have past content from the following link.
Please see this link for more details
HTML5 Canvas vs. SVG vs. div
Use of gradient images is very common among developers for styling a page. Gradient images are used in many places from styling the navigation bar to styling the background. Technique like repeating a small image in either direction is also common.
One more way to style and give this effect is by using multiple div's one below another with different color, the latter being a little lighter than the former. In the most simple scenario doing so would include only a small script. So, no problem of writing a lot of markup, just some simple code.
The only concern that remains is speed and performance.
Speed
The script, more precisely the function would be much shorter in size than a image. So, in matters of speed the latter method seems more good.
Performance
Today's browsers are very powerful, so the difference between displaying an image and executing a function is negligible.
Css management
Obviously, problems like positioning would be another concern but we do struggle with such problems in every day life. The problem is no greater than overlapping two div's and setting their z-index. The whole gradient div's can lie inside one parent div.
So having addressed the issues of performance and speed isn't using Gradient div's a much better approach than using images?
It's an alternate approach, yes. But not a good one. You get zero points for:
Maintainability
Scalability
SEO
Separation of presentation from content
Furthermore, to say that we needn't worry about performance since today's browsers are more powerful is a gross assumption.
Actually, I think the second option you describe (creating multiple divs with atering colour) is downright terrible.
You're altering markup for the sake of styling. That's a no-go.
It's a common thing among users to disable JavaScript. What happens then?
As you said yourself, positioning mayhem.
When it comes to performance, I would be more cautious than to state it's no longer an issue. Especially with the dawn of mobile browsers in mind.
Such styling would be harder to understand and maintain. Particularly when your team changes someday.
Also, there are two other ways to implement gradients.
CSS gradients - limited to simple variants and requiring a lot of CSS to provide decent cross-browser capabilities. You can try this generator get a taste of these: http://www.colorzilla.com/gradient-editor/
SVG backgrounds. These allow you to create just any gradient you wish. You can use an svg file in your CSS just like any other image. However, some browsers don't support this feature. Here's a table showing when it's an option
Using images is the most reliable option, while combining SVG with normal images (for these browsers that don't support SVG) seems the most flexible approach.
i have a 100x100px image and i need to show that in 3 different dimensions in html,
50x50 60x60 70x70
so my dubt is if better to save img in 3 dimensions then do not use css or html width and height or if to use same img with css rules about dimensions... which solution is faster rendered ?
It depends.
If you are using the same image, Only 1 time image cache is required by the browser. So If you are displaying more than 1 type of image in the same page then dont go for multiple images. Otherwise go for multiple images.
But honestly, 100x100 if you have, It should not be a problem to load. Only in slow connections it will be problem (<128kbps). Otherwise i dont see a considerable difference.
I wouldn't worry too much about rendering speed, the main difference you'll see is in terms of image quality. Some browsers (Chrome) perform very high quality image interpolation, while others (IE, Firefox) opt for a faster algorithm that does not give as nice of a result. So you'll get the best, most consistent image quality by having the three separate image files, one for each size.
That said, since you're only scaling from 100x100 to a minimum size of 50x50 you probably don't need to worry too much about interpolation artifacts either. So I'd recommend just doing whatever is most convenient for you to implement.
And in terms of pure rendering speed, having the separate images will be faster, because no interpolation step is required in that case. In terms of initial page-load speed, however, having a single image will be faster, because there is only 1 file to download instead of 3 (or 4). As for using CSS or HTML tag attributes to set the width and height, there will be practically no difference in speed. The expensive operation is the interpolation of the image itself, and it doesn't make much difference if you specify the interpolation through CSS or through tag attributes.
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.
I'm making a sprite and its reaching about 4000px in height. Is there a general size for maximum sprite height that is used within the graphics design community?
Browsers will have to decompress (and keep in memory) the whole image even if you only use very few sprites in it, and even if most of the image is blank/white.
For a desktop client you've only missed an occasion to be a good citizen by using too much memory (and browser are already sucking a lot of memory).
For some mobile client (eg. IPhone for files over 25k after degzipping), it can be more problematic, the image won't be cached at all, thus it may be better to have 2 files <25k and two HTTP request than one >25k file and a single request never cached.
Last problem, PNG compression is line-based, there is less overhead in having wide images than tall ones (though too wide could be theoretically bad in some case, since you can have only one prediction filter type per line).
Oh and also, with too much spriting, you may end with way too much different colors in the same image, and miss the opportunity for decent paletted image. Testing all combinations of this is tedious, but if you can, grouping your sprites by main colors of gradients is a good heuristic (since gradients/blur needs many different colors).
I don't think the focus should be on how big the sprite is physically (width x height) but rather how big the sprite file size is and ask yourself the question if it would be worth splitting the sprite into multiple sprites.
Quite often we split our sprites based on color so have sprites that are predominantly blue or red or yellow. That way we get smoother gradients and overall image quality while keeping image file sizes down