css - use attribute selector or set class name? - css

Should we use
css: input[type='submit']{...}
or set class name for input tag?
html: <input type="submit" class="submit">
css: .submit{...}

You should use the class name instead of attribute selector if you want to support IE6.
This article is interesting:
The Skinny on CSS Attribute Selectors

Yes, As Sarfraz said if you go for browser compatibility you should go for class name, but attribute selector provides a vast range of control over any elements.

IMO, it all depends on exactly what style you're applying - in addition to the general browser support factors that others have already mentioned, of course. For example, if what you're applying is an absolutely core part of your design (e.g. layout), then it's probably safest to stick with a class name.
However, if what you're applying is a 'decorative flourish' and, in particular, if it's CSS that isn't even supported in older versions of IE anyway (think border-radius, for a start) then it's much better to keep your markup clean and make use of the attribute selector.
Under similar circumstances, you may deem it worthwhile to progressively enhance via javascript - i.e. leave the markup nice and clean but add a class or inline style to the element using JS.

Related

CSS `:disable` vs `[disabled]` [duplicate]

I'm trying to style a disabled input. I can use:
.myInput[disabled] { }
or
.myInput:disabled { }
Is the attribute selector the modern CSS3 way and the way to go forward? I used to use the pseudo-class, but I can't find any info on whether they are the old way and won't be supported or whether they're both equal and you can use whatever you like best.
I have no need to support older browsers (it's an intranet application), so is it:
attribute is newer and better
pseudo-class is still the way to go
whichever you like best
there's a technical reason to use one over the other
Is the attribute selector the modern CSS3 way and the way to go forward?
attribute is newer and better
No; actually, attribute selectors have been around since CSS2, and the disabled attribute itself has existed since HTML 4. As far as I know, the :disabled pseudo-class was introduced in Selectors 3, which makes the pseudo-class newer.
there's a technical reason to use one over the other
Yes, to some extent.
With an attribute selector, you're relying on the knowledge that the document you're styling makes use of a disabled attribute to indicate disabled fields. Theoretically, if you were styling something that wasn't HTML, disabled fields might not be represented using a disabled attribute, e.g. it might be enabled="false" or something like that. Even future editions of HTML could introduce new elements that make use of different attributes to represent enabled/disabled state; those elements wouldn't match the [disabled] attribute selector.
The :disabled pseudo-class decouples the selector from the document you're working with. The spec simply states that it targets elements that are disabled, and that whether an element is enabled, disabled, or neither, is defined by the document language instead:
What constitutes an enabled state, a disabled state, and a user interface element is language-dependent. In a typical document most elements will be neither :enabled nor :disabled.
In other words, when you use the pseudo-class, the UA automatically figures out which elements to match based on the document you're styling, so you don't have to tell it how. Conversely, the attribute selector would match any element with a disabled attribute, regardless of whether that element actually supports being enabled or disabled, such as div. If you're using one of the many modern frameworks that rely on such non-standard behavior, you may be better served by using the attribute selector.
In terms of the DOM, I believe setting the disabled property on a DOM element also modifies the HTML element's disabled attribute, which means there's no difference between either selector with DOM manipulation. I'm not sure if this is browser-dependent, but here's a fiddle that demonstrates it in the latest versions of all major browsers:
// The following statement removes the disabled attribute from the first input
document.querySelector('input:first-child').disabled = false;
You're most likely going to be styling HTML, so none of this may make any difference to you, but if browser compatibility isn't an issue I would choose :enabled and :disabled over :not([disabled]) and [disabled] simply because the pseudo-classes carry semantics that the attribute selector does not. I'm a purist like that.
It turns out that Internet Explorer 10 and 11 fail to recognize the :disabled pseudoclass on some elements and only work fine with the attribute selector syntax.
#test1:disabled { color: graytext; }
#test2[disabled] { color: graytext; }
<form>
<fieldset id="test1" disabled>:disabled</fieldset>
<fieldset id="test2" disabled>[disabled]</fieldset>
</form>
The code snipped above renders in IE like this:
As long as you're only styling input elements, you should be fine either way. Still it's a good advice to test the final result in all browsers you wish to support.
Apparently, you can only select and style input elements with ":(pseudoclass)" / ":disabled" , but other elements, such as DIVs, must instead use [disabled].
I often run into this issue when writing SCSS / SASS and try to select a disabled element.
See
CSS selector for disabled elements

does css selector require a definition?

Does a css class selector always require a definition? For example, if you found in the html: div class="banner", should you always find a .banner in a css file? I ask this question as I've been looking at some website themes and I sometimes find these selectors without any other reference. I'm just not sure if it's an oversight or something common.
There are many reasons to have class names on your HTML elements without having CSS rules associated with them. A couple of examples:
More readable markup. If a component is properly labeled, it's easier to find, debug, or work collaboratively on.
Javascript. Sometimes an element requires some Javascript behaviors, but doesn't inherently need CSS styling itself.
So to answer your question: No, you do not need to define each class or selector in your CSS.

Should I use CSS :disabled pseudo-class or [disabled] attribute selector or is it a matter of opinion?

I'm trying to style a disabled input. I can use:
.myInput[disabled] { }
or
.myInput:disabled { }
Is the attribute selector the modern CSS3 way and the way to go forward? I used to use the pseudo-class, but I can't find any info on whether they are the old way and won't be supported or whether they're both equal and you can use whatever you like best.
I have no need to support older browsers (it's an intranet application), so is it:
attribute is newer and better
pseudo-class is still the way to go
whichever you like best
there's a technical reason to use one over the other
Is the attribute selector the modern CSS3 way and the way to go forward?
attribute is newer and better
No; actually, attribute selectors have been around since CSS2, and the disabled attribute itself has existed since HTML 4. As far as I know, the :disabled pseudo-class was introduced in Selectors 3, which makes the pseudo-class newer.
there's a technical reason to use one over the other
Yes, to some extent.
With an attribute selector, you're relying on the knowledge that the document you're styling makes use of a disabled attribute to indicate disabled fields. Theoretically, if you were styling something that wasn't HTML, disabled fields might not be represented using a disabled attribute, e.g. it might be enabled="false" or something like that. Even future editions of HTML could introduce new elements that make use of different attributes to represent enabled/disabled state; those elements wouldn't match the [disabled] attribute selector.
The :disabled pseudo-class decouples the selector from the document you're working with. The spec simply states that it targets elements that are disabled, and that whether an element is enabled, disabled, or neither, is defined by the document language instead:
What constitutes an enabled state, a disabled state, and a user interface element is language-dependent. In a typical document most elements will be neither :enabled nor :disabled.
In other words, when you use the pseudo-class, the UA automatically figures out which elements to match based on the document you're styling, so you don't have to tell it how. Conversely, the attribute selector would match any element with a disabled attribute, regardless of whether that element actually supports being enabled or disabled, such as div. If you're using one of the many modern frameworks that rely on such non-standard behavior, you may be better served by using the attribute selector.
In terms of the DOM, I believe setting the disabled property on a DOM element also modifies the HTML element's disabled attribute, which means there's no difference between either selector with DOM manipulation. I'm not sure if this is browser-dependent, but here's a fiddle that demonstrates it in the latest versions of all major browsers:
// The following statement removes the disabled attribute from the first input
document.querySelector('input:first-child').disabled = false;
You're most likely going to be styling HTML, so none of this may make any difference to you, but if browser compatibility isn't an issue I would choose :enabled and :disabled over :not([disabled]) and [disabled] simply because the pseudo-classes carry semantics that the attribute selector does not. I'm a purist like that.
It turns out that Internet Explorer 10 and 11 fail to recognize the :disabled pseudoclass on some elements and only work fine with the attribute selector syntax.
#test1:disabled { color: graytext; }
#test2[disabled] { color: graytext; }
<form>
<fieldset id="test1" disabled>:disabled</fieldset>
<fieldset id="test2" disabled>[disabled]</fieldset>
</form>
The code snipped above renders in IE like this:
As long as you're only styling input elements, you should be fine either way. Still it's a good advice to test the final result in all browsers you wish to support.
Apparently, you can only select and style input elements with ":(pseudoclass)" / ":disabled" , but other elements, such as DIVs, must instead use [disabled].
I often run into this issue when writing SCSS / SASS and try to select a disabled element.
See
CSS selector for disabled elements

Resetting and Overrulling CSS under a certain element

I have element that could be injected into any page using a Firefox Addon.
Naturally, it and its ancestors are affected by the CSS rules defined on that page.
I can get so far by simply being explicit about every attribute, but even then my declarations may be overridden by an earlier declaration on the page with greater specificity.
Without making a huge mess of needlessly specific selectors and hanus use of !important, how could I go about resetting all elements' attributes under a given element (div#my_root_container_element) and ensure that my declarations under this parent element apply.
Using an iFrame is one option, but I would rather avoid it if possible - is there another way? Given the application, solutions need only work in Firefox.
Thanks.
Obviously, it seems like this aims to override the "specificity" which is core to CSS in general, but this is the closest I remember ever seeing someone attempt it. It seemed somewhat reputable at the time coming from someone involved with the YUI project:
http://developer.yahoo.com/yui/reset/#code
Using SASS, it's not too unpalatable nesting everything under a div with an ID to achieve sufficient specificity, which is the solution I've opted for.
That said, any !important declaration made in the page CSS will overrule my styles.

In CSS, is anchor the only element that supports pseudo style properties?

I was thinking of using these styles for easier cell rollover effects in a datagrid, but I can't seem to get these styles working on anything other than the most basic of tag.
Is the <a> anchor tag the only element in HTML to support styles like hover, active, visited?
It should work on all elements, but IE6 only supports in on links. I used whatever:hover to work around that.
Modern browsers support the pseudo style properties for all elements, IE6 is the only current wide-spread browser that doesn't (and that's only for the :hover property).
It is unfortunate but until IE6 usage drops below minimal levels, you should avoid using the :hover property on non-anchor elements for better cross-browser support. Alternatively, you can provide IE6 support for it using javascript (with browser detection) or CSS expressions.
According to the CSS2 specification:
CSS doesn't define which elements may be in the above states [:hover, :active, and :focus], or how the states are entered and left.
In other words, don't depend on them working at all. I would use Javascript, along with CSS, to get a wider audience.
PPK has a great reference for browser compatibility here: http://www.quirksmode.org/css/contents.html#t16
It shows the browsers that correctly support the :hover pseudoclass (and lots of other css selectors).
Yes unfortunately anchor is the only tag that supports these styles.
I would recommend the following:
Before coding any of your own JS, try use the JQuery framework, it might save you loads of work.
Another crazy workaround would be to expand the size of the using style to 100% of the parent (cell), this way you would effectively be applying the style to the cell.

Resources