notes from Nicole Sullivan’s talk “Using Flexible Boxes” at AEA2011SF
things to avoid:
!important declarations
float (too many means you don’t have an abstract layout mechanism)
font-size
myth: pixel-based font sizes are naughty.
why did we stop using pixels for fonts? (IE6 didn’t allow you to re-size pixel-based fonts)
bc with ‘page zoom’, pixels, em, and %’s can all be resized (IE7+)
takeaways:
%’s and em’s have drawbacks for predictability. nesting messes it up
px-based fonts can be resized
check how many ie6
only use %/em’s on body and “leaf nodes”
myth: don’t add any extra markup
separation of concerns. “process of separating a computer program into distinct features that overlap in functionality as little as possible”
the module body plays an important role.
takeaways:
solve one problem at a time.
add mark-up judiciously,
don’t cause bugs just to eliminate a div or two
myth: the more semantic the better
css is coupled too tightly to the style – mixing things up that don’t belong
class names & ids are not read by accessibility devices, not read by search engines, not read by users
more is not always better
css is coupled too tightly to the content – mixing things up that don’t belong
DRY – don’t repeat yourself
if you find yourself solving the same problem over and over, you need to create an abstraction
“Media Block”
unabashedly visual, but class names are abstract enough
what do we know about this media block?
- can it be nested?
- does it have a close button?
- does it have a clearfix?
what don’t we know about this media block?
- is the image width and decoration unique for each implementation?
- is the content known?
- is the width known?
need to separate structure from chrome
takeaways:
choose good semantic elements: headings, list, paragraphs
css shouldn’t be tightly coupled with display nor content
think abstract (visual represendatations of our repeating patterns)
“understanding specificity”
universal selector – specificity of 0
* { ... }
concatenating specificity
[inline, id's, classes, elements]
0,0,1,0 is less specific than 0,0,0,10
specificity grows over time (cruft!)
difficult to tell which rules take precedence
developers end up coding by firebug
!important adds another layer of specificity
[inline !important ] [ids !important] [classes !important] [elements !important] – [inline] [ids] [classes] [elements]
creates a hostile coding environment
“hostile code environment”:
- Two layers develop
- Specificity grows over time (more and more rules become impor tant).
- Even more difficult to tell which rules will take precedence Developers always code by firebug
- Eventually, it becomes impossible to get the look and feel you want.
takeaways:
- Classes are far more flexible & reusable
- Keep specificity as low as possible
- Avoid the descendent selector
- Make reusable website “lego”
- Add classes to the element you wish to change rather than a parent node.
“GREAT DEVELOPERS CAN BUILD AMAZING THINGS
if we move worst-best practices out of our way”
-@stubbornella
If you enjoyed this article, please consider sharing it!
