I'm still getting to grips with SASS. I want to check within a selector whether or not an element is within a certain other ancestor/parent element.
I have this:
p.key-name {
float: left;
padding: 4px 32px 0 2px;
}
li:last-of-type p.key-name {
padding-right: 0;
}
Works great, but is regular CSS so no surprise there. But I'd rather have that second selector grouped within the first, so I tried this:
p.key-name {
float: left;
padding: 4px 32px 0 2px;
li:last-of-type & {
padding-right: 0;
}
}
That doesn't work. I can see why by looking at the processed CSS, but I'm wondering if there's a way of using SASS to make this notion work.
Thanks for any help offered!
Edit: As explored in the comments, it turns out that the code works but there's a parent <li> higher up the hierarchy interfering due to a lack of specificity in the SASS (i.e. no class or anything more qualifying on the li:last-of-type). So the two snippets above are in fact equivalent _as long as there are no <li>s surrounding these ones.
Related
Precursor:
Under normal circumstances, I would never do this.
I have a CSS file that I am currently collaborating on with another person. I built the file initially, then they have added rules to it after the fact. But, instead of adding rules to selectors that already exist, they have duplicated selectors everywhere. I don't even want to get into how disorganized the file has become. The problem is that the duplicated selectors are spread out all over the file now and it could take some time to sort it out.
Anyway, I am currently in the process of trying to clean up the file. I have tried beautify, css format, etc in my editor (ST3), which cleans up fine but still leaves the duplicate selectors. I have tried various online tools like CSS Lint, ProCSSor, Dirty Markup, CleanCSS and so far none of these tools give me the desired result.
Is there any way that these selectors can be merged by some other means instead of manually?
Here's an example of my situation, just for reference:
I'd like to turn this...
.sameClass {
float: left;
width: 100%;
margin: 0;
padding: 0;
}
.differentClass {
border: none;
background: black;
padding: 0;
}
.sameClass {
font-weight: bold;
font-size: 24px;
display: inline-block;
}
into this...
.sameClass {
float: left;
width: 100%;
margin: 0;
padding: 0;
font-weight: bold;
font-size: 24px;
display: inline-block;
}
.differentClass {
border: none;
background: black;
padding: 0;
}
CSSO (Github project) is the tool will help you merge identical CSS classes.
It can be configured to execute some cleaning, compaction and restructuring.
Test in sandbox here : https://css.github.io/csso/csso.html
// Input
.card {box-shadow: none;}
.foo { color: #ff0000; }
.bar { color: rgba(255, 0, 0, 1); }
.card {border: 1px solid grey;}
// Output compacted + merged
.bar,.foo{color:red}
.card {box-shadow: none;border: 1px solid grey;}
A simplistic approach would be to sort your CSS file(s) by selector. This can be done by considering each rule as a "paragraph" (meaning you will have to ensure there are empty lines between rules, and nowhere else), and then using your editor's "sort paragraph" feature, if it has one. For instance, emacs has the M-x sort-paragraphs command.
Once multiple rules for the same selector are grouped together, you can manually go in and combine them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As a result of using less I have started to use nesting more and more. It's clean and easy to follow, but I use more selectors than normal because of nesting.
For example (simplified):
#footer {
background: #footer-background;
padding: 20px 0;
margin-bottom: 20px;
.seal {
width:22%;
img {
display:block;
margin:0 auto;
}
}
.copyright {
margin: 20px 0 0;
}
}
Or:
#footer {padding: 20px 0; margin-bottom: 20px}
#footer .seal {width:22%}
#footer img {display:block; margin:0 auto}
.copyright {margin: 20px 0 0}
The first will result in additional selectors that are not really needed, but it also prevents duplication and makes it easy to find and remove all unused/unneeded/duplicated css. All of this happens because your less files have a structure.
I think that the reduction in development time is worth the extra selectors. I think that my development time would be better spent elsewhere... but I'm not confident in that answer.
Should I avoid unneeded nesting, or is the gain worth the loss?
You Can Achieve Both Organization and Minimal Specificity
It is generally recommended to use the least specific selector to do the job. If your main desire is to also do some nesting in LESS for structural organization, then you can achieve the best of both worlds. Take your simplified example modified:
LESS
#FOOTER() {
#footer {
background: #footer-background;
padding: 20px 0;
margin-bottom: 20px;
.seal {
width:22%;
}
img {
display:block;
margin:0 auto;
}
}
.copyright {
margin: 20px 0 0;
}
}
#FOOTER();
CSS Output (your original shorter code)
#footer {
background: some color you set for #footer-background;
padding: 20px 0;
margin-bottom: 20px;
}
#footer .seal {
width: 22%;
}
#footer img {
display: block;
margin: 0 auto;
}
.copyright {
margin: 20px 0 0;
}
I've used a mixin with a set of parenthesis to "group" styles related to the footer area, and call that mixin to actually output the styles. This allows me to keep the code together, and insert it "wherever" in my final output css. But the styles can then be a bit more loosely grouped under that. So I have moved the img outside the .seal, and the .copyright outside the #footer. It may be true that the img is found in the html inside the .seal, or the .copyright inside the #footer, but if that is not relevant to selecting it, then simply knowing it is related to the #FOOTER() group may be enough for your organizational needs.
This is still an improvement over merely a /*comment*/ that sets apart a group, because it does still minimize duplication (#footer is not duplicated), and it does allow me to output the css in an organized way--one can envision this:
#RESET();
#HEADER();
#CONTENT();
#FOOTER();
Inside #HEADER(); may be some other sub-groupings:
#NAV();
#BRANDING();
It may be opinion, but in my mind rarely should selectors require more than a single level of nesting to get the specificity needed in a well structured html page. One set of exceptions are sibling relationships, where sometimes a complex set of nesting and sibling relationships are needed to select the elements.
Of course, you have to be aware that, for example, .copyright is defined in #FOOTER() but it is outputting a selector that is not necessarily constrained to that area. If you as the designer know that the copyright appears no where else, okay. If not, then subsuming it under #footer will be important.
I'm trying to override a particular widget's style using UiBinder. What am I overlooking?
<ui:style>
/*************
* Note #1
*************/
.btnVote {
display: inline-block;
width: 50px;
height: 50px;
background: #fff;
margin: 5px;
text-align: center;
outline: none;
cursor: pointer;
}
/*************
* Note #2
*************/
.btnVote-up-hovering, .btnVote-down-hovering {
background: #ddd;
}
.btnVote-up-disabled, .btnVote-down-disabled {
border-shadow: inset 0 1px 3px #aaa;
}
.lblName {
line-height: 50px;
font-size: 40px;
padding: 5px 10px;
}
.clear {
clear: both;
overflow: auto;
}
.floatLeft {
float: left;
}
</ui:style>
<g:HTMLPanel styleName="{style.clear}">
<g:FlowPanel styleName="{style.floatLeft}">
/*************
* Note #3
*************/
<g:PushButton ui:field="btnVoteUp" stylePrimaryName="{style.btnVote}">
(+)
</g:PushButton>
<g:PushButton ui:field="btnVoteDown" stylePrimaryName="{style.btnVote}">
(-)
</g:PushButton>
</g:FlowPanel>
<g:FlowPanel styleName="{style.floatLeft}">
<g:Label ui:field="lblName" stylePrimaryName="{style.lblName}"/>
</g:FlowPanel>
</g:HTMLPanel>
Note 1: This rule is being applied and works fine
Note 2: This other rules seem to be getting ignored (they don't take effect)
Note 3: The default naming for the widget is being reset, hence Note 1 works fine. The base class is set to GOGXR1SCFI instead of gwt-PushButton
Why aren't they other rules working? When I hover the widget, the class GOGXR1SCFI-up-hovering is indeed set to the widget, but no accompanying CSS.
Thanks for your help.
Update
Something I ran into that gave me a hard time for a while: when you use the #external keyword, you must place a semi-column at the end of the #external statement, as in:
<ui:style>
#external .btnVote;
.btnVote {
...
}
</ui:style>
<g:FlowPanel styleName="{style.btnVote}"/>
One thing you could do is to create your CSS using ClientBundle, define all the different states there, then handle the various states manually. This way you don't need to define classes as #external, and GWT will optimize the CSS for you (shorten the names, only ship what gets used, etc.). This is especially beneficial for custom widgets and such.
The easiest way to deal with this is to write #external .btnVote, .btnVote-up-hovering, .btnVote-down-hovering, .btnVote-up-disabled, .btnVote-down-disabled at the top of your <style> section.
The original GWT widgets do not work well with CSS resources (like the one you have in your UiBinder). They depend on a primary style name that they append things like "up-hovering" to. This is terrible for CSS resources and UiBinders because when you type "up-hovering" it becomes things like SDLFJKS.
The button styles do NOT get obfuscated (so you can read "up-hovering"). Your UiBinder styles DO get obfuscated. You can never make them match as long as obfuscation is going on.
So, the #external keyword tells UiBinder and CssResource not to obfuscate certain styles. Now, when you use {style.btnVote-up-hovering}, that will actually come through to the final HTML, which is where these old-fashioned GWT styles will be applied.
I suspect you have CSS stylenames being obfuscated by GWT in your UIBinder. Reference - garbled css name when styling within UiBinder
Chose the approach you find easier to integrate in your proces. Cheers :)
Is there a way to simplify the following css rule so that .x-grid-row selector won't have to be repeated?
#OpenRequestListGrid .x-grid-row, #MyRequestListGrid .x-grid-row {
line-height: 13px;
padding: 0 1px;
vertical-align: top;
background-color: #BBB;
}
Important issue here is that I don't want to specify .x-grid-row by itself as this rule is from a larger library.
Note: maybe I wasn't clear the first time but I don't want to use .x-grid-row as this will effect other grids that I want to leave alone. I would like to target just my two grids. What I am aiming for is not repeating the same config twice one for each grid ID.
HTML sample :
<div id="dontChangeMe" class="x-grid-row">
<div id="OpenRequestListGrid" class="x-grid-row">
<div id="MyRequestListGrid" class="x-grid-row">
CSS doesn't have variables, but when you want to select all elements .x-grid-row in your document, you should simplify it to:
.x-grid-row {
line-height: 13px;
padding: 0 1px;
vertical-align: top;
background-color: #BBB;
}
Or just search for a common parent of your .x-grid-row when talking about a partial scope and use it like:
#common-parent .x-grid-row {
...
}
or
.common-parent .x-grid-row {
...
}
or any other css selectors ;)
EDIT
I just reread your question and you could also use a global selector like .x-grid-row {...} when you want to address a lot of elements and just specify more selectors like #inner-box .x-grid-row { ... } to change values back to default for only few elements.
How about just using .x-grid-row or using a selector which is a parent to both #OpenRequestListGrid and #OpenRequestListGrid.
So the Answer is there really isn't another way. Repeating element id and then the same selector is necessary. Thanks to all those who replied.
I've been educating myself. Reading this:
The engine evaluates each rule from right to left, starting from the rightmost selector (called the "key") and moving through each selector until it finds a match or discards the rule. (The "selector" is the document element to which the rule should apply.)
For example:
ul li a {...}
#footer h3 {...}
* html #atticPromo ul li a {...]
Now, some example code SASS outputs for me:
#content #blog {
/* ... */
}
/* line 85, ../sass/screen.scss */
#content #flickr {
/* ... */
}
#content #flickr div p {
/* ... */
}
This seems a bit awkward.. am I doing something wrong? Is this a communication problem between me and Sass? Are we losing it?
Edit:
Some SCSS code:
#flickr {
#include columns(5,8);
background: url('../img/ipadbg.png') no-repeat;
#ipod-gloss {
z-index: 999;
position: relative;
}
div {
margin-top: -80px;
margin-right: 20px;
h2 {
color: $white;
font-size: 24px;
}
p {
margin-top: 40px;
}
}
}
Side Bonus!: The article says browsers (or at least Firefox) search the selectors from right to left. I couldn't understand why this is a more efficient why. Any clues?
You have to find your compromise between maintainability (nesting makes it easier to find your way around in the stylesheet) and rendering performance.
A rule of thumb says you should try to restrict yourself to a three-level nesting and you should avoid to nest IDs if it's not necessary.
However, I think nesting too much is not the biggest issue. As soon as I became aware of the power of mixins, I used them a lot.
For example, this is my often used button mixin:
#mixin small-button($active-color: $active-color, $hover-color: $button-hover-color, $shadow: true)
display: inline-block
padding: 4px 10px
margin:
right: 10px
bottom: 10px
border: none
background-color: $button-color
color: $font-color-inv
+sans-serif-font(9px, 700)
text-align: center
text-transform: uppercase
cursor: pointer
#if $shadow
+light-shadow
&:hover
text-decoration: none
background-color: $hover-color
&:last-child
margin-right: 0
a
color: $font-color-inv
&, &:hover
text-decoration: none
&.disabled
+opacity(0.75)
&:hover
background-color: $button-color
&.active
background-color: $active-color
&.disabled:hover
background-color: $active-color
You see, quite a bit code. Applying such mixins to many elements on your page will result in a big CSS file which takes longer to be interpreted.
In the old fashioned CSS-way you would give each button element e.g. the class .small-button. But this method pollutes your markup with unsemantic classes.
Sass provides a solution though: selector inheritance via the #extend directive.
If you set defaults for your parameter of the mixin, you can also provide a simple class, which uses the mixins with your default:
// Use this mixin via #extend if you are fine with the parameter defaults
.small-button
+small-button
And then you can just inherit from this class in various contexts:
#admin-interface
input[type=submit]
#extend .small-button
The resulting CSS statement aggregates all usages of .small button into one rule with comma-separated selectors:
.small-button, #admin-interface input[type=submit] {
display: inline-block;
...
}
Concluding, a naive usage of Sass can effect your CSS performance. Used wisely, however, it is maintainable thanks to well-structured and DRY code, it leads to proper separation of markup and styling (semantic classes only) and allows for smart and performant CSS code.
SASS is only a language that compiles down to CSS. If you're concerned with SASS' performance in terms of how it runs in the browser, then SASS doesn't enter the equation -- it'll be compiled and served to the browser as regular CSS.
From what I can see of your usage of SASS, there's a couple of things I could suggest:
You don't have to nest everything.
The ability to nest rules inside each-other in SASS is a language feature, but you don't have to do it if it doesn't make sense to do so.
In terms of your general CSS usage:
If the nesting gets too severe/unwieldly, consider using classes where it makes sense.
When it's necessary to use the hierarchy of DOM elements, consider using the [child combinator]: .foo > .bar.
IDs are meant to be unique, thus should always only reference a single element. Most of the time, they can be CSS rules unto themselves -- #content #flickr would become just #flickr, for instance -- and browsers will optimise the lookup for a single ID. The only time you would need something like #id1 #id2 is if #id2 needs to appear in different contexts on different pages.
If your selector contains things like #id div p, that div is either superfluous or serving a specific purpose.
If it's superfluous, change the rule to #id p, which selects any <p> that occurs as a descendant of #id.
If it serves a specific purpose, consider classing the <div> with a class name that describes its purpose -- perhaps <div class="photos-list">. Then your CSS could become .photos-list p, which is far more maintainable and reusable.