Web development , php , ajax , symfony, framework, zend
In: web resources
11 Mar 2010Editors Note: In his first article for Think Vitamin Thierry Koblentz discusses the issue of “resetting” your CSS.
For a long time, the very first line in my styles sheets was:
* {padding:0;margin:0;}
This simple rule was very convenient as it leveled margin and padding values of all elements across browsers. This “hard reset” was short and simple and it had the advantage of belonging to the main styles sheet rather than being an external file.
Later, this technique was denounced as bad practice as it makes the rendering agent style (check) every single element in a document. It also triggered issues with form controls, but authors were used to specifying styles for these.
Then came “reset” styles sheets. These files go way beyond resetting margin and padding. The most complete in terms of properties/elements involved has to be Eric Meyer’s. It “unstyles” everything you could think of, from a to var.
Authors start with a clean slate. From there, they most often write rules to style elements that were originally styled by the browser’s styles sheet, but overwritten by the reset file. In short, many elements are styled three times:
Jonathan Snook, Jens Meiert and others have “criticized” this approach, saying more or less that there was no use for a “middle man”. On Jen’s site, “randomCommenter” summarizes the issue pretty well when asking: “Wouldn’t a well written base style sheet render a reset style sheet redundant and therefore useless?”
Actually, I believe Eric Meyer himself hints in that direction when he says:
“I don’t particularly recommend that you just use this in its unaltered state in your own projects. It should be tweaked, edited, extended, and otherwise tuned to match your specific reset baseline. Fill in your preferred colors for the page, links, and so on. In other words, this is a starting point, not a self-contained black box of no-touchiness.”
In any case, people should at least evaluate the rules in these reset files before copying and pasting their content. For example, if one authors documents as HTML 4.01 Strict! one may safely remove from a reset styles sheets any reference to elements like:
Following the idea of “tweaking” a reset file, I came up with this “base styles sheet“. It sets default styling for many elements, follows a couple of recommendations regarding usability/accessibility, and addresses a few “common issues” as well.
What does it do that a reset doesn’t?
It fixes a few things
It styles lists by default
It is easier to remove markers on lists than to style them. So, by default, lists are styled to show indentation and markers depending on hierarchy and list types. But the styles sheet contains a class to reset this styling. When applied to a UL or OL – it will remove markers and left margin on their items.
It creates vertical “gutters”
Left and right padding are applied to most block-level elements to create vertical gutters. This allows to build layouts without having to use “padding” on main containers which helps to produce designs that do not break in IE 5 (or IE 6 in quirks mode) as width and padding values are not mixed. This is also an alternative to using non semantic wrappers as a workaround to avoid mixing these properties.
Why using padding instead of margin to create that space?
Using padding allows to paint elements’ background all across their parent container. Stretching from one edge to another. When this behavior is not seeked, for example when styling a heading with a bottom border that should be no wider than what appears to be the “content box”, authors can use a class (in the sheet already) to revert that styling (swaping padding values with margin values).
It creates horizontal white space too
Rules in this base styles sheet are well commented and values that one would like to change (font-family, font-size, line-height, color, padding, etc.) are placed near the top of the file.
You can download base.css with comments or a minified version. My advice is to use these rules as a starting point to create your own styles sheet. Do not link to an external file to then override property values, instead, add, remove and edit anything you want to end up with a main styles sheet for your own project(s).
My base.css styles sheet is a work in progress. If you play with it, and if you see things that should not belong in there or to the contrary things that should be included, please join the discussion.
1 The YUI reset styles sheet sets a background-color on html. This styling makes the browser paint the background of body no taller than its content instead of matching the viewport’s height (this is by specs). I believe a future release of YUI reset will include this change.
In: tutorial
3 Oct 2009Style Sheet switchers (or "colour theme choosers") are not really that new. Apart from that fact, they still are pretty fun to use and cool to see. I was wondering how jQuery could help me achieve this technique. While searching, I came across several solutions.
There is a problem when using these techniques, which I will explain later. I created a little work-around to create a better jQuery stylesheet switcher. We’ll simply change some colours for the user!
Make sure to check out the demo to view what we’re trying to accomplish.
The cute little monsters used in the demo are created by Fast Icon (Dirceu Veiga). Now, let’s take a look at how you can create something like this yourself!
In: web resources
24 Apr 2009I’ve been thinking about this for a long time and while I thought I had a solid opinion on the matter, I find myself waffling on the issue.
If you haven’t done so, I highly recommend cracking out a copy of Firefox 1. Start bouncing around to a few sites and check out what’s broken. Sure, most stuff is fine but you’d probably be surprised at what’s broken. What about Firefox 2? I have more people using this old version of Firefox than I do of all Opera users put together. These are browsers that I don’t check my site in any more. In a way, it’s like they don’t even exist.
As web browsers have progressed, we’ve increasingly gotten to the point where we just ignore old browsers like they don’t exist. No more testing, no more hacks, no more nothing. Who knows what it looks like? Is it good, is it bad? Does it even matter?
My initial stance was that every browser mattered. It doesn’t matter if they’re coming in with Netspace 1.0 or Internet Explorer 3. These people are armed with a browser and they deserve content. No, they don’t get any CSS, or maybe a limited amount. Only the recent browsers get the good stuff.
We draw a line in the sand that says, "You popular browsers, stand over here. Everybody else, just be happy you got content."
More specifically, a base style sheet would declare some default font styles but no float or other layout tricks. Just linear content. This default would look decent in any browser, no matter from what era. It makes a great print style sheet, too.
Then, for those cool, fancy browsers that we know and like, we give them the good stuff. The whole enchilada.
Two major issues here:
With Internet Explorer, it’s really easy: we have conditional comments that we can use to target specific versions. Now for the rest of them? Unfortunately, the best way (that I can think of) is to use user agent sniffing on the server to serve up the extra stylesheets only if the visitor has a browser within the subset that we find acceptable.
On that second point, what happens when a new version comes out? Or somebody says they’re "compatible" with another engine and your user agent sniffing serves up something limited. Basically, it becomes difficult to future-proof something for any length of time.
My pragmatism comes into play, like that little devil and angel on my shoulders telling me each side of the story. The fact is, these are old browsers. Why haven’t these people upgraded? Why are all these people still using Firefox 2? So what if it’s a little (or a lot) broken for them. They should upgrade.
Obviously, Internet Explorer 6 is the oddball here. She’s that awkward girl who doesn’t understand social cues and realize that the party is over. It’s the elephant in the room, as it were. Too big to ignore. But right! We have a way to target IE browsers by version. We can use our conditional comments to tailor for IE6 until it disappears. We can feed it the limited CSS and let everybody else get the fun stuff.
When it comes to market support, I’ve often looked at it as one big pie. You may say that Opera is too small to really care about. It’s only 2%. You don’t care about Firefox 2 users. It’s only 2%. You may not care about accessibility issues. It’s only 2%. Soon enough, you’ve whittled down your potential market to 90% of what it could have been.
Every site, whether it be for personal or professional reasons, needs to mark that line in the sand. If you’re running a content-heavy, large traffic site targetting a less than savvy crowd then maybe IE6 and FF2 support is critical. You want to capture as much of the market as you can. If you’re running a niche blog focused on tech issues then even IE6 might be safe to put on the ignore list.
But all the while, I’ll keep thinking about all those people I could be getting. Did they walk away with the best experience? Sometimes it hurts my head just to think about it. So now it’s your turn: Should we care about old browsers or fringe browsers? Or are we safe in our little bubble?
This blog delivers stylish and dynamic news for designers and web-developers on all subjects of design, ranging from: CSS, Ajax, Javascript, web design, graphics, typography, advertising & much more. Our goal is to help you communicate effectively on the web with an engaging website or functional interface.



