Tag Archives: development

Structure your CSS

One of the most annoying things in the world is editing someone else css code. Css in it self is not very structured and doesnt make a hole lot of sense without comments and document structure.

To get this working in our development environment we need a set of rules.

  1. Always use tabs. I prefer 4 spaces using tabs
  2. Use a naming convention that describes what the element does and contain. Not on what page it appears. No more .frontpage-mywidget {}
  3. Split up css in multiple files. One for layout and one for widgets. By multiple files i dont mean 4,5,6 or 7. Keep it simple!
  4. Keep your widths and padding off each other
  5. Use YUI Reset!

To go through some of these rules, let me show you some examples.

1. Use tabs!

Tabs makes css so much more easier to read. Dont write long lines like this:

See what i did there? Even though background: #fff might might make sense background-color is way more describing. Oh yeah, and the tabs. If your scared that your file might end up big and bulky you could always compress it using PHP.

Tabs also makes it easy grouping information. Say you have a widget called login. The frame for .login might not have any styles but the items underneath have. To easy the reading do something like this:

That way you can easily read what belongs to what and also get a sense of the markup structure. Easy right?

2. Naming conventions

One of the hardest things in css is to reuse your classes. Imagine your page might have a widget section on the frontpage but also on a subpage, though the subpage is slightly bigger. Maybe you want all your widgets to follow the same structure, both in markup but also follow some some generic rules.

Take this markup for example:

The naming conventions should be pretty straight forward, and the css pretty much writes it self right? If not keep reading!

The html and css pretty much match exactly and you can read the html from the css, and the css from the html. The great thing about this is that it’ll make perfect sense for new developers to continue where you left off.

3. Split css in files

Removing layout and grid like things from the rest makes it easier to read and also more manageable. This can be done in a numerous ways. Its up to you really but something like layout.css, widgets.css and blocks.css isnt a bad start.

4. Widths and padding dont play nice

Widgets are a dangerous thing and “should” not be merged with classes containing paddings. Its a hard rule to follow but it makes it so much easier doing flexible code. Remember divs are block elements and will fill out the containers width. If a div doesnt have a position, it’ll always be relative to the element above or its container. Though if your element is absolute, it’ll position it self to the first parent element with position:relative defined. When defining absolute as position the browser might position the element relative at first. To “fix” this add top:0px; left:0px; to move it to its absolute position.

5. YUI Reset

Theres a bunch of css resets out there. One might be better than the other but ive found that YUI’s method is quick, clean and easy. It works great and makes html render very much the same way in every browser.

Debugging php can be a hurdle

Debugging PHP can be a hurdle. Specially if you dont have access to something like XDebug. A great way to solve those things is by reading the log files PHP and Apache is generating. One way is enabling error logging in htaccess like this:

[code]
php_flag log_errors On
php_value error_log /home/ranza/Sites/project/logs/php_errors.log
[/code]

Of course you need to create the php_errors.log file and set chmod to 755