Comments on: CSS Best Practices and a Return to the Basics http://ikeif.net/2009/10/26/css-practices-return-basics/ iKeif.net - Web developer, father, and brewer. Sat, 05 Jun 2010 04:20:35 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-418 keif Wed, 06 Jan 2010 23:45:20 +0000 http://ikeif.net/?p=466#comment-418 A combination! Some things I've done because I liked it, and found it reinforced, others are the process of reading, educating, testing and discussion. A combination! Some things I've done because I liked it, and found it reinforced, others are the process of reading, educating, testing and discussion.

]]> By: Dr Gregg Ramsay http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-417 Dr Gregg Ramsay Wed, 06 Jan 2010 23:41:03 +0000 http://ikeif.net/?p=466#comment-417 Nice blog here. One question though, are the CSS rules yours or are they others that you've collected along the way? Nice blog here. One question though, are the CSS rules yours or are they others that you've collected along the way?

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-406 keif Tue, 01 Dec 2009 09:52:19 +0000 http://ikeif.net/?p=466#comment-406 It *can* be argued that inline styles are acceptable in some cases (i.e. CMS systems, or the current design showcase of "make each blog post it's own style") but I feel it needs to be drilled in to most devs to NOT use inline styles, period, as when they increase their competence they'll see inline styles as valid in extreme circumstances. It *can* be argued that inline styles are acceptable in some cases (i.e. CMS systems, or the current design showcase of “make each blog post it's own style”) but I feel it needs to be drilled in to most devs to NOT use inline styles, period, as when they increase their competence they'll see inline styles as valid in extreme circumstances.

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-405 keif Tue, 01 Dec 2009 01:52:19 +0000 http://ikeif.net/?p=466#comment-405 It *can* be argued that inline styles are acceptable in some cases (i.e. CMS systems, or the current design showcase of "make each blog post it's own style") but I feel it needs to be drilled in to most devs to NOT use inline styles, period, as when they increase their competence they'll see inline styles as valid in extreme circumstances. It *can* be argued that inline styles are acceptable in some cases (i.e. CMS systems, or the current design showcase of “make each blog post it's own style”) but I feel it needs to be drilled in to most devs to NOT use inline styles, period, as when they increase their competence they'll see inline styles as valid in extreme circumstances.

]]> By: walterg2 http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-404 walterg2 Mon, 30 Nov 2009 14:31:41 +0000 http://ikeif.net/?p=466#comment-404 While I would agree that inline styles are, generally, a bad practice, there are still some very valid reasons for using them, hopefully sparingly, within a site. I would say that 99.999% of those reasons are around the use of a CMS, where the user wants to have control of which background images are used for a reusable element. Without the use of inline styles, the user would need to lean on development to update and release the CSS files each and every time a new piece of content is needed using that "template".<br><br>Again, it's only in extreme circumstances that inline styles should be considered, but they shouldn't be discounted if you can still control the mechanism that the user will be using to add those in (i.e. - CMS). While I would agree that inline styles are, generally, a bad practice, there are still some very valid reasons for using them, hopefully sparingly, within a site. I would say that 99.999% of those reasons are around the use of a CMS, where the user wants to have control of which background images are used for a reusable element. Without the use of inline styles, the user would need to lean on development to update and release the CSS files each and every time a new piece of content is needed using that “template”.

