csswizardry / css-guidelines Goto Github PK
View Code? Open in Web Editor NEWHigh-level guidelines for writing manageable, maintainable CSS
High-level guidelines for writing manageable, maintainable CSS
What naming conventions do you use for: @function
, @mixin
, %placeholder
, $variable
, $map: ('key1': value1, 'key2': value2)
and why?
Hi,
What's the "Style trumps" mean? Can you describe more about this? I'm not really understanding about this.
Thanks!
BR,
Will
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
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!
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
Hi, is it possible to add translations in other languages? For example, I want to translate it to my native - Azerbaijani language. Thanks!
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.
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:
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.
https://github.com/chadluo/CSS-Guidelines/blob/master/README.md
Would you please include this?
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.
License is nowhere to be seen.
is that MIT?
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{}
Could easily use CloudFlare like you did for your main site:
https://csswizardry.com/2017/01/moving-css-wizardry-onto-https-and-http-2/
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 li
s, 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..
Hi!
Spanish translation coming soon!
Congratulations! Fantastic guidelines! :)
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)
High-level guidelines from writing manageable, maintainable CSS
I believe from should be for.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.