Step 11 should be: If you don't have an element to clear out the bottom, you can get limited functionality by applying
overflow: hidden
to the containing element. In most cases this will cause it to extend and prevent the inner elements from bleeding out. In some edge cases it will cause them to be hidden, though.
There is one case in which I don't know how to do away without extraneous presentation divs: I want a 2-columns layout where the left column is written after the right column in my source code. Good for my eye (navigation on the left) and for search engines and text based browsers (relevant text first).
Right now, my div structure looks like this:
<body>
<header />
<div-hackw>
<div-hack1>
<div-hack2> <article /> </div-hack2>
<nav /> -- written after, displayed on the left
<div-hackw>
<footer />
<body>
Header, footer, nav, and article are okay (they eventually will be actual html5 tags). Hakcw, hack1 and hack2, however, are ugly. Does anyone know of a way to ditch them ?
This layout is source ordered (header article nav aside footer), liquid, and the side columns have a fixed width. You can easily do the same thing with 2 columns only. The only drawback left is the fact that I can't force the columns to share the same height. As far as compatibility is concerned, I think an html 4.1 version will work on any relevant browser. So I think I found my ultimate layout. At last.
I fail to see the use of CSS frameworks (and yes, I have tried most of them).
Honestly, in my experience:
- The time you invest in learning the ropes of that framework would be better invested in properly learning CSS. I wouldn't say this of any framework in any language, but CSS is easy and, contrarily to what I constantly hear, it isn't that hard to master.
- Once you know CSS well, it's much faster to convert a PSD by hand than trying to make it work with your framework. The more detailed the actual design, the more this applies.
- The only pseudo-framework that actually boosts styling speed is leveraging a well-maintained css reset stylesheet.
Keep in mind that this is coming from somebody that knows CSS well... I understand why a framework sounds appealing, especially since we have a lot of them on the development side, but in the case of CSS, it is total overkill.
I've been using CSS off-and-on pretty much since the first browsers started supporting it; I too struggle to see the point of the frameworks I've tried. There's only one thing I have trouble with: maintaining clean & tidy CSS once a site grows beyond a certain point. Details get changed, which causes classes, etc. to be forked, rules don't get deleted because it's not clear if they're really unused, etc.
Do you have any advice for dealing with this? I feel there ought to be some way of semi-automatically "refactoring" style sheets, or keeping them compact and neat to begin with, but I haven't yet found it.
Frameworks are just reusable classes, this is most valuable when they're your own reusable classes. Coupled with something like less or sass to extend CSS to allow mixins, having parameterized reusable classes is awesome.
The problem with other peoples frameworks is, well... they're other peoples frameworks. Develop your own and you'll love it. Such frameworks allow you to factor your CSS and eliminate repetition and patterns you use often.
Personally I cannot stand frameworks for css. They completely screw up the default styles, and make it much harder for other developers to quickly make css changes to a site.
CSS frameworks are different from other programming frameworks because it overwrites defaults. It is equivalent to something like overriding printf in c to do add an extra character at the beginning. Its just ridiculous.
You know that's on purpose, right? Different browsers have different defaults. Therefore, the easiest way to ensure consistency is to start from a clean slate and be explicit.
Yes, thats the problem. When I add an h1 tag, I expect some defaults such as display:block, margins and padding. When I add a p tag it should NOT work the same as just adding br tags. I should see the default spacing between paragraphs.
I'm sold on CSS resets. When I add an h1 tag, I expect it to be styled exactly the way my CSS styles it, and nothing else (e.g. a default 1em bottom margin in some browsers but not others).
No, the easiest way is just to be explicit.
On the other hand, trying to chase pixel perfect look in different web browsers is just a waste of time these days,
so having slight differences in whitespace is OK, imho.
I can't stand trying to figure out a 4 column layout that works in most browsers. Also, there are really lightweight frameworks that don't touch default text and form styling.
If you leave off the doctype, you are put into quirks mode, in which browsers try to emulate bugs from the Netscape 4 and IE 5 era.
The biggest difference is probably the IE 5 box model (also called "traditional box model" or "border box"), which doesn't comply with the standard CSS box model. In the IE 5 box model, the size of boxes includes their borders and padding, while in the W3C box model, the size of boxes includes only the content of the boxes (the IE 5 version actually makes more sense, but it's not what's in the standard). In later versions of IE, the standard box model is used, but only if you're in standards mode; the IE 5 model is used in quirks mode. Nowadays, almost all browsers support a CSS3 property, box-sizing that can control which box model to use, so you can actually enable the traditional box model in a standard way (though it's prefixed -moz-box-sizing or -webkit-box-sizing in Gecko and Webkit, as that's the preferred way to implement standards that aren't yet finalized)
For more detail on the differences between quirks and standards mode, see:
For a quick overview / intro, this is excellent. Fast, to the point, and clean. I wish I had this when I started.
Of course, with only 9 effective steps of a single demonstration, it's rather lacking in completeness. But that's not its point, and I love all the links in this thread. Loads of good stuff :)
Yay! Just what the readers of Hacker News love to read… basic CSS tutorials! Can we have a "how to get amazing mouse cursors with JavaScript" one, too?
Sure you might know CSS inside out, but I'd be willing to bet some people here could learn something useful out of it. The rest of us that already are familiar with it get a quick refresher in under 5 minutes.
Positioning and the box model are at the core of understanding CSS layouts. Sure it's not the next cool thing and it certainly isn't advanced, but I'd much rather browse a Web where people understand layouts properly, than one filled with a lot of the trendy, over-complicated crap that fails at the basics.
We have to be careful with that basic = not challenging = not geek-worthy attitude. A beginner reading HN comments will most likely emulate it and miss out on the important stuff.
judging by the points it does look like what hacker news wants to read, but we can always do with less snark.
This looks like the best example I have so far to pass along to people asking me about css, which happens quite often.
That aside CSS is messy and complicated, lots of programmers dont understand the basics, and even experienced developers can easily miss a few very useful tips.
I think CSS itself isn't so complicated, but the whole different support in different browsers thing certainly does make a mess of it!
One of the most helpful things I ever did with respect to CSS was read the apress book on html/css patterns (just ignore the parts that use javascript).
If the reader doesn't know basic CSS - a definite possibility, remember - then this is concise and programmer-friendly.
If the reader does know CSS, then they're probably asked "can you make this for me?" by everyone and their extended family, and this is concise and has immediate, clear examples to make it newbie-friendly. I wouldn't dare throw a big CSS book at a non-programmer new to CSS.