Again, it's only in extreme circumstances that inline styles should be considered, but they shouldn't be discounted if you can still control the mechanism that the user will be using to add those in (i.e. – CMS).

]]> By: jasonkarns http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-403 jasonkarns Sun, 01 Nov 2009 11:46:01 +0000 http://ikeif.net/?p=466#comment-403 I would like to see a post concerning how the various libraries handle namespacing. And perhaps I boiled the subject down a little too far. The reason I brought it up is that IE7.js works perfectly well with jQuery but not with most other libraries out there. MooTools declares at least 15 global functions. It may be 'namespaced' with its modularity, but that's false advertising when you extend natives the way it does. And extending natives is the reason IE7.js doesn't work with MooTools out of the box. So you can call MooTools namespaced, but it may as well not be. I would like to see a post concerning how the various libraries handle namespacing. And perhaps I boiled the subject down a little too far. The reason I brought it up is that IE7.js works perfectly well with jQuery but not with most other libraries out there. MooTools declares at least 15 global functions. It may be 'namespaced' with its modularity, but that's false advertising when you extend natives the way it does. And extending natives is the reason IE7.js doesn't work with MooTools out of the box. So you can call MooTools namespaced, but it may as well not be.

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-402 keif Sun, 01 Nov 2009 03:35:09 +0000 http://ikeif.net/?p=466#comment-402 The issue with writing off IE6 as a corporate lock down, is that is your target selling audience - if your client is on IE6, and you try to argue that "most of your users will have a better experience" you won't get a warm reception. As well, one request for one HTC file that is something that could be broken out into multiple JS/CSS files (targeting specific pages, layouts, whatever) brings up the issue again (but this still falls in the "oh gee, it's an extra 30ms").<br><br>I hate AlphaImageLoader, and the more I've tested against DD_belatedPNG the more I'm liking it. I've only seen one situation it would've needed to be tweaked for past code.<br><br>I still am not sold on using a JS fix for CSS items - it's a pain in the ass, but .first/.last isn't too much to ask to give it the same experience without the JavaScript overhead.<br><br>AAANNND lastly - MooTools is namespace. I think Prototype and Dojo are not, but I'm not going to research the various JS libraries to see which ones still do/do not have this accounted for (maybe a future post?) The issue with writing off IE6 as a corporate lock down, is that is your target selling audience – if your client is on IE6, and you try to argue that “most of your users will have a better experience” you won't get a warm reception. As well, one request for one HTC file that is something that could be broken out into multiple JS/CSS files (targeting specific pages, layouts, whatever) brings up the issue again (but this still falls in the “oh gee, it's an extra 30ms”).

I hate AlphaImageLoader, and the more I've tested against DD_belatedPNG the more I'm liking it. I've only seen one situation it would've needed to be tweaked for past code.

I still am not sold on using a JS fix for CSS items – it's a pain in the ass, but .first/.last isn't too much to ask to give it the same experience without the JavaScript overhead.

AAANNND lastly – MooTools is namespace. I think Prototype and Dojo are not, but I'm not going to research the various JS libraries to see which ones still do/do not have this accounted for (maybe a future post?)

]]> By: jasonkarns http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-401 jasonkarns Wed, 28 Oct 2009 17:47:53 +0000 http://ikeif.net/?p=466#comment-401 Ah, I wasn't aware of IE6's issue with caching HTC files. Although I don't generally worry about overhead for IE6 workarounds that only affect IE6 users. Say your IE6 audience is ~24% (current IE usage is about 65% spread evenly over 6,7, and 8). Of those users, I would be willing to wager that over 75% of them are using IE6 due to IT lockdown, which means they are surfing your site on a T1 or T3 line. And if you declare all of your CSS behaviors with one selector, you only have one request.<br><br>As for TwinHelix in particular, yes there are certainly issues with it. But they are not due to the HTC, only the AlphaImageLoader technique in general. A standard JS library using the AlphaImageLoader has the same issues. And I prefer using the VML technique via DD_belatedPNG when the situation calls for it (which it nearly always does). However, this technique has its own problems, namely when the 'fixed' element's position or display properties are modified via JS.<br><br>I generally agree with everything you mentioned regarding the IE7 script. However, from my experience with it, the only fixes the script provides (that I rely on) are for 'nice-to-haves' that don't affect functionality. Things like :hover on non-anchors, :first-child, and :last-child which rarely do anything than change a border or margin property. The lack of these and other layout fixes does not impair the functionality of a site, merely its presentation, which is a perfect case for a JS solution.<br><br>And I'm completely ignoring the fact that IE7.js doesn't work with other libraries. I only use it with jQuery thanks to jQuery's namespacing (which is an entirely different conversation, ala MooTools). If I need MooTools or Prototype, et al. then IE7.js is out of the question. Ah, I wasn't aware of IE6's issue with caching HTC files. Although I don't generally worry about overhead for IE6 workarounds that only affect IE6 users. Say your IE6 audience is ~24% (current IE usage is about 65% spread evenly over 6,7, and 8). Of those users, I would be willing to wager that over 75% of them are using IE6 due to IT lockdown, which means they are surfing your site on a T1 or T3 line. And if you declare all of your CSS behaviors with one selector, you only have one request.

