The website Qq.com has a rule-set with two padding declarations which seem a bit strange. My question is, what does the 11px\0 part do? Does this have something to do with overriding the first padding declaration? I understand the use of the slash in situations like these: / (forward slash) in css style declarations, but I have never seen something like this.
.suggestion .s_title {
padding: 3px 0 1px 11px;
padding: 4px 0 1px 11px\0;
color: #a0a3a8;
font-size: 12px;
line-height: 18px;
}
"Backslash zero" is a css hack targeting IE8 for the current rule. This can be a terrible thing to do, unless there is no other choices. What happens is that IE8 will erroneously believe that this is a valid rule to be applied while other browsers won't, leaving you with a chaos rule:
.my-dirty-rule-for-ie-8-only { margin-bottom: 5px\0; }
For this ruleset, that means the second padding will take effect by overriding the first one only if the user displays your page with IE8.
From a developper point of view, css hacks should be avoided at all cost. You seriously never want to deal with rules targeting a specific browser, as it will haunt you forever from the moment you fall for it.
As Harry pointed out, it was a IE specific hack. You use the \0 part to specify the declaration for a specific IE version. More information about it here:
http://codemug.com/html/css-hacks-for-ie6ie7ie8ie9-and-ie10/
And here
http://mynthon.net/howto/-/webdev/CSS-big-list-of-css-hacks.txt
(See: 24. IE9 hack)
Related
This is a learning exercise for me, so thanks in advance for not telling me why I don't want to do to the following. I don't want to do, I want to understand.
Given the following CSS:
input[type="file"]:focus,
input[type="radio"]:focus,
input[type="checkbox"]:focus {
outline: thin dotted;
outline: 5px auto -webkit-focus-ring-color;
outline-offset: -2px;
}
input[type="checkbox"]:focus {
outline: none;
}
The specificity for both shows as 0,2,1, and everything I read about CSS says the second style should override the first as it comes last. If I get more specific about the second style, it wins. But as posted, Chrome doesn't display the outline, but IE11 and FF28 do. This seems to me to be such a fundamentally simple application of CSS. Does anyone have any insight into what the underlying issue is, so that I can pull it into my thinking as I'm developing stylesheets?
EDIT: Chrome also doesn't display the outline if I delete the second style. In Chrome, the outline: thin dotted are overridden by the following outline line. So it appears that per the spec, Chrome is playing by the book and FF and IE don't? Could it be a union vs. override difference in how browsers interpret CSS?
With apologies, the error was mine. When I switched from bootstrap.min.css to bootstrap.less, I didn't remove the former from loading so it was loaded last and overrode my Site.less -> site.css. I figured it out after I tried to create a fiddle, which I should have done in the first place. Feel free to down-mod this post to hell in the way that it deserves.
The problem only happens on input[type="text"] in Webkit. No matter what I do, there is the equivalent of an extra padding: 1px 0 0 1px (top and left only) on the element.
A similar problem happens in Gecko, input[type="text"] has an equivalent extra padding: 1px 0 0 1px and input[type="button"] has an extra padding: 1px 0 0 0.
Here's a JSFiddle showing you everything I've tried, and nothing works: http://jsfiddle.net/PncMR/10/
Interestingly, when you set the line-height of all the elements to 0 ( http://jsfiddle.net/PncMR/11/ ), the only unaffected elements are the ones with the problems, so I'm assuming that the browser is defaulting to a specific line-height, and I'm now looking for a way to override it.
I've found nothing in the webkit base styles that would do this, but feel free to check yourself:
http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css
This is not a moz-focus-inner problem, or an appearance: none problem, or a box-sizing problem, or an outline problem and I can't find any other solutions.
Edit: See my answer below for the vertical padding problems, but I'm still looking for a solution to the extra padding-left: 1px equivalent on text-inputs only in webkit and gecko. ( http://jsfiddle.net/PncMR/14/ )
In Webkit
The extra vertical "padding" on input[type="text"] in Webkit is because you cannot give text inputs a line-height value of less than normal, which isn't a specific value, but varies depending on the typeface.
I know this is the cause, but I cannot find where the input would be getting this style, because it doesn't appear in the Webkit UA stylesheets.
In Gecko
The extra vertical "padding" on input[type="text"] and input[type="button"] in Gecko is due to user-agent stylesheet containing:
input {
line-height: normal !important;
}
and !important declarations in the user-agent stylesheet cannot be overidden in any way.
Conclusion
You can't go under line-height: normal in Webkit, and you can't have anything other than line-height: normal on these elements in Gecko, so the best solution is to always style these elements with line-height: normal to get the best consistency, which isn't really a nice solution. Ideally, we'd be able to override all UA styles.
Neither of these account for the extra 1px of what acts like text-indent that only appears on input[type="text"] in both rendering engines.
People who care about this, should voice their opinions on these two Bugzilla threads:
https://bugzilla.mozilla.org/show_bug.cgi?id=697451
https://bugzilla.mozilla.org/show_bug.cgi?id=349259
The reason this is happening is because the browser is treating the content of the <input> as if it were an inline element, regardless of the display setting of the <input>. Inline elements have a minimum height as demonstrated here: http://jsfiddle.net/ThinkingStiff/zhReb/
You can override this behavior by making the "child" element inline-block. You can do this with the first-line pseudo-element.
input:first-line {
display: inline-block;
}
I go into more detail as to why this is in my answer to another question: https://stackoverflow.com/a/8964378/918414
This doesn't work in Firefox, but for another reason: Firefox's UA stylesheet (as outlined in #Ian's answer).
I don't know much about CSS (I'm purely a Java/J2EE developer), but I somehow got stuck with a CSS puzzle which I am unable to solve.
I was using a form with a jQuery light box effect which has a div with an id and a class:
<div id="contact-container"
class="myclass"
style="z-index: 1002; height: 386px; width: 450px; position: fixed; left: 406.5px; top: 15%; ">
In my CSS file, I'm using the following entry:
#contact-container {
font: 16px/22px 'Trebuchet MS', Verdana, Arial;
text-align:left;
width:450px;
}
But when this form was displayed as jQuery pop-up, it was getting displayed properly in Mozilla, but on Google Chrome and IE the box was not coming properly: only part of it was being displayed, and was hidden with a scroll bar.
When I saw it through firebug (my first time using it :)), it's showing me something like:
<div id="contact-container"
class="myclass"
style="position: fixed; z-index: 1002; height: 67px; width: 450px; left: 406.5px; top: 15%;">
and for the same settings, it was not coming properly for IE and Mozilla. After lots of Googling, I made the following changes to my CSS:
#contact-container {
font: 16px/22px 'Trebuchet MS', Verdana, Arial;
text-align:left;
width:450px;
height:380px !important;
}
I fixed the height using height:380px !important;, but not knowing much about CSS, I am not sure if this was the right approach, as I searched about height but it was not defined anywhere.
Please suggest if I have adopted a wrong approach.
!important is a useful tool, but the drawback is that it's kind of a tool of last resort. So you don't want to over-use it as you'll end up causing headaches down the road for anyone that's maintaining the site.
However, your example is a typical use. What is happening is that the JS is injecting inline style attributes on the fly. As such, that's over-riding the cascade in your CSS. !important allows you to over-ride that.
!important is valid CSS syntax and there is nothing wrong with using it—provided you understand what it is doing and why it is solving your problem, so that you use it in the right way.
CSS stands for Cascading Style Sheets. You can load multiple styles that layer on top of each other for the same selectors, both with a single CSS file and across multiple CSS files. The later rules within a CSS file take precedence over earlier ones, and rules in a later CSS file take precedence over rules in earlier files. That's the cascade.
You can think of !important as moving a particular rule into a special layer that sits above the others—still is subject to the cascade, but it will only be overridden by subsequent rules that are also marked !important. This enables you to place rules that you want to take precedence earlier in the cascade where this is logical. The most obvious example is to ensure that a rule in a hard-coded stylesheet still will take precedence over a rule that is dynamically-inserted by javascript at load-time... and that's exactly what you're doing here. Appropriate use.
There may, of course, be another way to solve your problem—such as using a more specific selector to target the attribute. There are cases however where changing the selectors available to you are not sufficiently specific to enable this, and where changing the html being generated to add additional selectors may be excessive (e.g. it is markup being dynamically generated by a content management system that does not allow easy customization of that part of the html). In such cases, using !important may be a much more expedient, pragmatic, and in that case be much easier to maintain than the alternative.
In my opinion, it is DEFINITELY bad practice.
Maintaining a site that has !important scattered throughout is a nightmare. If you feel like you need to use !important, what that says to me is that you need to brush up on your CSS specificity.
They're called Cascading for a reason :)
Use !important for development to quickly identify a problem in the cascade, but then fix the problem. It's best to use the least amount of specificity in CSS rules to get something to work. By all means, remove !imporant rule problems before going to production.
If you use !important, it has the highest priority on the element. But take care, if you use twice for a same function (like background-color, or color) on the same element , then the last one will be the highest. Be aware to using twice the !important (means don't do this):
<div id="contact-container" class="myclass" style="z-index: 1002; height: 386px; width: 450px; position: fixed; left: 406.5px; top: 15%; ">
#contact-container {width:450px !important;}
.myclass {width:500px !important;}
In this case, your solution is perfect and absolutely enough.
I have a TEXTAREA where spacing is very important. I formatted it as follows:
TEXTAREA {
font-family: Tahoma, Arial;
font-size: 8pt;
letter-spacing: 0px;
line-height: 13px;
}
How, if I enter some text, the line height is not correctly applied: The last line of every paragraph (before pessing enter or shift-enter) is one pixel to high:
This problem only occurs in Internet Explorer 9, not in Firefox 7 or Chrome 14 (haven't tested older versions so far).
Is there a way to get rid of thad?
BTW: It does not happen for the last line of the textarea, unless there is a linebreak behind it.
Regards,
Steffen
I know this may not actually help entirely nor be the full answer, but it may be worth while reading up a little on the use of !important declaration within CSS.
http://www.impressivewebs.com/everything-you-need-to-know-about-the-important-css-declaration/
The only reason why this springs to mind is there may be another style/declaration that is applied after which is causing some sort of problem and this will make sure your textarea has the correct styles applied to it.
You may also want to check that any <p> CSS declarations are not causing conflicts/problems with any bottom or top margin's/paddings? Same goes with span or any other styles that could potentially cause some sort of problems.
Like I said, I'm aware this may not help in the slightest but it could be a possibility.
I have had similar problems with the last line in a textarea in IE8. When my textarea had a line-height of less than 18px, the cursor changed the line-height. The reason I bring this up is your line-height of 13px is quite small. You may want to experiment with larger line-heights to see if the problem goes away.
I just went many many rounds with this issue and finally discovered that IE9 is adding extra padding to textareas. Line height, height, etc had no effect. This did the trick:
padding: 0px !important;
The styles:
h2 {
color: #71D0FF;
font-size: 11px;
font-weight: bold;
margin: 0px 0px 5px 0px;
}
a.box {
color: #FFFFFF !important;
cursor: pointer;
display: block;
padding: 10px;
text-align: justify;
}
a.box:hover {
background-color: #0C0C0C;
}
a.box span.down {
display: block;
color: #D04242;
float: right;
font-size: 11px;
margin-left: 5px;
}
a.box span.up {
display: block;
color: #71D013;
float: right;
font-size: 11px;
}
span.noob {
color: #FFA142;
}
span.pro {
color: #A142A1;
}
The HTML (this is basically repeated for each link):
<a href="/library/blaze" class="box">
<span class="down">-0</span>
<span class="up">+0</span>
<h2><span class="noob">NOOB</span> BLAZE</h2>
HAS CREATED 0 MAPS, WON 0 BATTLES, AND LOST 0 MAPS
</a>
What I'm not understanding is why it renders differently in Firefox occasionally. Sometimes it shows up like it's supposed to and sometimes it shows up in this weird format as seen here:
I've never had anything like this happen before, does anyone know what's causing it? Does it even do this for anyone else? Like I stated before, sometimes it loads just fine (exact same HTML, CSS, and everything) and sometimes it doesn't. It seems kind of random. It loads just fine in IE with no weird problems at all.
Interesting. I can definitely reproduce it on FF3.6, actually I'm getting the broken version more often.
I can't get my head around it right now, but looking at it in Firefox, there is something broken with the link. If you open "inspect element" in Firebug, you will notice that the rendered DOM definitely changes between the intact and broken view. Firebug will also add _moz-rs-heading to the link, which is sort of explained here.
The first step should definitely be making the markup W3C valid and checking whether it still occurs.
I am a bit surprised that it doesn't act up more than it does.
You have put a block element (h2) inside an inline element (a). The markup is broken, and different browsers will do different things to try to make the best of it. One thing that can happen is that the browser adds an ending tag for the link before the block element.
Us an inline tag instead of the h2 tag, and use CSS to style it to look the way you want.
I'm having the same problem.
http://www.jameshughbanks.com/
I've narrowed it down to this. It ONLY happens when I put a link around multiple elements (in my case it involves one (or more) block element(s) and one (or more) in-line elements.
It is very odd as in it seems to only affect "every other" "error" you create using the method I described above. It will modify the first and third div output but not the 2nd. (at first it affected the 2nd one only, but I partially fixed the problem (it used to mess up the H2's also, but putting the link around the h2's only removed them from getting the error.
So it comes down to only being able to put a link around 1 block element, I haven't tested the error with more than 1 block element, only the mis-match of a block element and multiple in-line elements.
If anyone has any work-arounds for this issue in firefox please let me know. It does not appear to happen in IE, Opera, or Chrome.
Also for those that think this is bad markup, it is included to be valid in the next revision of html5, and it is the only way (without javascript/etc) to do these types of links. Firefox is obviously coded to show this markup properly but for some reason has some type of bug that makes it render it differently sometimes due to unknown reasons. Regardless it needs to be fixed or a work-around developed, I could make each element its own individual block and probably fix it, but that's a lot of extra unnecessary code.
Works fine for me in Safari, Chrome, and Firefox 3.5.
I've tried refreshing repeatedly. No luck in duplicating your problem. Have you tried clearing your cache?
Inspecting the element in Safari or Web Developer (FF plugin) does not reveal anything unusual either.
Is N00B BLAZE always the one that messes up every time you see an issue or is it random?
For me, sometimes Firefox doesn't properly load CSS, it's usually all of it, not partially like it's happening to you. For me tho it's loading correctly. Have you recently changed it by any chance and didn't allowed to properly refresh?
When I buzzed your site, the problem occurred for me in FF3.6. Using Firebug to peek at the HTML, the problem was that the lines that display incorrectly have an extra <a> wrapped around the text, within the <span>. Maybe some HTML included in your DB where it should only be text?