101–110 of 122 posts
Earlier quoted context omitted.
What about an ID for main page elements and things that never will change like #header or #footer or #sidebar?
Ideally for those you would use the html5 header, footer, and aside tags, respectively. You can use the html5 Javascript shim to enable support for those tags in IE.
Eg. Files would be something like:
* reset * global (eg header/footer) * common (stuff used most places but not all, eg. forms) * specific to section of the site * specific to the page
After reading all comments it seems there is no (universal) solution to write good HTML/CSS code. Not like in Ruby or Python or other programming languages.
Since this year I'm struggling to create a post / best practices how to code front-end but the problem is too complex (for me).
The biggest issue is how to mark up HTML to have a DRY (minimal) CSS. And how to remember easily these mark up rules to be able to maintain anytime in the future your CSS/HTML.
If you would elaborate your naming / marking up best practices instead of suggesting frameworks/tools maybe that would help better.
I have four core files: reset.css - I use eric meyer's elements.css - Global defaults for things like body, h1, h2, h3, p, a, input, strong. All or almost all selectors in here are just tag names. layout.css - Just sets up the global layout with containers: e.g. header, footer, left column, right column. blocks.css - Reusable chunks. In addition to that, I use a separate file for each "page type". For example, 'artic…
What would you put in chunks.css? Could you maybe provide a brief example?
For a website: callouts, user quote styles, tables styles [zebra stripes, etc.], feature lists, intro paragraph styles, Flash/message styles, common control styles, etc.
I can't recommend Compass/Sass highly enough. A CSS pre-processor will completely free you to organize your CSS however you want, and more importantly, it lets you build up a library of common components (forms, buttons, etc.) that you can easily reuse and adapt for new projects. Generally, these library files will simply contain mixins (reusable chunks of code), so they don't output anything directly into your CSS,…
I do this, but with a slight tweak: instead of naming the colors things like $red, I try to give them semantic names like $shadow, $highlight, etc. in case I end up having to pick a completely different color scheme.
Sorry guys, After reading all comments it seems there is no (universal) solution to write good HTML/CSS code. Not like in Ruby or Python or other programming languages. Since this year I'm struggling to create a post / best practices how to code front-end but the problem is too complex (for me). The biggest issue is how to mark up HTML to have a DRY (minimal) CSS. And how to remember easily these mark up rules to be…
2. Only use the minimal selectors you need: div#features ul.feature_list li.feature a{color:red;} could be DRYed up to be .feature_list .feature a{color:red;} which will be far easier to override later.
3. Avoid !important at all costs (sometimes you can't, but try).
4. This is personal taste, but I also usually avoid IDs for styling.
5. Grid frameworks (Blueprint, etc.) are usually overkill, but syntax frameworks (LESS CSS, Compass) are fantastic.
It really boils down to experience, and knowing what you DON'T need - most people add in a ton of extra cruft and end up with hard to extend and debug spaghetti.
Sorry guys, After reading all comments it seems there is no (universal) solution to write good HTML/CSS code. Not like in Ruby or Python or other programming languages. Since this year I'm struggling to create a post / best practices how to code front-end but the problem is too complex (for me). The biggest issue is how to mark up HTML to have a DRY (minimal) CSS. And how to remember easily these mark up rules to be…
1. Separate presentation from layout. For example, all common layout (margin, padding, display, positioning, floats) go in structure.css and color, border styles, background, etc. go in presentation.css. It is far more likely that you will be making presentation changes going forward rather than to your core layout. 2. Only use the minimal selectors you need: div#features ul.feature_list li.feature a{color:red;} coul…
I have a navigation list which I want to display horizontally as a menu bar. In plus I want to highlight the current element with jQuery.
How to mark up this list? My immediate answer would be this:
...
The rule for marking up in this case would be:
* use #ID whenever you want to locate an element
* use .class whenever you want to alter the display of an element from the standard
Natalie Downe, my co-founder, has a very neat technique for organising CSS which she calls a CSS System. She described it in this talk: http://lanyrd.com/2008/barcamp-london-5/sg/ She splits everything in to general styles (basic HTML elements), helper styles (things like forms, notifications, icons), page structure (header, footer, layout columns etc), page components (reusable composable classes for components that…
I checked the lanyrd.com stylesheet. I'm sorry to say but if your stylesheet is this big you are doing it wrong. 100K for a compressed stylesheet! So I'm not so sure her technique is a winner.
Don't worry, I'm sure all those developers are "doing it wrong" too.
I haven't used it, as there just hasn't been a project with enough lead time to experiment with something lately, but I'm fond of the idea of code generators for CSS, like CleverCSS for Python and Sass for Ruby. Other than that, the best advice I can offer that I DO follow is that I group all HTML elements together, all IDs together, and then all classes together. Within each of those groupings, everything is in alph…
one thing to do is to place class names based on the url with your id's. the class name can be generated from the request_uri (assuming the html code is in a view/template/include).
example:
then if you need tweaks to a specific page, just add #container.contact_us { foo: bar... }
Earlier quoted context omitted.
1. Separate presentation from layout. For example, all common layout (margin, padding, display, positioning, floats) go in structure.css and color, border styles, background, etc. go in presentation.css. It is far more likely that you will be making presentation changes going forward rather than to your core layout. 2. Only use the minimal selectors you need: div#features ul.feature_list li.feature a{color:red;} coul…
Okay, let's see a simple example. I have a navigation list which I want to display horizontally as a menu bar. In plus I want to highlight the current element with jQuery. How to mark up this list? My immediate answer would be this: ... where .inline-list will transform this list to be displayed horizontally and #navigation will help to add jQuery on it. The rule for marking up in this case would be: * use #ID whenev…
...
$('.main-nav.inline-list a.selected').highlight();
//Each time you add another instance, you have to add its new id/selector (not very DRY)
#navigation.inline-list li,
#navigation_b.inline-list li{float:left;}
$('#navigation.inline-list a.selected, #navigation_b.inline-list a.selected').highlight();
The times I use ID in my markup is more for sub-navigation through the page rather that styling-specific reasons.
Two
Got to Ch. 2