I'm currently working on a new site. I'm just a few pages deep and they all use <img>s. I was thinking about it and decided to look into using a sprite sheet for all of the button images and such and then just using CSS to render the appropriate images. I wanted to see what everyone thought about this. Is it worth the effort? How does it affect SEO, specifically ALTs for <img>s. Is there anything else that I should be aware of?
Thanks in advance!
In my opinion, images which are part of content should use image tags, and everything else can use background images/CSS sprites.
By including a normal image tag with an alt attribute, you will make the image available for things like google image search. But, this is not a factor I weigh very heavily.
The important part is that if someone looks at your site with a screen reader or simply views the HTML, the content will be successfully conveyed with an image tag and alt attribute. If you use divs with CSS you will lose this effect, and some people might miss the content.
But, when it comes to non repeating background images, buttons, and other style oriented images, I do recommend using CSS Sprites to improve performance.
While putting the other images in real image tags should preform slightly worse, this can be very minimal if you set the caching headers properly on the images.
Edit:
A quick search found this:
http://www.google.com/support/forum/p/Webmasters/thread?tid=75fa18ce5e671f5b&hl=en
Which seems to mitigate the Alt attribute by placing text in the div and then using sprites to hide the text:
The approach Google uses, relevant text inside link, visible for crawlers, people who have images turned off, screen readers, etc.
<a href="..." style="position:relative; display:block; overflow:hidden; width:100px; height:100px">
relevant text here
<span style="position:absolute; top:0px; left:0px; width:100px; height:100px; background-image:url('sprite.jpg'); background-position:0px; -100px;"></span>
</a>
If performance is likely to be an issue it might be worth going that route but I do prefer the more semantic img tags if they are part of the content.
Sprites are definitely worth the effort. They save load time, increase response, and also take advantage of caching, which can all combine to dramatically decrease load time.
Alts can still be applied as usual.
SEO wise, there should be no negative effects. You're not applying any exotic methods (read: flash) that will block the crawlers, everything maintains W3 standards, so all should be fine. Be sure to run it through the W3 validator to ensure everything else is kosher.
If Google's doing it, it's gotta be good, right?
Related
As in topic title, I'm working on some project but my CSS works great in Mozilla but in Opera dimensions in px are different.I was trying to fix that using percent dimensions but other issues appears.It's some kind of Opera problem as it recognise CSS code in other way because when inspecting an element, it returns totally different px dimensions of div's and borders for example.My idea to avoid it is to create separate CSS files for specific browsers and choose correct one after checking user agent?Maybe exists shorter way to solve this problem?I need my website displayed correctly in Mozilla,Opera,Chrome.
While possible, loading a different CSS based on detected browser is not generally considered best practice and defeats the purpose of CSS. Before you take that decision:
consider writing cross-browser compatible CSS:
use em or rem instead of px as a font-size unit;
add browser specific prefixes to properties that require it for added compatibility;
use Can I Use when in doubt - it's a great tool;
check out browser specific selectors
As a personal note, I have tried this method myself and quickly fell behind updating all required CSS files. I ended up merging them in a single file about one year later and that change alone was harder than expected.
I coded a small website written in php, with a fixed 869px width to display properly in every screen. I also would like to integrate it to other pages with different width, which is sometimes wider then the original size.
I tried some solutions, but none of them seems to working cross-browser or does not scale the content within the wrapper. I am also trying with the viewport property but I had no success.
I am looking for some cross-browser jquery script that uses the zoom effect of the browser to fit the content to the browsing area. I have a div in the body called wrapper, and I would like to scale it and the content in it, like I do it with the CTRL + keys in the browser.
You can use Bootstrap to scale your content (http://twitter.github.com/bootstrap/). If you want to adjust the font size as well you can build with LESS or use plain javascript (e.g. using JQuery).
You can wrap your page into a
<div class="container-fluid">
</div>
that scales automatically on various standard resolutions. You can adjust the width by overriding the bootstrap.min.css. A guide on how to enable responsive features can be found here: http://twitter.github.com/bootstrap/scaffolding.html#responsive
You can add row-fluid class divs and use span classes to align your content. More information on how to use the grid system: http://twitter.github.com/bootstrap/scaffolding.html#gridSystem
For LESS I can recommend their homepage: http://lesscss.org/
And this is an older StackOverflow post that illustrates how to insert variables from JavaScript: variable manipulation in Less
Maybe using LESS is already enough for your needs.
Im currently building a practice responsive website, what I am doing is taking an exising website, building it up using twitter bootsrap js and css, meaning it will be fully responsive for mobile.
The issue is that there are some large carousels and images on the site. Ideally I would like to just completely remove certain elements, like a carousel for instance, and instead have the options within the carousel as a standard list menu.
It seems the main option is display:none based on media queries, but I am starting to foresee that I will run into big problems for loading time if the entire desktop site is still going to be loaded on the mobile, only elements hidden.
Are there ways to completely exclude html based on browser size? If anyone has any good links or articles that would be great. Or even just opinions, on whether there is actually need to exclude html or not.
Thank you
First off it is really good to see that although you're talking about display:none; you actually still want to display the content without the bells and whistles of the image. Well done you.
The next thing I would look at is if you don't want to load images for a mobile then why are you adding it for the larger sites. If the image isn't providing a function, assisting in explaining the content better, then why not just drop it for the desktop size as well?
If in fact it does help tell a story then you can include the images and some of the popular image services like adaptive images, hiSRC, or PictureFill which will serve the mobile version of the image first and replace with a larger image at higher viewports (but remember, there's no bandwidth test).
Finally, if you do want to serve some different content, then take the advice of fire around including more content with ajax. The South Street toolbox from Filament group can help you out, pay particular attention to the AjaxInclude pattern (it also has a link to the picturefill).
You could consider storing heavy data JSON-encoded, and then creating elements and loading them on demand like so
var heavyImage = new Image();
heavyImage.src=imageList[id];
Then you can append image element to a desired block. From my experience with mobiles this is more robust than requesting <img> via AJAX, since AJAX could be pretty slow sometimes.
You may also 'prefetch' images with this method (like 2-3 adjacent to visible at the moment), thus improving UX.
You could pull in the heavy elements via AJAX so they wouldn't sit on the page initially, making it load faster. You could decide to do the AJAX call only if the screen size is larger than X.
If you want you can use visibility:hidden, or if you use jQuery you can use
$(element).remove() //to remove completely
$(element).hide() //to hide
$(element).fadeOut(1) //to fadeout
I have a website (using PHP). The main background is of green color and content area is of white. While switching to one page to another (as it takes a few milliseconds) the background color gives a flash before the white takes it over. I think its because of the way the dom element being drawn/created. I tried using ob_start(); and ob_flush(); but not much of a help.
Is there any way to avoid this?
Thanks
JJ
You might try explicitly setting a size (height and width) or min-height for the content area. You can also use a background image that has the white area. If your background is a solid color (or a horizontal gradient), you can use a 1px high gif that would be a very small file size. But you still might have a blink before the background loaded the first time.
Ultimately, I think users are used to seeing this. I don't think it's a big problem and wouldn't spend a lot of time trying to solve it. But maybe your boss disagrees.
Just a guess, but in your CSS, put the two rules in one CSS file, then the content area style declaration first, and make sure this CSS file loads before any others.
I don't know if it is the case, but I saw that to avoid the flickering problem of not stylized elements in IE, somebody added an empty script tag as
<script type="text/javascript">//This is necessary to avoid flickering of not stylized items in IE</script>
I personally quite like the flash. It lets me know a new page has actually loaded. It’s feedback.
An old colleague introduced me to a little-known Internet Explorer <meta> tag... thing that lets you do, amongst other things, a fade transition between pages, e.g.
<meta http-equiv="Page-Enter" content="progid:DXImageTransform.Microsoft.Fade(Duration=2)">
<meta http-equiv="Page-Exit" content="progid:DXImageTransform.Microsoft.Fade(Duration=2)">
It’s IE-only.
I've recently bumped into facelift, an alternative to sIFR and I was wondering if those who have experience with both sIFR and FLIR could shed some light on their experience with FLIR.
For those of you who've not yet read about how FLIR does it, FLIR works by taking the text from targeted elements using JavaScript to then make calls to a PHP app that uses PHP's GD to render and return transparent PNG images that get placed as background for the said element, where the overflow is then set to hidden and padding is applied equal to the elements dimensions to effectively push the text out of view.
This is what I've figured so far:
The good
No flash (+for mobiles)
FLIR won't break the layout
Images range from some 1KB (say one h3 sentence) to 8KB (very very large headline)
Good documentation
Easy to implement
Customizable selectors
Support for jQuery/prototype/scriptaculous/mooTools
FLIR has implemented cache
Browsers cache the images themselves!
The bad
Text can't be selected
Requests are processed from all sources (you need to restrict FLIR yourself to process requests from your domain only)
My main concerns are about how well does it scale, that is, how expensive is it to work with the GD library on a shared host, does anyone have experience with it?; second, what love do search engines garner for sIFR or FLIR implementations knowing that a) text isn't explicitly hidden b) renders only on a JavaScript engine.
Over the long term, sIFR should cache better because rendering is done on the client side, from one single Flash movie. Flash text acts more like browser text than an image, and it's easy to style the text within Flash (different colors, font weights, links, etc). You may also prefer the quality of text rendered in Flash, versus that rendered by the server side image library. Another advantage is that you don't need any server side code.
Google has stated that sIFR is OK, since it's replacing HTML text by the same text, but rendered differently. I'd say the same holds true for FLIR.
I know that with sIFR, and I assume with FLIR that you perform your markup in the same way as usual, but with an extra class tag or similar, so it can find the text to replace. Search engines will still read the markup as regular text so that shouldn't be an issue.
Performance-wise: if you're just using this for headings (and they're not headings which will change each page load), then the caching of the images in browsers, and also presumably on the server's disk should remove any worries about performance. Just make sure you set up your HTTP headers correctly!
since FLIR is IMAGES and sIFR is flash i would imagine that it would be a bit more resource intensive to use sIFR. I havent run any tests but it seems logical.
Search engines search sIFR better than FLIR because some search engines can go into the text of a flash document
I don't know much about sIFR because FLIR worked, and it "felt" better to me than Flash. Just looking at the sIFR 3 beta demo page I noticed that it doesn't seem to react to browser preference text resizing. That is, I increase my font-size in Firefox (ctrl-+) and reload the page, the headings stay the same size.
To those who know sIFR, is this an actual limitation of the script or did they just do the demo page wrong?
If it actually doesn't handle this, I'd call that a major advantage for FLIR, which does work this way. People with impaired vision who don't use screen readers probably don't appreciate that the text doesn't resize to their preference.
That said, from a quick glance at sIFR's API, you should be able to make resized text work in sIFR. I'd consider it a bug to be fixed, not an essential disadvantage of the method.
Woff files is the best solution.
http://www.fontsquirrel.com/tools/webfont-generator