I recently completed an assignment that had this question:
Within a CSS rule set, a selector includes
a selector and a declaration block
a selector and a value
a property and a selector
a property and a value
The correct answer given was option 4.
I don't quite agree with the answer. In fact, none of the answers seem correct to me, but I wanted to make sure I wasn't misunderstanding the question.
I would appreciate if someone could confirm if the question is flawed or explain the answer if it was indeed correct.
As W3C (World Wide Web Consortium says, a selectors are:
patterns that match against elements in a tree, and as such form one of several technologies that can be used to select nodes in an XML document.
Mozilla Developer Network describes CSS rules here.
Indeed, a CSS rule includes a selector, a property and a value.
Personally, the sintax of the question is a bit awkward, but it is not flawed.
In CSS A "rule set" (or just "rule") consist of a "selector" and a "declaration block".
A "declaration block" consists of "declarations" between curly brackets.
Each "declaration" contains a "property", a colon and a "value" separated from each other within the "declaration block" by a semi-colon.
So you are right. None of the options match, and option 4 is the definition of a "declaration", not a "selector".
See 4.1.7 Rule sets, declaration blocks, and selectors and 4.1.8 Declarations and properties
It's correct:
div { margin: 0; }
The whole line is a rule set
div is a selector
margin is a property
0 is a value
Related
I am taking practice test for Microsoft 70-480. I came across the question in the image. To select attributes that end in specific given value should be a css attribute selector such as [attribute$='value']. I don't understand how we make that selection with a css pseudo-element. Can some one explain to me why
As you've correctly stated, you need an attribute selector for this (although you would need to use [attribute*=value] instead), and you can't match elements using pseudo-element selectors (that's why they're called pseudo-elements!).
The only explanation for the "correct answer" here being option C is that whoever wrote that test either made a mistake with the options, or doesn't understand CSS selectors. Hopefully the former.
This question already has answers here:
What's the difference between html[lang="en"] and html:lang(en) in CSS?
(4 answers)
Closed 6 years ago.
W3C is introducing a new pseudo-class for direction detection in Selectors 4. I am wondering what is the difference between that and a normal attribute selector:
CSS2 - attribute selector
E[dir="rtl"] { ... }
Selectors 4 - dir pseudo-class
E:dir(rtl) { ... }
Is there a specific reason for creating a new pseudo-class for that? Are these selectors identical or do they behave differently? Are there any performance or specificity implications?
Is there a specific reason for creating a new pseudo-class for that?
The same reason the :lang() pseudo-class was introduced alongside attribute selectors in CSS2.1 See What's the difference between html[lang="en"] and html:lang(en) in CSS?
Are these selectors identical or do they behave differently?
See my answer to the linked question. Here's the relevant quotation from Selectors 4 for the sake of completeness:
The difference between :dir(C) and ''[dir=C]'' is that ''[dir=C]'' only performs a comparison against a given attribute on the element, while the :dir(C) pseudo-class uses the UAs knowledge of the document’s semantics to perform the comparison. For example, in HTML, the directionality of an element inherits so that a child without a dir attribute will have the same directionality as its closest ancestor with a valid dir attribute. As another example, in HTML, an element that matches ''[dir=auto]'' will match either :dir(ltr) or :dir(rtl) depending on the resolved directionality of the elements as determined by its contents. [HTML5]
To drive the point home on the similarities between :dir() and :lang(), if you look closely the first sentence is in fact a word-for-word copy of the same paragraph in the section describing :lang().
Much of the rest of the text for :lang() is new, however, because along with :dir(), Selectors 4 also introduces enhanced functionality for :lang().
Are there any performance or specificity implications?
Since the answer to your previous question is that they behave differently, performance is irrelevant.
No specificity implications because pseudo-classes and attribute selectors are equally specific.
1 It's not clear to me why it took almost 15 years for :dir() to be added to Selectors, but there you go.
According to MDN, some subtle differences exist:
The :dir CSS pseudo-class matches elements based on the directionality
of the text contained in it. In HTML, the direction is determined by
the dir attribute. For other document types there may be other
document methods for determining the language.
Note that the usage of the pseudo-class :dir() is not equivalent of
using the [dir=…] attribute selectors. The latter matches a value of
the dir and doesn't match when no attribute is set, even if in that
case the element inherits the value of its parent; similarly [dir=rtl]
or [dir=ltr] won't match the auto value that can be used on the dir
attribute. In the opposite, :dir() will match the value calculated by
the UA, being inherited or the auto value.
Also :dir() considers only the semantic value of the directionality,
the one defined in the document, most of the time in HTML. It won't
consider styling directionality, the one set by CSS properties like
direction which are purely stylistic.
How can this situation happen? (image is from chrome css inspector)
-there is no higher priority rule above
-there is no orange exclamation mark (error)
-I have NOT deactivated it manually in Chrome
Computed:
In developer tools, go to Computed tab beside Style Scroll down and look for those two properties. Expand it and you'll see which file and line number is applied to it
It is very difficult to answer your question by just looking at that image. The rules for CSS rule cascading are complex. I'll refer you to the spec:
https://www.w3.org/TR/2011/REC-CSS2-20110607/cascade.html#cascade
In short: more specific rules override more general ones. Specificity is defined based on how many IDs, classes, and element names are involved, as well as whether the !important declaration was used.
When the !important keyword is used on a specific property/value pair, it will cause that particular value to escape the cascade and become, as the name suggests, the most important value for that property, overriding any others. description here
Why we can't grouping CSS like..
p::selection , p::-moz-selection
{background:transparent;}
Demo : http://jsfiddle.net/l2aelba/MRyVC/1/
Why we have to select one by one like
p::selection {background:transparent;}
p::-moz-selection {background:transparent;}
Demo : http://jsfiddle.net/l2aelba/MRyVC/
Someone can expand this issue ?
Browsers are expected to drop the entire rule if any part of the selector is invalid:
The selector (see also the section on selectors) consists of everything up to (but not including) the first left curly brace ({). A selector always goes together with a declaration block. When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.
CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.
(Note that as far as a browser is concerned, "valid CSS 2.1" really means "a selector that is understood and supported by the browser".)
Since non-Mozilla browsers don't understand ::-moz-selection, they have to drop the rule. Since Mozilla browsers don't understand ::selection, they have to drop the rule as well. It's a lose-lose situation (and another reason why prefixes are unwieldy, especially in selectors).
For the record, I'm surprised this no longer works in Chrome (at least in version 25 on Windows as I just tested anyway). It used to stubbornly parse the selector p::selection, p::-moz-selection as simply p::selection and apply the rule instead of following the spec, and the developers had reasons for making it so. I wonder what changed...
I'm looking more for links to mailing list discussions, etc. rather than speculation.
Can anyone help me find out the rationale behind the quoted error handling rules from the CSS Selectors Level 3 spec.
User agents must observe the rules for handling parsing errors:
a simple selector containing an undeclared namespace prefix is invalid
a selector containing an invalid simple selector, an invalid combinator or an invalid token is invalid.
a group of selectors containing an invalid selector is invalid.
Specifications reusing Selectors must define how to handle parsing errors. (In the case of CSS, the entire rule in which the selector is used is dropped.)
I had the following rule:
#menu li.last, #menu li:last-child {
...
}
To compensate for IE8's lack of last-child support, I used a class and a JavaScript shim. However, this didn't work because IE8 complies with the CSS spec on error handling, and discards the entire rule because it doesn't recognise one selector. This can be fixed by separating the two selectors in to individual rules.
Why is this desirable? Why doesn't the spec suggest simply discarding the unrecognised selector, but keeping the rest of the rule?
I'd like to know the rationale, as the rules currently seem counter-intuitive.
Why is this desirable? Why doesn't the spec suggest simply discarding the unrecognised selector, but keeping the rest of the rule?
The short answer is because it'd be too difficult for implementations to figure out what exactly constitutes "the rest of the rule" (or "the rest of the selector list" for that matter) without getting it wrong and inadvertently messing up layouts, as well as for consistency in error handling, and forward compatibility with future specifications.
I'll preface my long answer with a link to another answer of mine, on handling of invalid selectors. A comment on that answer points directly to section 4.1.7 of the CSS2.1 spec on dealing with errors in selectors within rule sets, which mentions commas in selectors as an example. I think it sums it up pretty nicely:
CSS 2.1 gives a special meaning to the comma (,) in selectors. However, since it is not known if the comma may acquire other meanings in future updates of CSS, the whole statement should be ignored if there is an error anywhere in the selector, even though the rest of the selector may look reasonable in CSS 2.1.
While the comma itself still means grouping two or more selectors as far as selectors are concerned, it turns out that Selectors 4 introduces new functional pseudo-classes that accept selector groups (or selector lists) as arguments, such as :matches() (it even changes :not() so it accepts a list, making it similar to :matches(), whereas in level 3 it only accepts a single simple selector).
This means that not only will you find comma-separated groups of selectors associated with rules, but you'll start finding them within functional pseudo-classes as well (note that this is within a stylesheet only; outside of CSS, selectors can appear in JavaScript code, used by selector libraries and the native Selectors API).
Although not the only reason by far, this alone is enough to potentially over-complicate a parser's error handling rules with a huge risk of breaking the selector, the rule set, or even the layout. In the event of a parsing error with a comma, the parser will have trouble determining whether this selector group corresponds to an entire rule set, or part of another selector group, and how to handle the rest of the selector and its associated rule set accordingly. Instead of trying to guess, risk guessing wrongly and breaking the rule in some way (e.g. by matching and styling all the wrong elements), the safest bet is to discard the rule and move on.
As an example, consider the following rule, whose selector is valid in level 4 but not in level 3, taken from this question of mine:
#sectors > div:not(.alpha, .beta, .gamma) {
color: #808080;
background-color: #e9e9e9;
opacity: 0.5;
}
A naïve parser that doesn't understand Selectors 4 may try to split this into three distinct selectors that share the same declaration block, instead of a single selector with a pseudo-class that accepts a list, based on the commas alone:
#sectors > div:not(.alpha
.beta
.gamma)
If it simply discards the first and last selectors which are obviously invalid, leaving the second selector which is valid, should it then try to apply the rule to any elements with class beta? It's clearly not what the author intends to do, so if a browser does that, it's going to do something unexpected to this layout. By discarding the rule with the invalid selector, the layout looks just a little saner, but that's an over-simplified example; rules with layout-altering styles can cause even bigger problems if applied wrongly.
Of course, other ambiguities in selector parsing can occur too, which can lead to the following situations:
Not knowing where the complex selector ends
Not knowing where the selector list ends
Not knowing where the declaration block begins
A combination of the above
All of which, again, are most easily resolved by discarding the rule set instead of playing the guessing game.
In the case of seemingly well-formed selectors that are unrecognized, such as :last-child as a pseudo-class in your example, the spec makes no distinction between unrecognized selectors and selectors that are just plain malformed. Both result in a parsing error. From the same section that you link to:
Invalidity is caused by a parsing error, e.g. an unrecognized token or a token which is not allowed at the current parsing point.
And by making that statement about :last-child I'm assuming the browser is able to parse a single colon followed by an arbitrary ident as a pseudo-class in the first place; in reality you can't assume that an implementation will know to parse :last-child as a pseudo-class correctly, or something like :lang() or :not() with a functional notation since functional pseudo-classes didn't appear until CSS2.
Selectors defines a specific set of known pseudo-classes and pseudo-elements, the names of which are most likely hardcoded in every implementation. The most naïve of parsers have the entire notation for each pseudo-class and pseudo-element, including the single/double colon(s), hardcoded (I wouldn't be surprised if the major browsers actually do this with :before, :after, :first-letter and :first-line as a special case). So what may seem like a pseudo-class to one implementation might very well be gobbledygook to another.
Since there are so many ways for implementations to fail, the spec makes no distinction, making error handling much more predictable. If a selector is unrecognized, no matter whether it's because it's unsupported or malformed, the rule is discarded. Simple, straightforward, and easy enough to get your head around.
All that said, there is at least one discussion in the www-style public mailing list suggesting that the specification be changed because it may not be so difficult to implement error handling by splitting selectors after all.
I should also mention that some layout engines behave differently, such as WebKit ignoring non-WebKit-prefixed selectors in a rule, applying its own prefixes, while other browsers ignore the rule completely (you can find more examples on Stack Overflow; here's a slightly different one). In a way you could say WebKit is skirting the rule as it is, although it does try to parse comma-separated selector groups smartly in spite of those prefixed selectors.
I don't think the working group has a compelling reason to change this behavior yet. In fact, if anything, they have a compelling reason not to change it, and that's because sites have been relying on this behavior for many years. In the past, we had selector hacks for filtering older versions of IE; today, we have prefixed selectors for filtering other browsers. These hacks all rely on the same behavior of certain browsers discarding rules they don't recognize, with other browsers applying them if they think they're correct, e.g. by recognizing prefixes (or throwing only the unrecognized ones out, as WebKit does). Sites could break in newer versions of those browsers if this rule were to change, which absolutely cannot happen in such a diversified (read: fragmented) Web as ours.
As of April 2013, it was decided in a telecon that this behavior remain unchanged for the reason I've postulated above:
- RESOLVED: Do not adopt MQ-style invalidation for Selectors
due to Web-compat concerns.
Media query-style invalidation refers to invalid media queries in a comma-separated list not breaking the entire #media rule.