Shannon Deminick's blog all about web development

CSS3: Using the fun stuff in real life

April 20, 2010 05:08

Sweep IE6 under the carpet

Do whatever you can to remove IE6 support from your website’s build spec. Proper CSS selectors like the direct child (ul > li), the :hover state for elements other than anchors, and attribute selectors (a[href*=”http://”]do not work in IE6. Then, add ie6updatein a conditional comment and voila! IE6 users see a totally legit looking alert bar across the top of their screen telling them that the page below looks horrible because they have an old browser and need to upgrade. Now you are ready to begin.

CSS3 is only sort of supported

CSS3 is currently a working draft. Microsoft hence decided to implement barely any of its features in IE8, and as a result your CSS3 magic is restricted to ‘modern’ (real) rendering engines, like WebKit (Google Chrome, Safari) and Gecko (Firefox). However, the developers of these engines understand that CSS3 is a draft and as such the interface can be changed without warning. As a safeguard they apply a prefix to the drafted properties they want to support. These are known as:

Vendor-specific extensions

If you’ve ever seen anything like -moz-border-radius: 6px; you know what I mean. Vendor-specific extensions are a standardised and accepted (however occasionally non-validating) way of implementing future rules without fear of breaking anything. If you want to use CSS3 properties you will most likely have to include the same property with a prefix right after (excepting the few properties like opacity and border-radius). Your rules will look something like this:

.box {
	-webkit-box-shadow:2px 2px 5px gray;
	-moz-box-shadow:2px 2px 5px gray;
	box-shadow:2px 2px 5px gray;

I know that hurts, but at least your repitition of code is localised.  And it is future-friendly – as browsers start supporting CSS3 your advanced styles will begin to appear!  A shadow on a header here, a rounded corner there, an opacity somewhere. Patience. 

You’ll notice there’s no -ie-border-radius property above. This is very sad. This leads us to our next restriction in using CSS3:

Don't force a design

Think about it - why must the design for a site look the same in IE as Chrome? What if they looked different? Someone who sees the site in IE is not going to know what they're missing. If a design feature can't be implemented in IE that's no reason not to implement it in WebKit, so long as it degrades gracefully.

For this to work you need to be close to the designers (or be the designer) and have laid back superiors - it can't really be done when you're dealing with long chains of design approval. Convince everyone that the site is going to look better in Chrome (happy face!), not worse in IE (ANGRY FACE).

Validating CSS3

By default, the W3C's CSS Validator does not recognise CSS3. You must specify that you are validating CSS3 by clicking "More Options" on the validator page and selecting the CSS level 3 profile.

That’s it! Go forth and play:

CSS3 Goodies you have got to check out:

Note on this site

This post is pretty much a press release for the recent redesign of FARMCode.org – CSS3 allowed me to code the site exactly how I wanted in Google Chrome, translate it across to Firefox in like 5 minutes and then conduct quick damage control for IE (no rounded corners there).

Can’t save changes to an Umbraco user

December 3, 2009 03:36
This post was imported from FARMCode.org which has been discontinued. These posts now exist here as an archive. They may contain broken links and images.
The other day Shannon was griping about a problem he’d come across when editing a user in Umbraco (a back-office account). When ever he clicked the Save button nothing happened, unless he’d gone and edited the Username field as well.

Today I noticed the same problem, I was trying to edit a user (I was changing the applications they had access to), I’d click save and nothing would happen! There was no error, there was no message from Umbraco.
It was as if the Save button was disabled.

And then it hit me, I was using Firefox and I had saved the username/ password combination when I logged into Umbraco.
That makes sense, the error seemed like some kind of client validation had been failing, but there was nothing obvious to me.
Then I realised that the password fields for the user details were hidden, so I clicked the Change Password link and look there, I have an error saying that my passwords don’t match.

Because I’d saved the username/ password in Firefox it was kind enough to auto-complete one of the password fields (using what ever algorithm Firefox does to detect password fields), but then there was nothing in the confirm field, causing the compare validator to fail.

So I cleared the field and clicked save, and all is well.


But why did it work when we changed the username? Well then Firefox detected that there was no password for that user, so it cleared the field, and the compare validator passed (it don’t compare empty fields).


Lesson learnt – be careful when you’re storing passwords :P