As for TwinHelix in particular, yes there are certainly issues with it. But they are not due to the HTC, only the AlphaImageLoader technique in general. A standard JS library using the AlphaImageLoader has the same issues. And I prefer using the VML technique via DD_belatedPNG when the situation calls for it (which it nearly always does). However, this technique has its own problems, namely when the 'fixed' element's position or display properties are modified via JS.

I generally agree with everything you mentioned regarding the IE7 script. However, from my experience with it, the only fixes the script provides (that I rely on) are for 'nice-to-haves' that don't affect functionality. Things like :hover on non-anchors, :first-child, and :last-child which rarely do anything than change a border or margin property. The lack of these and other layout fixes does not impair the functionality of a site, merely its presentation, which is a perfect case for a JS solution.

And I'm completely ignoring the fact that IE7.js doesn't work with other libraries. I only use it with jQuery thanks to jQuery's namespacing (which is an entirely different conversation, ala MooTools). If I need MooTools or Prototype, et al. then IE7.js is out of the question.

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-400 keif Wed, 28 Oct 2009 16:29:35 +0000 http://ikeif.net/?p=466#comment-400 My issue with it, is you're creating additional server requests - to a CSS file, to an HTC file, to fire off JavaScript - why not just request JavaScript? On top of the number of issues that the TwinHelix "fix" can introduct, including the need of a custom htaccess file, it doesn't work with PNG backgrounds and links and needing to possibly set the content expiration (<a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q319176" rel="nofollow">http://support.microsoft.com/default.aspx?scid=...</a>) to fix excessive server requests. A whole slew of issues that can be overlooked until it's in production, or on a client's server that you can't necessarily easily fix on your end.<br><br>Dean Edward's IE7 script is a hack itself - it creates the illusion that CSS will work properly versus actually coding to account for it. You end up writing "advanced" CSS that fails without JavaScript, which can introduce more issues, particularly if you utilize it in addition to other JavaScript frameworks.<br><br>The issue with the IE7 script, is it is Dean Edward's script - there is no community of support. It has 12 accepted defects since January of 2008, and a total of 166 bugs - if there was a strong community behind it, I might say "okay" but it's just a simple "throw it in, hope it works" which can introduce more issues than it fixes, particularly since he considers it a "beta" project. I much prefer to write valid CSS that is cross-browser compliant and progressively enhance the site through the use of CSS3 and a JavaScript library to achieve cross-browser compliance.<br><br>For a majority of clients, a JavaScript solution to make it work is not a valid one if it prevents the site from functioning. My issue with it, is you're creating additional server requests – to a CSS file, to an HTC file, to fire off JavaScript – why not just request JavaScript? On top of the number of issues that the TwinHelix “fix” can introduct, including the need of a custom htaccess file, it doesn't work with PNG backgrounds and links and needing to possibly set the content expiration (http://support.microsoft.com/default.aspx?scid=…) to fix excessive server requests. A whole slew of issues that can be overlooked until it's in production, or on a client's server that you can't necessarily easily fix on your end.

Dean Edward's IE7 script is a hack itself – it creates the illusion that CSS will work properly versus actually coding to account for it. You end up writing “advanced” CSS that fails without JavaScript, which can introduce more issues, particularly if you utilize it in addition to other JavaScript frameworks.

