Skip to content

Loading…

Add spaces between property: value; in CSS #21

Merged
merged 2 commits into from

5 participants

@inlikealion

Does what it says on the label.

@inlikealion

Forgot spaces before opening brackets the first time around.

@cust0dian

Of course this is purely personal preference, but property: value style seems to be dominant at the moment:

  1. In specifications

  2. Default format for displaying CSS rules in browser's developer tools

    • Chrome's Developer Tools:

    Chrome Developer Tools HTML/CSS/DOM Inspector

    • Firebug for Firefox:

    Firebug HTML/CSS/DOM Inspector

    • Firefox's Developer Tools:

    Firefox Developer Tools HTML/CSS/DOM Inspector

  3. In Mozilla Developer Network refernce

    • From color property refernce:

      element { color: red }
      element { color: #f00 }
      element { color: #ff0000 }
      element { color: rgb(255,0,0) }
      element { color: rgb(100%, 0%, 0%) }
      element { color: hsl(0, 100%, 50%) }
      
      /* 50% translucent */
      element { color: rgba(255, 0, 0, 0.5) } 
      element { color: hsla(0, 100%, 50%, 0.5) }
  4. In various styleguides

Since CSS Guidelines is supposed to be a reference material, decreasing (although really small) amount of time needed to "parse" the code by utilizing the style that is more common should be a good thing.

I'm for merging this in :+1:

@cm0s

+1

@pim

Well, this is how Harry writes CSS (example), so it might be a bit hard to get this merged to his very own guidelines ;)

@inlikealion

@pim Actually this is out of context here on github. I have already asked @csswizardry about this on Twitter and he agreed: https://twitter.com/csswizardry/status/426406662015287296

I pointed out that given his method of using 2x spaces in markup between classes for legibility, it was inconsistent to remove spaces in his declarations what reduce legibility. Harry said he has already started adapting his style to be consistent with this and that he would be open to accepting this pull request.

@pim

@inlikealion Oh, I understand. That’s good then – I prefer to use spaces too :)

@csswizardry csswizardry merged commit c50e444 into csswizardry:master
@inlikealion inlikealion deleted the inlikealion:edit-spaces branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Showing with 90 additions and 90 deletions.
  1. +90 −90 README.md
