My main concern is more focused towards a best practice, and to know when should I use #extend directives with classes and when with placeholder selectors? Since they both do virtually the same.
I've read a few articles where the authors would create a certain class to use them only with #extend directives. Wouldn't placeholder selectors make the compiling process more performant?
I'm thinking that maybe #extend directives should be used with classes if that class is being used by another element, otherwise these directives should be used with placeholder selectors; but I might be wrong.
If you define placeholder selector, it won't be compiled into css - it will only happen if you extend it. With class selector, it will always be compiled, regardless of whether or not you extend it. Therefore less code = more performance :)
From SASS Documentation
Sometimes you’ll write styles for a class that you only ever want to #extend, and never want to use directly in your HTML. This is especially true when writing a Sass library, where you may provide styles for users to #extend if they need and ignore if they don’t.
If you use normal classes for this, you end up creating a lot of extra CSS when the stylesheets are generated, and run the risk of colliding with other classes that are being used in the HTML. That’s why Sass supports “placeholder selectors” (for example, %foo).
Related
What is the best way of defining general non-block-specific styles throughout the site?
For example:
html
<div class="intro">
<p class="intro__text">foo</p>
</div>
<div class="profile">
<p class="profile__text">bar</p>
</div>
sass/css
.intro__text {
}
.profile__text {
}
.text {
margin-bottom: 0.5em;
}
If I wanted the text to be styled the same, would I (given I am using a pre-processor) #extend .text into the .intro__text and .profile__text classes, or just have all paragraphs throughout the site have a class of text?
Both those solutions seem slightly incorrect to me.
If I have a very common style, it feels like I'm going to be duplicating a lot of styles throughout my rendered css (bumping up the filesize) but having a class of text repeated all throughout my markup seems unnecessarily verbose and untidy.
Is there a best practice for this situation?
I can't say that there is the best way to do it. It depends on the structure of your project and what style your prefer. Both approaches are used in mostly code.
If you like to manage styles through css files - write #extend. However in case you want an element without common style you have to create a modifier for the el. For example - .profile__text--reset.
If you want declare common styles, your class list with common classes may become too long. But it is more clear and specific. And you have a possibility to manage it via javascript.
One improvement for this code is that it is better to use helpers with modifiers. For example, instead of simple .text use .text--sm or .text--m-sm. Or if you want only margin - .m-sm. But it is up to you.
You have several options:
Preprocessor (Sass/LESS/etc) mixins + clean-css/postcss cleaner — this way is simple and powerful, but not flexible, since it's not useful for dynamic landing pages, SPA, etc.;
Element of outer block mix (BEM/runtime mixin): class="intro__text grid__text" — in that way you just splitting manually visual and positioning styles and use their classes together;
Other block mix: class="intro__text paragraph paragraph--valuable" — almost like the previous variant but without linking to the abstract grid block, the best and the most flexible way (IMHO).
NB: Also you can extend BEM mixes with modifiers even in runtime, it's VERY powerful tool.
NB2: If you don't need dynamic web pages, you can freely use sass mixins. Personally I don't use sass/less mixins, only global variables for colors, grid, gaps, etc used in my own classes.
Does a css class selector always require a definition? For example, if you found in the html: div class="banner", should you always find a .banner in a css file? I ask this question as I've been looking at some website themes and I sometimes find these selectors without any other reference. I'm just not sure if it's an oversight or something common.
There are many reasons to have class names on your HTML elements without having CSS rules associated with them. A couple of examples:
More readable markup. If a component is properly labeled, it's easier to find, debug, or work collaboratively on.
Javascript. Sometimes an element requires some Javascript behaviors, but doesn't inherently need CSS styling itself.
So to answer your question: No, you do not need to define each class or selector in your CSS.
I have several styles that use Sass' #extend or #include to inherit properties from selectors imported from Bootstrap scss files.
I would like to convert all of the Bootstrap selectors to #extend-Only placeholders, so I do not have to include any original Bootstrap selectors in my final .css output. The goal is to write my own css classes, extend from Bootstrap only where desired.
For example, I wish to have a navbar called .super-freaky-nav:
.super-freaky-nav{
#extend .navbar;
#extend .navbar-default;
#extend .navbar-top-fixed;
}
Ideally, my final .css output will not have a single reference to .navbar, .navbar-default, or .navbar-top-fixed.
Is there a way to do this without going into the _navbar.scss file and converting all of the selectors to #extend-Only classes (%navbar, %navbar-default, %navbar-top-fixed, etc)?
Thanks!
No. Sass does not have the ability to do what you're asking for. There's still a legitimate need to be able to extend normal classes and Sass has no way of differentiating between classes that should or shouldn't be extended.
One potential implementation I'm exploring uses custom importers in ruby-sass or the experimental importers feature in node-sass (2.0+) to apply a sed (find and replace) transform to the Bootstrap Sass files, replacing leading class definitions with % syntax. I haven't gotten much past experimentation, though, and I don't know what I might break without a comprehensive visual test suite. Happy to have some help with it.
When a JavaScript library creates a <div>, it typically sets a class on the div so that the user of the library can style it him/herself. It's also common, however, for the JS library to want to set some default styles for the <div>.
The most obvious way for the library to do this would be with inline styles:
<div style="application's default styles" class="please-style-me">
...
</div>
However, this will make the application's default styles trump the user's styles. A workaround is to use nested divs:
<div style="application's default styles">
<div class="please-style-me">
...
</div>
</div>
This works great for many styles like 'font' but fails for others like 'position', where the inner div's style will not override the outer div's.
What is the best practice for creating user-stylable elements with defaults in a JavaScript library? I'd prefer not to require users to include a CSS file of defaults (it's nice to keep your library self-contained).
When a JS library has a default set of styles that should be used, but should also be overridden, the JS library should include a separate stylesheet.
JavaScript should avoid adding styles directly as much as possible, and defer all styling to CSS where it's reasonable.
It's common for sets of styles to be toggled on and off. The way to elegantly handle these situations are with CSS classes.
A case where it may not be reasonable to simply use external stylesheets is animation. CSS animations could certainly be used, but for cross-browser support, asynchronous interpolation is used to animate styles from one value to another.
There isn't !notimportant or !unimportant in CSS. And I haven't run into an accepted best practice. It seems like a CSS file is the defacto standard for styles that should be user modifiable.
But if you want to keep things all in one library, I would take your second example, with your application default styles, then append a CSS class to it and prepend something unique to the class name. Then if the implementor wants to override your styles, the implementor could just use !important to override your user styles.
Adding !important to one or two styles in a CSS file shouldn't be a huge deal, but if you're creating a bunch of inline styles, this may not be the best solution.
Lets say that youre using Twitter Boostrap and you have their generic boostrap.css and other boostrap associated css files, and you want your own classes to have identical attributes to some of the given boostrap classes. To my understanding, you would not want to directly modify the css bootstrap files, but you would want to extend them by creating a custom.css file.
So without touching the boostrap files. How would I replicate a boostrap class for my own class? Would the only way be to copy and paste from the boostrap.css file. Or is there a way to do
.myownclass {
-- some command to replicate class 'alert alert-error' without repeating the CSS that has already been written
}
You could use a css preprocessor. Other ways already cited by other users are fine but using a css preprocessor is the best way.
Bootstrap is built using LESS, so you can use LESS. Take a look at here: http://bootstrap.lesscss.ru/less.html.
Also SASS can be used. According to me SASS is better. You find a tutorial here: http://www.1stwebdesigner.com/css/build-website-using-twitter-bootstrap-sass-1/
What are CSS preprocessors?
A browser can only understand CSS, as the styling technique for any DOM element being rendered. CSS, as a language has its own feature set, which at times might not be enough to create a clean and reusable chunk of rules. Eg. Not being able to reuse a collection of rules in multiple selectors, unavailability of variables which may lead to ambiguous pieces of data across the stylesheet. To overcome most of these limitations, the concept of a preprocessor was born – offering an advanced way of writing CSS, which extends the basic functionalities. This advanced code is later compiled as normal CSS code using respective compilers (which depends on what preprocessor you are using), which the browser will understand.
Should you use preprocessors?
The decision of adopting preprocessors for your next project, in my opinion, should be made after much analysis and solely depending on your expertise level and most importantly the project requirement and workflow of the team as a whole. Here are some tips that might help you come to a decision:
Not for beginners: If you are a beginner and starting to explore the fantastic world of CSS, I would suggest you get your hands dirty with normal CSS before moving into a framework or preprocessor of any sorts. It’s really important to understand and be able to use the core concepts of any language that you work with, and that’s true for CSS as much as any other programming language.
Are you a team of front end developers? As a team of front end developers, adopting preprocessors will be a great move. But only if somebody on the team really knows how to handle huge CSS files and structure them accordingly. By making use of the powerful features offered by the language, it is important to first structure the whole CSS into reusable chunks and define a strategy for CSS organization. Eg. Are you going with multiple CSS files for typography, forms, layout etc. Are you going for theme-able UI, where you might need to use variables extensively, etc.
Are you willing to cross the barrier? Adopting preprocessors means you are going to be implementing more programming concepts into your CSS coding approach. There will be a lot of concepts that are native to any basic programming language, which you might want to learn and implement, by using a preprocessor. This means, you will definitely need to brush-up your programming skills and might forever change the way you see a CSS code. If you are willing to cross this barrier, and feel ready to embrace the change confidently, this is for you.
In CSS this is not possible. The only way to do it, is to chain the classes in your html tags.
<div class="alert alert-error myownclass"></div>
If you are using less you can do it like this:
.myownclass {
.alert
.alert-error;
}
This will copy the settings from one class to another. The result will be the same as if you copy the contents of the class directly.
If you are using Sass you can do it without copying the class contents. Just reference the classes as shown below. This will not copy the contents, instead it will reference your custom class at the right position in your css code.
.myownclass {
#extend .alert;
#extend .alert-error;
}
Ref: Sass #extend
You would have to use LESS to avoid copy/paste:
.myClass {
.bootstrapClass;
}
Or you could use any of the other CSS preprocessors TBS has been ported to (Sass has one, not sure on the others).
You could give the element two classes - the original Bootstrap class, and then one of your own making. Then you would target it like this:
HTML
<h1 class="original_class myownclass">Hello</h1>
CSS
.original_class.myownclass {
// css code
}
Here's a little jsfiddle illustrating the concept: http://jsfiddle.net/ApEpr/
This does not require the use of a CSS preprocessor - it's just regular old CSS.