csswizardry / css-guidelines

High-level guidelines for writing manageable, maintainable CSS

Hi there 👋

css-guidelines's Issues

Chinese Translation

https://github.com/chadluo/CSS-Guidelines/blob/master/README.md

Would you please include this?

HTTPS version of site insecure

https://cssguidelin.es/

Could easily use CloudFlare like you did for your main site:
https://csswizardry.com/2017/01/moving-css-wizardry-onto-https-and-http-2/

Possible translations?

Hi, is it possible to add translations in other languages? For example, I want to translate it to my native - Azerbaijani language. Thanks!

menu using these/bem guidelines

Probably not the very best place to ask this, but I tried asking on SA and got shouted at.

I've been using https://github.com/csswizardry/csswizardry-grids for a while now, and decided I wanted to recode my whole app using BEM, so I read all the articles, and decided to use the same naming conventions you are using(http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/) but this is not really about naming conventions.

I found all the articles lacking real life use examples. And I immediately stumbled upon a problem when trying to use BEM on the very first thing on the app, that is the navigation.

Now consider this code, it has to be the most common thing everyone does

<ul>
    <li>
        <a href="/what">What</a>
    </li>

    <li>
        <a href="/why">Why</a>
    </li>

    <li>
        <a href="/how">How</a>
    </li>
</ul>

which is supposed to look, say, like this

ul, given a class .menu will be the "block" now what would be the element? li or a, the obvious choice would be the li, but if I styled the li, only text would be clickable, so the more practical(and standard) choice would be the a.

But I'd still need to, at very least, do .menu li { display: inline; } .. but I'm not supposed to use element selectors in css, right? Does this fall to "you don't have to BEM everything category"? The other option would be to give the li some BEM class as well, like .menu__listitem along the class for a which would be .menu_item.. but if I decided to apply this .menu to any other element, which doesn't required an additional element to be semantic, like div&a combo, that .menu__listitem would become redundant, right. So what's the best approach?

I could probably create a handy .display-inline utility class a put it on each one of the lis, but can see this "problem" happening basicaly everytime any "block" is made by more than one nested element, whatever the reason would be, and an utility class just might not be enough..

Thank you in advance if you find a couple of minutes to read and respond to this..

Universal selector isn't slow by itself

In Selectors->Performance you advise against using the universal selector (*{}).

That's actually not true if the selector is just *{} as that is pretty fast. As fast as an element selector some say.
What's slow is this: div *{} and the deeper it goes it gets even slower because of browsers reading from right to left meaning it first gets all elements, then checks which of them are inside a div for each of them, going up until the parent HTML node looking for a div.

Why u no love spaces?

Hi,

First of all, let me tell you that I dig your guidelines, bro. Especially about the naming conventions (dashes only, lowercase…).

On the other side, I noted that you didn't like spaces (in rules or for indentation)!

Why do you write this:

.selector{
  property:value;
}

Instead of this:

.selector {
  property: value;
}

The second example (with spaces before the bracket and after the colon) looks more readable (and is also more popular amongst developers). What do you think?

Also, I'm using spaces to indent the code, so my indentation matches HAML's and looks everywhere the same, but that's just personal taste and better for my workflow. Some developers would burn people like me (@LeaVerou).

Thanks and keep up the good work!

Spanish translation

Hi!

Spanish translation coming soon!

Congratulations! Fantastic guidelines! :)

Suggest include output of SCSS - end of article.

After suggested Sass nesting, perhaps demonstrate the result. For example:

If you were to Sass this up you’d write it as:

.header{}
.site-nav{
li{}
a{}
}

This would output the following vanilla css, with correct selector specificity:

.header{}
.site-nav li{}
.site-nav a{}

Typo in repo description

High-level guidelines from writing manageable, maintainable CSS

I believe from should be for.

@media query best practices needed

What's Style trumps?

Hi,

What's the "Style trumps" mean? Can you describe more about this? I'm not really understanding about this.

Thanks!

BR,
Will

Suggest to include chapter on SASS specific naming conventions

What naming conventions do you use for: @function, @mixin, %placeholder, $variable, $map: ('key1': value1, 'key2': value2) and why?

About ID specificity

Great stuff about CSS, as always. I've found a small issue, though. In the IDs section you've wrote:

An ID is 255 times more specific than a class [...]

That's only the case for IE and Fx. Chrome and Opera will require more ridiculous number of classes to actually beat an ID, so for the sake of being totally correct, you might want to change this part.

