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)
Great read
Thanks for that link JohnAlbin, not at all what I expected when I saw the link title.
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?
Yes, you are correct. In a
Yes, you are correct. In a large document they could be useful to visually demarcate sections.
I just don't really like large CSS files. I prefer to break out styles into logical groupings such as:
css/theme.layout.csscss/theme.menus.css
css/theme.forms.css
css/theme.fonts.css
css/theme.typography.css
css/theme.buttons.css
If a CSS file needs these long style sectioning comments, then it points towards the need for a more granular file structure.
fs.io
drupalcontrib.org
To add, the use of these
To add, the use of these multi-line comments is also more consistent (the file-level comment is already required), and will help those transitioning for module development to theming (and vice-versa).
Ignore
Duplicate.
Small files vs. one large file
I prefer breaking CSS files into smaller chunks too, but most of Drupal core's themes already have really long CSS files. See Seven and Bartik's styles.css.
The section comments are about trying to visually break up long files into smaller chunks.
Also, I don't think any module should have a long stylesheet. Any module considering adding a section comment to its stylesheet probably needs refactoring.
Should we add language that smaller files are preferable to section comments? And only to be used in theme stylesheets?
- John (JohnAlbin)
Small Files and Sectioning
This is true, many core themes are already quite verbose in their individual files. That said, I'm convinced that small files and sectioning aren't mutually exclusive, but two organizational tools that both have their place. Even smaller files could benefit from proper sectioning, especially where breaking the CSS into two additional files might make it more difficult to grok with a quick glance. A note to this effect may be helpful.
I also agree that modules generally shouldn't have a lengthy stylesheet, but should leverage what defaults are already given whenever possible. Rather, I'm referring to module developers stepping into the world of theming for the first time, and vice-versa. The more similar the two documentation standards are, the easier they'll be to pick up. So it's less a sectioning issue when I mention this specifically, and more a general DX issue.
Explanation
There were a couple of reasons why the section comment blocks are in the draft standards:
Given points 2 and 3, I felt including the section comment block in the draft is “paving the cow paths” (as the HTML5 working group likes to do.)
That said, everything is up for discussion. :-)
As a counter point to your preference that “we used regular multi-line comments, with a blank line below”, take a look at Seven's style.css which nearly does that already. IMO, your eyes cannot quickly find the start of sections and cannot easily distinguish between docblock section comments and docblock long-form comments. http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/theme...
- John (JohnAlbin)
Great stuff! I agree with
Great stuff! I agree with psynaptic, maybe it's just personal preference or not wanting to type out all those = characters and make sure they're the correct length if I'm not using snippets in my text editor. I have no evidence for this but I feel like I see regular multi-line comments more in contrib themes already.
CTO @ Settled
http://www.hedleysmith.com
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.
Responding to lukebrooker and echoz
Yeah, I've been struggling with this problem as well. Modules and Themes are loaded terms for Drupal users. Especially since Drupal segregates/aggregates CSS based on whether the CSS file comes from a Drupal module or a Drupal theme. It gets confusing very quickly.
Personally, this just makes me want to rename Drupal modules to be Drupal extensions. :-D
But, I do agree that SMACSS's "theme" is not very clear. Skins seems clearer then themes.
However, I really don't want to introduce a Drupalism, like we did when we introduced the "clearfix" class, but called it "clear-block". I'd like to use common terms that are known outside of Drupal. So patterns, components, and objects are all good alternatives to modules.
Design patterns, of course, means something different to software engineers then the idea of a pattern in graphic design. Just noting that. And ditto with objects.
Component also means something in software engineering, but it actually means the same thing as a design component: “A reusable software element with a specification.”
Maybe we should explain that we want to use SMACSS categories, but have renamed a couple parts to make it clearer in a Drupal context.
What about this?
What do people think of the above suggested terminology changes?
- John (JohnAlbin)
terms
I like the word Pattern better than Component, but I get how the meaning of Component is more accurate here. State is very clear to me but hey, I'm a front-end dev :-). I don't like the word Skin from it's Windows-centric past (skinning vs theming the OS) but I'll have to live with it since it's the obvious choice and I don't have an alternative. Whatever the outcome, I would want these to be each one word only.
If we can't use Pattern, then
If we can't use Pattern, then Component would have been my second choice anyway.
As a front-end guy, state makes sense for me. If we're worried about causing confusion then let's pick a synonym - here are my three picks:
'Skin' makes me feel yucky. What about 'Overlay'?
Visual
As another alternative to Skin, how about "Visual" for Theme?
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.
Agreed.
The docs are not very clear here. I've changed it to now say:
- John (JohnAlbin)
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?
I see this as an improvement.
I see this as an improvement.
fs.io
drupalcontrib.org
I do not agree. The extra
I do not agree. The extra whitespace is entirely unnecessary. Visual breaks already exist from the natural formatting of CSS.
However, I don't agree with using them to differentiate groups of related rules either. The emerging standard that more and more editors are using to allow visual folder-like view of your CSS is:
/* @group Group 1 /.selector{
rule: value;
}
/ @end /
/ @group Group 2 /
.selector{
rule: value;
}
/ @end */
Some of my asterisks seem to have been stripped but you get the idea.
Visual breaks already exist
I totally agree, no need for all this white-space.
Love the new 'Declaration order' recommendation, never got that Alphabetizing thing.
Sorry to disagree
I absolutely hate those grouping tags. Adding things to the source code to enable features in specific editors is in my opinion bad practice.
There should be a space before the opening curly and you can get your asterisks to show if you pick the "no markdown" input format.
I stand by my original comment, that I much prefer a single blank line between each and every ruleset, for example:
/**
* Sectioning group name.
*/
selector {
property: value;
}
selector,
selector {
property: value;
}
This is so much easier to read. A general programming guideline is to prefer less dense code over dense code as it improves readability. I think we should apply it here.
fs.io
drupalcontrib.org
I agree with this commenting
I agree with this commenting style rather than comments with unnecessary "@grouping" tags and "/* End */" comments at the bottom of each group too.
Regarding the spacing between selectors, I'm the opposite here. I find dense code easier to read (example below) because you can differentiate the 'groups' of CSS sections, rather than seeing every single CSS selector having a space and it all looks the same and more un-grouped.
/**
* Group 1 name
*/
selector {
property: value;
}
selector,
selector {
property: value;
}
/**
* Group 2 name
*/
selector {
property: value;
}
selector {
property: value;
}
Consistency
Setting my personal disagreement about the improved readability of the above aside for a moment, both the grouping tags and the lack of additional whitespace between a comment and its associated block are already established patterns when writing comments for modules. I think it behooves us to stay as consistent as possible.
Agree
I agree, this is much more readable.
Edit: for clarity, I meant this.
Just putting this out
Just putting this out there... I think it would be a good idea to have a css styleguide. I've only played with KSS somewhat unsuccessfully but I think it is a good idea none the less.
Is there an issue?
I'd just like to point out that the normal process (flawed though it may be) for discussing Drupal project coding standards is to file an issue in the "Drupal Core" project, component "documentation", tagged "coding standards". I think the discussion here is great, but an issue should also be filed pointing people here (if you haven't done so already), because there are some people who watch the "coding standards" tag, and that is our official standard way of doing things (for the moment anyway).
Drupal programmer - http://poplarware.com
Drupal author - http://shop.oreilly.com/product/0636920034612.do
Drupal contributor - https://www.drupal.org/u/jhodgdon
Thanks, Jen!
I went and created a new issue in the queue, as you suggested, so that people will know to come here to discuss the issue. :-)
http://drupal.org/node/1891580
- John (JohnAlbin)
Selector specificity?
I noticed there wasn't any documentation regarding correct use of selector specificity. It'd be nice if there were some guidelines regarding that.
It'd obviously require a bunch of people fighting over classes vs. div, but I think that conversation is important to at least begin.
selector choices is important!
I agree - it can be a hornets' nest, but the SMACSS type approach is really helpful in avoiding tons of '!importants' or overly specific selectors to overcome too many ID's vs classes. If we had a convention for using ID's only for major 'page furniture' it might help cut down on that need for so many specific selectors.
Jason Pamental
[ @jpamental ]
Speaking of !important, can
Speaking of !important, can we agree that this should NEVER exist in a module's CSS?
Also IDs are fine if they meet one of these two:
1) Part of core, major piece of page structure
2) Extremely unique ID with 0% chance of another module using it
I'm not really sure how you make good rules for this, as my knowledge mostly just comes from lots of experience. But it's generally best to be as non-specific as possible I think. The highest-level element with an ID and then selecting an actual tag without a class is ideal, when it works.
Most modules right now are wrapping everything in quite a long series of divs. We need more semantic elements than divs obviously, but we need a lot less of them in my opinion as well. It'd be nice if more modules went with a very clean default, and allowed you to add extra wrappers where it might be necessary via options (like with Views, I can cut down almost all the markup, I think this should be the default, if people need more they can add them). Hope I'm making sense to people.
mostly agree :)
I think that it's likely fine to say no to '!important' within Drupal modules, as long as core CSS is written in a way so as not to require it! (i.e. dealing with IDs better than we currently do)
Which leads to the bit about ID's - I don't think that it should ever be coming out of core with ID's - I think that should only be added in the theme layer to define page structure as you say.
I think I'd disagree with your last point though and say that there's not really a good way to know that anything is that unique, but if it is you're just as well to use a unique class name anyway. Especially if the thing you are applying it to has any elements within it that might not be so unique. So why not stick to classes instead?
Thanks!
Jason Pamental
[ @jpamental ]
Great point
This is a great point. I've been seeing a lot of really specific selectors lately such as:
.some-body-class .some-page-wrapper .some-other-wrapper #some-specific-element-wrapper some-element { ... }Which is just... insane!
I think it would be helpful to have guidelines so that people become more aware of the implications of having huge selectors like this (hard to override, weightier CSS, etc.)
fs.io
drupalcontrib.org
I like this A LOT! I'll
I like this A LOT!
I'll mention, though, that the ideas put forth in http://drupal.org/node/1887918 will need to be very well defended.
Also, echoing that a guide for preprocessors could be handy.
Note for module developers
"Note for module developers" on http://drupal.org/node/1887918 is entirely about HTML. I don't think that belongs in the CSS guidelines. That's not where I'd look for it.
The one large thing that
The one large thing that concerns me about this document is, while fine for those not writing CSS with a preprocessor, it appears as if, from first glance, it will be for those who do, especially when it becomes super easy to separate out different sections of a CSS declaration (positioning, box model, design, etc…) and can use partials instead of the, frankly atrocious section breaks.
Great start. Perhaps one
Great start.
Perhaps one thing to consider would be naming conventions, in particular camel case, underscores or hyphens.
There's some good arguments for using hyphens here http://csswizardry.com/2010/12/css-camel-case-seriously-sucks
S
Strict alphabetical ordering
If you sort the properties in a selector in alphabetical order, it's easy to read and also easy to know in which order you should write them.
"grouped with like properties next to each other" sounds a bit like the "do-whatever-my-brain-says-is-next ordering method" which leads to css from different authors have different ordering. Then the CSS Box Model Convention (http://fordinteractive.com/2009/02/order-of-the-day-css-properties) is a better recommendation.
But my vote goes to strict alphabetical ordering of properties. You don't have to be familiar with the box model and it's also the former recommendation.
--
Happiness - www.happiness.se
I totally agree with
I totally agree with you.
Alphabetical order gives more predictability when you read the CSS. Also is more easy to standardize in a big team.
Aren't most editors capable
Aren't most editors capable of doing this?
I absolutely hate this, it makes it extremely difficult to work with. Alphabetical order has absolutely no meaningful connection to the style. I feel really strongly that things should be ordered contextually, especially considering many editors can show you the document in alphabetical order if you prefer, but context is not something that can be automatically obtained that way.
I would never work in alphabetical order, this would be a standard I'd ignore personally :/ Not trying to be a jerk and I will usually follow just about any standard even if I disagree with it, but this one would impede my personal workflow a great deal and I assume I'm not alone.
Just to add another voice of
Just to add another voice of agreement, I concur. Alphabetical order is arbitrary and devoid of context, and most editors can replicate this for you if you really need it to scan a document.
+1 to logical grouping over
+1 to logical grouping over alphabetical. I find this much clearer in general and the proposed standard gives an excellent guideline for logical grouping.
http://cleaver.ca
I have to agree with
I have to agree with TelFiRE's disdain of alphabetical sorting, what's listed in the existing draft is the most suitable method going forward. Most editors can (or have a plugin that can) sort alphabetically; ordering by positioning, box model, then other properties actually has a useful meaning that can be obtained no other way. Why on earth would you separate properties that obviously go together, it just feels wrong. This should definitely not be a hard requirement.
Properties ordering
When I write css, I group attributes by logic - first go elements that influence the box model - position, display, padding, margin, etc. And then go markup styling - backgrounds, colors, fonts, etc. So, when I work on layout and the box model, I don't need to search for 'display: block' in the top section, 'margin' in the middle section, and 'padding' closer to the bottom of a list of attributes. I don't object strongly to alphabetical order - but would better prefer it as a option.
CSS Attribute groupingI've
CSS Attribute grouping
I've been following the way of the Alphabetized declarations for a long time now, it's both easy and comfortable for me to navigate my way around CSS documents that way.
However, my vote is for the suggestion presented here in this draft. I find it to be very well thought out and it makes just about as much sense, if not more, than alphabetizing. This styling implies a sense of priority to the attributes on a selector that seems useful for finding the source of problems in a document. Instead of needing to down the cascade line by line, the eye can simply jump from grouping to grouping for investigation.
Time and usage will tell.
If you're dead set on alphabetizing, then combine the methods - It's not so difficult to stay alphabetical within each grouping.
I feel fairly certain that this horse in particular has already been beaten to death and come back as a zombie steed with a thirst for time wastin'.
Naming conventions
Hyphens suit me best, although again this is habit not any purpose driven decision.
I use casings for different purposes: snake_casing for PHP, camelCasing for JS and Ruby, hyphen-casing (?) for CSS/markup. This also seems like the pattern I see most in code written by other developers.
Comments / Space between selectors: I think it will be fine, whatever we end up doing there. The point is that code gets explained.
I'll go against my own preference for long comments used to break up pages visually and say we should use as few extra characters as possible. While it may be trivial and nit-picky, filesize does increase with characters and whitespace.
Other thoughts
I can anticipate the cognitive dissonance the Snook / Gallagher / Sullivan approach to CSS is going to cause for most Drupal folks due to the use of the word "module", I'd just like to give a bump to @echoz' suggestion that we refer to these things (modular design patterns, CSS objects, etc...) as Patterns. I really like that.
I would like to keep the
I would like to keep the alphabetizing because it makes it easier to read imho. I think your idea to combine both methods would be best for the community.
Your argument about filesize is not an issue because when aggregation is on drupal removes comments and unnecessary whitespaces.
CSSDoc?
I recall CSSDoc (http://cssdoc.net/) being discussed before - it is reasonably similar to Doxygen, which makes our comment styles much more internally consistent (sectioning comments in this draft seem jarring and out of place, for instance). That, and adopting an existing standard seems much easier than trying to reinvent the wheel.
Perhaps this is a direction we should continue to explore?
No thank you
CSSDoc is a DOA (dead on arrival) standard. It was flawed when it was created (they asked me to review) and the spec hasn't been touched in 4 years and no tools have been created to build useful documentation from CSSDoc blocks.
http://cssdoc.net/ <-- Everything is dated 2009.
You can find my original objections to this spec here: http://groups.drupal.org/node/14421#comment-49869
- John (JohnAlbin)
All fair objections;
All fair objections; apparently I missed this part of the conversation. Thanks for the link!
Duplicate
.
Should not we use css-lint for make css better (as Lint says)?
I am using css-lint to check my css errors and warnings, But Its shows much more warnings. Lint doesn't allow to use IDs as selectors and It also disallows overqualified selectors like li.first or input.text-field.
More can check on this css-lint.
But we have to use IDs. can't just use classes. So should we not use css-lint, because It will always hurt feelings ?
crazyrohila
#Ubuntu, #Drupal
csslint is a great tool
csslint is a great tool we should leverage. I think we need to figure out what command-line flags we want to pass to it so it works best for Drupal's CSS standards.
- John (JohnAlbin)
If we switch from alpha
If we switch from alpha sorting of properties to logical grouping, we will need to rewrite all of the CSS in core or be ok with it living in some state of transition for a very long time.
Logical grouping is also going to lead to chaos. With at least over 100 unique CSS properties that could be sorted into at least 15 groups, it will not be possible to maintain consistency without a very long canonical list of properties and their sanctioned order in the logical scheme. And this will lead to more nitpicking during reviews.
Alphabetical order isn't pretty, but it's predictable, consistent and easy to apply.
You missed last week's mobile meeting…
You missed last week's Drupal 8 mobile meeting.
Rewriting all of core's CSS is EXACTLY WHAT I WANT TO DO. :-D
- John (JohnAlbin)
Sorry about that :) Was under
Sorry about that :) Was under the knife.
Let's just leave it optional
Let's just leave sorting/grouping of css values optional.
100% Agree
Too many people have different tastes when it comes to this. If it becomes a standard for Drupal to make it sorted in a way that I don't like, then I just can't follow it because I prefer to read it in a way that works for me. I can't imagine other people breaking their personal preferences either.
I feel leaving this optional is the way to move on for now. Perhaps in the future if there are official CSS guideline standards for grouping to follow with this, then we should discuss it then.
According to this article from CSS-Tricks, most people do it by type grouping or randomly: http://css-tricks.com/poll-results-how-do-you-order-your-css-properties, with alphabetical and line-length as the minority.
If you're one of the people who code randomly, but want to clean it up, perhaps taking a look at and implementing CSScomb (http://csscomb.com) in your text editors to work in the order you prefer will at least clean it up to be more organized in general, instead of people just going at it randomly.
consistancy
It's not about how we like it isolated in our own text editor or readability, it's that every commited file orders declarations the same way.
Exactly. We need consistency
Exactly. We need consistency in core CSS files so that reviewers have a cold, solid, objective rubric to apply to proposed changes. Contributed modules can do what they will with their CSS file declaration orders.
Here is a list of CSS2 and CSS3 properties. It's most likely not complete. I tried to remove expanded properties so the number of items isn't artificially inflated. These properties would need to be grouped into probably more than 10 groups. I offer that a logical grouping approach is a bit too unruly for our distributed team.
a start
That's a good start, but it needs to be weeded a little for proprietary CSS selectors such as MS-only, "scrollbar-3d-light-color."
Hmmm…
I think maybe I should clarify the intention of the property ordering in the draft. I was suggesting there be exactly 3 groups: "Positioning", "box model", and "other". Trying to find 10-15 groupings for all CSS properties would make for an extremely nit-picky, difficult-to-work-with recommendation. By specifying only 2 groups that have specific properties and 1 group as a grab-bag for everything else, it because much easier to follow the recommendation. Also, I purposefully left off any requirement that the properties in these 3 groups by alphabetized.
The basic guideline for the property order rule is:
A specific regimented ordering of all CSS properties isn't necessary. ESPECIALLY, if we try to make our CSS rulesets be pattern-based where all the limited set of CSS properties in the rule are trying to achieve a unifying objective. (As opposed to the multi-purpose dumping group that our selectors have traditionally been.)
- John (JohnAlbin)
Try to group other properties
That is the opposite of a standard, no?[edit] sorry, that was too snarky. What I meant is, I'm hesitant to write anything into a standard for core that relies on any individual developers opinions about how to group properties.
I still like the logical
I still like the logical groups + alpha as proposed—provided we have three groups and not a dozen. It seems like this could be easily scripted to refactor existing code and do automated code reviews.
That said, I wouldn't be upset if everyone decides to just go alphabetical.
http://cleaver.ca
Not a fan of alpha-sorting
Not a fan of alpha-sorting but I do tend to logically group my properties by most important first. I'd be quite happy with the proposed standard as it's just a formalisation of what I'm already doing.
fs.io
drupalcontrib.org
Online video chat to discuss
Tomorrow we're going to have 2 Drupal 8 Mobile Initiative meetings and I'd like to discuss in real-time (over video/IRC) the draft CSS coding standards.
Pick the time that works best for you!
Meeting 28.0: http://groups.drupal.org/node/278278
Meeting 28.5: http://groups.drupal.org/node/278283
- John (JohnAlbin)
I think, there should be
I think, there should be compress version of all CSS files.
like: jQuery has jQuery.min.js
If someone needs documented styles sheets, they can refer the full css file, otherwise minified version is ok.
e.g. full= style.css and minified = style.min.css
-Imran
I think leaving minification
I think leaving minification to the aggregation system is a better idea. Libraries like jQuery have to cater for people who want to just include the file in a project so having a minified version is essential. Drupal can and should minify on output.
fs.io
drupalcontrib.org
This is a related
This is a related issue:
http://drupal.org/node/1839656
Is there any kind of summery
Is there any kind of summery to this thread? what is agreed upon? what is still on debate? it is very hard to follow with all those nested threads.
Summary are the draft coding
Summary are the draft coding standards at: http://drupal.org/node/1886770
You will need to run through each of the subpages:
CSS formatting guidelines: http://drupal.org/node/1887862
DRAFT - CSS Architecture: http://drupal.org/node/1887918
DRAFT - Grouping CSS rulesets: http://drupal.org/node/1887922
Shyamala
Unimity Solutions
Once such SMACSS-based naming
Once such SMACSS-based naming conventions are agreed upon, I'd love to see some guidance to implementing it on the templating side of things.
This discussion thread mainly covers how we write CSS files, but I think in the long run (and in combination with Twig) this will also affect our templates, theme and preprocessing functions.
I'm myself a bit sceptical to the verbosity of the proposed selector rules. So to convince people like me I think we need a complete example that shows the strength and robustness of the new standard.
Thanks to all working on this. Next time we can talk preprocessors as this hopefully will also greatly benefit contrib space :)
@snookca at drupalcon Portland!
Jonathan Snook featured speaker at drupalcon Portland!
Section Comments
As mentioned a few times above, this document is outstanding, except for one thing that really irks me:
Section Comments have too much visual junk. Furthermore, CSSDoc has a section style in its recommendation:
@section.If we're not going to use CSSDoc sections, then we need to at least make our version of section comments more concise. Singling out sections in a file with two lines of "=====" is distracting and a waste of time trying to make it line up properly with the 80 columns. In the end it will be a copy-paste job :-/
I would be much more partial to a Markdown-like syntax:
/
* Section
* =======
*
* Description text for section.
*/
OR
/
* ## Section ##
*
* Description text for section.
*/