This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Complex CSS selector for parent of active child
How would I make a css selector with that applies style to a table cell that has an input child element?
Unfortunately, you can't target parent elements in CSS yet (I believe it will come in CSS3)(see Sam's answer). If you want to do this, you'll either have to a) use javascript or b) add a class name to the td containing the input.
Here is a nice reference of the selectors you can use currently to target children, siblings, types, etc.
According to Wikipedia:
Selectors are unable to ascend
CSS offers no way to select a parent or ancestor of element that satisfies certain criteria. A more advanced selector scheme (such as XPath) would enable more sophisticated stylesheets. However, the major reasons for the CSS Working Group rejecting proposals for parent selectors are related to browser performance and incremental rendering issues.
And for anyone searching SO in future, this might also be referred to as an ancestor selector.
If you're using jQuery:
$("td input").each(function() { $(this).parent("td").css("style", "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.
This question already has answers here:
Should I use CSS :disabled pseudo-class or [disabled] attribute selector or is it a matter of opinion?
(3 answers)
Closed 7 years ago.
Somehow I am curious, why CSS create two ways for accessing attribute, I know for selector most of us use :hover, :visited, etc. But there are selectors that can be access using attribute selector, e.g: :disable, :readonly, etc.
Is there any benefit using selector instead of attr selector?
Thanks before :)
It is a little unclear exactly what you mean, but this Mozilla article might be informative:
Writing Efficient CSS (MDN)
It has a nice overview of the selector types, when they are useful, and general performance of the selector.
Note that this article is way out of date, but in general selectors based on ID are very efficient and ones based on attributes are less efficient (though many would argue that worrying about efficiency of your css selectors is quite a premature optimization).
But in general, there are different types of selectors for different situations, depending on the structure of your page.
Also, :hover and :visited aren't attribute selectors, they are "pseudo-class" selectors.
:hover would apply to most elements, :visited would only apply to hyperlinks, :readonly would only apply to input boxes...
In CSS terms, an "attribute selector" is one that would select elements based on an HTML attribute. For example this attribute selector would match this element:
<input type="text" name="some-data" />
[type="text"] {
...
}
According to mdn :
The descendant selector is the most expensive selector in CSS. It is
dreadfully expensive—especially if the selector is in the Tag or
Universal Category.
When Modernizr is up , it adds all the non supported classes to the html tag.
Meaning he can later do :
.myNotSupportedClass .myLastDiv <-- notice descendants selecotr[ ]
{
color:red;
}
But this is absolutely slow operation an operation which can be optimized.... which has to go through all the DOM tree in order to find the div.
I know there isn't another way of doing it , but still :
1) they could have added those classes to the body/form which is closer to the elements. soo there will be less of searching.
Or am I wrong ...,?
But this is absolutely slow operation
Eh.
they could have added those classes to the body/form which is closer to the elements. soo there will be less of searching.
body: how much less searching? 1 level less? How much of a difference does that make?
form: not every page has a form, and pages can have more than one form. The form element itself can be placed anywhere in the page body too, so the elements that should be affected by selectors in Modernizr class context may very well be unrelated to it, making searching completely impossible.
Do whatever you like, but since Modernizr chooses to place classes on the html element, write contextual selectors that make use of those classes and the descendant selector. If you're that obsessive about descendant selector performance, you have the choice not to use Modernizr and lose all the feature detection goodness it brings.
Why it chooses to place classes on the html element is anybody's guess. It could have been the most convenient element to place them on.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Cascading style sheets use “id” or “class”
When should i use an id v/s class in my css file.
I know that id is used when it is a unique element.
For all practical purposes if I assume that none of the elements are repeating what should I use?
The design decision comes from practical use. As I'm sure you're guessing: yes, it is perfectly standards-valid to use classes for everything. If you ever need to manipulate elements (take a look at jQuery), though, it is much easier to work with an id rather than a group of elements in a class.
You seem to understand: ids for unique elements, classes for multiple elements with the same design/purpose.
A good heuristic approach to think about is that the id is like the name of the element for if you want to refer to it specifically and the class is for properties of the element that some other elements around your site might have also.
Another thing to think about is specificity, which is the rules for when one css rule overrides another. Here is a good read for that: http://css-tricks.com/specifics-on-css-specificity/
ID has a higher selector specificity than a class. This means that if you have a class and id competing for properties, the id css properties will most likely overwrite the class properties. If I am correct, an ID is worth 100 points, a class selector is 10 points, tag selector is 1 point, and an in-line style is 1000 points. The higher the amount of points, the higher specificity and the higher it has a chance to overwrite the other selector properties.
Hope this helps.