notes from Nicole Sullivan’s talk “Using Flexible Boxes” at AEA2011SF
things to avoid:
float (too many means you don’t have an abstract layout mechanism)
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+)
%’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.
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
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
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)
universal selector – specificity of 0
[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.
- 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”
- September 2014
- November 2013
- October 2013
- February 2013
- October 2012
- September 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- October 2011
- September 2011
- August 2011
- July 2011
- July 2010
- April 2010
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- January 2009
- December 2008
- October 2008
- September 2008
- August 2008
- April 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006