I have a fixed footer on my website and in order to create space between it and the main contents I gave the latter a bottom margin. This works fine in Chrome and Firefox.
The rule I used for this is
div#wrap>div:last-child{
margin-bottom:45px;
}
However, IE8 does not seem to respect this (very basic!) CSS rule as shown below.
Insofar as IE8 provides any errors/warnings whatsoever, it doesn't mention anything about this rule being problematic. Increasing the margin-bottom has no effect so the rule seems to be completely ignored. Does anybody understand why? And what is a sound workaround for this?
:last-child is a css3 selector and will not be applied in ie8 if used.
First alternate solution(not recommended)
:first-child+(all the tags until the end) //:first-child+div+div+td+....
{
margin-bottom:45px;
}
Option 2(Recommended)
Give a class to the last child and add your css styling
Related
I have code like this:
.module::first-letter{
visibility:hidden;
}
But this solution is not working on Firefox:(
Display:none; not working with "::first-letter" CSS code :(
How can I hide first letter in Firefox?
you can always try setting font-size:0 while this is not fully supported.
.module::first-letter{
font-size:0
}
<div class="module">Hide Letter H </div>
or as last resort color:transparent
.module::first-letter {
color: transparent
}
<div class="module">Hide Letter H</div>
Note the difference between both, 1st removes the letter space, second
one doesn't.
Note: The following properties can be used with ::first-letter:
font properties
color properties
background properties
margin properties
padding properties
border properties
text-decoration
vertical-align (only if float is 'none')
text-transform
line-height
float
clear
http://www.w3schools.com/cssref/sel_firstletter.asp
Another note, it only works with block level elements, I am not sure, and I could be wrong, you can hide the first letter with only CSS. Quite easy in JS to pull off.
As mentioned in the other answers the properties that can are used is limited but it's possible other browser vendors are initiating greater support
As this list will be extended in the future, it is recommended that you not use any other properties inside the declaration block, in order to keep the CSS future-proof.
Source: MDN
HTML:
<p>Hover</p>
CSS:
p::after {
content: " here";
transition: all 1s;
}
p:hover::after {
font-size: 200%;
color: red;
}
Live demo: http://jsfiddle.net/SPHzj/13/ (works in Firefox and Chrome)
As you can see, I've set up CSS transitions on the ::after pseudo-element of the paragraph. Then, when the paragraph is hovered, two new styles apply for the pseudo-element which are transitioned.
This works in Firefox and Chrome, but not in IE10. My reasoning was that IE doesn't understand the p:hover::after selector, as it works in IE if you set the hover on an ancestor element, e.g. div:hover p::after - live demo: http://jsfiddle.net/SPHzj/14/.
However, this is not the case, as IE is indeed able to understand that selector. The trick is to define a p:hover {} rule as well. (Discovered by #maxw3st.)
p:hover {}
This rule can be empty. The mere presence of this rule will make the transitioning work in IE10.
Live demo: http://jsfiddle.net/SPHzj/15/ (also works in IE10)
What's going on here? Why does IE require that rule to be present in order for transitions to work on the pseudo-element? Should this be considered a bug?
Appears to be a Regression
This does appear to be a legitimate regression in Internet Explorer 10. As indicated on MSDN, since Internet Explorer 7 users have been able to target the hover state of any element , and not only a.
Curiously I tried the :active pseudo-class, and this appears to work as expected. Further establishing that this is a regression, you can see that by changing this to an a element, the transition takes place as expected (since historically, a and :hover go hand-in-hand).
Optional Work-Arounds
There are only a few solutions that I can think of at this point (while waiting for this to be fixed):
Use the empty p:hover {} fix.
Modify your markup to target ::after on a child of the p.
Modify the selector to use combinators.
The first item is that which you specified in your question, and is very attractive given its simplicity. In fact, you could use :hover{} and get the same results (probably the best solution).
The second item is also do-able, but a little less desirable since it requires modifying the markup, which is not always possible, and to be frank, a bit silly.
The last option is somewhat interesting. If you modify the selector to be based on sibling relationships, it magically begins to work again. For instance, suppose we have multiple elements in the body:
<h1>Hello, World</h1>
<p>This is my first paragraph. it does not animate.</p>
<p>This animates, with a pseudo-element.</p>
We can now use combinators to target the second paragraph:
p+p:hover::after {}
This selector will match any paragraph following a paragraph though, which isn't desirable. At this point we could consider :nth-child, or :nth-of-type to further specify which paragraph we want, even using the general sibling combinator:
h1~p:nth-of-type(2):hover::after {} /* Targets second <p> nearest <h1> */
But more ideally we would target with a class:
h1~.hoverme:hover::after {} /* Targets <p class="hoverme"> */
A Two-Char Solution?
One step further, maybe you don't want to be locked down explicitly providing a general sibling tag. You could also use the Universal Selector:
*~.hoverme:hover::after {} /* Targets <p class="hoverme"> among siblings */
This requires that the p tag have siblings, which is typically expected. Very rarely does a document consist of nothing more than a single paragraph tag.
I understand that these aren't ideal, but they are a means to an end for now. Let's hope to see this resolved in future releases of Internet Explorer.
Strangely, the effect will work on a <a> link rather than a paragraph tag.
It certainly appears to be an IE10 bug or regression. Fortunately, you've found a nice fix.
This same phenomenon popped up when I tried adding a rule to change the cursor to a pointer. However, cursor: pointer; has to be included in the pseudo's parent, it can't be used to target just the pseudo's content string in IE10.
http://jsfiddle.net/maxw3st/SPHzj/22/ uses a div as a container, http://jsfiddle.net/maxw3st/7sBVC/ uses the p:hover workaround. Adding the div was suggested by #simevidas, and works fine for the transition, just not the pointer. The pointer only seems to appear in IE10 when it is applied to the parent of the pseudo-element.
After designing and coding a standards-compliant website, that works functionally in normal browsers (Firefox, Chrome, etc), I now need to make it look identical (or mostly so) in Internet Explorer, down to Internet Explorer 6.
The current version of the website can be found at http://www.adwas.org/test/redesign/, with a minimal version of the problem at http://jsfiddle.net/FdS6L/
The problem I'm having is that at and below the area with the logo, it absolutely breaks down in IE6 (and 7, I'm guessing, still). I've already attempted to fix some of the issues, using the star-hack selector, though it still looks heavily borked. My question is: how do I maintain the size of the header, and get the elements to be (somewhat, if not totally) visible, similar to how it looks in most browsers?
Note:
I'm not adverse to adding JavaScript for the layout to work as necessary in IE6. (applies mostly to the submenu navigation)
I was trying to work on your site, and got it to this point: http://jsfiddle.net/3m367/3/. I basically cleaned up some code and restructured the header, where the bars are full-width automatically rather than forcefully (overflow-x is a CSS3 property, so wouldn't work for older browsers). This displays fine in IE7 and up. However, I stumbled upon an issue with your navigation - IE6 supports :hover pseudo-class on a elements only, so selectors like li:hover wouldn't work. Yet, you cannot put your submenus inside parent menu item's a element because you cannot have links within links. I'm not sure if it's possible to do that drop-down menu in IE6 without using JavaScript. Other than that, the navigation seems to be the only thing messing up in IE6 right now.
Instead of using float: left on #sitenav li you could try:
#sitenav {
display: table;
}
#sitenav ul {
display: table-row;
}
#sitenav li {
display: table-cell;
}
You should also consider using conditional comments to hide a set of IE-only stylesheets from other browsers, especially a stylesheet targeting something as old and archane as IE6. If you don't get anything to work with bare CSS and conditional comments, you should consider trying HTML5 Shiv and do the markup with HTML5 (which I believe you should either way).
What rule do you need to enable styling of disabled elements in IE8? I have the code below now. It that works fine under IE7, but not on IE8. IE8 just give me plaint wihte background. Why?
input[disabled], input:disabled, textarea[disabled], textarea[disabled="disabled"], textarea:disabled {
background:#EBEBE4;
}
the :pseudo class in the selector is tripping up IE8!
you have to ungroup these selectors if you absolutely have to use those CSS3 pseudo classes;
If there's a selector in the ruleset that IE8 doesn't understand it's ignoring the whole thing - this is common in IE8 with CSS3 pseudo classes
e.g. If you separate them out and remove the pseudo :disabled parts of the selector completely - you'll see the first example below works for all, whereas the second one still works except for IE7
input[disabled], select[disabled], textarea[disabled] {background-color: #0f0;} /* lime green - works in IE7+ and modern browsers */
input[disabled="disabled"], select[disabled="disabled"], textarea[disabled="disabled"] {background-color:#ff0;} /* yellow - IE8+ and modern browsers */
the color (as opposed to background-color) issue pointed at in another answer is not the cause of your issue, but it wouldn't help if you were also trying to change the color ;)
Another option is to add a disabled class and style it:
input.disabled, textarea.disabled{
background:#EBEBE4;
}
link text
In Safari/Chrome it has extra spacing on the left/top of ol's, blockquotes and other elements.
I can't isolate this, however when I look in the web inspector in Safari, its picking up a margin-left: of 26px on some elements. I have not specified any such rules, so is this a bug in Web inspector?
Can someone enlighten me as to why these exta spacing problems are occurring? Thanks!
That margin-left:26px is the "computed style" of your styling margin-left:2em. Hence why it's under Computed Style section in Safari's Web Inspector.
So if you change your margin-left to some other values the computed-style pixel value will also change too.
Anyway there are indeed extra padding! And it's caused by the user agent stylesheet (-webkit-padding-start:40px). Reset this style by setting padding:0 on your ol and any others elements you want.
A good way to prevent this problem from happening again and develop without worry is to reset your css. A basic reset would be:
* { margin:0; padding:0; }