by Shay Howe at HTML5 Texas Conference in Austin, TX (Deck)
There are a million ways to write HTML and CSS, and everyone has their own, but is there a right way? Our code needs to be well structured, written in an organized manner, and performance driven. Sharing code with others should be a joyful experience, not absolute terror.
In this session, Shay will cover some best practices and performance tips for writing the highest quality HTML and CSS possible. Writing code is the easy part, finding a practice and structure that works well across the board is the hard part. Shay will outline HTML and CSS conventions that can be applied to your everyday practice.
- Websites have difficulty scaling
- code becomes brittle
- Files and code bases begin to swell
Best practices aren’t exactly best practices
- avoid extra elements
- avoid classes
- leverage type selectors
- leverage descendent selectors
We code so specifically (leveraging selectors) that we can’t make the changes we were trying to code for
- Specificity determines which styles are applied
Code must be…
- stop thinking about pages
- Core styles for entire site
Normalize (reset), default elements, grid, variables
- User interface concepts & design patterns
Alerts, buttons, forms, lists
- Business logic
Aside, Header, Footer
Your goal over time should be to not write css and just write HTML and see how the styles are automatically applied.
Looking at rdio site for modularity
We put a lot of effort into our properties and values, but not so much on our selectors.
- use a grid
- separate presentation (or theme) from layout
code for reusable elements
- remove the container element selectors
- Use selectors instead of elements
Great ideas on using classes to really separate content from layout
- be explicit
- keep specificity low
- Never use IDs or !important
- avoid nested selectors (minimize)
count IDs, Classes/Pseudo-classes/attributes, Elements
High Specificity (bad)
Low Specificity (good)
- write understandable class names
- avoid unnecessary nesting
- use same strength specificity
Object-Oriented CSS (Nicole Sullivan – oocss.org)
Scalable and Modular Architecture for CSS (Jonathan Snook – smacss.com)
- Do not duplicate code
- remove old code
- defer loading subsequent styles
- combine lide files
- use image sprites (use caution)
- use data URIs (difficult to edit)
Compress & Cache Files
- utilize gzip compression
- losslessly compress images
- cache common files
HTML5 Boilerplate includes compression and caching
- Build a styleguide (Twitter Bootstrap, Zurb Foundation)
- Review Methodologies (OOCSS, SMACSS)
- Test your code (CSS Lint, Inspector, PageSpeed)
Here is a video of the talk.
Umber code says
I am currently trying to create a workflow for myself that involves modularity. True modularity. This means (to me) that each module consists of it’s own html (or php), css and js. This module should be able to function on itself (when it is not part of a bigger whole) because one aspect that is never mentioned is that modules should be framework agnostic. It should not have to matter if I use the module in WordPress, Yii, Joomla, phpCake or whatever.
There are 2 main problems I encounter.
1) Since styles need to be modular by itself, (the module must be styled according to the project needs) it must be possible to override the included styles in the module. CSS cannot do such a thing (unless we use !important for every style) and while e.g. sass enables us to override variables, it does not allow us to do so with mixins or functions.
I see an increasing amount of articles covering modular design, but they all seem too theoretical to me not aimed at true practical applications?
Jonathan Jeter says
Thanks for posting your comment. I need to take another look and maybe it will result in another blog post.