Quite possibly the best CSS "hack" I've ever used...

After a good couple of days banging my head against the desk trying to figure out a solution to a Windows Safari "bug" I think I may have found the best CSS "hack" ever...

Ever wondered why Safari renders fonts bolder than all other browsers on Windows? Well it's down to a setting hidden away in the preferences dialog shown below:



Which is great if you can control everyone's install of Safari but, well let's face it - you can't. Which left me with the dilema... how the hell do I get the headers on my website to render as expected in Safari? Well fear not - just add the following line to your css:

text-shadow: 0 0 0 #FFF;

Where #FFF is whatever the background colour your text appears on and voila Safari's nasty aliasing "bug" has vanished!

Pure CSS headers as gradients?

Just a quick one (ooo-argh missus) to share this great post I found on Web Designer Wall for doing CSS headers with a graident effect. Ok, granted, it's not exactly a new technique but it's a really nicely written tutorial for all you CSS newbies and some nice ideas for those of you who have been doing this stuff for years (scroll down to see the examples).

Check it out at http://www.webdesignerwall.com/tutorials/css-gradient-text-effect/

Cheers
Jon

Flickering graphics for rollovers

One common thing that crops up with graphical navigation bars is when they flicker whilst an image preloads (or the browser renders the change rather slowly) for example.

There are many traditional ways around this... Javascript preloaders being one example. How about a purely CSS, compliant version? Well here you go...

CSS background-position
Simple right? Well here goes... You need accessible links so you need a text equivalent... You need your links in a list too... OK let's get on with it:

<ul>
<li id="link1"><a href="http://www.google.com">google</a></li>
<li id="link2"><a href="http://www.yahoo.com">yahoo</a></li>
</ul>

That's the xhtml done... No seriously that's it - the rest is pure CSS - No JavaScript I promise!!

Ok so our nav bar is 40px in height.. And each is a graphic with the name of our link on it... When we rollover it displays with the graphics in inverse colours.. Cool?

OK so you need two graphics per link... One in the on state and one in the off state... Right? Wrong.

The way around the flicker is to have the two states on the same graphic and change the background position of the image... That way we have no flicker or preload issues...

ul #link1 a {
background:transparent url(/images/link1.gif) no-repeat scroll left top;
}
ul li a:hover, #main_nav li.selected a {
background-position:0pt -40px !important;
}

It really is that simple... We just move the graphic (background-position) up by the height of our original bar and voila!

Ok but our text still shows OVER the grpahic in our anchor tag? Well seeing as we're all CSS purists let's just move that with CSS...

ul li a {
display:block;
float:left;
height:0px !important;
overflow:hidden;
padding:40px 0pt 0pt;
}

Simple... Really nice, clean, accessible graphical navigation WITHOUT JavaScript.

Code examples written by Dom Smith, one of our coding buddies, from www.webmotivated.com

Internet Ignorer 8 and the 'Super Standards' meta tag

OK So everytone is blogging about IE8 and the new "Super Standards" meta tag so we thought we'd jump on the bandwagon and throw our two-pence worth into the ring.

What's "Super Standards"?

Microsoft wanrts us to include a new metatag: <meta equiv="X-UA-Compatible" content="IE=8"> to show that the browser wants IE8 to act in a certain way to render the page. Great hey? Well ermmm no.

Since web standards took off developers could focus on CSS for styling their pages and doctype declarations to determine how their code should be interpreted by a browser. Hence the underlying XHTML would be platform (or browser independant) with a range of css hack's (I know, I know, but who's actually got a complex design looking perfect without them?) and, with the arrival of IE7, conditional css statements.

The scary thing is that Microsoft actually worked in tandom with WaSP (the webs standards project) to come up with this idea.

So what's the problem?

Well think about it... IE7 is going to be shipped as an automatic update any day now (although MS deny they would ever do such a thing) either way all the stats still point to IE6/5.5 being the most popular versions with users therefore we're writing yet another check for IE with this new meta tag. Microsoft even insist that we should leave it out as standard and only include it for pre-IE8 pages... Great there's the IE7 busting pages thing all over again as we have to go back and hack about with old websites when the clients kick off (don't you just wish they'd think before opening their big gobs?).

Anyway the big question is... Why don't IE just stick to the W3C and WaSP recommendations and get their new browsers to comply with strict/transitional DTD's like everyone else?

So Microsoft - if you're listening: fix the damned loopholes for hacks such as the Harvey Morse Code css hack, and the underscore hack so that the new browser behaves like a "proper" browser... IE7 and below will still work with the hacks and you can actually start to claw back some of the market cos you have a browser that developers can actually code for.

Failing that (WaSP we're pointing the finger directly at you here - how dare you side with the billion dollar bung man at Microsoft!) how about we actually push a new version of CSS?

CSS3 has been kicking around the archives at the W3C for what a decade now? Let's get browsers to comply with CSS3 have a conditional statement to include it if browsers support it otherwise they revert back to pre-IE8 hack-you-like-it CSS?

Here's something original... How about Microsoft ask the developers that struggle to cope with the shit it produces what they would like in the new browser???

Nah forget it what a stupid idea.

Windows Safari and the Aliased Fonts Debate

The debate about web typography (and accessibility to some extent) goes on as Safari released their "Beta3" version of Safari for Windows this week and an interesting debate arises - should fonts be automatically aliased as per Apple's Safari?

We've seen, and in my case touted, sIfr and then we discovered the frailties of design with varibale width fonts etc etc... Then Apple go and release yet another browser for us to test against... Safari on Windows. Now take away the super efficient rendering engine, which I adore for quick Google queries, and take a look at how it renders fonts... Yes that's right - the Apple rendering engine rears it's head.

I'm not going to get into a Microsoft versus Apple debate here (or here care of Joel Spolsky), as personally I believe there is a case for both sides. However what I am going to say that for pure usability versus design it's my opinion that aliased fonts combat the design issue (nice headers, graphical navigation etc) and anti-aliased fonts combat the readability issue (i.e. a big blob of text is indefinately more readable in non-aliased Arial that aliased Helvetica for example.

So before I turn this into a massive ramble about text replacement concepts like sIfr and dynamic image creation with JavaScript (et al) replacement methods... It appears the W3C are actually considering this with the font-smooth property in the CSS3 Fonts module.

So why the hell are they taking so long? This is the fast moving web not print for goodness sake...

Read more about the CSS3 module: Fonts

Harvey Morse Code Hack (css hack for ie7)

I have just accidentally discovered a hack css for Internet Ignorer 7 with the dot dash sequence needing to be identical to below...

body{
background:red; /* all "normal" browsers */
.background:green; /* ie <=6 and 7 */
_background:blue; /* ie <=6 only */
}

Enjoy my fellow web developers!

Cheers
Jon

Accessiblity and DHTML Menus

The general consensus amongst users unfamiliar with what you can and can't do with web standards and accessibility is that javascript and accessibility don't mix? This is a total fallacy.

After much research the conclusion is that DHTML is fine. As long as the code is structured using lists and you give alternatives for users, such as "onkeypress" instead of "onclick" events ? basically drop-down-menus are perfectly feasible.

For example the top level DDM would have an "onclick" event to go to the top-level homepage. Then, for accessibility compatibility, we would add an "onkeypress" (and an access key) to the link so that users, unable to use a mouse, could also go directly to the page.

This is fine as the user will then see the full navigation on the subsequent page, or, for users using screen readers or non-visual browsers where the navigation would effectively be hidden, the navigation elements would be coded using pure web standards so that all of the navigation is "visible" to those users.

related link