I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.
Related
I've been mocking up a landing page in Adobe Illustrator, and I'm about to begin coding it.
Is there a reason I shouldn't just export the whole page as an SVG and use that in lieu of recreating everything in html/css?
The only cons I can think of are:
SEO, as I won't have regular text
(easy enough to just remove text from SVGs and recreate in html)
User interaction (buttons etc)
(same solution as the SEO problem)
Responsiveness with respect to elements repositioning at different viewport sizes.
(trickier; but already mocked up a few different layouts for different device sizes, so i can just serve different versions)
My suspicion is there's something I'm missing, because I haven't been able to find anything online addressing this approach.
Some clarification:
I believe SVG compatibility gets dodgy before IE9 or so, but my product involves a chrome extension, so this isn't a huge concern
my design is Material Design-inspired, so there are a lot of colored divs & the like. this is a good approximation (source):
While the buttons and text would best be handled with HTML/CSS/JS, I'm interested in the reasons that the rest of it (i.e., the image and layout components) can't be handled w/ a single SVG.
How can you add a footer in SVG always at the bottom of the page with dynamic page content?
I think that the main difference is that a SVG is a canvas with fixed height and width, html document has a dynamic-sized window.
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.
I am a hobbyist webdesigner, use html and CSS for testing various website designs. However one particular thing that always confuse me is the decision to make use of image as tag or to use it as background via css or html.
Is their any rule of thumb for this ?
As one of the answers pointed out, you need to make the difference between content and actual page style.
Let me elaborate on that. The purpose of the background-image property is used to define the look of a certain block of your page, be it a div or a p, the key point to take home is that you're defining the page's look. And images in the context of defining the page's design (be that patterns, logos, gradients etc.) should almost never take the explicit form of an img tag. That tag is used to define content images, something linked to the news at hand - something that is unique to a story you're trying to portray.
It's very crucial to differentiate these two concepts because it'll allow you to contemplate a good design independent of the underlying content - as it should be. Uniformal, elegant and precise.
So, in review. Use background-image to define the look of the various blocks that comprise your website and use the classic img tag when you want to add visual content that is context-specific.
The question is it Content or Styling is a good place to draw the line on images.
Will this image be reused? etc.
Do you want the image be part of the document flow, give descriptions to the search engines (alt-text)? Use the img tag.
If you want to place other elements over the image (like text, copyright info), use a background image. You can even combine it by placing an image with transparency over the background image to get some effect.
Furthermore a lot of examples exist where the positioning of background images is used to get performance benefits ("sprites").
In other topics I've found that IE/FF doesn't print background images by default. Now that's a shame, because background images add some possibilities that are very difficult to reproduce with classical <img> tags:
You can align them both horizontally and vertically
You can crop them if they are larger than the target element (which also enables the idea of CSS sprites)
Now, it's not impossible to do, but it will require me to have different HTML layouts for printing and normal page, and the printing layout will be quite overcomplicated (since I'll have to use <table>s to achieve vertical alignment). Also, the benefits of CSS sprites will be lost.
Is there any hope? I gather that #media print doesn't help, but isn't there something else, maybe browser-specific, that would allow one to say: "Yes, this isn't a normal background, it really needs to be there even in print view"?
Not possible. You would have to some how convert your background images to img or use Canvas. Of course using canvas depends on which IE you supporting.
Its a browser setting which restricts the printing of background images. I think the logic behind it was that the vendors wanted to give the users the option of printing background images and ensure that the web developer could not alter these settings through some sort of script.
As a general rule, background images should be reserved for adding to the page design but aren't essential to understanding the content. Therefore it shouldn't matter if they are missing when the page is printed. If something (such as a product shot) is important, then it should be included as an actual image (which has the added bonus of being more accessible).
Could you look at including the image, then hiding it using CSS and duplicating is as a background image (perhaps dynamically using JS)? That way, you can ensure the image itself shows in your print stylesheet, and you get the benefits that having a background image brings. I've created a very simple example here.
I have an internal web app with an image at the top of the page, currently containing some english text with drop shadows. I now need to provide localized versions of this page for various languages. My main choices are:
Have a different graphic per supported language, containing the localized text.
Use CSS to position localized text over a plain image, with a complex CSS technique to get drop shadows in most current browsers.
Are there other options? This is for an educational environment, I don't get to control the browser used by the students.
I did try both removing the drop shadows from the graphic, and also moving the text into in a header in the HTML, but neither was appealing. People said it looked like a cheap knockoff of the current page, which wounds my pride.
Personally I'm a big fan of CSS techniques for visual effects like this. The big benefit is that you are offloading the processing of the effect to the client side, saving you bandwith and content creation time (custom text images for each locale is a big order!), and making the page download faster for the user.
The only reason to avoid it is if you absolutely MUST have the drop shadows on very old (IE5) browsers with next to no CSS support.
Edit: Just thought of something - I a few cases like this where I need a specific font or some exact text effect I've used PHP to render the text, with effects, to an image and cache it server side. That way you avoid the content creation process and gain wider browser support in exchange for bandwidth and server CPU time. It's your call if the tradeoff is acceptable.
Generate the images on request server-side for each language, complete with shadows. Cache them as needed.
If you can use Image Magick, you can refer to this tutorial for generating text + shadows...
Maintaining images with text can be a pain - even without localization, I'd avoid it.
Two choices that I would attempt before going with your options are:
Looking for a free program that generates drop-shadow images that you can have your program utilize whenever it detects that new text is available for the title
Using a shadow image that can be repeated as a background image underneath the text
If those don't work, I'd try the CSS, but test it in as many browsers as you can yourself before going live with it.
Well, Safari supports a proprietary CSS property for drop-shadows, but it won't work in other browsers. CSS3 will have drop-shadows, too (actually only one for boxes, but maybe it can be used for text, too, e.g. when the box has a transparent background).
But seeing that most browsers don't even have a 100% CSS2 support so far, I guess you need to go with one of your two options. Of course, there is a not so complex CSS trick to get a drop shadow:
Drop Shadows for Everyone
But they don't look as nice as a real shadow, since they are not blurred. Further you need to have the text twice in the HTML for these to work.