My google chrome extension needs to wrap content of certain elements on page user is browsing into custom element, say, <xelem>original content</xelem>. This change should not make any visible effect.
Is it possible to make <xelem> NOT affected by * css rules (or any other rules that might apply to it), but at the same time retain inherited styles?
Considering you are working with css3, have a look at the :not pseudo-class.
Something like
:not(xelem) {
/* ... */
}
should work...
Related
This question already has an answer here:
Difference in applying CSS to html, body, and the universal selector *?
(1 answer)
Closed 3 years ago.
I would like to ask what is the difference between *{} and body,html{}. It changes the view in the html and I want to have a broad knowledge about this. Thanks.
The wildcard (*) will apply the styling to every element found on your HTML page unless you give specific styling for that element. It overrides any possible inheritance for the set property because it is setting that default value for each individual element. If you want to change something in a section that has child elements then you will have to make that change for each child. This can be useful in a few cases (box-sizing is probably the most common use) but most of the time you will not want to use this. Depending on how heavily this is used, it can slow down your page load times.
Setting the styling with body/html allows for inheritance to still take place. Elements within the html/body will still show the styling found here if their default is set to inherit. This will still allow a closer parent to the child to override the styling. In CSS, the best option is to be more specific.
The *{} selector (Universal selectors) matches elements of any type. (MDN).
body,html{} select body and html elements.
Consider the following example:
* { /* Selects all elements */
color: blue;
}
html,
body { /* Selects html and body element */
color: green;
}
<html>
<body>Body</body>
<footer>footer</footer>
</html>
*{}
is a universal selector. It will implement the styling of all the elements. If you want to do some changes with styling of the particular element then you have to override it.
body,html{}
will do the same for you. But there is one scenario. If you want to inherit the properties from the parent then body,html{} is definitely going to play this role. It is used for the inheritance of properties
Is there a way to reproduce that but using additional css rules ?
My specific problem is how to disable a framework rule (that i cannot modify or edit) using additional css the same way firefox and chrome dev tools do.
What you might mean is the CSS unset or inherit keyword. By that, you can rule out CSS-properties assigned from other CSS sources (that probably aren't your own, e.g. coming from some theme files). unset makes it as if it wasn't set in the first place while inherit makes it inherit the parent's property.
Then just define the selector you're targeting and switch off a certain CSS property, e.g.:
.foo .bar {
font-family: unset;
}
You might have to enforce that with !important in case your selector is less powerful than some other.
Disabling code in css while leaving it in place for possible later use is done by commenting it out. All code between /* and */ will not be used.
/* .foo {
display:block;
} */
I've just noticed that Webkit now has some support regarding the CSS Values and Units Module Level spec. And I was wondering if anyone knows if there is a way to reference another CSS selectors (or DOM style) property from a CSS selector?
I'm expecting something like this to be the answer here. Which I know is most likely the case for current browser implementations; but please keep reading...
For instance, in the case where an animation might resize an element (NOTE the ${.element2.width} is fictitious syntax):
<style type="text/css">
.element1 {
.width: /*-webkit-,-o-,-moz-*/calc(80% - ${.element2.width});
}
.element2 {
.width: 100px;
}
.element2:hover {
width: 200px;
transition: all 0.4s ease-in-out;
}
</style>
In this case I would expect the .element1's width to be re-evaluated based off the transition triggered from the hover events on .element2.
I realize that the aforementioned spec. is only a working draft but perhaps the syntax for referring to such a 'referential selector property' is defined within another spec. which I'm yet to discover? Or simply just not a case for concern (thanks to an overlooked work around)?
I added an answer to the question you linked: https://stackoverflow.com/a/11071806/137626
You can use the same declaration block with as many selectors as you want by grouping them (selectors are separated by commas)
You can't reuse the same declaration block later with a different CSS selector without rewriting the whole declaration block preceded by this selector or using a preprocessor/macro that'll do that for you. Or add it to the existing declaration block as above
Now with your example of an element resized by CSS itself: you could use CSS3 Media Queries and its #media rules containing as many declaration blocks as you want. These media queries would adapt to the width of viewport here.
Mixing expanding elements via animation and media queries that would've the reverse effect will be very soon very complicated (and I'll wonder what content you're playing with); if you want to Keep It Simple, then JS is the way to go. There are variables, loops, events ;) and you can start a CSS3 animation by adding or removing a single class from an element (or whatever CSS selector).
CSS3 won't replace JS (and you shouldn't use JS to style HTML as JS isn't activated or existing everywhere and there's already a nice fallback named CSS).
Other than using a pre-compiler such as sass/scss or less, I believe all you can do is wait or hard-code it.
I'm building an html5/js/css application that will exist inside of a div on my client's existing html. I want to be sure that none of the client's CSS styles are inherited by my app.
Is there a best practice to reset this div and its descendant elements?
I'm thinking I'll use something like:
#my-id * { //styles }
I'm wondering if there is a better/best-practice approach? Thanks.
That will be very difficult/likely impossible to ensure. The type of solutions that Starx is referring to assume no preset styles other than the browser defaults, and "reset" in that context refers to harmonizing the inconsistencies across various browser defaults.
But in your case, your client CSS may already contain highly specific selectors such as
#someDiv .aClass a{float:left;}
... and applying those "CSS reset" solutions simply will not override this.
You can see that Truth's selectors also have lower specificity than this, and therefore will fail to ovetride the client's styles in such cases.
Your question is very similar: How to remove all inherited and computed styles from an element?
So the short answer is: there is no way to ensure this because you cannot "remove all inherited and computed styles from an element" ... update: ...unless you can anticipate and override every preexisting style declaration with new declarations having appropriate specificity.
If you want to only recent this specific div, than what you have is fine. You forgot to reset the div itself though:
#my-id, #my-id * { /* styles */ }
You are probably looking for Eric's CSS Reset as it one of robust resets out there.
But the reset rule is applied to the whole page, instead of the just the box. SO, modify the rules, by keeping #my-id infront.
I'm inspecting an h2 element on a web page using Google Chrome's element inspector and some of the CSS rules--which appear to be applied--are grayed out. It seems that a strike-through indicates that a rule was overridden, but what does it mean when a style is grayed out?
For me the current answers didn't explain the issue fully enough, so I am adding this answer which hopefully might be useful to others.
Greyed/dimmed out text, can mean either
it's a default rule/property the browser applies, which includes defaulted short-hand properties.
It involves inheritance which is a bit more complicated.
Inheritance
Note: Chrome dev tools "style" panel will display a rule set, because one or more rules from the set are being applied to the currently selected DOM node.
I guess, for the sake of completeness, dev tools shows all the rules from that set, whether they are applied or not.
In the case where a rule is applied to the currently selected element due to inheritance (i.e. the rule was applied to an ancestor, and the selected element inherited it), chrome will again display the entire ruleset.
The rules which are applied to the currently selected element appear in normal text.
If a rule exists in that set but is not applied because it's a non-inheritable property (e.g. background color), it will appear as greyed/dimmed text.
here is an article that give a good explanation - (Note: the relevant item is at the bottom of the article - figure 21 - unfortunately the relevant section doesn't have a heading) -http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art033
Excerpt from the article
This [inheritance scenario] can occasionally create a bit of confusion, because defaulted
short-hand properties; figure 21 illustrates the defaulted short-hand
properties of the font property along with the non-inherited
properties. Just be aware of the context that you're looking at when
examining elements.
It means that the rule has been inherited, but is not applicable to the selected element:
http://code.google.com/chrome/devtools/docs/elements-styles.html#computed_style
The pane contains only properties from rules that are directly applicable to the selected element. In order to additionally display inherited properties, enable the Show inherited checkbox. Such properties will be displayed in a dimmed font.
Live example: inspect the element containing the text "Hello, world!"
div {
margin: 0;
}
div#foo {
margin-top: 10px;
}
<div id="foo">Hello, world!</div>
Michael Coleman has the right answer. I just want to add a simple image to go along with it. The link that he included has this simple example: http://commandlinefanatic.com/art033ex4.html
The HTML/DOM looks like this...
The Styles Pane in Chrome looks like this when you select the p element...
As you can see, the p element inherits from its ancestors (the divs). So why is the style background-color: blue grayed out? Because it's part of a rule-set that has at least one style that is inheritable. That inheritable style is text-indent: 1em
background-color:blue is not inheritable but it's part of the rule-set that contains text-indent: 1em which is inhertiable and the developers of Chrome wanted to be complete when displaying rule-sets. However, to distinguish between styles in the rule-set that are inheritable from styles that are not, the styles that are not inhertable are grayed out.
This also occurs if you add a style through the inspector, but that new style doesn't apply to the element you have selected. Usually the styles shown are only those for the element selected, so the grey indicates that the style you just added doesn't select the element which has focus in the DOM navigator.
It means the rule has been replaced with another rule with higher priority. For example stylesheets with:
h2 {
color: red;
}
h2 {
color: blue;
}
The inspector will show the rule color:red; grayed out and color:blue; normally.
Read up on CSS inheritance to learn which rules are inherited/have higher priority.
EDIT:
Mixup: the grayed out rules are the unset rules, which use a special default stylesheet that is applied to all elements(the rules that make the element renderable, because all styles have to have a value).
When using webpack, any css rule or property that has been changed in the source code is grayed out when the page reloads after a rebuild. This is really annoying and forced me to reload the page every time.
The new version of chrome developer shows where it is inherited from.
I'm answering long after the question already has many correct answers because I encountered a different case of having a block of CSS code greyed out and uneditable in Chome DevTools: The block in question contained U+200B ZERO WIDTH SPACE characters. Once I found those and removed them, I could edit the block in Chrome DevTools again. Presumably this might happen with other non-ascii characters as well, I haven't tried to figure that out.