Over 4 years ago, Alan Burke noticed that Drupal didn't have any CSS coding standards. He asked the documentation team lead at the time, Addison Berry, for advice and she suggested that if they wrote the first draft of the CSS coding standards, that would get the ball rolling on discussing them. The goal being to write, iterate and come to consensus on Drupal’s coding standards. See http://groups.drupal.org/node/14421 for the original discussion.
Unfortunately, its 4 years later and the CSS coding standards are still marked “Draft”. http://drupal.org/node/302199
Fortunately, there are now some great external resources for CSS coding standards. I've taken Drupal’s former draft and combined it with other resources, added a sprinkling of new Drupal 8 features and come up with a new expanded DRAFT version of our CSS standards:
DRAFT - CSS coding standards for Drupal 8.
So that we can actually move from DRAFT to consensus, I'd like to timebox this discussion to 2 weeks today. All comments should be in by January 30, 2013! Hopefully, by then we'll have reached consensus on most items. Any item that we haven't reached consensus on should be removed from the standard.
Speak up!
Comments
Shared values
One thing I'd like to point out is that we have standards, not simply because we have to agree on stuff. But because Drupal’s culture has shared values. And our standards should be based on preserving and promoting those values. I tried to describe the values behind the rules as I wrote this draft of the standards.
I recently read an article (with a linkbait-y title) called “The Process Myth” that talks about infusing documentation with the values/rationale behind a process' rules. That article really shaped my thinking on writing standards documentation. I highly recommend it: http://www.randsinrepose.com/archives/2013/01/01/the_process_myth.html
- John (JohnAlbin)
CSS Declaration order
Wow, thanks for having a more common sense version already in the draft. The current guideline having everything in alphabetical order always felt out of place.
Awesome! Sincere thanks for
Awesome! Sincere thanks for doing this, John.
I love all of this with the exception of one thing: Sectioning comments. I prefer to use multi-line doxygen-style comments for sections. I really dislike long lines of characters:
/* ==========================================================================Section comment block
========================================================================== */
I would much prefer it if we used regular multi-line comments, with a blank line below:
/**
* Section comment block.
*/
/* Does something cool. */
selector {
property: value;
}
fs.io
drupalcontrib.org
Don't the long comment blocks
Don't the long comment blocks make the sections easy to find and read, when scrolling through a long document?
Category Names
Awesome work on this.
I like the idea of categorising like this (I have been taking a SMACSS approach to my CSS for a while now). Just wondering, since modules/themes are very Drupal related, would it be worth looking at changing the names to something like components/skins?
I only say this as developers I work with have gotten a little confused because of its Drupal counterparts, I could explain it to them, but I wonder if this would confuse others?
http://lukebrooker.com
Pattern
"Pattern" might be another word for module to not confuse with drupal module.
Awesome work, John.
Improvements to clarity
At first this seemed to imply that all property values must have double quotes, but based on the example below I believe it only refers to situations where quotes are required.
font-family: Times, "Times New Roman", sans-serif;Perhaps this could be clearer, as I was about to start writing something like this:
font-family: "Times", "Times New Roman", "sans-serif";Quoting for every font
Quoting for every font without whitespace isn't good practice, because generic font names (such as monospace) are keywords and should not be quoted.
Source: http://www.w3.org/TR/CSS2/fonts.html#value-def-family-name
Re: Quoting for every font
I don't think anyone is suggesting that each font should be quoted. I was just saying that the documentation seemed unclear.
Definitely worth reading,
Definitely worth reading, thanks.
@mstrelan, maybe need a bit more clarification on that part, based on:
http://xhtml.com/en/css/reference/font-family/
Font names that contain spaces should be put in single or double quotes.
Perhaps this will do:
Use double quotes in property values that contain spaces, e.g. font-family: "Arial Black";
Or the draft applies to non-spaced family, too? I think it is just a miss, CMMIW.
laught, light n laughter
rule set grouping
In the former CSS coding standards we have, "A blank line should be placed between each group, section, or block of multiple selectors of logically related styles." An example there shows a related rule set with no blank line between.
In our proposed new CSS formatting guidelines
Under format, we simply have (at the end a great list), "Separate each ruleset by a blank line." There is nothing about grouping logically related rule sets sometimes with no blank line, as we do now. Is this intentional or an oversite?