Know this might be a ridiculous question but what is the difference between using the * universal selector, which I know applies to every single element on the page and using just html?
For example:
* {
margin: 0;
padding: 0;
}
and
html {
margin: 0;
padding: 0;
}
* wildcard is for all elements in page, doesn't matter what tag, classname, id or attribute it have.
html is only for <html> element.
Examples:
* {
color:red;
}
div {
color: green;
}
<p>this is red</p>
<p>this is red</p>
<div>this is red but styling specifically to green</div>
<p>this is red</p>
The obvious answer is that simply using the * {} wilcard selects all elements on the page (even including the html element and any other element whether they had a class, id or not).
Using the html tag as a selector simply targets the html tag.
The * wildcard is very useful in that you can also use it to target ALL children of other elements, ie:
.parent > * {
color: red;
}
The above means that any DIRECT descendant of .parent will have a font color of red. Similary, you can do .parent * {} to target all descendants of .parent, whether they're directly below, or a few levels below.
The Universal Selector
In CSS, you generally want to be as specific as possible, so using the universal selector is often not the best approach to take.
The Universal Selector * is going to apply the specific styles to every single element within the entire DOM, regardless of its tag. Additionally, the universal approach can interfere with default inheritance as more specific styles may still be overridden by the * style.
The HTML Selector
The html selector will only apply to the single <html> element that is present. This will still allow inheritance and specificity to function as expected (as it's merely targeting a single parent element and not all of the children individually).
Applying styles to html will work like with any other element and its children: styles trickle down from the top unless the child has its own definition.
With * you set the style for each element individually, so it's applied to each first level element, second level element and so forth.
An example of a practical difference is when using the > operator, which applies styles to direct children of the element:
* > p {
font-size: 12px;
}
Will set the font size to every p that's directly a child of any element in the DOM, regardless of how deep it is.
html > p {
font-size: 12px;
}
Will set the font size of every p that's directly a child of the html element, which would not happen, since body and head are usually the only children of html
Related
This is driving me nuts:
HTML:
<div><h1>Hello World!</h1></div>
CSS:
*:not(div) h1 { color: #900; }
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?" Thus, "Hello World!" should not be coloured red, yet it still is.
For the above markup, adding the child combinator works:
*:not(div) > h1 { color: #900; }
But doesn't affect the h1 element if it is not a child of a div element. For example:
<div><article><h1>Hello World!</h1></article></div>
Which is why I'd like to indicate the h1 element as a descendant, not a child, of the div element. Anyone?
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?"
It does. But in a typical HTML document, every h1 has at least two ancestors that are not div elements — and those ancestors are none other than body and html.
This is the problem with trying to filter ancestors using :not(): it just doesn't work reliably, especially when the :not() is not being qualified by some other selector such as a type selector or a class selector, e.g. .foo:not(div). You'll have a much easier time simply applying styles to all h1 elements and overriding them with div h1.
In Selectors 4, :not() has been enhanced to accept full complex selectors containing combinators, including the descendant combinator. Whether this will be implemented in the fast profile (and thus CSS) remains to be tested and confirmed, but once it is implemented, then you will be able to use it to exclude elements with certain ancestors. Due to how selectors work, the negation has to be done on the element itself and not the ancestor in order to work reliably, and therefore the syntax will look a little different:
h1:not(div h1) { color: #900; }
Anyone who's familiar with jQuery will quickly point out that this selector works in jQuery today. This is one of a number of disparities between Selector 3's :not() and jQuery's :not(), which Selectors 4 seeks to rectify.
The <html> element is not a <div>. The <body> element is not a <div>.
So the condition "has an ancestor that is not a <div>" will be true for all elements.
Unless you can use the > (child) selector, I don't think you can do what you're trying to do - it doesn't really make sense. In your second example, <article> is not a div, so that matches *:not(div) too.
This is driving me nuts:
HTML:
<div><h1>Hello World!</h1></div>
CSS:
*:not(div) h1 { color: #900; }
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?" Thus, "Hello World!" should not be coloured red, yet it still is.
For the above markup, adding the child combinator works:
*:not(div) > h1 { color: #900; }
But doesn't affect the h1 element if it is not a child of a div element. For example:
<div><article><h1>Hello World!</h1></article></div>
Which is why I'd like to indicate the h1 element as a descendant, not a child, of the div element. Anyone?
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?"
It does. But in a typical HTML document, every h1 has at least two ancestors that are not div elements — and those ancestors are none other than body and html.
This is the problem with trying to filter ancestors using :not(): it just doesn't work reliably, especially when the :not() is not being qualified by some other selector such as a type selector or a class selector, e.g. .foo:not(div). You'll have a much easier time simply applying styles to all h1 elements and overriding them with div h1.
In Selectors 4, :not() has been enhanced to accept full complex selectors containing combinators, including the descendant combinator. Whether this will be implemented in the fast profile (and thus CSS) remains to be tested and confirmed, but once it is implemented, then you will be able to use it to exclude elements with certain ancestors. Due to how selectors work, the negation has to be done on the element itself and not the ancestor in order to work reliably, and therefore the syntax will look a little different:
h1:not(div h1) { color: #900; }
Anyone who's familiar with jQuery will quickly point out that this selector works in jQuery today. This is one of a number of disparities between Selector 3's :not() and jQuery's :not(), which Selectors 4 seeks to rectify.
The <html> element is not a <div>. The <body> element is not a <div>.
So the condition "has an ancestor that is not a <div>" will be true for all elements.
Unless you can use the > (child) selector, I don't think you can do what you're trying to do - it doesn't really make sense. In your second example, <article> is not a div, so that matches *:not(div) too.
This is driving me nuts:
HTML:
<div><h1>Hello World!</h1></div>
CSS:
*:not(div) h1 { color: #900; }
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?" Thus, "Hello World!" should not be coloured red, yet it still is.
For the above markup, adding the child combinator works:
*:not(div) > h1 { color: #900; }
But doesn't affect the h1 element if it is not a child of a div element. For example:
<div><article><h1>Hello World!</h1></article></div>
Which is why I'd like to indicate the h1 element as a descendant, not a child, of the div element. Anyone?
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?"
It does. But in a typical HTML document, every h1 has at least two ancestors that are not div elements — and those ancestors are none other than body and html.
This is the problem with trying to filter ancestors using :not(): it just doesn't work reliably, especially when the :not() is not being qualified by some other selector such as a type selector or a class selector, e.g. .foo:not(div). You'll have a much easier time simply applying styles to all h1 elements and overriding them with div h1.
In Selectors 4, :not() has been enhanced to accept full complex selectors containing combinators, including the descendant combinator. Whether this will be implemented in the fast profile (and thus CSS) remains to be tested and confirmed, but once it is implemented, then you will be able to use it to exclude elements with certain ancestors. Due to how selectors work, the negation has to be done on the element itself and not the ancestor in order to work reliably, and therefore the syntax will look a little different:
h1:not(div h1) { color: #900; }
Anyone who's familiar with jQuery will quickly point out that this selector works in jQuery today. This is one of a number of disparities between Selector 3's :not() and jQuery's :not(), which Selectors 4 seeks to rectify.
The <html> element is not a <div>. The <body> element is not a <div>.
So the condition "has an ancestor that is not a <div>" will be true for all elements.
Unless you can use the > (child) selector, I don't think you can do what you're trying to do - it doesn't really make sense. In your second example, <article> is not a div, so that matches *:not(div) too.
This is driving me nuts:
HTML:
<div><h1>Hello World!</h1></div>
CSS:
*:not(div) h1 { color: #900; }
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?" Thus, "Hello World!" should not be coloured red, yet it still is.
For the above markup, adding the child combinator works:
*:not(div) > h1 { color: #900; }
But doesn't affect the h1 element if it is not a child of a div element. For example:
<div><article><h1>Hello World!</h1></article></div>
Which is why I'd like to indicate the h1 element as a descendant, not a child, of the div element. Anyone?
Doesn't this read, "Select all h1 elements that have an ancestor that is not a div element...?"
It does. But in a typical HTML document, every h1 has at least two ancestors that are not div elements — and those ancestors are none other than body and html.
This is the problem with trying to filter ancestors using :not(): it just doesn't work reliably, especially when the :not() is not being qualified by some other selector such as a type selector or a class selector, e.g. .foo:not(div). You'll have a much easier time simply applying styles to all h1 elements and overriding them with div h1.
In Selectors 4, :not() has been enhanced to accept full complex selectors containing combinators, including the descendant combinator. Whether this will be implemented in the fast profile (and thus CSS) remains to be tested and confirmed, but once it is implemented, then you will be able to use it to exclude elements with certain ancestors. Due to how selectors work, the negation has to be done on the element itself and not the ancestor in order to work reliably, and therefore the syntax will look a little different:
h1:not(div h1) { color: #900; }
Anyone who's familiar with jQuery will quickly point out that this selector works in jQuery today. This is one of a number of disparities between Selector 3's :not() and jQuery's :not(), which Selectors 4 seeks to rectify.
The <html> element is not a <div>. The <body> element is not a <div>.
So the condition "has an ancestor that is not a <div>" will be true for all elements.
Unless you can use the > (child) selector, I don't think you can do what you're trying to do - it doesn't really make sense. In your second example, <article> is not a div, so that matches *:not(div) too.
I read an article with some css file
#mainNav #toTop a {
float: right;
margin: 0 8px 0 0;
font-size: 40px;
}
Can someone explain why they have two # things in one css id type ? and how can I use it?
Thank you in advance
I don't know what you mean by a "CSS id type". So I'm just going to explain CSS in general, and we'll see if what this snippet is doing becomes clear.
In CSS you have selectors and property blocks. Your question is about a selector:
#mainNav #toTop a
Selectors are used to target (and on some other platforms to query) HTML (and sometimes XML) elements. This particular rule is using three simple selectors - two id selectors and a tag name selector - put together with two descendant combinators.
That means the selector will target (and the rule block accompanying it will affect) any anchor element (<a>) which is the descendant of any element with id=toTop which in turn is the descendant of any element with id=mainNav.
Since id elements are supposed to be unique, it might seem silly to have two of them in one selector. You can do it if you want to though, and sometimes you'll need to: we haven't spoken about selector specificity.
Specificity defines which rules take precedence over other rules. For example, if two elements both seem to target the same element:
form .label { color: blue; }
#contact-us .label { color: green; }
/* what color is the label? */
... then which rule takes precedence? To figure that out we calculate the specificity. I won't explain the math.
So, let's suppose you have a CSS stylesheet in your project which you can't change - it comes from a 3rd party vendor or something, and it looks like this:
#toTop a { /*...*/ }
If you needed to change the styling of the elements affected by that rule, what would you do?
You could (and probably would) define a new rule with greater specificity. One of the ways you can do that is by adding another id selector to your rule:
#mainNav #toTop a { /*...*/ }
But realistically you could just as easily add any other selector:
div#toTop a { /*...*/ }
Realistically whether it's necessary or not depends on what you're trying to do, what other rules it's interacting with, and what kind of HTML you're dealing with.
Here's another thing to consider: CSS stylesheets are meant to be re-used. What if that element should behave differently if it is in a different place in the document? What if the id="toTop" is sometimes inside the id="mainNav" element on some pages, and in a different place (let's say in the id="footer" element) on others? What if it moves, depending on client-side JavaScript? Then you might want to define CSS like this:
#mainNav #toTop a { /*...*/ }
#footer #toTop a { /*...*/ }
... so ultimately again, why a developer would choose to do this really depends on the CSS, JavaScript and HTML they are working with. It's definitely unusual, but it's not unnecessary nor bad practice.
ID must always be unique. However it is valid to use more than one id to make styles more specific.
In your example you are looking for an element with id #toTop inside #mainNav.
This is a perfectly valid CSS rule. It is very specific. The motivation for this use may have to do with how the page layout is designed and/or how JavaScript handlers interact with the DOM.
This is an example of poor CSS. The selector hierarchy in your example is redundant and unnecessary. It says select all a elements that are descendants of the element with the ID of toTop that is a descendant of the element with the ID of mainNav. So it assumes a basic structure like this:
<div id="mainNav">
<div id="toTop">
link
</div>
</div>
However, as IDs must be unique, only this is needed to target the same elements:
#toTop a
#mainNav #toTop a is using the Descendant Combinator to specify an element a descendant of an element with id toTop descendant of an element with id mainNav.
As said by other answers, this rule seems to be overly specific, because IDs must be uniques and then #toTop a should do the trick.
The real reason behind the choice of declaring this rule is:
Assuming that in a website you have one or more shared CSS (read:
you don't have an different CSS for every page), this rule means:
in a page where a is descendant of #toTop, but #toTop is descendant of an #mainNav element too, then apply this rule;
in a page where a is descendant of #toTop, but #toTop is NOT descendant of an #mainNav element, then DO NOT apply this rule;
because #toTop could be an reusable element that could be declared in different places (one-per-page, of course), for example inside the #mainNav in a page, and inside the #sideNav in another page, with a desired potentially different behavior and look-and-feel.