CSS and JS - so now you know
April 21, 2010 12:31 PM Subscribe
CSS Tips I Wish I Knew When I First Started - Seven JavaScript Things I Wish I Knew Much Earlier In My Career
Thanks for this... very useful, and yeah, I wish I'd known them from the start. I also wish I'd known how to build drop-down menus in CSS.
posted by Guy_Inamonkeysuit at 12:44 PM on April 21, 2010 [1 favorite]
posted by Guy_Inamonkeysuit at 12:44 PM on April 21, 2010 [1 favorite]
My personal theory is that most everything can be found here.
posted by djgh at 12:50 PM on April 21, 2010 [1 favorite]
posted by djgh at 12:50 PM on April 21, 2010 [1 favorite]
Specifically, here for solid examples and tutorials related to CSS, not just evangelism or whatnot.
posted by djgh at 12:51 PM on April 21, 2010 [5 favorites]
posted by djgh at 12:51 PM on April 21, 2010 [5 favorites]
I really like Iconize Textlinks with CSS and HTML and CSS Table Border Style Wizard
posted by wcfields at 12:51 PM on April 21, 2010
posted by wcfields at 12:51 PM on April 21, 2010
I find it interesting that the web design community collectively spent so many hundreds of hours working out various hacks in order to hide certain rules from IE when a nearly-perfect, officially supported way of doing it, namely conditional comments, existed all along. It simply wasn't widely known. Likewise, many specific bugs in IE's layout engine actually had a common cause which hardly known of for years: the hasLayout property.
If you took that knowledge back to 1999 and told the web design community, I wonder what things would be different today.
posted by The Lurkers Support Me in Email at 12:56 PM on April 21, 2010 [7 favorites]
If you took that knowledge back to 1999 and told the web design community, I wonder what things would be different today.
posted by The Lurkers Support Me in Email at 12:56 PM on April 21, 2010 [7 favorites]
I would just travel back to 2006 and tell me to start using jQuery already - it would have saved a lot of hassle. Maybe I'd hand myself a copy of JavaScript: The Good Parts as well.
posted by Artw at 1:01 PM on April 21, 2010 [3 favorites]
posted by Artw at 1:01 PM on April 21, 2010 [3 favorites]
I'm working on a project that involves a lot of menus, which was the subject of an AskMeFi post today (I still need help). One approach was through CSS and I've really learned a lot from Stu Nicholls' site.
I'm also really impressed with the tutorials here.
Alas, I think CSS code might be too complicated for content that I want to be easily updated and reordered, especially when my menus have5 sub levels. Maybe I need to save CSS for when my menus are really set in stone. Or maybe I need to try pulldown menus.
posted by jimmymcvee at 1:13 PM on April 21, 2010
I'm also really impressed with the tutorials here.
Alas, I think CSS code might be too complicated for content that I want to be easily updated and reordered, especially when my menus have5 sub levels. Maybe I need to save CSS for when my menus are really set in stone. Or maybe I need to try pulldown menus.
posted by jimmymcvee at 1:13 PM on April 21, 2010
I think CSS code might be too complicated for content that I want to be easily updated and reordered
lol wut?
posted by thesmophoron at 1:16 PM on April 21, 2010 [8 favorites]
lol wut?
posted by thesmophoron at 1:16 PM on April 21, 2010 [8 favorites]
Alas, I think CSS code might be too complicated for content that I want to be easily updated and reordered, especially when my menus have5 sub levels. Maybe I need to save CSS for when my menus are really set in stone.
The typical technique nowadays is to use an unordered list styled with CSS. It couldn't be any easier to update and rearrange. Just cut and paste.
I have become a big fan of Blueprint for basic layout and jQuery for functionality. Basically, all I worry about anymore is making sure my XHTML validates and everything degrades well.
It's certainly easier than it used to be.
posted by Benny Andajetz at 1:23 PM on April 21, 2010 [1 favorite]
The typical technique nowadays is to use an unordered list styled with CSS. It couldn't be any easier to update and rearrange. Just cut and paste.
I have become a big fan of Blueprint for basic layout and jQuery for functionality. Basically, all I worry about anymore is making sure my XHTML validates and everything degrades well.
It's certainly easier than it used to be.
posted by Benny Andajetz at 1:23 PM on April 21, 2010 [1 favorite]
Look, I'm a total newb. Plus, I'm talking about really huge menus with many levels and long lists that might require techniques like this.
But, please, enlighten me. I need all the help I can get.
posted by jimmymcvee at 1:28 PM on April 21, 2010
But, please, enlighten me. I need all the help I can get.
posted by jimmymcvee at 1:28 PM on April 21, 2010
OH MOTHER FUCKER. Google Chrome has fucked up my links all day because of the http:// thing.
Let's try this again!
posted by Jairus at 1:30 PM on April 21, 2010 [1 favorite]
Let's try this again!
posted by Jairus at 1:30 PM on April 21, 2010 [1 favorite]
Look, I'm a total newb. Plus, I'm talking about really huge menus with many levels and long lists that might require techniques like this.
But, please, enlighten me. I need all the help I can get.
Google "mega menus". Big e-commerce sites generally use these types of menus. They can be built fairly easily with jQuery. ( They are unordered lists that are "operated" with javascript.)
posted by Benny Andajetz at 1:35 PM on April 21, 2010
But, please, enlighten me. I need all the help I can get.
Google "mega menus". Big e-commerce sites generally use these types of menus. They can be built fairly easily with jQuery. ( They are unordered lists that are "operated" with javascript.)
posted by Benny Andajetz at 1:35 PM on April 21, 2010
Thanks Benny for a patient response. Ok, so it sounds like it's much easier these days. Maybe I just lack patience. I'm also trying to combine flyout blocks with flyout lists and dropdown flyout html. So, it's just giving me a headache since I'm new at it.
posted by jimmymcvee at 1:36 PM on April 21, 2010
posted by jimmymcvee at 1:36 PM on April 21, 2010
Ah, I must have been linking about the Jquery mega dropdowns as you were typing that last tip. It might be the way to go. Gracias.
posted by jimmymcvee at 1:39 PM on April 21, 2010
posted by jimmymcvee at 1:39 PM on April 21, 2010
Thanks for that superfish link as well, Jairus. Trying it now.
posted by jimmymcvee at 1:43 PM on April 21, 2010
posted by jimmymcvee at 1:43 PM on April 21, 2010
*pets The Lurkers Support Me in Email gently* There there. I know, I know, I know, I know IE will never hurt you again.
posted by adipocere at 2:00 PM on April 21, 2010 [5 favorites]
posted by adipocere at 2:00 PM on April 21, 2010 [5 favorites]
Here's the thing I wish I knew back in the day: CSS is processed by the browser right-to-left (from the key selector up), not left-to-right as most assume -- thus, if your CSS looks like this:
...the browser is collecting every single td element in the DOM, then traversing the DOM upwards until it hits a match (or tops out.) If you're trying to style a single unclassed td in a table with thousands of td elements, you can see how costly (performance-wise) that can become.
posted by davejay at 2:26 PM on April 21, 2010 [9 favorites]
.outer-class .inner-class td {font-weight:bold;}...the browser is collecting every single td element in the DOM, then traversing the DOM upwards until it hits a match (or tops out.) If you're trying to style a single unclassed td in a table with thousands of td elements, you can see how costly (performance-wise) that can become.
posted by davejay at 2:26 PM on April 21, 2010 [9 favorites]
Screw floats. Inline blocks is where it's at*
http://homepage.ntlworld.com/spartanicus/ie_block_level_element_inline-block_hack.htm
*Actually inline floats have some weird white space issues if you're trying to snug elements up close to one another, but for rendering a grid like list of elements with margins between, inline block is far superior.
posted by device55 at 2:36 PM on April 21, 2010
http://homepage.ntlworld.com/spartanicus/ie_block_level_element_inline-block_hack.htm
*Actually inline floats have some weird white space issues if you're trying to snug elements up close to one another, but for rendering a grid like list of elements with margins between, inline block is far superior.
posted by device55 at 2:36 PM on April 21, 2010
Does anyone who has recent experience with Dojo have any opinions they'd be willing to share?
posted by Crabby Appleton at 2:38 PM on April 21, 2010
posted by Crabby Appleton at 2:38 PM on April 21, 2010
These are good tips, though I'm surprised that grouping and shorthand aren't well known and indeed most of the tips are in many a decent CSS book, though I suppose choosing a good source is always difficult.
Commenting? Absolutely. It makes your own life easier for sure. Though I have run into a couple of freelance developers in my time who make some rather client unfriendly comments so always check them to be sure there aren't any easter eggs per se.
For IE6 in particular we try sell the making of a lo-fi version. Use modern CSS for IE 8/Firefox/Webkit browsers (though of course IE 8 is still lacking) and spin a lo-fi style sheet for IE6.
Using a framework like jQuery is great advice too. Even "frameworks produce substandard applications" Apple uses JavaScript frameworks on their own site. Our project management software, Feng Office, wouldn't be as rapidly developed and usable without the use of frameworks.
I'd also add that using a good CMS or CMF is great for building a web site. I'm a MODx guy myself, though Drupal is immensely popular and WordPress (the theming of the latter two really turns me off but to each his own, I find the ability to not have to make a PHP riddled template but a regular XHTM/CSS template liberating in MODx). Joomla is another popular one but I've vowed to never work with it again but again one's preferences, mindset, and methodology make the tools one likes or dislikes extremely subjective. CMS's also have a lot of fundamentals that like CSS and JavaScript can suffer from clear documentation that details production level pointers.
Of course Google, SEO in general, and the ability to use CMS's to allow client updates have really reduced the use of Flash for a number of years now, though it's still great for technical or entertainment animations and games and won't be plugin but native to Chrome. As for video, hopefully Google really will open source VP8 so we can get away from the patent encumbered h.264. Interesting times for web development for sure.
posted by juiceCake at 3:21 PM on April 21, 2010
Commenting? Absolutely. It makes your own life easier for sure. Though I have run into a couple of freelance developers in my time who make some rather client unfriendly comments so always check them to be sure there aren't any easter eggs per se.
For IE6 in particular we try sell the making of a lo-fi version. Use modern CSS for IE 8/Firefox/Webkit browsers (though of course IE 8 is still lacking) and spin a lo-fi style sheet for IE6.
Using a framework like jQuery is great advice too. Even "frameworks produce substandard applications" Apple uses JavaScript frameworks on their own site. Our project management software, Feng Office, wouldn't be as rapidly developed and usable without the use of frameworks.
I'd also add that using a good CMS or CMF is great for building a web site. I'm a MODx guy myself, though Drupal is immensely popular and WordPress (the theming of the latter two really turns me off but to each his own, I find the ability to not have to make a PHP riddled template but a regular XHTM/CSS template liberating in MODx). Joomla is another popular one but I've vowed to never work with it again but again one's preferences, mindset, and methodology make the tools one likes or dislikes extremely subjective. CMS's also have a lot of fundamentals that like CSS and JavaScript can suffer from clear documentation that details production level pointers.
Of course Google, SEO in general, and the ability to use CMS's to allow client updates have really reduced the use of Flash for a number of years now, though it's still great for technical or entertainment animations and games and won't be plugin but native to Chrome. As for video, hopefully Google really will open source VP8 so we can get away from the patent encumbered h.264. Interesting times for web development for sure.
posted by juiceCake at 3:21 PM on April 21, 2010
The only tip I dislike in the CSS list is the reset tip. Reseting is a pointless waste of time, because you end up having to rewrite margin/padding for every element in your layout, bulking your CSS files and making them generally harder to work on (other tips in the list talk about being efficient as possible in your code).
True, if you stick with browser defaults, your layouts won't be pixel perfect across all browsers, but so what? It's great when a design is loose enough where a pixel here and there isn't a problem.
posted by mathowie at 3:31 PM on April 21, 2010 [2 favorites]
True, if you stick with browser defaults, your layouts won't be pixel perfect across all browsers, but so what? It's great when a design is loose enough where a pixel here and there isn't a problem.
posted by mathowie at 3:31 PM on April 21, 2010 [2 favorites]
The only tip I dislike in the CSS list is the reset tip. Reseting is a pointless waste of time, because you end up having to rewrite margin/padding for every element in your layout, bulking your CSS files and making them generally harder to work on (other tips in the list talk about being efficient as possible in your code).
I'll disagree on this one; as someone who uses YUI's reset-fonts package regularly, I can tell you that if you do need consistent, pixel-perfect fonts and other things (which in the corporate world can be a requirement, although not one I agree with) resetting is extremely helpful -- and the reset code from YUI, at least, isn't very big.
The easy way to avoid the bloat, then, is to drop in the small reset code, then establish a baseline for your commonly-used margin/padding per element (if you have one), so you only need to rewrite margins/paddings further when forking from your standard.
posted by davejay at 3:38 PM on April 21, 2010
I'll disagree on this one; as someone who uses YUI's reset-fonts package regularly, I can tell you that if you do need consistent, pixel-perfect fonts and other things (which in the corporate world can be a requirement, although not one I agree with) resetting is extremely helpful -- and the reset code from YUI, at least, isn't very big.
The easy way to avoid the bloat, then, is to drop in the small reset code, then establish a baseline for your commonly-used margin/padding per element (if you have one), so you only need to rewrite margins/paddings further when forking from your standard.
posted by davejay at 3:38 PM on April 21, 2010
If you can all get out of supporting IE6 then do. It simplifies everything dramatically.
posted by Artw at 3:42 PM on April 21, 2010
posted by Artw at 3:42 PM on April 21, 2010
Even "frameworks produce substandard applications" Apple uses JavaScript frameworks on their own site.
Frameworks aren't a problem. Alternative frameworks that compile directly to binary code and force developers to only use that framework are the problem.
posted by Talez at 3:44 PM on April 21, 2010
Frameworks aren't a problem. Alternative frameworks that compile directly to binary code and force developers to only use that framework are the problem.
posted by Talez at 3:44 PM on April 21, 2010
Gah. If you can *at all* get out of supporting IE6...
What I'd really hope for is a mass migration of IE users onto 9 when that's here, as that's going to mean a huge increase in the amount of common interpretation of code between browsers, but I suspect that Microsoft have screwed us over there by not supporting XP - XP isn't going anywhere soon, and so neither will IE 8, making it a potential new IE6 in terms of being a lagging browser that hangs around forever that everybody hates.
Oh... and so far no sign of CANVAS support in IE9. Sure, SVG is nice, but it's not what we want.
posted by Artw at 3:47 PM on April 21, 2010
What I'd really hope for is a mass migration of IE users onto 9 when that's here, as that's going to mean a huge increase in the amount of common interpretation of code between browsers, but I suspect that Microsoft have screwed us over there by not supporting XP - XP isn't going anywhere soon, and so neither will IE 8, making it a potential new IE6 in terms of being a lagging browser that hangs around forever that everybody hates.
Oh... and so far no sign of CANVAS support in IE9. Sure, SVG is nice, but it's not what we want.
posted by Artw at 3:47 PM on April 21, 2010
Inline blocks is where it's at*
* Not supported cross-browser.
As for the article… The only thing worse than CSS inconsistencies are CSS tutorials with inconsistencies.
posted by Civil_Disobedient at 3:47 PM on April 21, 2010 [3 favorites]
* Not supported cross-browser.
As for the article… The only thing worse than CSS inconsistencies are CSS tutorials with inconsistencies.
- You have to specify a width on the container if you want to use overflow:hidden to clear your floats. See also.
- No shit.
- No shit.
- Font-size isn't a safe base style to set on the BODY element; apply it to the (inevitable) wrapper DIV, instead. Also, older IE doesn't play nice with base font sizes and tables (you have to re-apply it to the cells).
- Finally, some non-obvious good advice.
- CSS shorthand is utterly non-intuitive to look at. For instance: { margin: 1em 2em 3em; } is the same as { margin: 1em 2em 3em 2em; }, but it looks like the LEFT value is inherited. And how about the CSS shorthand for FONT? font-style, font-variant, and font-weight all default to NORMAL. So your shorthand can look like this: { normal normal normal 1em; } which is just WRONG.
- No shit.
- The idiot didn't number his tips (forgiveable)
- The idiot didn't put anchors on his tips, making them un-linkable (come on, what year is this?)
posted by Civil_Disobedient at 3:47 PM on April 21, 2010 [3 favorites]
The only tip I dislike in the CSS list is the reset tip.
I'll disagree on this one
I'd disagree about reseting being bad too, but I'm usually working to photoshop comps, plus do a lot of position sensitive UI stuff, and want everything pixel perfect.
On the other hand, not every site has to be that kind of beast. This one isn't, and is better for it.
posted by Artw at 3:49 PM on April 21, 2010
I'll disagree on this one
I'd disagree about reseting being bad too, but I'm usually working to photoshop comps, plus do a lot of position sensitive UI stuff, and want everything pixel perfect.
On the other hand, not every site has to be that kind of beast. This one isn't, and is better for it.
posted by Artw at 3:49 PM on April 21, 2010
Actually, device55, I'd take your inline-block and raise you display:table for achieving traditional grid-style layouts. (Sorry for the self-link, but it's the nearest resource I have at hand).
Of course the problem is that IE does not support either property, at least up until IE8... but you can always throw pre-IE8 a different stylesheet that uses floats to achieve a similar result, albeit with a lot more CSS.
Long-term, the CSS3 Grid Positioning module, combined with some of the new semantic tags of HTML5, will make layouts a lot easier.
posted by Bora Horza Gobuchul at 3:55 PM on April 21, 2010
Of course the problem is that IE does not support either property, at least up until IE8... but you can always throw pre-IE8 a different stylesheet that uses floats to achieve a similar result, albeit with a lot more CSS.
Long-term, the CSS3 Grid Positioning module, combined with some of the new semantic tags of HTML5, will make layouts a lot easier.
posted by Bora Horza Gobuchul at 3:55 PM on April 21, 2010
display:table pisses me off. Hey, tables are bad now, so what are we going to do? Replicate their structure in DIVs and use CSS to fake exactly the same thing?
Not to mention that it's quite often suggested as yet another shaky technique for addressing something that CSS has thus-far been disastrously bad at: Vertical placement of elements.
Long-term, the CSS3 Grid Positioning module, combined with some of the new semantic tags of HTML5, will make layouts a lot easier.
That *might* improve things. As for the new fancy semantic tags... well, their nice, but DIVs do the same thing so they're basically pointless... I guess it can be something for standards nazis to get all het up about while everyone else scratches their heads, like B versus STRONG.
posted by Artw at 4:04 PM on April 21, 2010
Not to mention that it's quite often suggested as yet another shaky technique for addressing something that CSS has thus-far been disastrously bad at: Vertical placement of elements.
Long-term, the CSS3 Grid Positioning module, combined with some of the new semantic tags of HTML5, will make layouts a lot easier.
That *might* improve things. As for the new fancy semantic tags... well, their nice, but DIVs do the same thing so they're basically pointless... I guess it can be something for standards nazis to get all het up about while everyone else scratches their heads, like B versus STRONG.
posted by Artw at 4:04 PM on April 21, 2010
As for CSS, don't forget:
- Hack at it until it works and then give up trying to understand why. It's hopeless, and once you have your spaghetti of selectors and styles, don't try to optimize them. It's better to have it working than to change one selector and have the whole thing fall apart.
posted by clvrmnky at 4:04 PM on April 21, 2010
- Hack at it until it works and then give up trying to understand why. It's hopeless, and once you have your spaghetti of selectors and styles, don't try to optimize them. It's better to have it working than to change one selector and have the whole thing fall apart.
posted by clvrmnky at 4:04 PM on April 21, 2010
/looks at mess of .css files.
/cries
You had to ruin my mood!
posted by Artw at 4:07 PM on April 21, 2010
/cries
You had to ruin my mood!
posted by Artw at 4:07 PM on April 21, 2010
My pet peeves (so far) about HTML5:
posted by kirkaracha at 4:36 PM on April 21, 2010
aside instead of sidebar. "Aside" is a theatrical term, "sidebar" is a traditional publishing term that's already widely used in web publishing. How is "sidebar" any less semantic than "aside?" They're replacing a widely-used term that's analogous to a similar field (print design) with a term that isn't any clearer or more semantic.article and section. Sections can be inside articles and articles can be inside sections. Clear as mud.posted by kirkaracha at 4:36 PM on April 21, 2010
If you can *at all* get out of supporting IE6
Not an option for many, many many people. Sad, but painfully true.
Even after large corporations cease to support IE6, there will be a significant long tail of people who simply want to put food on the table by coding web pages and apps, and these solutions will continue to be valuable. Provide this functionality if you can. Optionally display upgrade recommendation snarks, if you are so inclined.
I certainly don't disagree with you, though.
<except for one .NET intranet project, everything I've written for money can be accessed in full using lynx, la la la>
posted by sidereal at 4:41 PM on April 21, 2010
Not an option for many, many many people. Sad, but painfully true.
Even after large corporations cease to support IE6, there will be a significant long tail of people who simply want to put food on the table by coding web pages and apps, and these solutions will continue to be valuable. Provide this functionality if you can. Optionally display upgrade recommendation snarks, if you are so inclined.
I certainly don't disagree with you, though.
<except for one .NET intranet project, everything I've written for money can be accessed in full using lynx, la la la>
posted by sidereal at 4:41 PM on April 21, 2010
Heh. When I first dumped tables I went through a phase of testing my sites on Lynx and seeing how pretty I could make them appear just as pure text… oddly satisfying.
posted by Artw at 4:42 PM on April 21, 2010
posted by Artw at 4:42 PM on April 21, 2010
It's great when a design is loose enough where a pixel here and there isn't a problem.
God, you should meet most of my clients. I wish I could get them to agree with that. Headache of today is someone getting complaints that one out of a few hundred recipients of their html newsletter isn't able to view correctly because they use Lotus... and no, apparently a text only version isn't good enough. Anyone care to advise on how they deal with this sort of pedantic nonsense?
posted by twistedonion at 4:53 PM on April 21, 2010
God, you should meet most of my clients. I wish I could get them to agree with that. Headache of today is someone getting complaints that one out of a few hundred recipients of their html newsletter isn't able to view correctly because they use Lotus... and no, apparently a text only version isn't good enough. Anyone care to advise on how they deal with this sort of pedantic nonsense?
posted by twistedonion at 4:53 PM on April 21, 2010
So – in short: The best clients in the world would be ones that don’t mind some looseness in terms of pixels being here and there and don’t care about IE6…
:-)
Did I mention my current project is IE 7+ ? It’s bliss. The other thing... not so much.
posted by Artw at 5:09 PM on April 21, 2010
:-)
Did I mention my current project is IE 7+ ? It’s bliss. The other thing... not so much.
posted by Artw at 5:09 PM on April 21, 2010
you can always throw pre-IE8 a different stylesheet that uses floats to achieve a similar result, albeit with a lot more CSS.
Since you have to do this work anyway, why bother maintaining two separate stylesheets?
posted by ook at 5:14 PM on April 21, 2010
Since you have to do this work anyway, why bother maintaining two separate stylesheets?
posted by ook at 5:14 PM on April 21, 2010
More and more I am against forks of that kind.
(Of course, any framework is going to be full of them - but someone else has already done the work and the testing and it's all nicely hidden away)
posted by Artw at 5:26 PM on April 21, 2010
(Of course, any framework is going to be full of them - but someone else has already done the work and the testing and it's all nicely hidden away)
posted by Artw at 5:26 PM on April 21, 2010
Since you have to do this work anyway, why bother maintaining two separate stylesheets?
Well, if the "modern" CSS sheet can be 50% or less the size of the "legacy" one, that can be a significant latency gain for most of your users. A lot of big websites have a couple hundred k worth of JS&CSS, and that is a big speed issue (could easily save a second or two on average page load time by significantly shaving that). But otherwise I'd tend to agree.
posted by wildcrdj at 5:46 PM on April 21, 2010
Well, if the "modern" CSS sheet can be 50% or less the size of the "legacy" one, that can be a significant latency gain for most of your users. A lot of big websites have a couple hundred k worth of JS&CSS, and that is a big speed issue (could easily save a second or two on average page load time by significantly shaving that). But otherwise I'd tend to agree.
posted by wildcrdj at 5:46 PM on April 21, 2010
I'm going to second the display:table disdain. If you have data that needs to be displayed as a table, use a table. I'm torn on the whole reset matter. If I think a reset is necessary,
posted by potch at 5:52 PM on April 21, 2010
* {margin:0;padding:0} usually will suffice, but when it's time to get precise, having a ready-made solutions is fantastic. We use libraries to normalize JS across browsers, why not CSS?posted by potch at 5:52 PM on April 21, 2010
Well, if the "modern" CSS sheet can be 50% or less the size of the "legacy" one
I'm hard pressed to imagine a plausible case where this would be even close to true.
Generally I find the best savings in terms of both file size and code complexity is achieved by just gritting your teeth and using a table when necessary. If you need a grid, we have a really excellent tool for producing grids. It's backwards compatible to Netscape 2 or so, with no browser hacks, css forks or conditional comments required.
The semantic web is a fairy tale. Fuck it. Use code that works. Nobody's keeping score.
posted by ook at 6:24 PM on April 21, 2010 [4 favorites]
I'm hard pressed to imagine a plausible case where this would be even close to true.
Generally I find the best savings in terms of both file size and code complexity is achieved by just gritting your teeth and using a table when necessary. If you need a grid, we have a really excellent tool for producing grids. It's backwards compatible to Netscape 2 or so, with no browser hacks, css forks or conditional comments required.
The semantic web is a fairy tale. Fuck it. Use code that works. Nobody's keeping score.
posted by ook at 6:24 PM on April 21, 2010 [4 favorites]
When I first dumped tables I went through a phase of testing my sites on Lynx
You could actually do that with Lynx before you ditched tables. It more or less ignored tables for a while, and around 1999, got fairly smart about which tables were probably tabular data and which were probably layout it could ignore (one exhibit in the case that a lot of the handwringing about "abusing" the semantics of tabular markup has been overwrought)
If you have data that needs to be displayed as a table, use a table.
I'll endorse that and go a step beyond: tables/grids solve some non-data layout problems that are either impossible using the rest of the CSS positioning arsenal or difficult enough that it's often not worth it. Frankly, I'm an advocate of just repurposing tabular markup when it makes layout convenient, but that makes some people inordinately cranky, so when IE 6/7 die, going with
posted by weston at 7:34 PM on April 21, 2010
You could actually do that with Lynx before you ditched tables. It more or less ignored tables for a while, and around 1999, got fairly smart about which tables were probably tabular data and which were probably layout it could ignore (one exhibit in the case that a lot of the handwringing about "abusing" the semantics of tabular markup has been overwrought)
If you have data that needs to be displayed as a table, use a table.
I'll endorse that and go a step beyond: tables/grids solve some non-data layout problems that are either impossible using the rest of the CSS positioning arsenal or difficult enough that it's often not worth it. Frankly, I'm an advocate of just repurposing tabular markup when it makes layout convenient, but that makes some people inordinately cranky, so when IE 6/7 die, going with
display: table-*; would seem to make sense.posted by weston at 7:34 PM on April 21, 2010
Yeah, don't even get me started in using table markup for non-tabular data. ;-)
I'll agree that vertical positioning of content has been problematic, but you've got to keep in mind where HTML came from - it didn't even have inline images at the beginning! Not to go all Rumsfeldian, but we work with the tools we have: grumbling about them makes no difference.
Well, if the "modern" CSS sheet can be 50% or less the size of the "legacy" one
I'm hard pressed to imagine a plausible case where this would be even close to true.
Really, ook? I can save at least 50% in size by using semantic markup and good CSS over old IE-6 legacy code. That's why conditional comments are such a godsend: you don't have to write your IE-only hacks inline.
posted by Bora Horza Gobuchul at 8:05 PM on April 21, 2010
I'll agree that vertical positioning of content has been problematic, but you've got to keep in mind where HTML came from - it didn't even have inline images at the beginning! Not to go all Rumsfeldian, but we work with the tools we have: grumbling about them makes no difference.
Well, if the "modern" CSS sheet can be 50% or less the size of the "legacy" one
I'm hard pressed to imagine a plausible case where this would be even close to true.
Really, ook? I can save at least 50% in size by using semantic markup and good CSS over old IE-6 legacy code. That's why conditional comments are such a godsend: you don't have to write your IE-only hacks inline.
posted by Bora Horza Gobuchul at 8:05 PM on April 21, 2010
Yes, really, Bora.
If you're not stupid about your markup -- which means using thoughtfully placed divs where appropriate, and simple tables where necessary, you don't have to write hundreds of lines of CSS to get IE6 to behave the way you want it to. If you're really writing two separate stylesheets, and the one full of IE6 hacks is twice as large as the default one, you're doing something wrong.
I completely agree with the rumsfeldian point of view that we must work with the tools we have. IE6, infuriatingly enough, is one of those tools, which a substantial percentage of the userbase still uses. If I need to position something vertically, I'm going to use a table, so that not only don't I have to write my IE-only hacks inline, I don't need to write any IE-only hacks, period.
posted by ook at 8:29 PM on April 21, 2010 [1 favorite]
If you're not stupid about your markup -- which means using thoughtfully placed divs where appropriate, and simple tables where necessary, you don't have to write hundreds of lines of CSS to get IE6 to behave the way you want it to. If you're really writing two separate stylesheets, and the one full of IE6 hacks is twice as large as the default one, you're doing something wrong.
I completely agree with the rumsfeldian point of view that we must work with the tools we have. IE6, infuriatingly enough, is one of those tools, which a substantial percentage of the userbase still uses. If I need to position something vertically, I'm going to use a table, so that not only don't I have to write my IE-only hacks inline, I don't need to write any IE-only hacks, period.
posted by ook at 8:29 PM on April 21, 2010 [1 favorite]
If I need to position something vertically, I'm going to use a table, so that not only don't I have to write my IE-only hacks inline, I don't need to write any IE-only hacks, period.
And it's why you're one of the developers keeping the internet in the 20th century.
Look, I can understand using non-semantic markup, such as tables, for presentation, pre-2000. Hell, I'll even give you until 2006. But using it now, for many websites, unless you are working for a sector of industry or government that refuses to update past IE6, is perverse. Why should I kowtow to using non-semantic markup for presentation when IE6 is less than (in my case) 3% of the browsers that visit my sites?
Have you ever gone back to one of those table-based websites and tried to move an image in a cell, even a little bit? How about a design refresh? How did that work out for you?
I'm not talking about hundreds of lines of CSS to get IE6 (let's be clear on version here) to behave. Perhaps two dozen, probably less, maybe with an HTC file thrown in to get it to support standards that have been around for a dozen years.
IE6 is broken. Badly. It was malformed from birth. Personally, I would prefer to take it out the back of the barn to put it out of its misery... but I'll be damned it I will follow its demands to make the Internet worse for everyone else.
posted by Bora Horza Gobuchul at 8:55 PM on April 21, 2010
And it's why you're one of the developers keeping the internet in the 20th century.
Look, I can understand using non-semantic markup, such as tables, for presentation, pre-2000. Hell, I'll even give you until 2006. But using it now, for many websites, unless you are working for a sector of industry or government that refuses to update past IE6, is perverse. Why should I kowtow to using non-semantic markup for presentation when IE6 is less than (in my case) 3% of the browsers that visit my sites?
Have you ever gone back to one of those table-based websites and tried to move an image in a cell, even a little bit? How about a design refresh? How did that work out for you?
I'm not talking about hundreds of lines of CSS to get IE6 (let's be clear on version here) to behave. Perhaps two dozen, probably less, maybe with an HTC file thrown in to get it to support standards that have been around for a dozen years.
IE6 is broken. Badly. It was malformed from birth. Personally, I would prefer to take it out the back of the barn to put it out of its misery... but I'll be damned it I will follow its demands to make the Internet worse for everyone else.
posted by Bora Horza Gobuchul at 8:55 PM on April 21, 2010
And it's why you're one of the developers keeping the internet in the 20th century.
Oh puh-leeze. Yes, I also oppose these newfangled steam engines. They make my goiter itch.
Look, I am in complete agreement with you on the innate brokenness of IE6. I hated Netscape 4 back in the day too. And yet, this year my clients tend to see a much higher than 3% of users still dependent on IE6, and when those clients require me to support it -- which to my glee has finally this year started to be less than 100% of the time -- I do so in the cleanest, most efficient, and most maintainable way possible. This often involves some use of tables for layout.
Have you ever gone back to one of those table-based websites and tried to move an image in a cell, even a little bit? How about a design refresh? How did that work out for you?
Note that I am not proposing a return to the bad old days of multiply-nested tables with dozens of tangled colspans and rowspans. I'm just suggesting treating the table tag -- which has some real layout benefits not otherwise available through pure CSS -- as another useful tool in your markup arsenal. I'm suggesting that we shouldn't avoid using that particular tool for simply arbitrary or fashionable reasons.
And frankly yes, I often find that a partially table-based design is much easier to maintain than a jumbled collection of divs stuffed full of floats and absolute-positioning and negative-margin hacks and * html {} and box model overrides and conditional comments. Don't you?
Why should I kowtow to using non-semantic markup for presentation?
What is this "semantic markup?" What semantic meaning does the word "div" carry? What tangible benefit does using "div" instead of "table" offer you, or the user, or next year's code maintainer?
HTML is a presentational language. The semantic web doesn't exist, and never will. Semantic microformats and other xml schemas will continue to proliferate where they're useful, but no useful semantic language can ever be broadly intelligible enough to cover everything we use HTML for. All the evidence you need for that is in the HTML5 arguments over what "footer" ought to mean, or "aside" vs "sidebar". Or, from the other side, in the history of why HTML doesn't look like SGML. <b> is the same as <strong>, if browsers render them the same way, which they do. Separation of presentation from content does need to happen, but it should be happening at the template layer anyway, long before the content gets dumped into HTML.
Use whichever tags do what you need them to do; that's all I'm saying.
I'm not talking about hundreds of lines of CSS to get IE6 (let's be clear on version here) to behave. Perhaps two dozen, probably less
How, then, are you saving "at least 50% in size" of your css files in your 'non-legacy' code?
posted by ook at 10:17 PM on April 21, 2010 [1 favorite]
Oh puh-leeze. Yes, I also oppose these newfangled steam engines. They make my goiter itch.
Look, I am in complete agreement with you on the innate brokenness of IE6. I hated Netscape 4 back in the day too. And yet, this year my clients tend to see a much higher than 3% of users still dependent on IE6, and when those clients require me to support it -- which to my glee has finally this year started to be less than 100% of the time -- I do so in the cleanest, most efficient, and most maintainable way possible. This often involves some use of tables for layout.
Have you ever gone back to one of those table-based websites and tried to move an image in a cell, even a little bit? How about a design refresh? How did that work out for you?
Note that I am not proposing a return to the bad old days of multiply-nested tables with dozens of tangled colspans and rowspans. I'm just suggesting treating the table tag -- which has some real layout benefits not otherwise available through pure CSS -- as another useful tool in your markup arsenal. I'm suggesting that we shouldn't avoid using that particular tool for simply arbitrary or fashionable reasons.
And frankly yes, I often find that a partially table-based design is much easier to maintain than a jumbled collection of divs stuffed full of floats and absolute-positioning and negative-margin hacks and * html {} and box model overrides and conditional comments. Don't you?
Why should I kowtow to using non-semantic markup for presentation?
What is this "semantic markup?" What semantic meaning does the word "div" carry? What tangible benefit does using "div" instead of "table" offer you, or the user, or next year's code maintainer?
HTML is a presentational language. The semantic web doesn't exist, and never will. Semantic microformats and other xml schemas will continue to proliferate where they're useful, but no useful semantic language can ever be broadly intelligible enough to cover everything we use HTML for. All the evidence you need for that is in the HTML5 arguments over what "footer" ought to mean, or "aside" vs "sidebar". Or, from the other side, in the history of why HTML doesn't look like SGML. <b> is the same as <strong>, if browsers render them the same way, which they do. Separation of presentation from content does need to happen, but it should be happening at the template layer anyway, long before the content gets dumped into HTML.
Use whichever tags do what you need them to do; that's all I'm saying.
I'm not talking about hundreds of lines of CSS to get IE6 (let's be clear on version here) to behave. Perhaps two dozen, probably less
How, then, are you saving "at least 50% in size" of your css files in your 'non-legacy' code?
posted by ook at 10:17 PM on April 21, 2010 [1 favorite]
TBH the big advantage for me from dropping TABLES for layout was never anything semantic, but simply the huge reduction in the quantity and complexity of the tags needed to get anything done - TBALE layouts are nasty to build, but for maintenance they are hell. It's safe to say never looked back on dropping them, though occasionally the odd thing to do with, say, matching the height of vertical columns ina DIV layout will frustrate the shit out of me.
On the other hand, yeah, if you've got something on the page that's clearly a table of information of some kind then using the TABLE tags for it is absolutely the way to go - fucking about with a ton of DIVs and CSS to simulate it - that's just stunty bollocks.
posted by Artw at 10:29 PM on April 21, 2010 [1 favorite]
On the other hand, yeah, if you've got something on the page that's clearly a table of information of some kind then using the TABLE tags for it is absolutely the way to go - fucking about with a ton of DIVs and CSS to simulate it - that's just stunty bollocks.
posted by Artw at 10:29 PM on April 21, 2010 [1 favorite]
Anyone care to advise on how they deal with this sort of pedantic nonsense?
In my neck of the woods, we've (finally!) convinced the visual designers and UED folks that if they want the way-cool features, they're going to have to accept that some browsers won't look exactly the same, because support for those way-cool features is limited. So, following the lead of YUI's A-Grade/C-Grade/X-Grade browser lists, we have A-Grade and B-Grade, where both are tested and fully functional (like YUI's A-Grade) but A-Grade is (almost) pixel-perfect, while B-Grade is allowed any number of undocumented "cosmetic inconsistencies".
It's a toehold, but we had to start somewhere, and in an organization the size of this place, I'm glad we managed to institutionalize even that much.
I got 99 problems but a px ain't one
posted by davejay at 10:33 AM on April 22, 2010 [2 favorites]
In my neck of the woods, we've (finally!) convinced the visual designers and UED folks that if they want the way-cool features, they're going to have to accept that some browsers won't look exactly the same, because support for those way-cool features is limited. So, following the lead of YUI's A-Grade/C-Grade/X-Grade browser lists, we have A-Grade and B-Grade, where both are tested and fully functional (like YUI's A-Grade) but A-Grade is (almost) pixel-perfect, while B-Grade is allowed any number of undocumented "cosmetic inconsistencies".
It's a toehold, but we had to start somewhere, and in an organization the size of this place, I'm glad we managed to institutionalize even that much.
I got 99 problems but a px ain't one
posted by davejay at 10:33 AM on April 22, 2010 [2 favorites]
If you're having URL problems I feel bad for you son
I got 99 problems but a px ain't one
(just had to get that out there)
posted by davejay at 10:36 AM on April 22, 2010 [2 favorites]
I got 99 problems but a px ain't one
(just had to get that out there)
posted by davejay at 10:36 AM on April 22, 2010 [2 favorites]
Until late January of this year, I developed mainly for my personal sites, my coding for institutions having passed with the end of my grad school tenure.
Now I work for a shop whose user base is solidly 10-15% IE6. Many of those users are clients. I have never taken kindly to Microsoft software technology, but I understood the importance of supporting these users given their relative (if minor) numbers.
My day is spent coding on a MacBook Pro switching between our IDE, FireFox 3.6.x for Mac, and a VMWare Fusion virtual machine with IE6 installed. That is, I develop with FF 3.6.x for Mac and IE6 as bookends. Everything else falls in between.
In some way this makes sense, but I find it perplexing because I really would like those bookends to be Safari 4.x and IE 6, but because our user base is ~1% Safari, my supervisor makes the very good point that supporting Safari doesn’t make economic sense.
But I can’t help but feel that coding to the top (Safari 4.x/Webkit) is likely to move standards forward and that the subset of users who use Safari because they think even Firefox sucks are more willing to spend money on good UX, whereas IE6 users will go out of their way to avoid spending anything on good UX, whether they are motivated by necessity, laziness, or stinginess.
posted by mistersquid at 7:27 AM on April 23, 2010
Now I work for a shop whose user base is solidly 10-15% IE6. Many of those users are clients. I have never taken kindly to Microsoft software technology, but I understood the importance of supporting these users given their relative (if minor) numbers.
My day is spent coding on a MacBook Pro switching between our IDE, FireFox 3.6.x for Mac, and a VMWare Fusion virtual machine with IE6 installed. That is, I develop with FF 3.6.x for Mac and IE6 as bookends. Everything else falls in between.
In some way this makes sense, but I find it perplexing because I really would like those bookends to be Safari 4.x and IE 6, but because our user base is ~1% Safari, my supervisor makes the very good point that supporting Safari doesn’t make economic sense.
But I can’t help but feel that coding to the top (Safari 4.x/Webkit) is likely to move standards forward and that the subset of users who use Safari because they think even Firefox sucks are more willing to spend money on good UX, whereas IE6 users will go out of their way to avoid spending anything on good UX, whether they are motivated by necessity, laziness, or stinginess.
posted by mistersquid at 7:27 AM on April 23, 2010
The CSS3 Flexible Box Model looks like it could significantly address a number of layout problems. Still way off in futureland of course.
posted by Artw at 2:59 PM on April 23, 2010
posted by Artw at 2:59 PM on April 23, 2010
Couldn't you just keep IE 6 & 7 out of standards mode, and tell Safari, Opera, Firefox, and IE8 to use the CSS 3 Box model?
posted by weston at 4:33 PM on April 23, 2010
posted by weston at 4:33 PM on April 23, 2010
Nope. But you could use a table; that would work.
posted by ook at 4:38 PM on April 23, 2010 [1 favorite]
posted by ook at 4:38 PM on April 23, 2010 [1 favorite]
We develop to Firefox and then make some very minor adjustments (if any) for WebKit browsers and then make an alternative style sheet for IE 6 and/or 7, but only declaring the styles that didn't quite work right and leaving IE to pick up the rest of the ones that did function from the standard style sheet. Sometimes this is a little as 2 to 5 alternate style declarations, and sometimes more, depending on the layout of course.
As for tables, with the exception of tabular data, I find them to be a huge pain and avoid them for layout. Have only been forced to use a one row, one column (in other words, one entire cell) table once in what must be the last 4 or 5 years, and this was for IE and an issue with vertical alignment (and this is still a weak spot in CSS in general). Getting away from tables was liberating.
That said, there are too many rather odd CSS quirks, as a result of the browsers and poor planning that we just end up getting a CSS guru to code all of our sites and then make adjustments in production as needed. They are extremely efficient at coding CSS (and fast), the files are very small and accomplish so much. Resets are standard in them.
I wouldn't say Safari/Webkit are on "top", but Firefox and Webkit browsers are pretty much equal with weaknesses and strengths varying here and there and updates and fixes rather numerous. I hope to never have to code to a browser whatsoever eventually and that's largely what we do. We code to standards, and then tackle IE. People can use whatever they wish.
Arstechnica and other sources have reported Chrome now has a larger base than Safari, with Firefox second behind the variety of IEs. When I taught CSS to a large bank recently all of them hated the fact that they were still mandated to use IE 6 and mentioned that they were scheduled to move off of it in a year. They implied that their developers were committed to coding to standards so that any browser, in theory, could use the web based applications. I'm optimistic that in 5 years time we'll be in a better place and CSS3 will be settled by then... Another international corporation I do some freelancing for have upgraded their laptops and desktops to Windows 7. This helps tremendously.
Our tracking has IE 6 still rather strong at a range of 18 - 25 percent.
posted by juiceCake at 7:11 PM on April 23, 2010
As for tables, with the exception of tabular data, I find them to be a huge pain and avoid them for layout. Have only been forced to use a one row, one column (in other words, one entire cell) table once in what must be the last 4 or 5 years, and this was for IE and an issue with vertical alignment (and this is still a weak spot in CSS in general). Getting away from tables was liberating.
That said, there are too many rather odd CSS quirks, as a result of the browsers and poor planning that we just end up getting a CSS guru to code all of our sites and then make adjustments in production as needed. They are extremely efficient at coding CSS (and fast), the files are very small and accomplish so much. Resets are standard in them.
I wouldn't say Safari/Webkit are on "top", but Firefox and Webkit browsers are pretty much equal with weaknesses and strengths varying here and there and updates and fixes rather numerous. I hope to never have to code to a browser whatsoever eventually and that's largely what we do. We code to standards, and then tackle IE. People can use whatever they wish.
Arstechnica and other sources have reported Chrome now has a larger base than Safari, with Firefox second behind the variety of IEs. When I taught CSS to a large bank recently all of them hated the fact that they were still mandated to use IE 6 and mentioned that they were scheduled to move off of it in a year. They implied that their developers were committed to coding to standards so that any browser, in theory, could use the web based applications. I'm optimistic that in 5 years time we'll be in a better place and CSS3 will be settled by then... Another international corporation I do some freelancing for have upgraded their laptops and desktops to Windows 7. This helps tremendously.
Our tracking has IE 6 still rather strong at a range of 18 - 25 percent.
posted by juiceCake at 7:11 PM on April 23, 2010
There's a rather neat collection of links in this Reddit comment, mostly JS SVG/CANVAS stuff.
posted by Artw at 10:45 AM on April 26, 2010
posted by Artw at 10:45 AM on April 26, 2010
The Big List of JavaScript, CSS, and HTML Development Tools, Libraries, Projects, and Books
posted by Artw at 2:34 PM on April 29, 2010
posted by Artw at 2:34 PM on April 29, 2010
A brief history of markup - Jeremy Keith, author of DOM Scripting and Bulletproof Ajax, takes us through the history of HTML, from Tim Berners-Lee's first few tags to HTML5, in the first chapter of his new book, HTML5 For Web Designers.
posted by Artw at 4:24 PM on May 9, 2010
posted by Artw at 4:24 PM on May 9, 2010
« Older Total Protection ... from a usable computer | I think it's time for debate. Newer »
This thread has been archived and is closed to new comments
posted by colinshark at 12:43 PM on April 21, 2010 [2 favorites]