Splitting CSS?
-
CSS is powerful, but can throw Separation of Concerns out the window. A single class is often used for selection, box layout (height, width), and "theming" (color). What are peoples thoughts on separating CSS? For example, a skeletons.css file that only contains layout styles and a skin.css file that only contains theming styles.
// skeleton.css
.bigBox{ height: 40px; width: 40px; }
.littleBox {height:10px; width: 10px;// skin.css
.red {color: #F00; }
.blue { color: #00F; }// page
The browser parses the css into box and "theme" trees when it processes them. Does doing that ourselves provide value?
I have been separating my CSS documents based upon it's function since around 2004. The reason I started doing it was to easily find what I needed and so classes didn't conflict with one another. I have not used Bootstrap or W3 yet. Typically, I have a structure.css (container), a main.css for the main content including HTML controls, grid, calendar, nav, foot, and head.css. Then I'll import another for a certain page if needed. So the way you're using skelton.css layout and skins.css for coloring is the way I do it. I cannot say that is best practice with Bootstrap and others out there, but I have more control and I know what I code. And since I know what I code, it is easier to modify, since I don't have to learn anyone else's framework.
-
This may be because it's a contrived example, but I'm thinking if you're going to have a CSS class named "red", whose only job is to set the color of the given element to red, then you might as well hardcode the color right in the HTML. If you decide "red" should instead be yellow, then your CSS names are just going to cause confusion, unless you also change the name at the same time. Although I get what you probably meant to say, and that would be perhaps to name "red" to something like "error" instead--representing a state rather than details about its implementation.
Yeah, it's just contrived. The main idea was basically separating by which pass the browser uses it. Anything that takes "box-space" (changes the box layout) would be separate from things that don't change the box layout. But I was thinking in a more "what it is" way than "how it is used". I see your point. I generate a lot of html dynamically (with components or .Net with TagHelpers), so I translate states, like "error", into a predefined set of classes on the server side. I can see how that would be more difficult when writing by hand. I sort of mix. So for me, I would just have `Error Message` in my code. That might end up as `
Error Message
` in the page html, where `errorBox` defines the box, and `errorTheme` has color, rounding, etc.
-
I have been separating my CSS documents based upon it's function since around 2004. The reason I started doing it was to easily find what I needed and so classes didn't conflict with one another. I have not used Bootstrap or W3 yet. Typically, I have a structure.css (container), a main.css for the main content including HTML controls, grid, calendar, nav, foot, and head.css. Then I'll import another for a certain page if needed. So the way you're using skelton.css layout and skins.css for coloring is the way I do it. I cannot say that is best practice with Bootstrap and others out there, but I have more control and I know what I code. And since I know what I code, it is easier to modify, since I don't have to learn anyone else's framework.
Cool. Yeah, the conflicts is was what I was thinking about. Also side effects. If I keep things that change the box layout separate from those that don't, I know I can use any of the second anywhere and the layout the users sees won't be impacted.
-
Have you checked out how common frameworks such as Bootstrap [^] or Semantic UI[^] do it?
cheers Chris Maunder
I took a look. They both mix structural and stylistic parts at some levels, but separate at others.
-
RandyBuchholz wrote:
For example, a skeletons.css file that only contains layout styles and a skin.css file that only contains theming styles.
I'm fine with that, but I tend to think (and mind you, this is based on the fact that I still consider myself somewhat junior with web development) that the bigger problem is the abuse of CSS. So you lets say you have
class="bigBox"for several divs. Now someone asks you to change the style in for just one of those divs. Now you have to create a separate style for just that one div. What if you don't realize that there are other divs using that style? How do you find them? Sure, by searching, which seems easy enough but I've discovered isn't, particularly if you don't have access to all the scripts -- perhaps it's a common style sheet used across multiple web apps. The result then ends up being a mess of another kind -- lots of styles with minor variations, not to mention the potential nightmare of nested styles. And what do you name them?bigBox2?bigBoxThatJoeWanted? So, knowing that, you create separate styles based on the function of the div. So you might havebigBoxLoginandbigBoxLogout. But then your mostly needlessly creating redundant styles for the potential future of having to change the style later on. Alternatively, you could just code the style directly in the div. But that's frowned upon and worse, if you want to change the style for all the divs of a particular "look", you're back to the first problem -- searching for where the common styles are used. Or, you have styles associated strictly with the uniqueidof the element. Still the same problem. Personally, I believe that the idea of associating styles with anidor aclassis a totally farked up kludge. It's bassackwards IMHO. Tags should be what they're supposed to be -- ways to find an unique element or a set of common elements. Personally, I'd like to see a completely separate mapping, ok, use theclassandidtag values, that would map those values to the css that styles those elements. And there should be a simple rule -- an ID overrides / extends any styling that the element's class value mapped style defines. To me, that would be a clean separation of concern and make it really easy to change the style globally or of specific element without caring about whether the stylMarc Clifton said:
Personally, I'd like to see a completely separate mapping, ok, use the class and id tag values, that would map those values to the css that styles those elements. ... To me, that would be a clean separation of concern and make it really easy to change the style globally or of specific element without caring about whether the style is used elsewhere. Maybe such a thing exists. It shouldn't be to hard to actually write something like that that applies styles to elements after the DOM is loaded but before the page is rendered
I do something similar, but on the server side, with Razor. I can put semantic classes in the Razor page and these get converted to "lower level" classes when the page gets rendered.
-
Yeah, it's just contrived. The main idea was basically separating by which pass the browser uses it. Anything that takes "box-space" (changes the box layout) would be separate from things that don't change the box layout. But I was thinking in a more "what it is" way than "how it is used". I see your point. I generate a lot of html dynamically (with components or .Net with TagHelpers), so I translate states, like "error", into a predefined set of classes on the server side. I can see how that would be more difficult when writing by hand. I sort of mix. So for me, I would just have `Error Message` in my code. That might end up as `
Error Message
` in the page html, where `errorBox` defines the box, and `errorTheme` has color, rounding, etc.
I'm an old-school desktop/server developer, and I've only recently had the "chance" (? if you wanna call it that) to do web development, and I'm quickly coming to the same conclusion re: CSS that you brought up in your original post. It's an intriguing idea and I'll be sure to give it more thought. Before I learn bad habits. :-)
-
RandyBuchholz wrote:
For example, a skeletons.css file that only contains layout styles and a skin.css file that only contains theming styles.
I'm fine with that, but I tend to think (and mind you, this is based on the fact that I still consider myself somewhat junior with web development) that the bigger problem is the abuse of CSS. So you lets say you have
class="bigBox"for several divs. Now someone asks you to change the style in for just one of those divs. Now you have to create a separate style for just that one div. What if you don't realize that there are other divs using that style? How do you find them? Sure, by searching, which seems easy enough but I've discovered isn't, particularly if you don't have access to all the scripts -- perhaps it's a common style sheet used across multiple web apps. The result then ends up being a mess of another kind -- lots of styles with minor variations, not to mention the potential nightmare of nested styles. And what do you name them?bigBox2?bigBoxThatJoeWanted? So, knowing that, you create separate styles based on the function of the div. So you might havebigBoxLoginandbigBoxLogout. But then your mostly needlessly creating redundant styles for the potential future of having to change the style later on. Alternatively, you could just code the style directly in the div. But that's frowned upon and worse, if you want to change the style for all the divs of a particular "look", you're back to the first problem -- searching for where the common styles are used. Or, you have styles associated strictly with the uniqueidof the element. Still the same problem. Personally, I believe that the idea of associating styles with anidor aclassis a totally farked up kludge. It's bassackwards IMHO. Tags should be what they're supposed to be -- ways to find an unique element or a set of common elements. Personally, I'd like to see a completely separate mapping, ok, use theclassandidtag values, that would map those values to the css that styles those elements. And there should be a simple rule -- an ID overrides / extends any styling that the element's class value mapped style defines. To me, that would be a clean separation of concern and make it really easy to change the style globally or of specific element without caring about whether the stylI find that LESS, SASS, or SCSS, combined with SMACCS (see my answer above), solves quite a few problems. Let's say you have an order page and an invoice page. Let those pages be wrapped in a
divwith the classorder-pageandinvoice-pagerespectively (I stopped using ID's in my CSS since I read some good reasons not to that I've forgotten by now). Now there's a table in both pages, let's sayoverview-table. With SCSS you can now write a sort of "object oriented" CSS:/* table.scss */
table {
/* Styles for ALL tables. */
}/* overview-table.scss (or components.scss) */
.overview-table {
/* Styling for all tables that serve as an overview. */
}/* order-page.scss */
.order-page {
.overview-table {
/* Specific styling for the order page, will never be shared with anything else! */
}.something-else-order-specific { /\* ... \*/ }}
/* invoice-page.scss */
.invoice-page {
table {
/* Maybe tables have something special on the invoice page... */
}.overview-table { /\* You get the point... \*/ }}
Makes for pretty decent and separated CSS files and overriding styles for one specific page becomes a lot easier. Could be done with regular CSS, but a preprocessor makes it a lot easier and clearer. And with a preprocessor you can use variables and mixins, which can make it even easier to change a style globally or locally. Ultimately, you can still compile it to a single CSS file and include it on your layout.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I took a look. They both mix structural and stylistic parts at some levels, but separate at others.
Nothing like consistency, right? ;) For a personal answer to your question I would group your CSS semantically. Define groups of user elements (containers, sidebars, banners, text areas, lists etc). I wouldn't use adjectives (big, small etc) so instead of bigBox I'd use "box". Your 'bigBox' may evolve one day into being smaller than other boxes. You could then have a set of placement classes: "box side", "box main-content", "box callout". Then a set of use-case classes: "box callout error" Finally, you may wish to have style classes for theming, but never name the class based on their internal style. Instead of "lightblue" it could be "main-theme", or "sub-theme". This allows you to change your colours in one place and have the class names still make sense. As a postscript there's the cheat classes we all use. "bold", "small" etc. We want the text to stand out boldly, and we can't think of a synonym for bold that won't be confusing, so we do
class="label bold"instead ofclass="label" style="font-weight:bold">. Because we may want "bold" to mean "slightly bigger" or "with lasers flying out of it". I'm still waiting for W3C to ratify thetext-decoration: lasersvalue. Still waiting...cheers Chris Maunder
-
Nothing like consistency, right? ;) For a personal answer to your question I would group your CSS semantically. Define groups of user elements (containers, sidebars, banners, text areas, lists etc). I wouldn't use adjectives (big, small etc) so instead of bigBox I'd use "box". Your 'bigBox' may evolve one day into being smaller than other boxes. You could then have a set of placement classes: "box side", "box main-content", "box callout". Then a set of use-case classes: "box callout error" Finally, you may wish to have style classes for theming, but never name the class based on their internal style. Instead of "lightblue" it could be "main-theme", or "sub-theme". This allows you to change your colours in one place and have the class names still make sense. As a postscript there's the cheat classes we all use. "bold", "small" etc. We want the text to stand out boldly, and we can't think of a synonym for bold that won't be confusing, so we do
class="label bold"instead ofclass="label" style="font-weight:bold">. Because we may want "bold" to mean "slightly bigger" or "with lasers flying out of it". I'm still waiting for W3C to ratify thetext-decoration: lasersvalue. Still waiting...cheers Chris Maunder
I'll vote for lasers! :) Your naming suggestions make sense. Thanks.
-
Interesting, thanks. I've been playing with dynamic css through WebSockets and I'm doing things like this
// file A.css
.node { height: 20px; width: 20px; }// file B.css
.node { background-color: green; }// File C.css
.node { background-color: blue; }I parse these and send them over WebSockets. Using script I go straight to the CSSOM (styles collection) and delete "greenTheme" and then add "blueTheme". Or I modify the sheets dynamically. I'm not a CSS guy, so I don't know if there are big issues with using the same class name in several files. It seems to work OK.
Not sure about that, never had to change CSS dynamically like that. I could imagine you'd either send the file green-theme.css or blue-theme.css, but not switch it with AJAX or even WebSockets. By the way, when you use a preprocessor like LESS, SASS, or SCSS you can use a variable.
// green-theme.scss
$primary-color: green;// blue-theme.scss
$primary-color: blue;// theme.scss
.node {
background-color: $primary-color;
}Now you only have to switch or overwrite some variables instead of writing your complete theme twice :D See also my reply to Marc Clifton below.
Best, Sander Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
