Is there any way to disable all these !important options in semantic-ui?
I keep running into issues with things like:
.ui.right.sidebar {
right: 0!important; /* why is this important */
left: auto!important; /* why is this important */
-webkit-transform: translate3d(100%,0,0); /* why is this NOT important */
transform: translate3d(100%,0,0); /* why is this NOT important */
}
Why does almost every positioning property have !important? Is there a way to compile semantic omitting the !important modifiers? It is interfering with my custom styling, and I have to do extra work that feels hacky (like countering margin: 0!important; with padding-top: NNpx and just hope that at least one isn't marked as !important in any of the states it could be in)
Disabling !important in semantic-ui is a bad idea as it may lead to unpredictable results. To understand more about why there are !important keywords in the framework, here are some statements made by Jack Lukic, the author of SUI:
..CSS should have a specificity property for defining priority (it was
part of the original discussion when creating css), however they left
us with automatic weight calculations from an arbitrary point system.
This is pretty terrible when you run into something that happens to be
classified less ".ui.button" lets say, having to override '.ui.menu
.ui.button' , there are only two solutions, arbitrarily increasing
weight by repeating class names in selectors, or using important...
Source 1
And also here (among other places):
...CSS specificity has always been a terrible sort spot of the
standard, instead of giving developers a way to assign priority to
rules we have to with two options, increase rule specificity or 'drop
the hammer' with !important.
A lot of css rules in semantic aren't able to increase specificity beyond a certain point. The only assumption we can make about a red ui
button is that it will have classes .ui.red.button, no greater
specificity can be gained by altering the selector. If we then have a
rule that appears later with the same or greater specificity we're
stuck without important.
I'm positive that each decision to use important in semantic was after dealing with no other option. This happens a bit more than other
libraries because the specificity is so granular in the library.
If you want to override the behavior, you can do two things:
Use one of the 3000 theming CSS variables in SUI
OR
Override the behavior by using more specific selectors
See this
One way to make your custom CSS more specific is to use an id in the
body tag of your page and use the following selector:
#bodyid .create-new-menu-btn {
//Properties }
Related
What do the CSS precendence rules say about the <style> tag in shadow DOM?
I have an element <component class="component">, a CSS file included in <head> with:
component {
display: inline-block;
}
and a <style> tag inside some shadow DOM with:
::slotted(.component) {
display: block;
}
If I understand it correctly, the first rule should have a specificity of 0.0.1 as it has one element and the second one specificity of 0.1.1 as it has one pseudo-element and one class. Therefore, the second one is more specific and should override the first one. This doesn't happen though. In the developer's console (Chrome) I see both the rules and neither of them crossed out and in the "computed styles" panel I see 'display: inline-block'.
A more detailed example as requested in the comments:
<head>
<style>
/* "other-component" related styles: */
other-component {
display: inline-block;
}
</style>
</head>
<body>
<some-component>
#shadow-root:
<style>
slot[name=some-slot]::slotted(*) {
display: block; /* Only works with !important. */
}
</style>
<slot name="some-slot"></slot>
<!-- The actual ("light-dom") content: -->
<other-component slot="some-slot"></other-component>
</some-component>
</body>
This behaviour is defined in the CSS Scoping Module Level 1 Draft §3.3:
When comparing two declarations that have different tree contexts, then for normal rules the declaration earlier in the shadow-including tree order [the first, global rule] wins, and for important rules the declaration coming later in the shadow-including tree [the second, ::slotted(*) rule] order wins.
Note: This is the opposite of how scoped styles work.
In other worlds:
Styles that applied before distribution continue to apply after distribution.
We might have the most in-depth explanation of the design at https://github.com/w3c/csswg-drafts/issues/2290#issuecomment-382465643
A few reasons went into the current design:
We purposely didn't involve specificity at all. Doing so would expose implementation details of the component, which makes code fragile - if the component is updated and changes the exact selector it uses, it might start overriding outside rules that previously won, or vice versa, and there's no good way for the component's user to understand or manipulate this.
So we have to decide in some other way. Document order (the final cascade step) doesn't really work here - it adds an unexpected dependency on exactly how you load the custom element, and might have interesting race
So we're left with Cascade Origin, or something close to it, that just unreservedly makes one or the other win. Actually injecting a new origin into the list didn't seem like a great idea; it's unclear how user vs author stylesheets should interact with this. So instead we add another cascade step for this.
And finally, we have to make a decision about which wins. We already know that whatever order we choose, !important should have the reverse order; this is how the cascade origins already work. So we have to decide whether the outer page wins by default, but the component wins in !important, or the reverse. We decided that the former made more sense; this means that the component author's normal styles are "defaults", the component user's styles (!important or not) can override that, and the component author's !important styles can be used to "lock down" styles that need to stay how they are. Going the other way around didn't seem to satisfy use-cases as well: it would mean that component users can't override styles by default; they'd have to use !important to do so, possibly interfering with their other styles; and then component authors would have no way of "locking down" styles.
So, I'm not sure what I've stumbled upon here. I'm working with some CSS and I know it is common place to do something like this:
#content{
/* Style the content div. */
}
#content p{
/* Style all p elements in the content div. */
}
I'd like to give one specific p element a float:right style. Only one such p element will occur in the content element. Naturally, I'd just give this element an id, but then I had the idea to do it this way:
#content #right_floating_p{
float:right;
}
This works when I run the code, but I was wondering about best practice and whether or not this actually does anything scope wise. I could just as easily define a separate id for right_floating_p, but to me it feels natural that it should be defined with the content id because it will be used only on one p element inside the content element.
If anyone has any information about this syntax, please let me know. Thanks!
My recommendation is to only include the last ID. This is fairly standard separation of concerns. What if you want to change the first ID #content, but the last one #right_floating_p still makes sense and shouldn't change? There is more room for error if you specify something unnecessarily.
Other reasons this is good:
Smaller, faster (but barely) download size for your users.
More readable, in my opinion.
Faster (but barely) performance.
Over-qualifying tags is bad practice in general, as far as performance goes. Browsers read your selectors from right-to-left, by the time it interprets your #content selector, that information is pointless. My advice is to not trust that the browser will optimize for this.
Alvaro nailed it in his comment above.
The id must be unique on the page, but not necessarily across the whole site. So, for instance, if you had the #right_floating_p element on every page, but it had a #content element as an ancestor only on a certain page where you wanted it styled differently, then you'd want to use the #content #right_floating_p selector to apply the context-specific style.
I would suggest only using the most precise selector as you can, not only for readability and file size, but also for specificity.
CSS selectors have a specificity to them, so if you were to override it later (such as with a media query), the more specific selector will override the less specific one.
#content #right_floating_p {
color: red;
}
div #right_floating_p {
color: green; /* Will not apply, as it's less specific */
}
p {
color: black; /* Even less specific */
}
It will work having the first selector, but it's not necessary.
I am building websites for a while, and I have a question about CSS I can't really rid over. So there is that frequent situation when multiple classes affect a DOM element, and both classes declare the same properties. For example:
.first {
color:white;
}
.second {
color:black;
}
I know that if I have an element with class="first second" in that the text will be black. If I rather want it to be white, I have several options:
Using !important: I know this one is handy and I use it, but sometimes, if I use it too often, my CSS may become messy. I mean, multiple !important's can result the same basic situation.
Reordering the classes inline: if I am correct, which class comes first, it will be the priority one. This is nice, but i often work with environments where I can't affect that. Secondly, this is not a global but a local solution.
Reorder the CSS itself: well, this sounds interesting, but if I work with many stylesheets (and I do), it is hard to track, especially when it is WIP.
Actually what I am looking for is some workaround like z-index but for priorizing which class is stronger. Because I can't really find anything useful in this topic, I am just curious maybe it is a user error, and you guys know something I don't. How do you manage this? What do you suggest?
class="first second" is the same as class="second first". The priority is based on the position of the declarations in your css and not in their position on the html element.
So, if you want priority of a class against another, put the top priority class LAST on the css file.
.first {
color:white;
}
.second {
color:black;
}
in this example, class second has always priority over class first. This happens because browser scans through the css top-to-bottom and always applying the rules of matched classes that finds. So, the last matched class has priority over the previous matched classes.
see this fiddle: http://jsfiddle.net/5c29dzrr/
At the same specificity level, the CSS selector that is furthest down the stylesheet will be applied. So in your example, if you wanted in that situation to have the element with the white colour you would have to order your properties like so:
.second {
color: black;
}
.first {
color: white;
}
The order of the classes in the HTML tag is not important; it is the order in which they appear in your CSS.
The better way to handle this is to go with some better naming convention such as BEM or SMACSS so that you don't have the issue of conflicting class names.
Edit: It might be worth reading up on specificity and the cascade for a better understanding of this. I found this calculator to be pretty handy in determining which rules will take precendence, although these days you can just use the developer tools to find out that information.
I've been reading up on specificity and, quite frankly, I'm surprised that I didn't know about this properly before, since I've witnessed the very issues that specificity can give if CSS is declared in the wrong manner.
So, I've been doing a little research on the subject, and I now understand the rule for calculating specificity. However, during my findings, I've been left with three questions which I was hoping you guys could help me out with.
Firstly, when relating to CSS specificity, I've noticed that one source includes pseudo elements in the calculation, while another tells you to leave them out of the calculation. Is this purely an optional thing, or should I include them?
Secondly, is there any specific reason why I should declare classes above identifiers? For instance, I've already sectioned my development CSS file, and in the 'footer' section, I have #footer, #footer-container, .grid and .one-third, declared in this order. Is this perfectly fine, or should I switch them around? The defined rules are below, to show that both classes don't contain any conflicting properties:
#footer {
background: #e4e4e4;
border-top: 1px solid #eeeeee;
border-bottom: 1px solid #666666;
overflow: hidden;
padding-bottom: 1em;
width: 100%;
}
#footer-container {
margin: 0 auto;
width: 100%;
min-width: 1000px;
}
.grid {
margin-right: 2.1%;
float: left;
display: inline;
position: relative;
}
.one-third {
width: 31.9%;
}
Lastly, just a quick question about listing CSS properties in alphabetical order. I fully understand that this is optional, but using my declaration for #footer above as an example, is there any preference for border, margin or padding, as in alphabetical (bottom; left; right; top), or declared as written in shorthand (top; right; bottom; left)?
Thank you very much!
Firstly, when relating to CSS specificity, I've noticed that one source includes pseudo elements in the calculation, while another tells you to leave them out of the calculation. Is this purely an optional thing, or should I include them?
This is news to me; it looks like pre-CSS2.1 pseudo-elements were originally supposed to be ignored when calculating selector specificity. The article that says to leave them out of the calculation was published almost a decade ago, right in the middle of CSS level 2's refactoring. Here's what the 1998 CSS2 recommendation says (which, for reference, is also quoted in that article, but the URL that it links to redirects to the latest revision of the spec where it's changed):
A selector's specificity is calculated as follows:
count the number of ID attributes in the selector (= a)
count the number of other attributes and pseudo-classes in the selector (= b)
count the number of element names in the selector (= c)
ignore pseudo-elements.
In CSS2.1, as well as the latest Selectors standard, pseudo-elements must be counted like normal type selectors when calculating specificity.
Perhaps what's even more curious is that CSS1 had the same rule for pseudo-elements in terms of specificity as the current standard:
Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively.
This leads me to believe that the change in CSS2.0 was ultimately reversed in CSS2.1 so it wouldn't break existing (legacy) stylesheets that happened to rely on the behavior, and/or because it simply didn't make sense not to include pseudo-elements since you apply styles to them like you do with actual elements.
Secondly, is there any specific reason why I should declare classes above identifiers? For instance, I've already sectioned my development CSS file, and in the 'footer' section, I have #footer, #footer-container, .grid and .one-third, declared in this order. Is this perfectly fine, or should I switch them around?
There should be no difference whether you place your classes before your IDs, as long as your two classes follow the order they are in and your two IDs, likewise. Even assuming that all of these rules happen to match the same element, the IDs should take precedence over the classes for any properties that need to be overridden.
Lastly, just a quick question about listing CSS properties in alphabetical order. I fully understand that this is optional, but using my declaration for #footer above as an example, is there any preference for border, margin or padding, as in alphabetical (bottom; left; right; top), or declared as written in shorthand (top; right; bottom; left)?
If you are declaring the longhand properties separately, then it's entirely up to you how you want to order them. I would certainly follow the order already laid out by the shorthands for the sake of simplicity.
FYI, the order in the shorthands is laid out the way it is because if you literally connect the dots, the order is actually clockwise starting from the top.
Many would argue not to use IDs at all for styling to avoid issues with specificity. You CAN use classes over and over or you can just use them for one element like an ID. I agree that it is an unnecessary issue to battle with when its just as easy to use a class. And before you say "but sometimes I cant change the markup." let me just say attribute selector. These may be a little more to type but to avoid problems with specificity I think its worth it. So
div[id='yourID'] {
}
and you dont have to worry about not being able to overwrite this later. This is especially helpful when you work on a team.
So, I was wondering about the following: I have some main content div and a sidebar div and the CSS looks as follows:
.main{
width: 400px;
height: 300px
}
.sidebar{
width: 100px;
height: 300px;
}
I will not include now all the floating properties, since I am only interested in the following:
If I have a p element in both of them and I want them to have different styles, shall I give the paragraphs different classes or shall I define the style for them like this:
.main p{
color: blue;
text-align: right;
font-family: ...
}
And then for .sidebar p I would define something else...
The alternative would be to define a class p.myclass and define the style there.
I am trying to understand what a better practice is. Obviously I need less markup if I have 30 p elements in one of the elements with the first method, since I would have to give them all a class. On the other hand, I create CSS that I can only "use" for that parent element, instead of having a general definition that I can apply in more places in the site...
I noticed that in a lot of "big" websites, almost every single html element has its own class...
Any ideas?
I would definitely go ahead with the containment selector in the case you give. Fewer spurious classes in the markup is easier to maintain, and the rule ‘.main p’ says clearly what it does. Use your judgement to whether more complicated cases are still clear.
Note that ‘.main p’ selects all descendent paragraphs and not just direct children, which may or may not be what you want; accidentally-nested descendant matches are a potential source of bugs (especially for cumulative properties like relative font size). If you want only children to be selected you need ‘.main>p’, which unfortunately does not work in IE6.
This is one reason why many sites go crazy with the classnames: the more involved selectors that could otherwise be used to pick out elements without a classname, tend not to work in IE.
I vote for .main p and .sidebar p because:
It most clearly expresses your intention, as you're expressing it in English
It reduces the number of explicit classes you need in your HTML
If you change your mind later and want an explicit paragraph class with that style you can just add it: .main p, p.foo
In my opinion using nested selectors [ parent child relations ] will be harder to read and maintainable.
Evdn if the design changes in a frequent manner CSS should be less affected by that. So styling individual element will be easier in the case of maintainability.
If the element is going to exist in a predictable location then you can style it based on a parent element.
The major drawback of styling by class on each individual element is the bloat: If you have many of these elements, the CSS attributes will become a noticeable percentage of the transferred bytes. Especially for large documents, saving a couple of KB in the download can count. Even more so with AJAX requests or IE where parsing innerHTML is extremely slow.