n-th child on firefox - css

On this site:
http://c3.finearts.txstate.edu
I styled the right sidebar navigation using:
.sidenav a:after {
display: block;
position: relative;
z-index: 0;
top: -3.6em;
left: 0.15em;
width: 90%;
content: ".";
font-family: 'Ropa Sans', helvetica, arial, sans-serif !important;
font-size:1.5em;
padding-top:1em;
padding-bottom:1em;
padding-left:0.7em;
margin-bottom:1.16em;
background-color: rgba(51,50,48,0.9);
background-image: url('http://uweb.txstate.edu/~j_f166/codepen/images/notch.png');
background-position: top right;
background-repeat:no-repeat;
}
.sidenav a:nth-child(n+2) li{
margin-top: -4.4em;
}
In Firefox 3.6.17 it renders like this:
http://www.browserstack.com/start#os=Windows&os_version=7&browser=Firefox&browser_version=3.6&zoom_to_fit=true&url=http%3A%2F%2Fc3.finearts.txstate.edu&resolution=1024x768&speed=2
(it only takes a moment to load...I'm a newbie here so I can't post a screenshot).
although according to caniuse
these pseudo-classes should be supported starting with 3.5.
As an added hassle, I am using our university's content managements system. It's a Magnolia system. I am 99% positive I can't alter the head to insert javascript.
So three questions:
Is there a css fix I can use to get these pseudo-classes working in this and nearby Firefox version?
Is there a polyfill?
If so, where can I insert such a polyfill given that I don't have access to the html head?
Thanks a bunch. Of course I just noticed this (it didn't show up in BrowserShots and I just happened upon it when doing random testing on colleague's machines). The site is to go live to the University tomorrow.
Yay,
Jill

I believe the issue has something to do with Firefox 3.6 not liking how you have li tags inside anchors inside ul tags, not your CSS. It seems to be trying to automatically fix your markup structure, which is then breaking your CSS.
Take a look a the following screenshot from FF 3.6 and you'll see that your anchor tags are being duplicated:
FF 3.6
Now take a look at this screen shot from Chrome where I've recreated the erroneous markup that FF 3.6 is rendering:
Chrome
This COULD be an issue with how your CMS is serving markup to FF 3.6 but I doubt it. My money is on FF seeing un-semantic markup and trying to "fix" it for you.
If you absolutely had to keep the markup that you're using, then you could try looking for CSS hacks for firefox 3.6, or even use a browser sniffing library like WhichBrowser.
However, I would recommend tweaking your CSS to work with markup that looks more like this:
<ul>
<li>
</li>
</ul>
Some browsers will try to "fix" your markup for you if it's not organized in a way that it was expecting, and this structure is more semantic.

Related

What is `ua.css` and why are some CSS properties expandable in inspector?

