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 7 years ago.
Improve this question
I have following snippet
.global-oxygen-font{
font-family: $font-oxygen;
font-size: 16px;
line-height: 31px;
letter-spacing: 0.32px;
}
And I am extending it whenever it is used like this
line 100. div{#extend .global-oxygen-font}
line 200. p{#extend .global-oxygen-font}
So as you can see among different sections, I am extending the font-snippet. But during a code review I was told that put that
div,p{
font-family: $font-oxygen;
font-size: 16px;
line-height: 31px;
letter-spacing: 0.32px;
}
on the line 100 itself. Extending global-oxygen-font would essentially copy the code those places. I was like, but div and p exists in line 100 and 200 for a reason, as they are in order of the structure of the markup. And if I make the change as suggested, it won't be good for maintenance. Whose approach is correct?
Extending global-oxygen-font would essentially copy the code those places
No, that's not how #extend works. Instead it works by adding div and p to the list of selectors for .global-oxygen-font. (Compile it and view the result to verify this yourself.)
Therefore, if pressed I would say you are right, they are wrong. Your approach clearly isolates the rules and then assigns them to p and div, and therefore I would say it is also more maintainable.
You might want to designate .global-oxygen-font as a virtual class (using % IIRC) so no rules are generated for it (unless you want to be able to use that class explicitly).
I'm curious, though, why you would apply these rules to all p and div elements. It would seem to be better to write the class explicitly on those elements. Or, since all the properties are inheritable, it could make sense to apply them at a higher level.
Another comment:
as they are in order of the structure of the markup
There is no particular need to order your CSS so as to match the structure of the markup.
At the end of the day, it is often not a good idea to push back against code reviewers. They may have their own point of view, which they are allowed to assert because they are more senior. For instance, they might not even like the entire idea of #extend, and there are legitimate reasons some people avoid it.
Related
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 2 years ago.
Improve this question
I frequently need to address generic elements inside some specific sections of a page. I find this approach most easy to understand in terms of what any rule is affecting:
.shop > .products > .product > .description > .warning {
color: red;
}
But I often see this:
.shopProductsProductDesc > .warning {
color: red;
}
Does it really matter which approach is taken?
It really depends on the problem you are trying to solve.
The selector .shop > .products > .product > .description > .warning to my understanding would be used for two cases:
You have multiple warning elements but you only want to select the elements inside your description and there are other selectors used for warning that you don't want to overwrite.
You need to overwrite a previous selector that is less specific. Ex. .shop > .products > .product > .description .warning
The other selector .shopProductsProductDesc > .warning is less specific than the first one but assuming the container of .warning has those two classes .description.shopProductsProductDesc then the outcome would be the same as the first one.
CSS is all about specificity, if your selector is more specific than the last one used the properties would change. This is why you have to be careful if you are using specific selectors because your last option to alter the properties would be to use !important.
I hope this helps to clear things out.
After trying a few different styles, I think that personal preference (or a set standard if you have collaborators) is really the way to go. I prefer the second version, but the first one is also quite legible.
If you consider efficiency of what the browser has to do under the hood to render CSS styles, BEM-style for example, is usually the ultimate winner as it is the most lightweight for the browser. I use BEM for some layout/common elements.
In real life unless you are doing something seriously wrong, modern browsers and devices make this difference of CSS parsing and rendering somewhat negligible. But that is if you code everything well.
I've worked with spaghetti CSS codebases that could take minutes to render all SCSS (it was a huge codebase, but a few files were big bottlenecks).
It matters because of specificity. The first style rule will always override the second, regardless of where they both appear in the stylesheet, because it is more specific (basically it has more class selectors in it).
That said, the first rule is a nightmare from a maintainability perspective, for a number of reasons:
It makes code incredibly hard to read and understand
It's harder to override (as we have seen).
If you change the structure of the HTML, it will break
You can only reuse it if you mirror the structure of the HTML exactly.
It's also bad from a performance perspective. When browsers are matching an element to a style rule they read each selector right-to-left and keep going till they either find a match or can exclude the rule. Therefore, the more simple the selector is, the faster a match can be determined. If a selector consists of just a single class name, the browser can match the element with the style rule more quickly than if it has to search upwards in the DOM tree.
The second rule is better, but optimal would be something like the following:
.shopProductsProductDesc--warning {
color: red;
}
This solves all the problems above, and it's long enough that there's unlikely to be name clashes elsewhere, (though obviously not impossible).
In general, nesting selectors in CSS is bad practise, in my opinion, and the best CSS methodologies are those that have ways of avoiding this, e.g. BEM, CSS-in-JS.
According to my own experience, the second option is often best, not for direct technical reasons (in fine, it will perform the same), but rather for UX consistency and code maintenance.
The first option produce an "heavy" selector, which will be harder to override. It can be wanted, but it is often the sign of an overall messy CSS, because if everything is overconstraint, it is less easily reusable/extensible.
From my understanding of CSS and frontend reusable components, you would always only need two levels.
The style of your warning component (no size, no margin, size depends on where you will display it, and margin is position, only internal design here):
.warning {
//Your design here
font-size: 1.5rem;
font-weight: bold;
color: orange;
}
And the positionining and variants inside containers:
.container > .warning {
//This is an example.
position: absolute;
right: 0;
border: solid 1px red;
}
Having long CSS selectors will make things more complex, hard to follow for your teammates, and hard to override because you will probably need a longer CSS selector, and it never ends. Plus, you will get an heavier bundle at the end.
If you want an efficient UX, the UI shouldn't be that different everywhere, so you should not need to have that many variants of the same component. Otherwise, maybe you need multiple different components, but you certainly want a simple and efficient UX, and that often goes with not so much visual concepts, so you must avoid tons of variants.
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
In the following article I read that one should try reduce the number of selecetors.
Article: use less selectors
I'm wondering if writing LESS and I'm using a lot of nesting to group parent and child elements, will that generate bad CSS code in the end?
LESS
.wrap{
width: 100%;
height: 20%;
background: green;
header{
background: blue;
h1{
color: red;
}
}
}
I'm using a lot of nesting to group parent and child elements, will that generate bad CSS code in the end?
In a word, yes. In the long run this will give you highly specific, unmaintainable CSS. Let 's have a look at what your example will produce for the h1 style.
.wrap header h1{ color: red; }
So what you've ended up with here is a very specific CSS selector, that isn't really necessary. You could, for instance, just have
h1 { color: red; }
or use a class on the h1
.title { color: red; }
Why is specificity bad?
So imagine, 6 months later another developer comes along and they need to change the color of a h1, but just one of them.
First they try to add a class to the h1
.new-color { color: blue; }
But the colour doesn't change because the original CSS is so specific. So they have to do this
.wrap header h1.new-color { color: blue }
or worse still they may do this
.new-color { color: blue!important; }
And then what happens when other changes need to be made? As you can see very quickly and very easily you can end up with unmaintainable CSS, that will have everyone pulling their hair out.
Performance
People usually negate performance when it comes to CSS, but it is always good to know what is going on when a page is rendered. CSS is read from right to left. Using your example
.wrap header h1 { color: red; }
This means the browser engine will search for every h1 and check if they have a parent header and then if that has a parent class wrap. If so it will apply the style. A low specificity makes the rendering process a lot simpler.
Summary
So to sum it up, nesting, whilst it may seem great keeping your code nice and readable, should only be used when absolutely necessary. It's very easy to forget what the CSS that is actually being produced looks like. Before you know it you'll be in nesting hell.
Languages like LESS or SASS give you more flexibility in declaring your style rules, and that can be good or bad depending on how you use it. The more flexibility you have in a language, the more you need design patterns and good practices to avoid making things worse than they were before.
LESS doesn't require that you always nest. You can always use CSS of course, and if you are applying a style to all p it might be better to define it globally, than to call mixins to obtain the same result on several nested ps.
But LESS and SASS do allow you avoid duplication, to write code that is clearer and easier to maintain, and other problems caused by the code duplication required by CSS.
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
I understand the title is a bit misleading, but I come from an Object-Oriented background, and I've recently began a shift towards web development. I've only got a basic grasp of HTML, and been learning and messing around with CSS, but there are some parts of it that are a bit confusing, and I'm trying to get it into terms I can understand.
My CSS:
.Person .span4 p
{
margin-left: 10px;
margin-right:10px;
margin-top:10px;
}
From what I can understand, this means that any p tag that is inside a container, like with the class of "span4", which is in turn inside another container that has class="Person" will be formatted with the specifications listed above.
In other words person.span4.p.format(String[] formatArgs), where the formatArgs are the margin-left, right, and top.
The Question: Is this an appropriate way to look at it?
I know it might be comparing apples to oranges, but I'd like to get an opinion before I go running with some conclusion that could be very wrong, and an actual explanation on how these work.
Your question about .Person .span4 p is correct, that will style a p element that's a descendant of an element with a span4 class that's a descendant of an element with a Person class.
However I wouldn't try to interpret classes in HTML as similar in any way to OO classes. They're completely different concepts, and I think that'll just end up confusing things.
Classes can be assigned to HTML elements using the class attribute (class="span4"), and these can then be used in CSS or JavaScript to apply additional styling or behaviours to those elements. Think of giving an element a class as tagging it with a particular keyword, so it can be easily targeted later. Elements can also be assigned multiple classes by separating them with a space, eg. class="span4 box".
In addition, .Person .span4 p isn't actually a "class", it's a selector. The .span4 syntax is called a class selector, the p is an element selector, and using a space between two selectors creates a descendant selector. Additionally #myId is an ID selector, and there are plenty of other types of selector as well.
I'd recommend this guide as a good way to get up to speed on the correct terminology.
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
I read an article where it was recommended that we should ONLY use classes in our markup and only use ids when we need to refere to it from javascript (as it is easier to attach functions to ids)
At the moment I only use classes when I have more than one element that needs the similar style. However the article (which I THINK I read - but have no reference) stated that we should use classes throughout
I would do this:
<header id="banner"></header>
Where as the recommendation was :
<header class="banner"></header>
(even though the banner is only used once per page)
is this the new "good practice"?
Thanks
As far as I know you are correct, you should use classes when you need to style multiple elements and IDs when you are only styling a unique element.
I think you may have stumbled on an article about object oriented css. The basic idea is that you should think of the style as a sort of abstraction which is linked to your markup via classes. I find it to be a good technique for keeping things organized, but, as with all techniques, it's not a universal hard and fast rule. I see no problem with linking style to markup with ID's, as long as that makes the most sense.
It's what "makes sense" that is the real tricky thing to define.
ID Attribute, Definition and Usage
The id attribute specifies a unique id for an HTML element (the value must be unique within the HTML document).
The id attribute is most used to point to a style in a style sheet, and by JavaScript (via the HTML DOM) to manipulate the element with the specific id.
Read more about it here!
CLASS Attribute, Definition and Usage
The class attribute specifies one or more classnames for an element.
The class attribute is mostly used to point to a class in a style sheet. However, it can also be used by a JavaScript (via the HTML DOM) to make changes to HTML elements with a specified class.
Read more about it here!
So, you can style using either Id's your Class's, just knowing that the class can be re-utilized on other elements across your web page, the Id must always be unique.
The reason to tell that Class's are the best attribute to utilize to apply CSS is because you can have generic class names and use then a lot through your web page, thus simplifying and reducing the time spend coding :)
Simple example:
HTML
<div id="theUniqueID">
Hello!
</div>
<div id="theUniqueIDTwo">
Hello Again!
</div>
CSS
#theUniqueID {
font-size: 15px;
text-align: right;
}
#theUniqueIDTwo {
font-size: 15px;
text-align: right;
}
Can be reduced to:
#theUniqueID, #theUniqueIDTwo {
font-size: 15px;
text-align: right;
}
And can be generically utilized across the document like this:
.format_01 {
font-size: 15px;
text-align: right;
}
Having then the HTML like:
<div class="format_01">
Hello!
</div>
<div class="format_01">
Hello Again!
</div>
<div class="format_01">
Hello Again and Again!
</div>
Ps:
Sorry for the overkill answer, but this allows others with less knowledge to learn as well.
Basically you should use id for unique elements that means if you want to keep an element on the page that won't be appear on the page twice then you should use id and to style a group of elements with same style or to keep some elements in the same group you should use class.
But remember, you can also use class for a single a element but you can never use an id for more than one element on the page.
For example, getElementById or $('#idOfElement') (using jQuery) returns a single element but getElementsByClassName or $('.idOfElement') (using jQuery) returns an array of matched elements. So if you have more than one element on the page using same id then you'll get only the first element that have the id, so never use id for more than one element.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm looking for a way to automatically organize (alphabetically, or by any other accepted "standard") all of my CSS properties. I would prefer a method in Dreamweaver, but I'll take anything at this point!
Example:
.div-name {
padding: 5px;
width: 300px;
margin: 10px;
color: #000;
}
would be converted to:
.div-name {
color: #000;
margin: 10px;
padding: 5px;
width: 300px;
}
There was formerly a tool called "CSScomb" (at csscomb.com) to sort and group your CSS. It had plugins for a wide variety of code editors.
Unfortunately, it is no longer online; the domain was for sale, and now it redirects to…something else.
There does appear to be an active repository here: https://github.com/csscomb/csscomb.js/
Try this:
http://www.cleancss.com/
Haven't used it, but it appears to do what you say.
Bob
I personally would not find this useful, but that's just me. I use my own hierarchy based on importance, and I keep this consistent throughout my stylesheets. Each person may have different preferences in regards to this. I personally like to do any positional formatting first, followed by layout parameters, then sizing and then colors and other text formatting properties.
This allows me to identify and edit the most important properties quickly, ones that may affect layout are to me the most important.
Here's a recap:
1.positional formatting such as display, position ... because this can affect the layout greatly
2.layout such as margin or padding ... same as above
3.sizing such as width, height or font-size ... this has the ability to affect layout.
4.color and text formatting such as color, background-color, letter-spacing or text-transform
CSSTidy is an executable and PHP script you can use to make formatting changes like this (as well as optimizations). In fact, cleancss.com that #rcravens mentioned is "based on" this tool.
i use visual studio 2010, this extension allows you to comment css and alphabetize your css and some other pretty handy tools too
http://visualstudiogallery.msdn.microsoft.com/6ed4c78f-a23e-49ad-b5fd-369af0c2107f