I really liked modular architecture by smacss.com/book/categorizing. But in real project I stumbled on simple case (as I thought).
ok, what I got:
1) I created a folder structure for my css-files by smacss:
Base
Layout
Module
State
Theme
2) In folder Module I've made a file with base modal windows styles, like this:
Base
Layout
Module/modal/modal.css
State
Theme
3) But I have a few types of modal windows with common styles (which I separated in modal.css - colors, borders, positions etc), but they have their own parameters. First window is very simple with two buttons, second has a lot of different content.
Question is: where should I put styles for these two windows?
a) Create folders for them as modules:
Module/modal/modal.css
Module/confirm/confirm.css
Module/product/product.css
b) or create for each css-file and put them in Base folder?
Base/confirm.css
Base/product.css
Module/modal/modal.css
I would be glad to get any advice. thank you
the main reason to use SMACCS is to organize your CSS files, therefore, there are a lot of approaches which totally depends on your project.
According to the author, as long as you keep the concept of SMACSS in your mind, you then are able to modify your project as you wish. So, what I recommend you is to have a look at your project and check your folders and files and just do whatever it makes sense more not only for you but also for other developers in the team or in the future while reading your code.
There are only two main goals that you should bear in mind:
A Base rule is applied to an element using an element selector, a
descendent selector, or a child selector, along with any
pseudo-classes. It doesn’t include any class or ID selectors. It is
defining the default styling for how that element should look in all
occurrences on the page.
and
a Module is a more discrete component of the page. This is the
meat of the page. Modules sit inside Layout components. Modules can
sometimes sit within other Modules, too. Each Module should be
designed to exist as a standalone component.
so, with this clear definition, you know now that if your rules should be standalone put them under the Module, however, if they are going to work as default to the elements so put them under the Base. In contrast, to me Product or Modal all can be Module and they are not Base as base are clearly stated as default element rules like I said on top.
I am just concern that you have written CONFIRM which looks like a State rules and I assume it can be placed under State folder.
A state is something that augments and overrides all other styles. For
example, an accordion section may be in a collapsed or expanded state.
A message may be in a success or error state.
I strongly recommend you, read SMACCS book or website one more time and have a look at one of the Jonathan Snook workshop that can be found on Youtube. It will help you to understand more and make a better decision.
Related
For an organization I work for, there is a common stylesheet that all web applications are supposed to use.
For example, they expect some elements to be in thead.table-sortable th.table-sortable-sorted-down a:after to add a sorting icon. Now, in an Angular application, I use a component library (primeng) that has a simple element that just has the class .pi-sort-up for the same thing.
How can I map / copy /use part of the organization css into my application's css, to just copy the interesting stuff without requiring the complicated nesting on component (which I have no real control on anyway)?
We could use css, sass, or even dynamically generate css rules in javascript. I'd prefer avoiding changing the DOM at runtime for all matching components, as it could be quite dynamic.
EDIT: A build-time solution (e.g. with sass) isn't the preferred way, but could be acceptable if nothing else.
If the company style sheet is readonly for you, there is not much you can do at all. You will have to load the whole document wherever you need some parts of it. A possible "workaround" to avoid that would be to write a backend program (in PHP or node.js) which opens the company style document and looks only for a specific CSS rule which it then copies and pastes to some other style document.
However, this approach would be very dynamic as well and you needed to execute the backend script with each request, for the original company style sheet could change always... If your company could agree, you should use a preprocessor like SASS or LESS and define a structure for the company style, dividing it into several documents that can be loaded on purpose.
So I've recently started making more use of EJS templates in my website and so I've done things like broken out the top nav bar and other things into their own template. Is there a standard practice for how to organize CSS (or more specifically SCSS) with that? Should I just make a matching SCSS for each template with just the styles for that template and add the <link/> in each page that uses the template? Or just I just add <style/> tags to the template itself with the CSS in there. Is there a standard pattern for this?
Good question. I think the answer is "no", there is no universally best or accepted standard.
The advice my "work-mentor" always gives me is good advice: he says "do what will be the easiest to maintain". This would depend on your project. I can think of a couple general strategies:
One stylesheet per template
That is, in a way, the simplest suggestion. Probably the easiest to develop, and each page will bring the minimum needed styles.
However, this makes reusing styles pretty impossible. You won't be able to plunk in a <button class="myclass"> into any template without reincluding the styles for .myclass in every sheet you need them in. Also, if you ever want to automate your style sheets (minifying or concatenating them for production, etc) as is common practice, it won't be very possible from here.
One more downside, you might get some unexpected ordering effects. Like if your "widget.css" ends up being added to the DOM after your "article.css" it may override styles in a different way than it would have if it had appeared earlier in the DOM.
All styles on every page
Again, this is nice and simple. Every page has all stylesheets (or maybe just one giant sheet) included. You can link to it once in your outer layout template. It will be easy to automate minification, etc, and there will never be any surprises related to the order stylesheets are added in.
The obvious downside is lots of unused styles brought to each page. But css is pretty "cheap" in terms of size, so this may not be such a bad downside.
Somewhere in between
Include some styles on every page, and make some either page-specific or template-specific. Realistically, this is probably what most apps end up doing.
You can universally include utility styles meant to be reused (ex button.bigred, form.orderform, etc), as well as dependencies like bootstrap or whatever. I'd also advise including any styles you will need on more than half of your pages (ex styles for your navbar).
Other styles intended for one specific page can be added to that page directly via links.
last note
I try to avoid <style> tags in the html for a couple of reasons:
Lots of js libraries dynamically add or remove <style> tags to your DOM, so leaving that space clear for them avoids possible mistakes or overlaps.
They are a good way to add dynamic or user-managed styles to pages from within your templates. Keep styles that don't change in the stylesheets, to avoid possible mistakes or overlaps with yourself :)
I'm writing a Chrome extension that injects HTML into a displayed page. I want the injected HTML to have it's own style, protected from the CSS that may be present in the host page.
I've tried using conventional CSS, and still suffer from style corruption from the host page.
After watching the Polymer presentation from I/O 15, I was wondering if there are any new, Chrome-specific techniques that I can use to achieve this?
What you will want to look into is shadow-dom. This will enable you to create a widget/component (which would be your injected html). This would mean that the DOM tree for the widget/component is encapsulated and no external styles from the page will affect it. There is a good article on html5rocks covering this. You may also want to look into WebComponents. Bear in mind that this functionality is only available in the latest browser versions.
Two things that I currently use at my place of work are:
css-modules
react-css-modules
I use react at work, hence react-css-modules, but css-modules should work in your case. It's not Chrome specific, but we use them within the context of each component we build. Basically, like the docs state, a class of row would become something like table__row___2w27N. The breakdown of the built name is the filename of the CSS than the class name followed by a base64 hash of 5 char. I hope this helps.
One potential downside is Webpack would be required.
Here is an example of our component folder structure:
- component
- Component.jsx/js
- component.css/scss/sass
- component.test.js
I've started a Rails project and implemented bootstrap-sass into it. A short time later I found a theme/template using a different version of twitter bootstrap. I've added the template to the app but the view doesn't align perfectly as was intended. I then added the specific assets that came with the theme/template to my project (such as jquery version, ANOTHER older bootstrap version) and the result is almost perfect. However, there are still some alignment issues. When I inspect the CSS I can see it's happening because of conflicts between the two versions of bootstrap.
I'm thinking I should make it so that this template only uses the version of twitter bootstrap that came with it. If so, how do I do this? How do I make it so that a rails view will only use a certain css stylesheet and not read from others?
(If this is not the best solution, what are some alternatives I should consider?)
Thanks
Try this out:
1) use 2 layouts (application.html.erb and new_application.html.erb)
2) have two master javascript/css file (application.js and new_application.js, application.css and new_application.css)
3) inside your application.html.erb include the first application.js and application.css, on your second layout, import the new application js and css
4) for the specific parts of your page, on the controlle inherit from the right parent controller for whichever layout you want.
class NewBootstrapController < ActionController::Base
layout 'new_application'
end
class OldBootstrapController < ActionController::Base
layout 'application'
end
Best practice is to try to view your project as consisting of "components" rather than pages. So focus on keeping the styling for your components up-to-date and consistent.
So rather than coding for individual pages, which doesn't scale and is difficult to maintain even with small(ish) projects, look for ways to turn elements into reusable components. Bootstrap is this way by default, so if there are certain components you use more than others, make those the priority for refactoring, and then look for repeating patterns across your pages and try to think about how you can create semantic, component-based classes to describe them.
Instead of this:
.sidebar-home {}
Try this:
.sidebar-narrow {} // or whatever describes your element
The operative point here is that if you will ever work on more than this project, get into the good habit of thinking about your CSS/HTML as consisting of components, and you will be able to reuse code and become much faster at identifying patterns in your UI.
I'd been reading up on themes in my ASP.NET book and thought that it could be a very handy solution, then I met some problems.
The theme picks up every single CSS file in the folder
If you want to use reset styles (where ordering is important) the order of imported stylesheets is not guaranteed
Your master page would not explicitly indicate what style is being used, only the rendered page can tell you that unless you dig into your web.config
Styling web controls using the theme file is... well... stupid? You can simply do this in your stylesheet. Granular control should be at the HTML level, should it not?
How do you specify print stylesheets without having all styles in a single stylesheet?
I'm wondering as to whether they're actually worth using at all. Is there any benefit? Are there any major sites using them?
EDIT
Just to clarify slolife's last point. If I had two stylesheets, one called print.css and one called main.css and I used ASP.NET themes, how would it know that print.css was a print stylesheet? In regular HTML you use the media type in the tag itself (i.e. <link rel= ...>) but the themes wouldn't know this, so it would just get included as a regular stylesheet.
I like using themes, but as Raj pointed out in his answer, URL rewriting can cause problems. My search for some solutions to that is what led me to your question. But I'll add my opinions in anyway.
I'll address some of your bullets from above as to why I think themes are good:
- The theme picks up every single CSS file in the folder
I guess you are looking to apply only certain stylesheet files to certain pages. Yes, themes takes the shotgun approach here, so that's a problem. But you don't have to put all stylesheets in the the theme folder. Put your specialized ones outside of it and they won't be included automatically. But I think it is nice feature to have the common/site wide ones included automagically.
- If you want to use reset styles (where ordering is important) the order of imported stylesheets is not guaranteed
I think you can guarantee the order by the way you name the files, so they are numerically and alphabetically ordered. Maybe not an elegant solution, but not horrible.
Personally, I have a build step that combines and compresses all of the *.css files in my theme folder into one single style.css file, and since I control that build step and the order that the files are combined, that doesn't affect me.
- Your master page would not explicitly indicate what style is being used, only the rendered page can tell you that unless you dig into your web.config
You can change the theme via code and in the <%#Page directive
- Styling web controls using the theme file is... well... stupid? You can simply do this in your stylesheet. Granular control should be at the HTML level, should it not?
I agree that applying style attributes to controls via the theme doesn't seem to be a best practice. But I love the fact that I can define image skins in the theme's skin files and don't have to cut and paste Width,Height,AlternativeText,Align attributes for common images that I use lots of places throughout the site. And if I ever change one of those images, I can fix the attributes in one place, rather than all over. I also can created skinned controls with a certain list of css classes applied, which seems handy to me.
- How do you specify print stylesheets without having all styles in a single stylesheet?
I have a Print.css file that starts with #media print and that defines print styles for my site. Why do you need to put them in one stylesheet?
IMHO, asp.net themes are absolutely USELESS
try implementing url rewriting with an app which uses themes and see them break straight away
basically, you can achieve the same thing writing few lines of code in asp.net and multiple css folders. i am yet to come across any developer / company who has been using themes
when asp.net 2.0 was launched, there was a big hype around themes but my personal opinion is its simply not worth it :-)
Use themes to change control attributes ONLY.
They were bad designed for working with css.