View
180 README.md
@@ -166,9 +166,9 @@ For further reading I cannot recommend Jonathan Snook’s
## Anatomy of rulesets
- [selector]{
- [property]:[value];
- [<- Declaration ->]
+ [selector] {
+ [property]: [value];
+ [<- Declaration -->]
}
I have a number of standards when structuring rulesets.
@@ -184,22 +184,22 @@ I have a number of standards when structuring rulesets.
A brief example:
- .widget{
- padding:10px;
- border:1px solid #BADA55;
- background-color:#C0FFEE;
- -webkit-border-radius:4px;
- -moz-border-radius:4px;
- border-radius:4px;
+ .widget {
+ padding: 10px;
+ border: 1px solid #BADA55;
+ background-color: #C0FFEE;
+ -webkit-border-radius: 4px;
+ -moz-border-radius: 4px;
+ border-radius: 4px;
}
- .widget-heading{
- font-size:1.5rem;
- line-height:1;
- font-weight:bold;
- color:#BADA55;
- margin-right:-10px;
+ .widget-heading {
+ font-size: 1.5rem;
+ line-height: 1;
+ font-weight: bold;
+ color: #BADA55;
+ margin-right: -10px;
margin-left: -10px;
- padding:0.25em;
+ padding: 0.25em;
}
Here we can see that `.widget-heading` must be a child of `.widget` as we have
@@ -213,19 +213,19 @@ text rules, followed by everything else.
One exception to our multi-line rule might be in cases of the following:
- .t10 { width:10% }
- .t20 { width:20% }
- .t25 { width:25% } /* 1/4 */
- .t30 { width:30% }
- .t33 { width:33.333% } /* 1/3 */
- .t40 { width:40% }
- .t50 { width:50% } /* 1/2 */
- .t60 { width:60% }
- .t66 { width:66.666% } /* 2/3 */
- .t70 { width:70% }
- .t75 { width:75% } /* 3/4*/
- .t80 { width:80% }
- .t90 { width:90% }
+ .t10 { width: 10% }
+ .t20 { width: 20% }
+ .t25 { width: 25% } /* 1/4 */
+ .t30 { width: 30% }
+ .t33 { width: 33.333% } /* 1/3 */
+ .t40 { width: 40% }
+ .t50 { width: 50% } /* 1/2 */
+ .t60 { width: 60% }
+ .t66 { width: 66.666% } /* 2/3 */
+ .t70 { width: 70% }
+ .t75 { width: 75% } /* 3/4*/
+ .t80 { width: 80% }
+ .t90 { width: 90% }
In this example (from [inuit.css’s table grid system](https://github.com/csswizardry/inuit.css/blob/master/base/_tables.scss#L96))
it makes more sense to single-line our CSS.
@@ -242,9 +242,9 @@ transparent and informative.
The naming convention follows this pattern:
- .block{}
- .block__element{}
- .block--modifier{}
+ .block {}
+ .block__element {}
+ .block--modifier {}
* `.block` represents the higher level of an abstraction or component.
* `.block__element` represents a descendent of `.block` that helps form `.block`
@@ -253,11 +253,11 @@ The naming convention follows this pattern:
An **analogy** of how BEM classes work might be:
- .person{}
- .person--woman{}
- .person__hand{}
- .person__hand--left{}
- .person__hand--right{}
+ .person {}
+ .person--woman {}
+ .person__hand {}
+ .person__hand--left {}
+ .person__hand--right {}
Here we can see that the basic object we’re describing is a person, and that a
different type of person might be a woman. We can also see that people have
@@ -317,12 +317,12 @@ functionality.
Despite being a British developer—and spending all my life writing <i>colour</i>
instead of <i>color</i>—I feel that, for the sake of consistency, it is better
to always use US-English in CSS. CSS, as with most (if not all) other languages,
-is written in US-English, so to mix syntax like `color:red;` with classes like
-`.colour-picker{}` lacks consistency. I have previously suggested and advocated
+is written in US-English, so to mix syntax like `color: red;` with classes like
+`.colour-picker {}` lacks consistency. I have previously suggested and advocated
writing bilingual classes, for example:
.color-picker,
- .colour-picker{
+ .colour-picker {
}
However, having recently worked on a very large Sass project where there were
@@ -369,7 +369,7 @@ comments, namely:
#### Quasi-qualified selectors
You should never qualify your selectors; that is to say, we should never write
-`ul.nav{}` if you can just have `.nav`. Qualifying selectors decreases selector
+`ul.nav {}` if you can just have `.nav`. Qualifying selectors decreases selector
performance, inhibits the potential for reusing a class on a different type of
element and it increases the selector’s specificity. These are all things that
should be avoided at all costs.
@@ -383,16 +383,16 @@ tell.
By quasi-qualifying this selector (i.e. commenting out the leading type
selector) we can communicate where we wish to have this class applied, thus:
- /*html*/.product-page{}
+ /*html*/.product-page {}
We can now see exactly where to apply this class but with none of the
specificity or non-reusability drawbacks.
Other examples might be:
- /*ol*/.breadcrumb{}
- /*p*/.intro{}
- /*ul*/.image-thumbs{}
+ /*ol*/.breadcrumb {}
+ /*p*/.intro {}
+ /*ul*/.image-thumbs {}
Here we can see where we intend each of these classes to be applied without
actually ever impacting the specificity of the selectors.
@@ -405,12 +405,12 @@ a comment above it, for example:
/**
* ^navigation ^lists
*/
- .nav{}
+ .nav {}
/**
* ^grids ^lists ^tables
*/
- .matrix{}
+ .matrix {}
These tags allow other developers to find snippets of code by searching for
function; if a developer needs to work with lists they can run a find for
@@ -430,14 +430,14 @@ In your base stylesheet:
/**
* Extend `.foo` in theme.css
*/
- .foo{}
+ .foo {}
In your theme stylesheet:
/**
* Extends `.foo` in base.css
*/
- .bar{}
+ .bar {}
Here we have established a concrete relationship between two very separate
pieces of code.
@@ -464,15 +464,15 @@ apply only the relevant classes and CSS _afterwards_.
I work in an OOCSS manner; I split components into structure (objects) and
skin (extensions). As an **analogy** (note, not example) take the following:
- .room{}
+ .room {}
- .room--kitchen{}
- .room--bedroom{}
- .room--bathroom{}
+ .room--kitchen {}
+ .room--bedroom {}
+ .room--bathroom {}
We have several types of room in a house, but they all share similar traits;
they all have floors, ceilings, walls and doors. We can share this information
-in an abstracted `.room{}` class. However we have specific types of room that
+in an abstracted `.room {}` class. However we have specific types of room that
are different from the others; a kitchen might have a tiled floor and a bedroom
might have carpets, a bathroom might not have a window but a bedroom most likely
will, each room likely has different coloured walls. OOCSS teaches us to
@@ -524,9 +524,9 @@ benefits of ems with the confidence of pixels. Here is a handy Sass mixin to
work out a rem and pixel fallback for you (assuming you set your base font
size in a variable somewhere):
- @mixin font-size($font-size){
- font-size:$font-size +px;
- font-size:$font-size / $base-font-size +rem;
+ @mixin font-size($font-size) {
+ font-size: $font-size +px;
+ font-size: $font-size / $base-font-size +rem;
}
I only use pixels for items whose dimensions were defined before the came into
@@ -544,19 +544,19 @@ full explanation of how this works please refer to my article
**Shorthand CSS needs to be used with caution.**
-It might be tempting to use declarations like `background:red;` but in doing so
+It might be tempting to use declarations like `background: red;` but in doing so
what you are actually saying is ‘I want no image to scroll, aligned top-left,
repeating X and Y, and a background colour of red’. Nine times out of ten this
won’t cause any issues but that one time it does is annoying enough to warrant
-not using such shorthand. Instead use `background-color:red;`.
+not using such shorthand. Instead use `background-color: red;`.
-Similarly, declarations like `margin:0;` are nice and short, but
+Similarly, declarations like `margin: 0;` are nice and short, but
**be explicit**. If you actually only really want to affect the margin on
-the bottom of an element then it is more appropriate to use `margin-bottom:0;`.
+the bottom of an element then it is more appropriate to use `margin-bottom: 0;`.
Be explicit in which properties you set and take care to not inadvertently unset
others with shorthand. E.g. if you only want to remove the bottom margin on an
-element then there is no sense in setting all margins to zero with `margin:0;`.
+element then there is no sense in setting all margins to zero with `margin: 0;`.
Shorthand is good, but easily misused.
@@ -580,7 +580,7 @@ them in CSS _ever_.
Keep selectors short, efficient and portable.
Heavily location-based selectors are bad for a number of reasons. For example,
-take `.sidebar h3 span{}`. This selector is too location-based and thus we
+take `.sidebar h3 span {}`. This selector is too location-based and thus we
cannot move that `span` outside of a `h3` outside of `.sidebar` and maintain
styling.
@@ -607,30 +607,30 @@ An over-qualified selector is one like `div.promo`. You could probably get the
same effect from just using `.promo`. Of course sometimes you will _want_ to
qualify a class with an element (e.g. if you have a generic `.error` class that
needs to look different when applied to different elements (e.g.
-`.error{ color:red; }` `div.error{ padding:14px; }`)), but generally avoid it
+`.error { color: red; }` `div.error { padding: 14px; }`)), but generally avoid it
where possible.
-Another example of an over-qualified selector might be `ul.nav li a{}`. As
+Another example of an over-qualified selector might be `ul.nav li a {}`. As
above, we can instantly drop the `ul` and because we know `.nav` is a list, we
-therefore know that any `a` _must_ be in an `li`, so we can get `ul.nav li a{}`
-down to just `.nav a{}`.
+therefore know that any `a` _must_ be in an `li`, so we can get `ul.nav li a {}`
+down to just `.nav a {}`.
### Selector performance
Whilst it is true that browsers will only ever keep getting faster at rendering
CSS, efficiency is something you could do to keep an eye on. Short, unnested
-selectors, not using the universal (`*{}`) selector as the key selector, and
+selectors, not using the universal (`* {}`) selector as the key selector, and
avoiding more complex CSS3 selectors should help circumvent these problems.
## CSS selector intent
Instead of using selectors to drill down the DOM to an element, it is often best
to put a class on the element you explicitly want to style. Let’s take a
-specific example with a selector like `.header ul{}`
+specific example with a selector like `.header ul {}`
Let’s imagine that `ul` is indeed the main navigation for our website. It lives
in the header as you might expect and is currently the only `ul` in there;
-`.header ul{}` will work, but it’s not ideal or advisable. It’s not very future
+`.header ul {}` will work, but it’s not ideal or advisable. It’s not very future
proof and certainly not explicit enough. As soon as we add another `ul` to that
header it will adopt the styling of our main nav and the the chances are it
won’t want to. This means we either have to refactor a lot of code _or_ undo a
@@ -644,7 +644,7 @@ selector.
Make sure your key selector is never an element/type selector or
object/abstraction class. You never really want to see selectors like
-`.sidebar ul{}` or `.footer .media{}` in our theme stylesheets.
+`.sidebar ul {}` or `.footer .media {}` in our theme stylesheets.
Be explicit; target the element you want to affect, not its parent. Never assume
that markup won’t change. **Write selectors that target what you want, not what
@@ -656,7 +656,7 @@ For a full write up please see my article
## `!important`
It is okay to use `!important` on helper classes only. To add `!important`
-preemptively is fine, e.g. `.error{ color:red!important }`, as you know you will
+preemptively is fine, e.g. `.error { color: red !important }`, as you know you will
**always** want this rule to take precedence.
Using `!important` reactively, e.g. to get yourself out of nasty specificity
@@ -670,17 +670,17 @@ A magic number is a number which is used because ‘it just works’. These are
because they rarely work for any real reason and are not usually very
futureproof or flexible/forgiving. They tend to fix symptoms and not problems.
-For example, using `.dropdown-nav li:hover ul{ top:37px; }` to move a dropdown
+For example, using `.dropdown-nav li:hover ul { top: 37px; }` to move a dropdown
to the bottom of the nav on hover is bad, as 37px is a magic number. 37px only
works here because in this particular scenario the `.dropdown-nav` happens to be
37px tall.
-Instead you should use `.dropdown-nav li:hover ul{ top:100%; }` which means no
+Instead you should use `.dropdown-nav li:hover ul { top: 100%; }` which means no
matter how tall the `.dropdown-nav` gets, the dropdown will always sit 100% from
the top.
Every time you hard code a number think twice; if you can avoid it by using
-keywords or ‘aliases’ (i.e. `top:100%` to mean ‘all the way from the top’)
+keywords or ‘aliases’ (i.e. `top: 100%` to mean ‘all the way from the top’)
or&mdash;even better&mdash;no measurements at all then you probably should.
Every hard-coded measurement you set is a commitment you might not necessarily
@@ -694,7 +694,7 @@ fixes).
As a general rule, all layout and box-model rules can and _will_ work without an
IE stylesheet if you refactor and rework your CSS. This means you never want to
-see `<!--[if IE 7]> element{ margin-left:-9px; } < ![endif]-->` or other such
+see `<!--[if IE 7]> element { margin-left: -9px; } < ![endif]-->` or other such
CSS that is clearly using arbitrary styling to just ‘make stuff work’.
## Debugging
@@ -706,7 +706,7 @@ isn’t the right answer!
Delete chunks of markup and CSS until your problem goes away, then you can
determine which part of the code the problem lies in.
-It can be tempting to put an `overflow:hidden;` on something to hide the effects
+It can be tempting to put an `overflow: hidden;` on something to hide the effects
of a layout quirk, but overflow was probably never the problem; **fix the
problem, not its symptoms.**
@@ -716,26 +716,26 @@ Sass is my preprocessor of choice. **Use it wisely.** Use Sass to make your CSS
more powerful but avoid nesting like the plague! Nest only when it would
actually be necessary in vanilla CSS, e.g.
- .header{}
- .header .site-nav{}
- .header .site-nav li{}
- .header .site-nav li a{}
+ .header {}
+ .header .site-nav {}
+ .header .site-nav li {}
+ .header .site-nav li a {}
Would be wholly unnecessary in normal CSS, so the following would be **bad**
Sass:
- .header{
- .site-nav{
- li{
- a{}
+ .header {
+ .site-nav {
+ li {
+ a {}
}
}
}
If you were to Sass this up you’d write it as:
- .header{}
- .site-nav{
- li{}
- a{}
+ .header {}
+ .site-nav {
+ li {}
+ a {}
}
Something went wrong with that request. Please try again.