< ?php
header("Content-Type: text/css");
?>

Update! Now at Beta 2.

.hide {visibility: hidden; display: block; line-height: 0; font-size: 0.1em; height: 0; margin: 0; padding: 0;}

I’ve been wondering about whether this is still good practice recently and found today that I’m not the only one… thanks to Laura Carlson’s [webdev] Web Design Update newsletter (subscribe already! HERE) I seem to have found a reasonable debate in this post and subsequent comments from Roger Johansson on his site at 456 Berea Street. In short:

• Avoid using CSS techniques to hide text from your site. Especially avoid hiding text that contains keywords that are important to your site.
• If you want to provide an accessible format of text that is in an image – use a regular image with alt text in preference to any CSS background image replacing actual text. CSS sprites may be very useful to reduce server requests and page load times but use sprites for pure graphic elements only – not text.

In a moment of clarity I realise that an image is valid within a heading tag… but whether alt text within an image within a heading tag is as strong for SEO as regular text in that same heading tag (whether or not hidden/positioned off-screen) is a question that could do with a clear answer. I suspect that alt text is not as strong: clear guidelines from those Google folks (I do love you) seem to be lacking again. SEO and graphically rich websites are not something that the engines of Google can cope with properly when faced with trying to be a sh*t umbrella (in gmail or the wider web) against the legions of spam pedlars out there who would love to stuff keywords into every corner of a page. In the meantime the life of a web designer remains tough.

Poor me.

Main contenders:

1. for jQuery: jquery.corner.js from rc.rctonline.nl
2. for jQuery: jquery.corner.js from malsup.com
3. for jQuery: cornerz
4. stand alone: curvycorners

Using #1 at the moment. Would like to try them all again in the light of the IE8 workaround below. Gotta say I now think #3 (cornerz) looks most promising in terms of size and ability. Going to have another look to see which ones look to CSS first (for those browsers that are modern – and not Internet Explorer) before turning to JavaScript.

Problem with most of these is IE8 doesn’t play nice… fix seems simply to add the behave like IE7 meta tag: <tt><meta http-equiv=”X-UA-Compatible” content=”IE=EmulateIE7″ /></tt>

First impressions:

1. good, non-transparent outside corner
2. good,
3. throws errors in IE7, non-transparent outside corner
4. slow in IE,

After trying to “hide my shame” [was it Zeldman that turned me on to CondComs with this phrase?] by using conditional comments for IE specific hacks, I’m now happier with the new and revised and reverted wisdom that throwing all your CSS code into a single style sheet is best.

I’d read Meiert’s «CondComs are bad» article ages ago but I was still a print designer by trade so the message went into a back drawer in my mind. It’s a good read on the cons and it’s updated too.

For a while I have found elegance in removing offending and non-valid CSS code to fix bug for IE, particularly as a way of dealing with proprietary MS code when incorporating PNGs with full alpha transparency into IE6. I’ve since moved away from trying to make png24 work with IE6; and then came the speed demons and calls from the gallery for fewer HTTP requests.

Avoid Extra Stylesheets

• Fewer HTTP requests = quicker site (particularly for the majority IE crowd that need the hacks)
• All code is kept together for easy reading. ‘Cos we al know that code is read more than it is written…
• And lastly; the typical, for me, extra-ordinary reason: no more 404 errors sent to me from my better 404 page indicating phantom strangeness for style-sheets linked to through conditional comments when there’s an .htaccess versioning rule.

Hide my shame.

The only reason I was still using conditional comments was because I had failed to find an IE-7-only selector hack. Thanks to Web Devout. Look there for the comprehensive list – for posterity I copy paste here:

CSS hacks in CSS Selectors

IE 6 and below
* html {}

IE 7 and below
*:first-child+html {} * html {}

IE 7 only
*:first-child+html {}

IE 7 and modern browsers only
html>body {}

Modern browsers only (not IE 7)
html>/**/body {}

Recent Opera versions 9 and below
html:first-child {}

It took a kick from outside (“your site x sucks HTTP requests and bandwidth”) to realise things were going downhill.

So – with the help of the good folk at Yahoo YSlow and the new copy-cat-kid on the block (Google Page Speed) with their plug-ins for a plug-in(firebug) for Firefox [oh the irony]… I’ve started to get things in line again.

Both YSlow and Page Speed have helpful links and information once called – and now I can pat myself on the back for having improved my YSlow scores from an ‘F’ to a ‘B’. Wetware heh.

Main issues I was able were too fix were too many HTTP requests and a lack of explicit caching direction from the web server. Nextly I’ll be looking at getting interface elements into a sprites for future jobs. (Must take this sprite/CSS creation tool for a spin. Looks absolutely fab.)

Reduce HTTP requests

While combining CSS files is trivial, combining a bunch of disparate JS files into one is not painless – I’ve had to drop a jQuery tooltip plug-in as it wouldn’t play nice when bundled up with its playground compatriots.

Server side caching and compression

is achieved the following htaccess rules:

##Cacheing static components

FileETag none
Header unset Etag

# Far future 1 YEAR
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4|css|js)$">
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>
<FilesMatch "scripts.inc.php$">
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>

# Past last modified
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4|css|js)$">
Header set last-modified "Sun, 13 Jul 2008 20:00:00 GMT"
</FilesMatch>
<FilesMatch "scripts.inc.php$">
Header set last-modified "Sun, 13 Jul 2008 20:00:00 GMT"
</FilesMatch>

#Compress
<IfModule mod_deflate.c>
<FilesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

Shadowbox woes

I now may be on the lookout for a replacement to Shadowbox. Shadowbow v2 was great – it came with lots of build options and could be explicitly launched by jQuery on Document Ready. v2 wasn’t IE8 compatible however – forcing an upgrade to v3 – still in beta… Ho hum. This required an updated version of the JW FLV media player which I’m not mad keen on – and that needs a new licence. While Shadowbox is now very clever and can automatically find it’s own dependencies – it has many of these – each one with an HTTP request. While it is easy to combine the whole bundle into a single file its something I’d rather not have to do/keep track of – I’ve already got a rod for my back with the other jQuery plugins…

Set width and height for the element/s containing the transparent background image [...] (also, bear in mind that the background images can no longer be tiled or positioned via ‘background-position’)

Apply  position: relative; to any contained links to ensure functionality

The first point means I’ll probably not bother trying to tile a drop-shadow background image to a variable length column again. Time to switch to progressive enhancement with Photoshop CS4/Fireworks/other tools’ ability to stuff alpha transparency into  regular PNG8 files.

The second point is probably the better answer to my last PNG problem post.

Main post about how to work with PNG24 alpha transparency and IE6 …

I’ve been so excited to be able to use full alpha transparency PNGs and getting them to play nice in IE6. Today I’ve found another PNG/IE6 issue. It seems that in some cases IE6 doesn’t like to have links in an element that is child of one with a background PNG to which filter:progid:DXImageTransform.Microsoft.AlphaImageLoader is applied.

The solution (in my case) was very simple: just needed to close the div for the background and add another for the links. Now the links just appear to be contained by the background.

CSS trickery: eat my heart out.

Here’s a bug I came across while working on the updated Solutions Overseas website. Not used position:fixed; in anger before. The “Enquire Now” button there is fixed. Except in IE7 though. Looked around and it’s apparently caused by a floated div next to a postion: fixed div (next to/child of parent etc… )

Simple fix – add another div around or between those two scrapping trouble makers.

Documented here.