I have two CSS from two big projects, whereas I need to merge the two CSS together. Essentially, I just included both CSS in the HTML header of the new project that needs both CSS.
Using WebStorm what is the best way to find and track colliding CSS properties?
For example (note this is just a basic example to express my point):
first.css
.my-class-1 {
background: #eeeeee;
color: #ffffff;
font-family: 'Poppins', sans-serif !important;
min-height: 59%;
}
second.css
.my-class-2 {
background: #000000;
color: #ffffff;
font-family: 'Poppins', sans-serif !important;
min-height: 100%;
}
And given that it is used
<div class="my-class-1 my-class-2" ></div>
From these examples, the background and min-height properties are colliding to each other.
I think your best bet would be to actually load the page in your browser, and use chrome dev tools to inspect the styles. You can do this with most browsers, but I would choose either Chrome or Firefox as they're probably the most refined. This can show you the computed styles and what styles are overwritten by others.
You need to check for these styles manually as your IDE won't have the context to understand that there are conflicting classes being used in the html.
However, if you want to search for duplicate CSS within the CSS file, I would suggest something like http://csslint.net/
The best solution is to use https://stylelint.io/
With this configuration:
{
"extends": "stylelint-config-standard",
"rules": {
"no-duplicate-selectors": true
}
}
It is able to detect similar names which actually help (mostly) finding the colliding CSS properties based on common names.
Related
I am trying to change the color of the banner in the Jekyll leap-day theme, here https://github.com/pages-themes/leap-day/blob/master/_sass/jekyll-theme-leap-day.scss
To do that, I have added an assets/css/style.scss to my github page, with the following contents
---
---
#import "{{ site.theme }}";
#banner {
background: #a90000;
border: 1px solid #3399cc;
}
But nothing changed. How can I overwrite these values of the banner div in SCSS?
There are a number of reasons why this might not be working. Without being familiar with the output and html you are styling here are some things you should check (all of which you can check through browser developer tools. e.g. Chrome DevTools )
The element with id="banner" exists in your html and is visible.
Your additions to the SCSS are actually being included and are being applied to the element. You can check this in Chrome developer tools by inspecting the element. Under styles you should be able to see your style rules alongside the others. If you can't then it you may have a selector issue, likely caused by some earlier nested styles. (If you have also ruled that out, and your additions are not appearing anywhere in the output then something is going wrong with how you are building and fetching your SCSS).
If you can see them but they have a line through them, then they are being overruled by rules with a higher CSS specificity. You can fix this by making your selectors more specific. E.g.
div#banner {
background: #a90000;
border: 1px solid #3399cc;
}
Or perhaps
.someWrappingClass #banner{
background: #a90000;
border: 1px solid #3399cc;
}
Bearing in mind that these will change how they are selected - which could be an issue later if the HTML changed.
Really how you fix specificity issues properly will depend entirely upon your HTML, how you structure it and how you might change it in future. There really is no substitute for just learning how cascade and inheritance works.
In Bootstrap tutorials, when people create their own Sass variables in a custom style.scss, I see lots of them using trailing !important.
If you want to see an example of what I mean, start at 13:45 here:
https://www.youtube.com/watch?v=MDSkqQft92o&time_continue=24&app=desktop
.navbar {
width: 100%;
background none !important;
#media(max-width: 34em) {
background: black !important;
}
}
But then other code in the .scss file doesn't use !important. No explanation of why that is.
Anyone have some suggestions?
!important means that the style preceding it will be "forced" onto the element, despite what other styles may set on it. For example:
.element {
font-weight: bold;
}
.custom-class {
font-weight: normal !important;
}
If you have an <span class="custom-class element"></span>, it will be displaying a font-weight normal, not bold.
! important guarantees (or at least it tries) that the rule you're trying to apply is more important than others. So it overwrites other rules that might interfere with the new one. ! important is not necessary if the rules are ordered correctly because the last rules prevail over previous ones. ! important must be avoided as much as possible. Use it only if it's really necessary.
When I add bootstrap on my html link it changes some of my css code.
Pre-bootstrap:
After-bootstrap:
Bootstrap link:
Css code changed:
#bannerRodap{
background-color: black;
position: fixed;
width: 100%;
height:80px;
top: 88%;
}
#bannerRodap p{
position: relative;
top: 25%;
color: white;
text-align: center;
font-family: 'Helvetica',sans-serif;
font-size:0.8em;
}
And besides that, bootstrap also added this little blue thing under my flex-box container.
Yes the CSS change you experience is bound to happen, it is one of the typical disadvantages of using Bootstrap. Like the name itself suggests the framework "Bootstrap" makes its complete CSS available to your entire project. Real problem is the immense code the bootstrap.css contains even though the programmer doesn't even need most of it(more than 3000 lines). I have taken a very small snippet from the file(bootstrap.css) to explain:
a {
color: #337ab7;
text-decoration: none;
}
a:hover,
a:focus {
color: #23527c;
text-decoration: underline;
}
This means all the anchor tag(<a>) in your project would have the color #337ab7 by default UNLESS you override this style to what you need in your own stylesheet. The real problem arises when you see other elements in your project changing its behaviour according to the bootstrap CSS but you really didn't want them to - In this case you need to override the styles coming from bootstrap.css just say in a way to cancel out the bootstrap styles you need to write your own unnecessary styles to make it look normal.
That's the reason when you ask most of the experienced UI devs about bootstrap they would just go ... ** yuck **
Your own stylesheet starts to get really messy.
HTML gets messy especially when you start using the grid structure of bootstrap
Huge unwanted code(from BS CSS/JS) lies in your project even though you will never ever need all of them.
Even the order of the stylesheets included hardly makes any difference. In your case use the Dev Inspector to see whats causing the blue thing(probably a shadow from boostrap) to appear & remove that by overriding the styles in your own stylesheet(in this case, your stylesheet should be included after the bootstrap.css)
Imo, bootstrap should be used mostly by those who need bootstrap to do everything about the look & feel of their project with very little customisation to do on their own. If you have heavy customisation of your own then might as well write you own CSS from the scratch without including BS.
What is the purpose for:
PostCSS Autoreset
PostCSS Initial
The documentation is very sparse on both and doesn't really explain why one should use them and what there purpose is.
I've tried autoreset. It seems to place all: initial on every element you style. This seems very wasteful when looking at the output.
How is it any different from:
* {
all: initial,
font-family: "Roboto"
}
Looking at the code for autoreset it seems to do just that: https://github.com/maximkoretskiy/postcss-autoreset/blob/master/src/resetRules.es6
I don't get why this is better than using *
postcss-autoreset protects your from inherited properties in CSS.
Imagine that you wrote a component and publish it to npm. You used BEM or CSS Modules, so selectors are isolated. But some developer took your component to webpage with:
* {
box-sizing: border-box;
line-height: 2
}
Because of non-default box-sizing all your sizes become broken. Because os non-standard line-height text become bigger and broke design.
Here is a real example of such issue in EmojiMart component.
postcss-autoreset will put a all: initial to every selector in your component CSS:
.component {
all: initial; /* added by postcss-autoreset, you didn’t write it */
width: 100px;
padding: 10px;
}
.component_title {
all: initial; /* added by postcss-autoreset, you didn’t write it */
height: 20px;
}
As result this auto-inserted all: initial disable user box-sizing and line-height in your component and your component looks in same way in user website.
This is better than * when you want to create isolable component, meaning component that you can integrate in other people app or website like a plug-in or add-on.
Usually when I build a site, I put all the CSS into one file, and all the properties that relate to a set of elements are defined at once. Like this:
#myElement {
color: #fff;
background-color: #000;
padding: 10px;
border: 1px solid #ccc;
font-size: 14pt;
}
.myClass {
font-size: 12pt;
padding: 5px;
color: #ee3;
}
I've been considering splitting up my definitions into a number of different files (colours.css, layout.css, fonts.css ...) as I have seen recommended. Something like this:
/* colours.css */
#myElement {
color: #fff;
background-color: #000;
border-color: #ccc;
}
.myClass {
color: #ee3;
}
/* layout.css */
#myElement {
padding: 10px;
border: 1px solid;
}
.myClass {
padding: 5px;
}
/* fonts.css */
#myElement {
font-size: 14pt;
}
.myClass {
font-size: 12pt;
}
To reduce HTTP requests, I'd be combining the files and stripping whitespace prior to rollout, so that's not an issue, but my question is: does having all those selectors repeated over and over cause any performance issues in browsers?
Alternatively, are there any tools which avoid this (potential) issue by merging definitions from different files? ie: take the input given in my second example (3 different files), and combine them into one file, like the first example.
The browser will have to find all the definitions and then add them up and override the different properties based on the latest definition. So there will be a slight overhead.
That being said it would be rather minimal and not very noticeable even on hardware 5 years old. The browsers are quite efficient at it these days.
I can't comment on performance, but I tried this approach on my website and ended up reverting to one large file.
My reasons:
I got tired of creating a rule for div.foo in three or four different files, and opening three or four files if I wanted to change that div.
Sometimes it's not as easy as it should be to separate functions. To center a div in IE, you may have to center the text of the parent element, even though that's not the standard way. Now my layout is mixed in with my fonts.
As the code grows, the easiest way for me to find things is to do a text search for the element I want. But I have to open several files to see all the rules, and maybe that element doesn't have a rule in this file so I get no matches.
So I went back to having main.css and iehacks.css. And breathed a sigh of relief.
As William said, you're not going to see any issue from the browsers parsing the CSS. What you might see, though, is an issue with the number of HTTP requests that a client can open to a single host. Typically this defaults to two. So, if you do put your CSS in multiple files, you might want to put them on a separate sub-domain and they will be treated as a different host which will allow the HTML page to be loaded at the same time as your CSS files.
There shouldn't be any noticeable difference in rendering/parsing speed. As everyone else said, computers are fast enough that they can render CSS pretty quick.
Your problem is really going to be with the number of requests required to load the page. Extra web requests increase overhead when loading a page. It is much faster to load one large file than it is to load several smaller files. It has an impact on both the client (browser) and the server serving up all of those CSS files.
As long as you combine your files in production, you should be fine.
Yahoo's YUI Compressor is a pretty good tool for compressing your CSS files into smaller files. The last time I checked, it can't definitions (at least the last time I looked at it) but there shouldn't be enough of a performance hit to really need to.