I have found the following css declaration in twitter bootstrap (link and source). Basically it declares the following:
background-color: #eee;
background-color: rgba(86,61,124,.15);
border: 1px solid #ddd;
border: 1px solid rgba(86,61,124,.2);
As far as you see - there is a duplicated background color and border. If it would be anywhere else, I would ignore it thinking 'these guys just do not know css'.
But because this is highly used open-source project, done by professionals, I have a pending question: is it really a bug or does it make sense (if so can someone explain to me why someone would use it?).
rgba() color value has been introduced in CSS level 3 specification.
It declares colors in Red-green-blue model including alpha, allowing specification of the opacity of colors.
rgba() is not supported in old web browsers such as IE8, Opera9, ... Thus, developers use a solid color as a fallback.
In this particular instance, the primary declarations treat as fallback for the next ones:
background-color: #eee; /* The Fallback */
background-color: rgba(86,61,124,.15);
border: 1px solid #ddd; /* The Fallback */
border: 1px solid rgba(86,61,124,.2);
If a web browser supports rgba() the second declaration will override the first one. But if the web browser doesn't understand rgba() color, the second declaration will be ignored, Thus the first one will be appled to the element(s).
However there are some alternatives you might want to consider:
Bulletproof, cross-browser RGBA backgrounds, today
CSS Transparency Settings for All Browsers
Related
I've a Joomla3 website with a custom template looking fine in most browsers but awful in IE8. Lots of the elements just don't seem to be picking up background colours and are just white.
For instance the footer normally has a background colour. When I look at the template.css file (compiled from bootstrap and my custom template.less file) you can see the footer formatting
.footer .container {
padding: 5px;
border: 3px solid #bbbbbb;
padding-top: 0px;
border-top: 0px;
-webkit-border-radius: 0px 0px 4px 4px;
-moz-border-radius: 0px 0px 4px 4px;
border-radius: 0px 0px 4px 4px;
background-color: rgba(245,248,250,0.7);
}
But when I use the website development tools of ie8 (via wine on my mac - in case that makes a difference) to examine why it is just white in ie8, I see
which seems to show that the background-color of .footer .container is just being ignored.
Why would this be? Is this because it's compiled into a rgba format by the less compiler?
Many thanks for any help on this and how I might solve it.
CSS3 colors, such as rgba() are not supported by IE8, that's why it's not working.
You will have to take an alternative approach for specifying the background-color if you want support in IE8. If you don't mind losing the transparency, just use background-color:rgb(245,248,250); or.. background-color: #F5F8FA;
See http://caniuse.com/css3-colors
What you can do is import css3.js in your website. This javascript files allows you to use CSS3 attributes that will work on older browser that wouldn't usually support it.
http://imsky.github.io/cssFx/
Once you've imported that, you can use the following as you were before:
background-color: rgba(245,248,250,0.7);
Just to be on the safe side, I think it's always good practice to have a fallback, just incase, like so:
background-color: #F5F8FA;
background-color: rgba(245,248,250,0.7);
Note that the fallback comes before rgba()
Hope this helps
I encountered this same issue when using IE11 in enterprise mode.
I had this style set:
.heading {
background-color:#f1f1ef;
border-style:solid;
border-color:#E4E3DD;
border-width:1px;
}
and my table heading did not have the background color:
<th class="heading">Test</th>
I had to manually set a property bgcolor for this to work in Enterprise mode:
<th class="heading" bgcolor="#f1f1ef">Test</th>
A basic CSS example. Every browser I have come across will render the item with the margin & padding and a red border
.test{
margin: 4px;
border: 1px solid black;
padding: 4px;
}
.test{
border: 1px solid red;
}
Naturally if I was writing this CSS by hand I would replace the black with red and only have one rule.
But If the first rule comes from a parent CSS file (or in my case a LESS file) that I can't edit because it is used elsewhere, or is from a 3rd party library that I don't want to hack then I see no alternative but to add an extra rule.
Now since I am using server side LESS -> CSS compilation with minification, it seems perfectly reasonable to me that the compressor/minifier should reduce the rules down to just
.test{
margin: 4px;
border: 1px solid red;
padding: 4px;
}
But everything I have tried, keeps both rules; some of the compressor/minifiers go as far as removing newlines
.test{margin:4px;border:1px solid black;padding:4px}.test{border:1px solid red}
It strips out a single newline character but left an entirely unnecessary rule declaration in. This seems bizarre to me.
Is there any system than can do this? (preferably an add on for node.js) If not, do we know why not? Seems like quite a big file size saving with no downside to me.
disclaimer I have tried searching for combining selectors, merging selectors and few variations, apologies if I have missed the common term for this procedure, seems likely since the gains just seem so obvious I have to be missing something!
Why It Cannot and Should Not Be Done
You state:
Every browser I have come across will render the
item with the margin & padding and a red border.
That is because, of course, the cascading nature of CSS. It is designed to work like that for the express purpose of overriding. Which is exactly the point of why (and how) you "add an extra rule" in your CSS to override.
There is a Reason
Now, I can see your point in a preprocessor perhaps "merging" code with the same selector for minimization purposes. However, (1) there would be a rare (if ever) case where the two classes would actually follow one right after the other in the CSS code, as your example shows (and in such a case, minimization would be okay). Usually there is going to be intervening CSS that can affect how the cascade might play out in rendering. Which leads to (2), it would require more logic than is initially obvious (or even possible) to implement. Consider this example:
HTML
<div class="test1 test2"></div>
CSS (Framework File)
.test1 {
margin: 4px;
border: 1px solid black;
padding: 4px;
}
.test2 {
border: 1px solid blue;
}
CSS (Developer File)
.test1 {
border: 1px solid red;
}
The above code if output as normal should render a red border by the cascade, just as the developer wants. Now suppose LESS or another preprocessor does minify it as you desire. It could end up like this:
Theoretical Minimization
.test1 {
margin: 4px;
border: 1px solid red;
padding: 4px;
}
.test2 {
border: 1px solid blue;
}
And would in fact render as blue not as red! This is because the two .test1 merged, now making the .test2 last in the cascade order rather than the second instance of .test1 being last. So a preprocessor would have to be "smart" enough to figure out a theoretically infinite number of possible cascade combinations, and that without knowing what the html coding is that ultimately influences the decision (like here, where the html double classes in conjunction with the cascade order is what is determining the final rendering).
Had the preprocessor merged into the second instance, that does not solve the problem, as what if developer had put a second instance of .test2 after the second instance of .test1, but did not define a different border color? The .test2 border color would still have overridden by merging with the following .test2.
This illustration should show why such a minimization cannot and should not be done--the interactive logic between possible html form and CSS cascade is impossible to predict what or how to merge except in a case were two exact selector strings in the CSS immediately followed one another. Any other case could make a wrong decision.
What is the best CSS practice to achieve a border on all sides of a container, apart from, for example, the bottom?
The border property cannot specify different values for each side.
Option 1: Overwriting Rules
border: 1px solid red;
border-bottom: none;
Seems that an extra computation is needed — similar drawbacks as CSS resets (at least philosophically).
Option 2: Setting Specific Rules
border-top: 1px solid red;
border-left: 1px solid red;
border-right: 1px solid red;
Might be more correct (in terms of CSS "semantics")
But if you want to change the border specifics, then it'll require
multiple changes (harder to manage).
Actually it totally depends on you, what is more convenient to you, it also depends on some state like if I want the color of all borders to be same I'll go for 1st but If I think I need to change the colors of each side of the border in near future I'll go with the second 1, but for now, I'll stick to first option
Reasons:
Less CSS to be stated
Specifically it shows that I want border-bottom as none
As you said I don't need to change each and every property: value if I need any changes
If you say proper semantics, proper semantics define very specifically like
border-color: /*Whatever*/;
border-width: /*Whatever*/;
border-style: /*Whatever*/;
Now am sure you don't want to be this specific
If you only want to specify the values once, you can specify the color and width for all, then the style specifically for the sides:
border-color: red;
border-width: 1px;
border-style: solid solid none solid;
Changing the border-bottom attribute along with removing text-decoration creates the colored underline in some browsers (I can vouch for FF 5 and 6 for sure). But other browsers (at least Safari & Chrome) don't display any line.
For example of the problem, see utsarotaract.org (there is a link in the bottom paragraph of the index page).
Since I've seen this work other places, I'm assuming that some of my CSS is clashing but I'm stumped as to where exactly the problem is.
The issue is the size of your border. Change your 0.5px border to 1px instead and it will work. Live example: http://jsfiddle.net/tw16/WcrNA/
.content a {
border-bottom: 1px solid #A80532; /* instead of 0.5px */
color: #000022;
text-decoration: none;
}
You may want to use:
<a><span>I'm a link</span></a>
with the following CSS:
a {
color: blue;
}
span {
color: green;
}
The alternative being using a border-bottom. It's also a cross-browser solution. You'll just have to set its padding/margin/line-height to make it consistent from a browser to another.
I am debugging my app in IE8's developer mode and I'm running into some very strange behavior. IE8's dev mode usually displays every CSS style on a new line, but not in these cases... take three examples:
#1
.messages .read
background-color: rgb(234,234,234); HEIGHT: 1.5em
padding-top: 0.3em
#2
a:link
color : rgb(80,80,82); TEXT-DECORATION: none
#3
#messaging .body
border-bottom: rgb(...) 1px solid
filter : progid:DXImageTransform.Microsoft.gradient(startColorstr='#FDFDFD', endColorstr='#C2C2C2'); BORDER-LEFT: rgb(...) 1px solid; PADDING-BOTTOM: 1.5em; MARGIN: 15px 0 25px; etc.
As you can see, these are three cases where IE seems to behave strangely, and especially for #3, I get some really strange artefacts, such as an ugly dark grey border around my gradient box.
Is there a known way of getting around this behavior?
Update - gradient artefacts fixed
#3 was fixed surprisingly easily, by adding position:relative; to that style. Apparently IE needs this in order to render its gradients properly.
I'm still interested in knowing why IE lumps some styles together on one line, and whether this quirk has any actual effect.
In the samples you give there are at least some missing semi-colons. This may very well be the problem here.
As suggested in comments: try to validate your CSS. Here's the one from W3:
http://jigsaw.w3.org/css-validator/