I got a problem on Firebug tools. You can see the pic. I drag it.. where is it from? and one more think if i write just some css it's expand a lot.. like
h2 {
padding: 20px
}
but when i am trying to copy my css style then
`h2 {
padding-top: 20px;
padding-right: 20px;
padding-bottom: 20px;
padding-right: 20px
position: 0 0;
}
please help me
They are not bugs, but features, Bapy.
ua.css stands for User Agent CSS and is internally used by your browser. You need a CSS reset to override it.
In style inspector, all shorthand properties can be expanded to see each of the individual properties they stand for.
Additional note: Over (at least) the past year, Firefox has been a step behind Chrome regarding (web) developer tools. Most of their recent enhancements have been implemented after that functionality was initially featured by Chrome dev tools and they look and feel surprisingly similar in Firefox.
For example, at the moment of this writing, Chrome dev tools currently feature a cubic-bezier() viewer which is not available yet in Firefox. I expect one to show up in Firefox dev tools over the following months.
For development purposes only, I recommend using Chrome, at least for the time being.
Please note the above note does not mean I don't appreciate the extraordinary effort and the quality of MDN as a resource, which I highly recommend. It is an incredible aid in web-development and has grown to be a dependable source of information on web standards.
CSS has properties for specifying the padding for each side of an element:
padding-top
padding-right
padding-bottom
padding-left
so you must have to use shorthand css like :
h2 {
padding: 50px 30px 50px 80px;
}
or you can specify individually by name like
h2
{
padding-top: 50px;
padding-right: 30px;
padding-bottom: 50px;
padding-left: 80px;
}
Hopefully it is useful to you :)

CSS :not pseudo-class not working as expected in IE9

Unfortunately, I'm stuck working with legacy code in IE9.
Long story short, I'm cloning an itinerary template (hidden) using jQuery and applying a top border to all clones except the first visible (which is really the second actual because the template is hidden).
What I'm running into is that the border renders in Chrome, FF, and Opera, but not IE9. I think it's because I'm stringing several pseudo-classes together, though in my mind that shouldn't cause a problem.
I'm targeting the itineraries as follows:
#itinerary table.formTable:not(:nth-child(2)):after {
content: "";
border-top: 1px solid #999999;
width: 100%;
position: relative;
margin-top: -130px;
margin-left: 17px;
display: block;
}
Basically, apply the above CSS to all except the second itinerary.
The qusetion is, why is this happening in IE9? According to can I use, the pseudo-class is suported. Is this becuse I've strung so many into this particular rule? I'm at a loss.
Here's how it's supposed to look (Chrome):
Here's what's going on in IE9:
Here's a close-up of the CSS from the IE9 screenshot:
Extended arguments are not supported in IE9 for the pseudo-class :not
here are the docs on that issue
Most likely you can use
#itinerary table.formTable:not(:nth-child(2))
but not
#itinerary table.formTable:not(:nth-child(2)):after
Fortunately IE9 supports conditional commenting so you can write a fallback for IE9 and >

Issue with background color and Google Chrome

Sometimes I get a broken background in Chrome. I do not get this error with any other browser.
This is the simple CSS line responsible for the background color of body:
body
{
background: black;
color: white;
font-family: Chaparral Pro, lucida grande, verdana, sans-serif;
}
This is exactly how I get this problem. I click a link included in an Gmail's email and I get something wrong (no background). I then refresh the page and the background is colored completely.
How do fix this problem?
Never heard of it. Try:
html, body {
width: 100%;
height: 100%;
background-color: #000;
color: #fff;
font-family: ...;
}
Ok guys, I found a solution,
. It's not great but does the trick with no side effects.
The HTML:
<span id="chromeFix"></span>
(put this below the body tags)
The CSS:
#chromeFix { display: block; position: absolute; width: 1px; height: 100%; top: 0px; left: 0px; }
What this does to solve the issue:
It forces Chrome to think the page's content is 100% when it's not - this stops the body 'appearing' the size of the content and resolves the missing background bug. This is basically doing what height: 100% does when applied to the body or html but you don't get the side effect of having your backgrounds cut off when scrolling (past 100% page height) like you do with a 100% height on those elements.
I can sleep now =]
I had the same issue on a couple of sites and fixed it by moving the background styling from body to html (which I guess is a variation of the body {} to html, body{} technique already mentioned but shows that you can make do with the style on html only), e.g.
body {
background-color:#000000;
background-image:url('images/bg.png');
background-repeat:repeat-x;
font-family:Arial,Helvetica,sans-serif;
font-size:85%;
color:#cccccc;
}
becomes
html {
background-color:#000000;
background-image:url('images/bg.png');
background-repeat:repeat-x;
}
body {
font-family:Arial,Helvetica,sans-serif;
font-size:85%;
color:#cccccc;
}
This worked in IE6-8, Chrome 4-5, Safari 4, Opera 10 and Firefox 3.x with no obvious nasty side-effects.
I was able to fix this with:
html { height: 100%; }
HTML and body height 100% doesn't work in older IE versions.
You have to move the backgroundproperties from the body element to the html element.
That will fix it crossbrowser.
Simple, correct, solution - define the background image and colour in html, not body. Unless you've defined a specific height (not a percentage) in the body, its height will be assumed to be as tall as required to hold all content. so your background styling should go into html, which is the entire html document, not just the body. Simples.
After trying all of the other solutions here without success, I skeptically tried the solution found in this article, and got it to work.
Essentially, it boils down to removing #charset "utf-8"; from your CSS.
This seems like a poor implementation in DreamWeaver - but it did fix the issue for me, regardless.
I am not sure 100%, but try to replace selector with "html, body":
html, body
{
background: black;
color: white;
font-family: Chaparral Pro, lucida grande, verdana, sans-serif;
}
I would try what Logan and 1mdm suggested, tho tweak the CSS, but I would really wait for a new Chrome version to come out with fixed bugs, before growing white hair.
IMHO the current Chrome version is still alpha version and was released so that it can spread while it is in development. I personally had issues with table widths, my code worked fine in EVERY browser but could not make it work in Chrome.
Google Chrome and safari needs a tweak for body and background issues.
We have use additional identifier as mentioned below.
<style>
body { background:#204960 url(../images/example.gif) repeat-x top; margin:0; padding:0; font-family:Tahoma; font-size:12px; }
#body{ background:#204960 url(../images/example.gif) repeat-x top; margin:0; padding:0; font-family:Tahoma; font-size:12px;}
</style>
<body id="body">
Use both body and #body identifier and enter same styles in both.
Make the body tag with id attribute of body.
This works for me.
Adam's chromeFix solution with Paul Alexander's pure-CSS modification solved the problem in Chrome, but not in Safari. A couple additional tweaks solved the problem in Safari, too: width: 100% and z-index:-1 (or some other appropriate negative value that puts this element behind all the other elements on the page).
The CSS:
body:after {display:block; position:absolute; width:100%; height:100%; top:0px; left:0px; z-index:-1; content: "";}
I had the same thing in both Chrome and Safari aka Webkit browsers. I'm suspecting it's not a bug, but the incorrect use of css which 'breaks' the background.
In the Question above, the body background property is set to:
background: black;
Which is fine, but not entirely correct. There's no image background, thus...
background-color: black;
I'm seen this problem with Chrome too, if I remember correctly if you minimize and then maximize your window it fixes it as well?
Haven't really used Chrome too much since it was released but this is definitely something I blame on Google as the code I was checking it on was air tight.
Everybody has said your code is fine, and you know it works on other browsers without problems. So it's time to drop the science and just try stuff :)
Try putting the background color IN the body tag itself instead of/as-well-as in the CSS. Maybe insist again (redudantly) in Javascript. At some point, Chrome will have to place the background as you want it every time. Might be a timing-interpreting issue...
[Should any of this work, of course, you can toggle it on the server-side so the funny code only shows up in Chrome. And in a few months, when Chrome has changed and the problem disappears... well, worry about that later.]
It must be a WebKit issue as it is in both Safari 4 and Chrome.
I'm pretty sure this is a bug in Chrome. Most likely it happens if you resize the browser TO full screen, then switch tabs. And sometimes if you just switch tabs/open a new one. Good to hear you found a "fix" though.
When you create CSS style using Dreamweaver for web designing, Dreamweaver adds a default code such as
#charset “utf-8″;
Try removing this from your stylesheet, the background image or colour should display properly
Source
body, html {
width: 100%;
height: 100%;
}
Worked for me :)
Here is how I ended up solving the problem:
This was the actual issue, clearly the body tag defined in CSS was not picked up.
My environment: Chrome Browser/Safari,
First time when it does not work, So according to the thread recommendation here I ended up adding the css file with the html entry
Sample CSS file: mystyle.css
<style type="”text/css”">
html {
background-color:#000000;
background-repeat:repeat-x;
}
body {
background-color: #DCDBD9;
color: #2C2C2C;
font: normal 100% Cambria, Georgia, serif;
}
</style>
Sample html file:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.6), see www.w3.org">
<title>Test Html File</title>
<link rel="stylesheet" href="mystyle.css" type="text/css">
</head>
<body>
<h1>Achieve sentence with Skynet! READ MORE</a></h1>
</body>
</html>
After the first loading it will work in Chrome and then go back to CSS file comment the html entry, so your modified CSS will be
<style type="”text/css”">
// html {
// background-color:#000000;
// background-image:url('bg.png');
// background-repeat:repeat-x;
// }
body {
background-color: #DCDBD9;
color: #2C2C2C;
font: normal 100% Cambria, Georgia, serif;
}
</style>
Clearly seems to be bug in webkit, Saw the same behavior in Safari as well. Thanks for sharing the html information, have been hunting around forever of why the body tag was not working.
The final output is something like this:
Oddly enough it doesn't actually happen on every page and it doesn't seem to always work even when refreshed.
My solutions was to add {height: 100%;} as well.
My Cascading Style Sheet used:
body {background-color: #FAF0E6; font-family: arial, sans-serif }
It worked in Internet Explorer but failed in Firefox and Chrome. I changed it to:
body {background: #FAF0E6; font-family: arial, sans-serif }
(i.e. I removed -color.)
It works in all three browsers. (I had to restart Chrome.)
IF you're still having trouble, you may try switching 'top' to 'bottom' in chromeFix above, and also a div rather than a span
<div id="chromeFix"></div>
style:
#chromeFix { display: block; position: absolute; width: 1px; height: 100%; bottom: 0px; left: 0px; }

How to make this site browser independent

I got this page, and have some problems with ie < 7 and opera 7.11
This is what i hoped to be the layout in all browsers, and these are the IE ones instead: ie 5.5 and ie 6.0.
the xhtml is quite simple:
print "<div id=\"page\">
<div id=\"header\">
<ul id=\"nav\">
<li>Címlap<div>Az oldal címlapja</div></li>
<li>Blogok<div>Minden bejegyzés</div></li>
<li>Friss tartalom<div>Aktuális témák</div></li>
</ul>
</div> <!-- header -->
<div id=\"main\"><div id=\"main-in\">
<div id=\"right\">";
do_boxes();
print "
</div> <!-- right -->
<div id=\"left\">";
do_content();
print"</div> <!-- left -->
</div></div><!-- main --> </div>";
Where a the content made from posts and a post looks like:
<div class="post">
<h2>Newcastleben betiltották a ketreces tojást</h2>
<div class="author">warnew | 2008. october 16. 20:26 </div>
<p>Az angliai Newcastle Városi Tanácsa kitiltotta a ketreces baromfitartásból származó tojásokat az iskolai étkeztetésből, személyzeti éttermekből, rendezvényekről es a "hospitality outletekből".</p>
<p>A ketreces csirke- és pulykahúst még nem tiltották be, de vizsgálják a kérdést, ahogy a Halal hús és a ketreces tojásból készült sütemények és tésztafélék tiltását is.</p>
<ul class="postnav">
<li>Tovább</li>
<li>Hozzászólások (0)</li>
</ul>
</div> <!-- post -->
and a box is like this:
<div id="ownadbox" class="box">
<h5>Viridis matrica</h5>
<img src="http://viridis.hu/files/viridis_matrica_jobb.png" alt="viridis matrica"/>
</div>
The -what i think is - relevan css:
body {
background : transparent url(/images/design/background.png) repeat;
}
#page {
margin : 0px auto;
width : 994px;
background : transparent url(/images/design/header.jpg) no-repeat top left;
}
div#header {
width : 746px;
margin : 0px auto;
}
div#header ul#nav {
padding-top : 170px;
margin-left : 3px;
margin-right : 3px;
border-bottom : #896e51 solid 7px;
overflow : hidden;
}
div#header ul#nav li {
display : block;
float : left;
width : 120px;
margin-bottom : 7px;
}
div#main {
width : 746px;
margin : 0px auto;
}
div#main div#main-in {
padding : 30px 20px;
background : transparent url(/images/design/content-background.png) repeat-y top left;
overflow : hidden;
}
div#main div#main-in div#left {
width : 460px;
overflow : hidden;
float : left;
}
div#main div#main-in div#left div.post {
clear : left;
margin-bottom : 35px;
}
div#main div#main-in div#right {
width : 215px;
float : right;
}
div#main div#main-in div#right div.box {
margin-bottom : 30px;
clear : both;
}
The live version is here, but after I got it fixed it's gona move - thats the reason behind the long codes in the post.
Do you really need to support IE5.5? That seems needlessly painful. Unless you're explicitly doing this for a client who's using the browser, you can pretty much assume that everyone uses IE6 or later.
The CSS support in IE6 is flaky, and almost nonexistent in IE versions older than that. Your best bet for such ancient browsers may be to just display a separate version of the site for those
Edit:
There are several things you can do to patch up IE. Conditional comments can be used to add specific javascript and CSS hacks for various versions of IE, and the following files in particular, do a lot to add in missing functionality:
<!--[if lt IE 7]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js" type="text/javascript"></script><![endif]-->
<!--[if lt IE 8]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE8.js" type="text/javascript"></script><![endif]-->
In addition, make sure IE doesn't jump into quirks mode. There are simple javascript snippets that test which mode the current page is being rendered in, but the main way to avoid quirks mode is to ensure that there is nothing (not even the <?xml prolog tag) before the doctype, and that the doctype is strict.
IE was never famous for its CSS support (it's infamous for its lack of support, and its bugs)... But if you really want to support old IE versions I recommend that you use conditional comments to add extra CSS files for the specific quirks of the older versions. But before you apply specific css, try making the pure HTML as semantic as possible, make its layout is almost how you want it without CSS, then style it afterwards.
I would also recommend that you check out Yahoo's YUI Reset CSS wich makes consistent styling a lot easier. I actually had to add just 3 lines of CSS specifically for IE7 to make a large project look OK, when I used it(!). And by the way: always code by the standards, and test in Firefox, Opera or Safari first, test later in IE.
Opera 7 is pretty old, I would guess most Opera users update their browsers more often than IE users (since they've actually made a choice to switch browsers).
I can live without ie 5.5, and opera 7 but ie 6 is important.
I'm already using a reset.css, and I sure can conditional styles.
So the problem was the following: ie<7 didn't picked up the correct height for the ul#nav and div#main-in elements. Adding the style: height: 100%; to them solved the problem.
Take a look at a stripped-down layout that works, such as on A List Apart.
Start with a working layout such as this and then edit it to your liking. I find this is easier than trying to fix a broken layout.
Well, your CSS is just fine, and it even validates in W3C, the problem is with old IE browsers. You'll have to hack your CSS with ugly code to make it work in those browsers.
Or you can just redirect users of those browsers to a simpler version of the website.
Start by fixing validation errors. I know it's silly to expect IE 5.5 to follow standards, but it might help for Opera. Other thing to thing about is whether you really need to support these ancient browsers.
Do your markup and CSS correctly for the now/future browsers... but to fix the specific versions of IE, I would recommend making a seperate css file, and only conditionally referrencing them. This way, you don't have to muddy up your good design or CSS files with hacks.
Also, shoot for IE6, but don't worry about IE5. It's less than 0.1% of the market now: http://www.w3schools.com/browsers/browsers_stats.asp

Does "display: marker" work in any current browsers, and if so, how?

I can't be sure if my code is sucking, or if it's just that the browsers haven't caught up with the spec yet.
My goal is to simulate list markers using generated content, so as to get e.g. continuation of the counters from list to list in pure CSS.
So the code below, which I think is correct according to the spec, is like this:
html {
counter-reset: myCounter;
}
li {
counter-increment: myCounter;
}
li:before {
content: counter(myCounter)". ";
display: marker;
width: 5em;
text-align: right;
marker-offset: 1em;
}
<ol>
<li>The<li>
<li>quick</li>
<li>brown</li>
</ol>
<ol>
<li>fox</li>
<li>jumped</li>
<li>over</li>
</ol>
But this doesn't seem to generate markers, in either FF3, Chrome, or IE8 beta 2, and if I recall correctly not Opera either (although I've since uninstalled Opera).
So, does anyone know if markers are supposed to work? Quirksmode.org isn't being its usual helpful self in this regard :(.
Apparently marker was introduced as a value in CSS 2 but did not make it to CSS 2.1 because of lacking browser support.
I suppose that didn’t help its popularity …
Source: http://de.selfhtml.org/css/eigenschaften/positionierung.htm#display (German)
Oh ouch, did not know that :-|. That probably seals its case, then. Because mostly I was under the assumption that such a basic CSS2 property should definitely be supported in modern browsers, but if it didn't make it into CSS 2.1, then it makes a lot more sense that it isn't.
For future reference, it doesn't show up in the Mozilla Development Center, so presumably Firefox doesn't support it at all.
Also for future reference, I got my original example to work with inline-block instead:
li:before
{
content: counter(myCounter)". ";
display: inline-block;
width: 2em;
padding-right: 0.3em;
text-align: right;
}

Resources