This will probably be an extremely easy question to answer, but I am trying to create a one-stop-shop for setting up property values from SQL and would like to know an answer to the issue that just came up in brainstorming:
If you set a parent (let's say a form) to be Read-Only but set an object (lets say a button) in that parent to NOT be Read-Only, will the button be read-only? Also, what If the parent or child had !Important included?
I am trying to set up a priority system so users can set up these kind of property values without running into issues where unexpected things do not happen.
readonly is not a css property, thus no style. It goes directly into the html tag.
The key buzzwords for you to search are css inheritance and css specifity.
For a quick overview: Yes, there are fixed rules. Not every property is inherited. You can look them up e.g. in the MDN CSS Reference.
Which css rule kicks in depends on where you place the style rules and how specific your selector is.
Cascading order (source):
Inline style (inside an HTML element)
External and internal style sheets (in the head section)
Browser default
Specifity is like a score system. The rule with the highest score (=highest specifity) applies.
ID, e.g. #paragraph {...} (100 points)
Class, e.g. .redparagraphs {...} (10 points)
Tag, e.g. p {...} (1 point)
So the rule div p span {...} would have a score of 3 points, because of three tag selectors.
#wrapper .centered #main .fancynews .withoutborder p {...} would have 231 points and so on.
If two rules have the same score (specifity), then the last one processed counts (stylesheets are processed from top to bottom).
The "quick and dirty" trick for applying a style is to add an !important to the rule like
.alwaysredtext { color:#F00 !important; }
This will override whatever color rule you made and whereever (as long as they do not also have an !important). This is not recommended due to later maintainability problems.
p.s.: Don't miss the Specifity Calculator where you can enter and compare several selector rules and see which one "wins".
Only <input> and <textarea> elements support the readonly attribute, so not, what you are describing is not possible.
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
In my CSS I have the following:
.myDiv{
float:left;
width:100px;
height:100px;
}
.yellow{
background:#faf8c7;
}
.lightGrey{
background:#f8f8f8;
}
In my HTML
<div class="myDiv lightGrey yellow"></div>
This should display the div as the yellow colour but instead it is lightGrey.
If I change the order of the .yellow and .lightGrey in my CSS (not HTML) then the div becomes yellow...why is this?
Surely it should be the order that the classes are written in the HTML that determines whether the div is yellow or grey. The order of the CSS should be irrelevant.
surely it should be the order that the classes are written in the html that determines whether the div is yellow or grey
It's how the cascade was defined:
Find all declarations that apply to the element and property in question, for the target media type. Declarations apply if the associated selector matches the element in question and the target medium matches the media list on all #media rules containing the declaration and on all links on the path through which the style sheet was reached.
Sort according to importance (normal or important) and origin (author, user, or user agent). In ascending order of precedence:
user agent declarations
user normal declarations
author normal declarations
author important declarations
user important declarations
Sort rules with the same importance and origin by specificity of selector: more specific selectors will override more general ones. Pseudo-elements and pseudo-classes are counted as normal elements and classes, respectively.
Finally, sort by order specified: if two declarations have the same weight, origin and specificity, the latter specified wins. Declarations in imported style sheets are considered to be before any declarations in the style sheet itself.
#4 is the part you're struggling with, the declarations have identical specificity, and therefore the latter one is winning.
Cascading Style Sheet.
That means that style that appears later in the stylesheet will overwrite style that appeared earlier in the sheet.
order in your html code of each class myDiv lightGrey yellow is not important at all, it's like you say : I bought 3 colors, but we don't know what is the first or the last you bought
since all rules have the same specificity, the last one (for the meaning of Cascade) specified in the CSS wins. In other words, no matter you re-arrange your classes in the markup, with the given style your background is always lightgray.
Surely it should be the order that the classes are written in the HTML that determines whether the div is yellow or grey. The order of the CSS should be irrelevant.
for the above explanation it's the opposite
everybody!
Reading this topic:
Change background color of HTML <area> tag
I saw the part of a CSS code:
area{
sharedAttr: 'attribute';
}
I wonder what is this sharedAttr. What is amazing Google search:
css sharedAttr
gives only 8 (eight!) results. I can not find any documentation mentioning anything about usage of sharedAttr in css sheet. Can anybody shed some light on the topic?
Thank you in advance!
The example you referenced is alluding (albeit rather poorly) to the fact that you can define one or more CSS properties using a fairly generic selector and then use a more restrictive selector to define specific additions/overrides.
area{
/* matches all instances of the area element, so properties
that should be applied to all area elements go here */
}
#one {
/* properties which should only be applied to the element
with the ID "one" go here */
}
In context of the original question, such a technique is commonly used to reduce the number of styles that must be declared. If 100 area tags all need the same background color, it would be silly to define a selector for each one. However, additional selectors can be defined to override that color and/or define additional properties on certain elements.
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 want to package up a widget to be easily included in an arbitrary project. I don't want to require that the user link to my personally-created style sheet in their host page - I just want the css to be magically injected when they use my code.
I understand that CssResource can go some ways towards this dream, but after scouring documentation I haven't found any reference to natural type selectors. For instance, I want to style the <tr>s in my widget without having to add a class name to each one.
Is this achievable with GWT? GWT's own widgets all come pretty thoroughly styled, but it seems they've added a style class to every single element in the DOM!
You're on the right track - a CssResource or UiBinder's inline <ui:style> will achieve what you're looking for. With regards to styling elements by type instead of class it certainly can be done:
<ui:UiBinder>
<ui:style>
.myTable tr {
color: red;
}
</ui:style>
<table class="{style.myTable}">
<tr><td>A row!</td></tr>
</table>
</ui:UiBinder>
GWT, however, has a reason for preferring explicit class names over descendent selectors: if you have the above style, for example, every time the browser renders a <tr> element it has to walk up the DOM and visit all of the ancestors of that element to see if any of them have the .myTable class. If your application uses a lot of <tr> elements (<div> would be a better example here), most of which don't have a .myTable ancestor, it can cause a noticeable decrease in rendering performance.
I think, I would use UiBinder, and only give the outermost element a class name, like this:
<ui:style>
.outer tr {
...
}
</ui:style>
<div class="{style.outer}">
...
<tr>...</tr>
...
</div>
Now you don't have to assign a class to each tr - you just use the selector ".outer tr", which only applies to <tr>s within some element marked with the class attribute {style.outer} (doesn't have to be a <div> by the way). The same principle would work without UiBinder, too, of course.
Ok I didn't really understand the whole question, maybe still don't but I think your asking for a way to "bulletproof your CSS" from specificity - I get the CSS bit now after seeing the other answers
Unique classnames (a bit of a oxymoron is CSS terms but heyho) added to everything are advised by most to make sure the site (not your) CSS fails as quickly as possible no matter how specific (weighted) their rules are
But you can make you widget CSS completely unique, i.e. so that it cannot be overruled by a site CSS,no matter how many ID's are in their selectors, without very much ado and without specifically classifying everything
e.g. #mywidget div {} could be overruled by site CSS very easily #wrapper #content div {} will do it - your div is a descendant of those two ID's too, and as their rule had 2 ID's versus your one, your CSS will lose - it's impossible to guess every permutation of a site CSS so the easiest thing is to add all those "extra" classes and why YUI and Blueprint are as they are
however if you write your CSS: #mywidget>div {} yours will likely always win, as never in their CSS will a div they're targetting likely be an immediate child of your widget ID (unless of course they choose to customise yours, which they could do with the 'class everything' method too)
so to bulletproof your CSS without adding classes to everything .. I assume your widget already has a unique iD wrapper? then if you don't already have an inner div wrapper, add one, it doesn't need to have a class but giving it one will place an extra layer of bulletproofing on this technique.
then prefix all your rules with #mywidget>div.myclass e.g. #mywidget>div.myclass td {} - the sites own rules, no matter how heavily weighted (many ID's and classes in a selector make a selector more weighted) theirs will fail as soon as they cannot match that particular combination - so your tr's are safe from site CSS takeover ;)
add one div or class and search and replace your CSS to add the prefix to everything.. as for how to package I've no idea