I am just getting started with less. In an attempt to mmake less ugly Bootstrap's multitude of classes on tags, I have attempted to write some simple wrappers in less.
The entireity of my code is below.
// Import boostrap.
#import "./less/bootstrap.less";
// General classes for content.
focus {
.span12;
}
content {
.span8;
}
side {
.span4;
}
The purpose of this less file is to provide nice looking wrappers that do a single thing, such as Bootstrap's .span12 class. I will, in time, extend this to buttons of sorts.
Either way, I am running into a problem when compiling the less file using lessc style.less.
The error it gives is:
NameError: .span12 is undefined in /srv/http/www/style.less on line 6, column 5:
5 focus {
6 .span12;
7 }
I have found some documentation with the .makeColumn(i) class but the problem with that is Bootstrap already has perfectly good media queries and I wanted to avoid writing my own.
Is there anyway to wrap the classes that already have the media queries or do I need to just suck it up and write my own for my wrappers?
You are going to run into a few major problems in this approach.
First, there are issues in that Bootstrap is dynamically generating the .spanX series of classes, so they are not immediately accessible as mixins, as I note in this answer.
Second, some of Bootstrap's span code is not set by the .spanX series, but is done through an attribute selector of [class*="span"] (see, as of this writing, line 602 of the mixins.less file; they are also extensively used in the responsive files for the #media rules). This selector code would not be picked up by a .span12 inclusion of code, and if you are not putting .span12 in your code, then your code will not have those properties applied. So you need to work around that.
There may be other issues not immediately obvious, but the point is, if you want to use Bootstrap for grid purposes (especially responsive), it is probably best to use it as it is designed. If you do not, then it is best to go and copy the Bootstrap code and modify it as you desire to make your own reduced grid code (if your intent is to use less overall classes in your html).
Related
i feel like this may be simple enough and I'm just missing it. I recently went to 7-1 folder structure instead of a single scss file. What i'm having difficulty with is referencing .panel(or h2 or span) in _typography.scss to do font-styling and reference the same .panel(h2,span, etc) in my _layout.scss.
I understand from a CSS pov this wouldn't be logical to have them broken up as of sequencing, however, from a sass pov, I feel like there should be a way to structure this so my CSS doesn't have .nav-container mentioned twice.
Just to note, I'm using NPM, not an ide compiler. Maybe I'm just going about structuring generally incorrect and shouldn't separate them.
Please advise,
UPDATE ANSWER
I've marked Frish's answer here correct because the way that they set it up is correct, but after several and i mean several days of research, i've decided to add some context as I see many others have created simiar threads.
The way I initially looked at SASS was incorrect. I was trying to make SASS work in a way i thought would eliminate complexity: (having .nav-container {} typography rules in a typography partial, then .nav-container {} layout in a layout partial.) This isn't the right way of thinking.
The real benefits are all the built in functions (placeholders,mixins, extends) that drive the magic of making SASS more effective.
However, there is a way to still do what you're looking to do, styling selectors across different partials, for example, separating typography styling from layout styling, and so forth, for particular selector. This was a major wakeup call. Passing Style Blocks (or Content Blocks) to a mixin or whatever. So for example:
#mixin button {
font-size: 1em;
padding: 0.5em 1.0em;
text-decoration: none;
color: #fff;
#content;
}
.button-green {
#include button {
background: green
}
}
Finally,
this link(https://openclassrooms.com/en/courses/5625786-produce-maintainable-css-with-sass/5951856-write-cleaner-code-with-sass-extensions) is where it really clicked for me
Look at the section paragraph that starts with "extensions are a lot like mixins." Review this example as it should be easy to apply its setup and way of structuring to what you're trying to do.
Getting deeper into this, i did some googling on "passing style blocks" and "sass passing content blocks" and that helped a ton on how to leverage placeholders, mixins, and extends effectively while still maintaining the simplicity of sass structuring.
This isn't a concrete answer as there are many ways to approach this (as you are undoubtedly aware), but here are my thoughts.
I typically use generic stylesheets (_typography, _layout) for generic elements (h1,h2,h3, .section, .container perhaps). Any element that merits special mention in multiple files potentially merits being its own component (e.g. panel.scss).
This does increase the numbers of folders and files floating around, but I still find this preferable to one, or a few, big files. I usually end up with a main.scss file that looks like this:
// main.scss
#import "_variables.scss";
#import "_typography.scss";
// etc....
#import "./components/panel.scss";
#import "./components/navContainer.scss"; // or, nav-container.scss!
// etc....
Components happily override generic styles, and I can track their CSS in individual files. Happy dev! You can sub-divide components or other files as you see fit.
I have some h1, h2, h3 and a lot of bootstrap snippets that I want to apply only to a specific part of my site, I added a unique class, say .unique but it would take hours to prefix over 1000 of CSS lines
I use sublime text
Thanks in advance
You could use a CSS-preprocessor like LESS or SASS (there are more). Both can do what you want, by just doing this:
.unique {
// Old CSS goes here
}
The have many other advantages over normal CSS.
common I would like to give you some ideas, cause i think your question has something to do with control css overriding.
the Jost's LESS or SASS solution is very good actually to prefix cause can use nested css features, but it requires a compile process, their eventually compiled files are still css. cause the .less or .sass files can not be recognized for html to render styling.
Another thinking To avoid css conflicts and wrong overriding,
Instead of including global styling, see if you can embed them in part of the specific section/page where they can get higher priorities than the rest global styles.
even the same css, generally, !important > inline css > internal css > external css
or javascript can trigger css override after previous css finished rendering on the page.
Instead of using css priorities or script running priorities to override styles, making two external mobile.css, destop.css for example, then using javascript to reload page to include different stylesheet when device width are detected to have been changed in browser resizing behavior.(This is one pop way used in responsive view)
using IDE to locate css patterns and replace them with your prefix if it's simple to match all the patterns.
So I know you can extend Foundation classes once you have the Foundation scss/css included and I know you can include the classes to the dom (OOCSS style) but here's my use-case:
I have style sheet, menus.scss. This is compiled into app.css along with Foundation.scss.
I can use the #extend here because I'm including Foundation before it.
#menu {
#extend .top-bar;
}
THE PROBLEM
Now, say I want to compile a separate sheet (because maybe it's only included on some pages)
Now if I #import Foundation into this stylesheet I will end up with the framework included twice (which is crazy of course.)
So... maybe a solution would be to have a version of the Framework that works on silent classes EG: %top-bar so I can include Foundation everywhere without fear of duplicating lots of code. I know there are some base components that will need to be included globally so that the sub-classes will work but how else can I do it?
To my knowledge silent frameworks don't exist so I'm looking for alternatives..
Ideas?
It will be perfect if you can isolate css critical to the initial page layout like grid, type, visibility components and inline them in to the page head or, if you have a ton of pages, in css file with the final size under 1-1.5k(really hard to do).
Then you can just defer auxiliary css and their size wont matter much.
Or You can use some css cleaner tool to remove selector duplicates or just make your own, it's pretty simple since the entire blocks of css will match.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Zero-D
Everybody starts using CSS with a single file that contains all the styles.
style.css
1D
Soon it becomes bulky and one decides to group CSS in a number of files by page elements:
html_elements.css
header.css
main-area.css
footer.css
Some may find this not convenient enough and group styles by function:
typography.css
layout.css
sticky-footer.css (contains declarations for many elements, not footer only)
2D
When a project has a lot of CSS, it might require using both groupings simultaneously. CSS files structure becomes two-dimensional:
layout/
grid-system.css
header.css
sidebars.css
look/
typography/
main.css
headers.css
lists.css
backgrounds/
html_elements.css
header.css
main-area.css
footer.css
Okay, the example is fabricated, but you sure do understand what i mean.
Up to this point everything is fine.
Enter Media Query
This is where my CSS structure gets funked up.
In addition to the 2D structure described above, i have to structure my code by media queries:
Some of my styles are universal (applied everywhere)
Some are applied to certain screen size only:
small;
medium;
large;
extra large.
Some are applied to certain groups of screen sizes:
everything except small (non-mobile styles);
small and medium (where sidebars aren't at the sides)
large and xlarge (where you do have sidebars)
I tried to overcome the issue by scattering media queried styles among existing CSS files. The breakpoint Compass extension helps a lot, but the stylesheets become too messy. Finding a certain style when it's not portrayed in the files structures a lot of pain.
I tried grouping by media queries, then by elements and function. But files structure is two dimensional, so you can't add a new dimension, you can only add another level of hierarchy. So, it's not graceful. Also, it's very bulky.
So i end up with a 2D structure with media queries on one axis and an ugly mix of elements and functions on the other axis.
I'm absolutely not satisfied with that but i just fail to come up with a graceful solution. Please suggest one.
CSS is already a structured language. For better or worse, the order of your code changes it's meaning. Because of that, it's important that any CSS organization scheme is dictated primarily by the cascade. The other structural aspect of CSS is semantics. Use it to your advantage. The concern of organization is keeping things meaningful and maintainable. The best thing you can do to retain meaning is to show relationships. Relationships are already expressed by semantics.
Put those things together, and you end up with code organized by specificity first and then semantics, but never by external concepts such as type vs. layout or screen-size. Here's my naming scheme:
base/
- Sass imports and settings - no CSS output.
- e.g _grid, _colors, _rhythm, etc.
general/
- Initial CSS baseline with resets, defaults, font imports, and classes to extend.
- e.g. _reset, _root, _fonts, _icons, _defaults, etc.
layout/
- The rough outline of the site structure.
- Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography.
- e.g. _banner, _nav, _main, _contentinfo, etc.
modules/
- All the details. First by effect (classes/general), then by widget (ids/specifics).
- e.g. _users, _admin, _product-lists etc.
Media-queries should stay as close as possible to the code they affect. When possible, they go directly inline (with Sass media bubbling). If that becomes bulky, they move outside the block, but never outside the partial. MQ's are overrides. When you override code, it is especially important that you are able to see exactly what is being overridden.
On some sites, you may take this structure farther. I've occasionally added two folders at the end: plugins/ to manage 3rd-party code, and overrides/ to handle unavoidable (try to avoid them!) location-specific overrides to a widget. I've also gone deeper, adding a fonts/ folder with partials for each font family, or a users/ folder with partials for adding, editing, viewing, etc. The specifics are flexible, but the basic organization remains the same:
Start general.
Move towards specifics as slowly as possible.
Never divide based on any external concepts (type/layout, screen-sizes, etc).
why not try something like this:
/root
/modules
/header
/html
header.html
/css
module_styles.css /*Configure which style sheets are included with #media rule in this file*/
/at-media
small.css
medium.css
large.css
/js
fancy-nav.js
/site
includes.css /*use #import to include each modules stylesheet in a file here and let each module control its own media issues*/
What I wind up doing is your 2D solution (although mine has some more nesting) and using Breakpoint to write my media queries in line when needed. One of the things we need to deal with is our output CSS isn't going to look the same as our hand-written code, it's a reality of using a CSS preprocessor and specifically abstracting things around. Soon, Google Chrome's dev tools are going to come with built in Sass partial support, and there is FireSass
for Firefox to help you figure out where styles come from.
Hope these help!
Ok so this is more a question of personal taste and may be not really answering the question but here is my contribution:
What I do is a "2D" organization like you say, with a lot of less files (let's say we are speaking css with less preprocessor)
I found it easier to use media queries in the same "less" file of the element I am styling.
So for example I have header.less and in the same file, its media queries.
#header {
...
}
//Header media queries
-----------------------
#media screen and (min-width:480px) { ... }
#media screen and (min-width:768px) { ... }
Now, Why I choose to do it that way ?
-> Because (for me) it's a huge pain in the... to have to look in another file (say responsive.less for example) , search in it the media queries for header, do my changes.. etc. Instead, with this method I always know where my media queries are and they are easy to reach / modify for each element and this does not add many more lines to the code.
The only problem with that is that when the css is generated, we end up with media queries for single elements spread all over the css code. Not very beautiful! (at this time less/winless does not group automatically media queries.)
I ended building a small app to group media queries: http://nokturnalapp.com/mqhelper/
I use it to build the css files for production. (it's not finished yet, I need to add the code stripped from the media queries version but have a look at it.)
I hope this helps you in some way.
After working on several large web applications, and seeing gigantic style sheets with no clear structure, I'd really love to know if people have found ways to keep their css clean for large and complicated web apps.
How do you move from a legacy, mess of css to cleaned up, nicely cascading, DRY stylesheets?
The app I'm currently working on has 12000 lines of css. It's grown to this size organically as early on there were no standards or review of the css, the only rule was to make the app match the design. Some of the problems we constantly have:
Conflicting styles: one developer adds a .header { font-weight: bold;} but .header was already used in other modules and shouldn't be bold in those.
Cascading problems: Foo widget has a .header but it also contains a list of Bar widgets with .header classes.
If we define .foo .header { ... } and .bar .header { ... } anything not explicitly overwritten in foo will show up in bar.
If we define .foo > .header and .bar > .header but later need to modify foo to wrap header in a div, our styles break.
Inheritance problems, we constantly redefine widget fonts to 11px/normal because some top container uses a 12px / 18 px line height.
Fighting against widget libraries, using libraries such as dojo/dijit or jquery ui that add tons of styles to be functional means that our code is littered with places where we have to override the library styles to get things looking just right. There are ~2000 lines of css just for tweaking the builtin dijit styles
We're at a point where we're thinking of implementing the following rules:
Namespace all new widget classes - if you have a widget foo all sub-classnames will be .foo_ so we get: .foo, .foo_header, .foo_content, .foo_footer. This makes our css essentially FLAT, but we see no other way to organize our code going forward without running into the legacy styles or the cascading problems I mentioned above.
Police generic styles - have a small handful of generic classes that are only to be applied in very specific situations. e.g. .editable - apply to portions of a sentence that should invoke an editor - should only contain text nodes.
Leverage css compiler mixins To avoid repeatedly defining the same styles in different widgets, define and use mixins. Although we worry the mixins will get out of control too.
How else can we move from css mess that constantly introduces regressions to something maintainable going forward.
We're using a style guide in the form of a simple HTML page with examples of every CSS rule in the stylesheet. It's very easy to tell if you add a new, incompatible rule since the examples are aligned on top of eachother.
An example I like: http://getbootstrap.com/components/ (added 2015)
The other pro you get from this method is reusability: you know what you got and you know that you want the style guide to be as small as possible - therefore: reuse.
When you make changes to styles already in use: check the style guide. If it doesn't change it's probably good (you might need to browse around a bit if you've just changed something including box model-issues, or width, height, padding, margin in general).
How do you move from a legacy, mess of
css to cleaned up, nicely cascading,
DRY stylesheets?
Use the style guide as a unit test. Once you got the essential parts in it: reduce, refactor and combine (you most probably will find some collissions between .campaign_1 span and your regular rules, inheritance can be your friend).
Conflicting styles: one developer adds
a .header { font-weight: bold;} but
.header was already used in other
modules and shouldn't be bold in
those.
In reply to Adriano Varoli Piazza's comment and the quote above: I don't recall this as a problem fully belonging to the CSS but more to the HTML markup. No matter what you do, it will be some heavy lifting. Decide which rule you'd want to keep and take actions towards cleaning out the lesser-used-ones; for example: via inheritance: #news a .header { ... } or renaming the HTML-class a .stand_out_header { ... }.
About the following idea
Namespace all new widget classes - if
you have a widget foo all
sub-classnames will be .foo_ so we
get: .foo, .foo_header, .foo_content,
.foo_footer. This makes our css
essentially FLAT, but we see no other
way to organize our code going forward
without running into the legacy styles
or the cascading problems I mentioned
above.
Use a containing element instead, which will be much more easy to maintain:
<div id="widget_email">
<h2>One type of h2</h2>
</div>
<div id="widget_twitter">
<h2>Another h2</h2>
</div>
I find that the method for "namespacing" and limiting conflict in CSS is separate into different includes what you want to apply, so each page calls only what it needs. Conflicting rules can then be made more specific simply by defining them in a more particular include:
general css for all pages
css for pages in section A
css for pages in section B
So if you find a .header modification you added in the general css works in A but doesn't in B, you simply move it to the lower CSS file.
Yes, this implies more files to load. There are ways around it with server-side languages, like reading all files with php and sending only one block of content.