CSS Positioning 101
alistapart.com
alistapart.com
[0]: http://www.barelyfitz.com/screencast/html-training/css/posit...
would be nice to see it called out as one of the core techniques above though. or I guess I could have just read the whole article before commenting :)
"You can set an element to top: 100px and left: 200px; and that element will sit exactly 100px from the top and 200px from the left of the document."
Which seems misleading, despite the example they show later.
1) "Fragile" layouts, where simple changes break the entire UI.
2) Broken javascript - as an eample, jQuery-UI uses the positioning in the DOM to calculate where to display some UI elements. Mixing relative and absolute positioning breaks these functions.
I've got a few friends who extol the virtues of inline-block, but my clients have viewer demographics of 70% ie6.
Hack here, if you really want inline-block with ie6: http://www.aaronrussell.co.uk/blog/cross-browser-support-for...
Section 9, "Visual formatting model" is especially useful: http://www.w3.org/TR/CSS2/visuren.html
.smth{
position:absolute;
top:0px;
left:0px;
right:0px;
bottom:0px;
}
It beautifully solved 2 interfaces I was working on (webapps with fluid widths). I remember being smiling for 2 hours after discovering this.Not sure about IE support though, i think its covered from IE8 and ahead
I really wanna cry... Please implement a cookie based autosave for comment forms :'(
Briefing of my hardworked comment that will never be read: -----------------------------------
I know about the px thing.
Fluid interfaces and traditional box model are wrong because padding and border mess things up You cant substract % - px, and % in width and height is calculated without taking in account border and padding.
I gave an example (wont rewrite it again)
I gave a few solutions: * extra markup inside the boxes with % ( ex. div.absolute>div.padding20>content ) Ugly and unsemantic, but usable * using positioning top/bottom and left/right for defining widths and heights This only works if you define boths of properties, anyway else if you specify width/height with padding/border it screws you * use new CSS3 box-sizing property Not compatible in all browsers, but maybe the best option thinking to future
Links to ilustrate: Traditional box model http://www.w3schools.com/css/css_boxmodel.asp Optional box models http://www.w3.org/TR/css3-ui/#box-sizing
I also said that a webapp like google calendar would benefit from this things, right now in chrome it gives me 2 scrollbars on the right side, one for the body and another one for the calendar pane.
Uh and heights is crappy because an element only expands to 100% height if parent is 100% height, anyway else it doesnt do shit. This is pain in the ass, redundant and messy between browsers.
Better option is to specify each box coordinates and anchors (and subsequently width and heigth) with position absolute top/left/right/bottom and then define padding without having troubles.
If somebody asks more i will jsfiddle some examples
I've found no better way to learn these details than just opening up a text file and browser and trying out my own wacky layout experiments.
It's even more fun with other devs! Modify the CSS/HTML in different ways and take bets on how it will look before hitting refresh.
When in doubt, go back to the specs and find your explanations there! http://www.w3.org/TR/CSS21/visuren.html#propdef-position
I've been unable to find a good introductory Photoshop book.
Do you still write css for layout?
Whether you're using 960gs or whatever it may be, you still need to be considerate of position and "write css for layout".
If you find yourself always using grid layouts, not just as guides but as the way to lay out everything, then you will soon find yourself caged inside that grid.
If you don't stick with the grid the framework provides you are just writing custom CSS anyway, at which point you probably wonder why you have another CSS file with lots of code that you are only using 50% of the time and that comes with it's own maintenance issues that you don't need.
I would also argue that from a maintanence point of view, semantically smart class and id names make it much easier to work with compared with a page full of "r3 w50 h10" type attribute properties.
To stick my flag to the mask, I hate CSS "frameworks" with something of a mild passion. CSS is too domain (domain in this sense I guess is a synonym for project) specific and abstract to benefit from a framework, you are much better keeping it lean and tidy and owning every line you write, because CSS is the kind of language where you should justify every line to yourself.
Bypassing those niggling pita xbrowser/ie6 issues with just a 'git clone' is clutch.