(Specificity tried on this pen)

License?

License is nowhere to be seen.
is that MIT?

Small grammatical issue.

Under the Indenting heading there is a small grammatical issue.

As well as intending individual declarations, indent entire related rulesets to signal their relation to one another, for example:

should read:

As well as indenting individual declarations, indent entire related rulesets to signal their relation to one another, for example:

French translation

Hello harry,

This beautifull guide is now avalaible in French :)

• Français

BEM naming contradictions about reusability

Hi
I read your guideline on BEM (and others) but I still find some contradictions about the reusability. Please answer!

ONE: project-specific or global name?
The naming conventions require naming for project-specific objects or for global objects (reusable on different projects)?

Code speaks: this (project-specific object "User")...

<div class="container users">
  <div class="user user--banned"> <!-- Block with modifier -->
    <h2 class="user__nickname">John Doe</h2>
    <p class="user__bio">Lorem ipsum lorem ipsum.</p>
  </div>
  <div class="user">
    <h2 class="user__nickname">John Doe</h2>
    <p class="user__bio">Lorem ipsum lorem ipsum.</p>
  </div>
  <div class="user">
    <h2 class="user__nickname">John Doe</h2>
    <p class="user__bio">Lorem ipsum lorem ipsum.</p>
  </div>
</div>

... or this (that is a global object "Card" that can be used for both "User" and, for ie, "Article")?

<div class="container users">
  <div class="card card--red"> <!-- Block with modifier -->
    <h2 class="card__heading">John Doe</h2>
    <p class="card__text">Lorem ipsum lorem ipsum.</p>
  </div>
  <div class="card">
    <h2 class="card__heading">John Doe</h2>
    <p class="card__text">Lorem ipsum lorem ipsum.</p>
  </div>
  <div class="card">
    <h2 class="card__heading">John Doe</h2>
    <p class="card__text">Lorem ipsum lorem ipsum.</p>
  </div>
</div>

If the right way is the first, I will have to write classes for different blocks ("user" or "article") with same properties (since now they're are visually the same)? It seems redundant and not reusable over multiple projects.

TWO: layout related properties
I have to put layout-grid related styles in the same class as well with theme styles? Or I have to separate them?

This:

    .user{
        // Grid-layout styles
        float:left;
        width:33.3333%;
        // Theme etc styles
        background: #EEE;
        border: 1px solid green;
    }

Or this?

    .card{
        // Theme etc styles
        background: #EEE;
        border: 1px solid green;
    }
    .col-1-3{
        // Grid-layout class to assign to each .card block
        float:left;
        width:33.3333%;
    }

Also, check this question http://stackoverflow.com/questions/36687676/bem-naming-separate-layout-styles-from-theme-styles

Section links when clicking on a heading

Hey @csswizardry,

It would be neat if you could click on a heading and get a link to that particular section of the docs – sort of like articles on A List Apart.

Japanese translation

Hi,
I have translated in Japanese to introduce your nice document for many Japanese codes.

I appreciate this document very much!

https://github.com/kiwanami/CSS-Guidelines/blob/master/README.ja.md

Application hooks (the js-prefix)

Thank you for this excellent reference! It's great to have this resource, and it's very well written and easy to understand.

There is one issue, which I find very controversial - your encouragement to use class names as application hooks.

A common practice is to use data-* attributes as JS hooks, but this is incorrect.

"incorrect" here is quite misleading - and the HTML5 spec makes it sound quite appropriate for exactly that:

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements

So, according to the spec, you'd have to be claiming that the class-attribute is "more appropriate" - but it is clearly designated for styling the visual appearance of elements, which Javascript hooks are not, and thereby clearly falls outside the defined meaning of the class-attribute.

data-* attributes, as per the spec, are used to store custom data private to the page or application (emphasis mine).

A Javascript hook is exactly that - it's data (in this case a flag) private to the page or application.

data-* attributes are designed to store data, not be bound to.

Again, I'm quoting the HTML 5 spec, which clearly states the exact opposite:

JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used

It then goes on to provide more details and encouragement for library authors to make use of this feature.

The problem with using class-names, even with a js- prefix, is it directly encourages the very thing you're trying to prevent: styling, which is the sole purpose of the class-attribute.

The data-attribute exists solely as a fallback attribute for application data, for which there is no more appropriate attribute, and the js- prefix convention exists solely as a work-around to the same problem: the fact that the class-attribute is entirely inappropriate for Javascript hooks.

I urge you to reconsider your point of view.