The issue with the IE7 script, is it is Dean Edward's script – there is no community of support. It has 12 accepted defects since January of 2008, and a total of 166 bugs – if there was a strong community behind it, I might say “okay” but it's just a simple “throw it in, hope it works” which can introduce more issues than it fixes, particularly since he considers it a “beta” project. I much prefer to write valid CSS that is cross-browser compliant and progressively enhance the site through the use of CSS3 and a JavaScript library to achieve cross-browser compliance.

For a majority of clients, a JavaScript solution to make it work is not a valid one if it prevents the site from functioning.

]]> By: jasonkarns http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-399 jasonkarns Wed, 28 Oct 2009 11:00:08 +0000 http://ikeif.net/?p=466#comment-399 I agree that the Twin Helix technique is nothing more than a JavaScript solution in HTC clothing. However, when you're throwing in a CSS behavior to fix a browser issue, I don't see anything wrong with it. You've already got your IE-specific stylesheet being included via Conditional Comments. No need to reference another JavaScript file when you can just as easily drop in behavior references. Using IE's proprietary features to patch IE bugs is perfectly fine in my book. CSS expressions (when written properly to avoid the performance hit) can patch in support for position:fixed, and max-height/width. Throw in another HTC for whatever:hover. Although if you need all of these features patched, I would rather drop in Dean Edwards' IE7 script and be done with it. I agree that the Twin Helix technique is nothing more than a JavaScript solution in HTC clothing. However, when you're throwing in a CSS behavior to fix a browser issue, I don't see anything wrong with it. You've already got your IE-specific stylesheet being included via Conditional Comments. No need to reference another JavaScript file when you can just as easily drop in behavior references. Using IE's proprietary features to patch IE bugs is perfectly fine in my book. CSS expressions (when written properly to avoid the performance hit) can patch in support for position:fixed, and max-height/width. Throw in another HTC for whatever:hover. Although if you need all of these features patched, I would rather drop in Dean Edwards' IE7 script and be done with it.

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-398 keif Tue, 27 Oct 2009 04:28:02 +0000 http://ikeif.net/?p=466#comment-398 CSS Specificity is more of a "destination" - I'm not nearly efficient as I should be, and I agree that sometimes adding in elements can help navigate a CSS file.<br><br>However, it could be argued that CSS commenting could negate the need for the element specificity (but then we're back to debating "how many milliseconds is this costing us?")<br><br>Totally missed :focus, thanks.<br><br>No reason for CSS Behaviors. At all. Twin Helix's htc file is just JavaScript shoved into an HTC file. There are one hundred (plus one) solutions for PNG's utilizing VML or AlphaImageLoader that don't try to hide behind the HTC that are just as effective (and some could argue that VML is *more* effective).<br><br>I'm looking into the HTC rounded corners fix, but I have a feeling that it too will fall into the "should be JavaScript" - unless someone can generate the benchmarks that say going the HTC route is actually more effective than a pure JavaScript route. CSS Specificity is more of a “destination” – I'm not nearly efficient as I should be, and I agree that sometimes adding in elements can help navigate a CSS file.

