I'm looking for a sanity check on an idea I'm considering implementing. I'm working on a client list page and I want some transition effects on the logos. For now, it's going to be a colour transition from white to gray but who knows what else down the line. I can't use something like CSS grayscale() filter because in my tests white isn't getting changed to gray. (And that makes sense, right???).
So I was thinking that I could use SVGs instead (either outputting them inline or more than likely as an SVG image). In terms of practical management it isn't going to be an issue to either create the SVGs or upload the logos to the site so I'm wondering about things like performance or just generally thoughts on whether having 20+ individual SVGs (which can be pretty weighty in terms of markup) is madness. I've not used SVGs a whole lot so excuse me if the answer is obvious.
On the other hand, I'm thinking that if I stick to pngs I'd have to create functionality to add 40 images (20 white and 20 gray versions) and this seems like a bad idea from a performance perspective and also like a massive pain in the you know what.
Related
As a web developer, I have to cut a layout similar to this (example website by Ruben Bristian):
Should I bother with cutting multiple small images like a logo:
a label:
and so on? Or should I just make one big background image with all elements like this:
and make a positioned <a href> with display: block; for a linked logo?
A single image has smaller size than multiple elements altogether. What are the other pros and cons?
Use separate images.
Here are a few reasons why:
Maintenance:
It's going to be much easier to maintain in the future, if/when there comes a point when you want to build on what you already have. Furthermore (and subjectively), the background image is not critical to the design. It wouldn't look broken if parts of the background were clipped. It would look broken however, if the logo were distorted.
Bear in mind also that newer, sharper displays are being developed. It's much easier to display the standard resolution background (it's already blurry, so clarity is not essential), and maintain two versions of the logo. One for standard displays, one for HD.
Semantics: What if the user has images disabled? Sure, it's unlikely, but what about Google? You should have some proper markup with real content. Your site needs real textual content in order for Google's crawlers to gather information about it. Use CSS image-replacement techniques to build the interface.
Another note on HD displays:
It's convention to serve larger images to HD (retina) displays, and use CSS to downsize them, effectively increasing their dots-per-inch. If you use just one image, the user will have to download a considerably large image. More bandwidth used by you, and slower experience for your users.
Furthermore, the text will look horrible on HD displays. It makes much more sense to allow the browser to render razor-sharp text to the user.
Accessibility: For a start, screen readers won't have a clue what your site is about. That might not be so relevant in this case, but it's best practice to build and accessible website. If you want to include some smaller text on the site, some users may be unable to read it. Normally they would increase the font-size, but if you use images, they're powerless.
I may have over-dramatised this answer, but the advice is well-intentioned.
I would honestly try a little bit of a different approach. The "photo" part of the image would be one image, the logo another, and maybe the double bar on either side of the heading another (but might not be necessary.
I would use the photo part as a bg image on a div, and within code the rest.
I wouldn't make the text part of the image at all. Try using a service like Google Web Fonts to get a good font.
The approach will save you lots of maintenance time, and also help with performance.
PROS:
Total bytes loaded is lower.
You do not have to worry about how little images are put together to become the total image.
if you just use 1 image you will find that it will be much easier to maintain the fluidity of the layout. You will not have padding/alignment issues, rendering issues, etc. Realistically the load time should be the same either way, maybe a tad longer for multiple images as the browser would have to render more css, but i imagine it would not be very noticable. In the end it really comes down to what is better for the job. I pretty biased towards 1 clean image :)
I guess you have to think about how you are going to use each element individually, and how they are going to change in the future.
You might want to change the logo, animate it, or want to re-use it elsewhere. The background image might change, or become multiple images in some sort of transitional gallery.
If this its never going to change (unlikely), then, yes, flatten it in a single image.
I personally would have as a separate background image. Then perhaps have the logo and the label on another transparent png and utilise css sprites to re-use them throughout the site. This will halve the number of requests required to download the logo/label, and allow you to optimise each image separately ie the complex background photo, and the more simple logo/label.
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 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.
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!
How do you approach the use of image sprites in css?
Should I take all the images in my website and combine them to one image sprite? Is it really that beneficial?
How hard is it to maintain those images and change them later on?
Should I take all the images in my website and combine them to one image sprite?
Of course not. You're taking it too literal.
I find sprites are best used for groups of similar images. Examples include:
All states of a graphical button
States of icons
All permutations of a background (unless it needs to tile two ways)
Is it really that beneficial?
If you have a lot of them on a busy site, very. It saves a request for each image, saving the user time and your server a whole bunch of concurrent connections.
How hard is it to maintain those images and change them later on?
If you've used them logically, pretty simple. If you need to add another navigation item, you open up your nav sprite and expand it. For things like navigation it can actually be easier to maintain because you have like comparisons right next to you in the same document.
Edit, having seen one of the more extreme examples, I'll add that I would never go that far because:
It's 60k to download. Not huge but on slow connections, that's 60k that has to be downloaded before anything shows. If all your visual assets are tied up, it can make the load time seem longer.
Your CSS becomes a nonsensical mish-mash of background-position commands. If you do want to make changes you have to go back to the sprite and measure everything. Again and again and again.
God have mercy on your soul if you need to enlarge something in the top-left of the sprite. You'd probably just add a new sprite below the current ones.
And that might lead to bloat. Indeed, just loading all these images might be loading a whole lot of material that some users will never actually see. Loading unused data is probably worse than a connection overhead (considering how easily static content can be served by multiple cheap servers or a CDN)
The other examples are a lot more simple and worthwhile (IMO).
Sprites are a great way of cutting down load-time on graphics (sometimes), and always a way of cutting down requests to the server. Generally speaking, they may take some serious planning as you don't simply want to drop a bunch of images onto a canvas and export as a jpeg. I would suggest you study some sprites currently in use by larger companies like Amazon. Get an idea for how they layout their elements, and what types of images they even consider for use in sprites.
You'll also want to evaluate your site and be sure whether you can successfully implement them or not. If you weren't planning on using them to begin with, it may require a lot of back-tracking and updating to prepare for them.
Amazon Sprite
Ebay Sprite
Current.com Sprite (Whoa)
Google
Sprites work well when you’ve got an element with at least one fixed dimension (width or height), and you want it to have a different background image in different circumstances.
When I’ve tried it, I’ve found that sprite image files tend to be smaller than the total size of the individual images files they’re made from, so you can get bandwidth savings as well as the other two benefits:
fewer HTTP requests
no delay waiting for another image to download when an image state changes on hover
That does depend on the contents of the images though.
Personally, I wouldn’t put unrelated images together in one sprite image, as I think it makes maintenance too non-obvious. Also, as mentioned in To Sprite Or Not To Sprite, really big sprite images can use quite a bit of browser memory. (Whether this is actually a bad thing depends on the context.)
The idea is to avoid unnecessary HTTP requests. This is especially an issue if you have a lot of small icons (say, for a WYSIWYG editor like the one used on this site). If you have twenty 16x16 pixel icons, that won't amount to much bandwidth, but it will still mean twenty extra requests each time the page is loaded.
Other candidates for sprites are button states and anything that's purely decorative but part of the layout.
If you use roll-over background image changes, you'll also find that you'll either have to preload the roll-over state image (either with JS or with silly hardcoding) or you'll encounter some latency as the browser requests the previously unused image. Sprites can alleviate that.
Things you probably shouldn't be making sprites of are pictures that are NOT just graphical elements (e.g. graphs, illustrations, avatars, ads) or that will change a lot (e.g. avatars or ads).
It's not impossible to change sprites, but depending on how much thought you put into the arrangement of the sprite sheet, it may be very hard to do. There's nothing forcing you to make the sprite sheet ultra-condensed, but it's obviously better for the file size if there's not much unnecessary whitespace in it (see Google).
Note that the extra requests may not be a problem for you if you have a relatively low traffic site (which almost everybody has, unless you're Google or Amazon). Sprites may still improve performance for mobile devices, though, as it means less chances for errors and thus lower latency.