However, it could be argued that CSS commenting could negate the need for the element specificity (but then we're back to debating “how many milliseconds is this costing us?”)

Totally missed :focus, thanks.

No reason for CSS Behaviors. At all. Twin Helix's htc file is just JavaScript shoved into an HTC file. There are one hundred (plus one) solutions for PNG's utilizing VML or AlphaImageLoader that don't try to hide behind the HTC that are just as effective (and some could argue that VML is *more* effective).

I'm looking into the HTC rounded corners fix, but I have a feeling that it too will fall into the “should be JavaScript” – unless someone can generate the benchmarks that say going the HTC route is actually more effective than a pure JavaScript route.

]]> By: jasonkarns http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-397 jasonkarns Mon, 26 Oct 2009 23:03:30 +0000 http://ikeif.net/?p=466#comment-397 Rule: CSS Specificity<br>I admit, I tend to get a little carried away here. In general I do a good job keeping my selectors to a minimum, but I also like to throw in an extra element or two (or class or id) to help show the HTML structure in the CSS.<br><br>Rule: Link States<br>You're missing one! :focus. Never leave out focus, else your styles will tend to only be mouse-friendly. Be sure to add :focus to any :hover rule and you've got both the keyboard *and* the mouse covered. The mnemonic I use for the rule order is: Lord Vader's Former Handle, Anakin (:link, :visited, :focus, :hover, :active).<br><br>Rule: CSS Behaviors<br>No reason for CSS behaviors at all? Really? Not even as an IE PNG Fix (ala Twin Helix)? Rule: CSS Specificity
I admit, I tend to get a little carried away here. In general I do a good job keeping my selectors to a minimum, but I also like to throw in an extra element or two (or class or id) to help show the HTML structure in the CSS.

Rule: Link States
You're missing one! :focus. Never leave out focus, else your styles will tend to only be mouse-friendly. Be sure to add :focus to any :hover rule and you've got both the keyboard *and* the mouse covered. The mnemonic I use for the rule order is: Lord Vader's Former Handle, Anakin (:link, :visited, :focus, :hover, :active).

Rule: CSS Behaviors
No reason for CSS behaviors at all? Really? Not even as an IE PNG Fix (ala Twin Helix)?

]]> By: keif http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-396 keif Mon, 26 Oct 2009 21:28:49 +0000 http://ikeif.net/?p=466#comment-396 I go all the way strict - CSS Behaviors (an IE methodology) require JavaScript to be used, therefore they should just be entered in as plain JavaScript.<br><br>The CSS a:hover work, period. Generally, I'll still utilize :hover when I can as CSS is seldom disabled, so most browsers still get a better experience than those that require JavaScript. Which is usually just IE. I go all the way strict – CSS Behaviors (an IE methodology) require JavaScript to be used, therefore they should just be entered in as plain JavaScript.

The CSS a:hover work, period. Generally, I'll still utilize :hover when I can as CSS is seldom disabled, so most browsers still get a better experience than those that require JavaScript. Which is usually just IE.

]]> By: Tweets that mention CSS Best Practices and a Return to the Basics – iKeif – tech and social media geek, mootools fan, and a ton of links — iKeif - tech and social media geek, mootools fan, and a ton of links -- Topsy.com http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-394 Tweets that mention CSS Best Practices and a Return to the Basics – iKeif – tech and social media geek, mootools fan, and a ton of links — iKeif - tech and social media geek, mootools fan, and a ton of links -- Topsy.com Mon, 26 Oct 2009 18:43:02 +0000 http://ikeif.net/?p=466#comment-394 [...] This post was mentioned on Twitter by Dan Green, Keith Baker. Keith Baker said: I blog'd: CSS Best Practices and a Return to the Basics http://bit.ly/gMCeG [...] [...] This post was mentioned on Twitter by Dan Green, Keith Baker. Keith Baker said: I blog'd: CSS Best Practices and a Return to the Basics http://bit.ly/gMCeG [...]

]]> By: Braxo http://ikeif.net/2009/10/26/css-practices-return-basics/comment-page-1/#comment-395 Braxo Mon, 26 Oct 2009 17:02:33 +0000 http://ikeif.net/?p=466#comment-395 In your rule CSS Behaviors Require JavaScript, how strict do you go with that?<br><br>I even go as far as to separate the CSS :hover effects to javascript as I view them as behaviors and snazzy extra functionality.<br><br>I am strict with content in db, html for markup, css for styles, js for behavior In your rule CSS Behaviors Require JavaScript, how strict do you go with that?

I even go as far as to separate the CSS :hover effects to javascript as I view them as behaviors and snazzy extra functionality.

I am strict with content in db, html for markup, css for styles, js for behavior

]]>