11 replies [Last post]
GazK
Offline
newbie
UK
Last seen: 12 years 29 weeks ago
UK
Joined: 2009-01-04
Posts: 5
Points: 0

I'm a total newbie to this forum, and a relative newbie to CSS positioning, so please be gentle with me!

I have a moderately popular but horribly-non-compliant t*b*e based website at

www.railwaysarchive.co.uk

I have been meaning to modernise the site using CSS-P for the last couple of years, but time etc got in the way. This Christmas, armed with a copy of Dreamweaver, I finally got around to it. I have a basic homepage set up at

www.railwaysarchive.co.uk/new

[full html and css code is at the bottom of this post. code validates to XHTML1.0 strict.]

which generally works fine in my favourite browser, Firefox 3.x - except for the RSS2.0 image at the top right of the document. This should be inside the "Latest News Stories from BBC News" banner, but is appearing absolutely positioned relative to the document.

I have placed it within the banner div like so:

RSS feed for news stories

and given it absolute position:

#wrapper #centre #bannerstories #newsrss {
position: absolute;
width: 16px;
top: 3px;
right: 3px;
}

My understanding was that it would take its absolute position relative to the containing element. Can someone tell me where I'm going wrong?

The other problem comes when you look at the same page in IE7. There is a strange behaviour where the background colour of some elements (#wrapper #centre #banneraccidents) bleeds into the margin. I presume this is an IE CSS problem, and if so, what is the workaround?

Thanks in advance for your patience,

Garry

[html]

The Railways Archive

The Railways Archive

On This Day in History - 1948:

The GWR, LMS, LNER and SR are nationalised as British Railways

view document

More most wanted...

Collision at Congleton on 18th December

Road vehicle collision involving Northern Rail, CrossCountry

0 fatalities, unknown number of injuries more...

Derailment at Bognor Regis on 14th November

Derailment involving Southern

0 fatalities, 0 injuries more...

More recent accidents...

Latest train fare rises attacked

Posted at 10:00 on 02 January 2009

Above-inflation rail fare increases of more than 6% are "completely out of kilter with the real economy", passenger groups have said. more...

Train fare hikes hit passengers

Posted at 04:45 on 02 January 2009

Commuters will have to pay an average of 6% more for their train journeys, as above-inflation rises come into force. more...

Note: the Railways Archive is not responsible for the content of external websites.

More news stories...

New site launched!

Posted by the Archivist at 10:00 on 2nd January

Our new-look site went live this morning. Now you have access to the same great content, but with a more coherent and accessible feel. more...

Charts now available

Posted by the Archivist at 04:45 on 2nd January

We have taken the opportunity to add some new charts to the site. They help to illustrate how the site has grown over the past four years. more...

More site news...

Have Your Say

Should the £16bn Crossrail scheme terminate at Maidenhead, or should it be extended to Reading at extra cost?

Maidenhead

Reading

or just view the results

Mailing List

Join our 429 other members and sign up to receive the RA newsletter, with links to all new documents and other site news...

See how our privacy policy protects your address

SetPromptText('email', 'your email address');

1219 documents6432 accidentsUpdated 21st Nov 2007

SetPromptText('search', 'wide search');

 Valid XHTML 1.0 Valid CSS 2.0

[/html]

/* ----------------- tags ----------------- */
 
a {
	color: #990000;
	font-family: Verdana, sans-serif;
}
 
a:hover {
	color: #DA2E2E;
}
 
a img {
	border-top-style: none;
	border-right-style: none;
	border-bottom-style: none;
	border-left-style: none;
	display: block;
}
 
body {
	margin: 0px;
	padding: 0px;
	/* background-image: url(siteimages/window%20sizes.jpg);
	/* background-repeat: no-repeat;
	/* background-position: 0px 0px; */
}
 
h1 {
	font: bold large times new roman, georgia, serif;
	color: #43616B;
	margin-top: 0px;
	letter-spacing: 0.1em;
}
 
h2 {
	font: times new roman, large georgia, serif;
	color: #43616B;
}
 
h4 {
	font: bold small times new roman, georgia, serif;
	letter-spacing: 0.1em;
	color: #43616B;
	margin-top: 0;
	margin-bottom: 20px;
	}
 
h5 {
	font: italic bold small Arial, sans-serif;
	color: #43616B;
	margin-top: 2px;
}
 
label {
	font-family: Verdana, Arial, Helvetica, sans-serif;
}
 
p {
	font: 0.7em Verdana, sans-serif;
}
 
ul li a {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 0.7em;
	font-weight: bold;
 
}
 
/* ----------------- classes ----------------- */
 
.banner {
	height: 30px;
	margin-bottom: 20px;
	padding-left: 0px;
	text-align: left;
	margin-top: 0px;
	margin-right: 3%;
}
 
.button {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: small;
	font-style: normal;
	font-weight: bold;
	color: #000000;
	background-color: #00df2e;
	padding: 0px;
	border: 1px solid #000000;
	cursor: pointer;
}
 
.latesticon {
	float: left;
}
 
.normal {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: medium;
	font-style: italic;
	font-weight: bold;
}
 
/* ----------------- IDs ----------------- */
 
#featureimg {
	background-color: #153976;
	background-image: url(siteimages/sky.jpg);
	background-repeat: no-repeat;
	background-position: right top;
	height: 250px;
	margin-top: 0px;
	margin-right: 25%;
	margin-bottom: 0px;
	margin-left: 170px;
}
 
#featureimg #onthisday {
	padding-top: 80px;
	padding-right: 200px;
	padding-bottom: 10px;
	padding-left: 120px;
}
 
#featureimg #onthisday p {
	font-weight: bold;
	color: #ffffff;
	text-align: left;
	padding-top: 1%;
	padding-right: 1%;
	padding-bottom: 1%;
	padding-left: 1%;
	line-height: 1.3em;
}
 
#featureimg #onthisday p a:hover, #latestdocs ul li a:hover {
	color: #a4b5c5;
}
 
#featureimg #onthisday h1 {
	color: #ffffff;
}
 
#featureimg #onthisday p a {
	color: #d6d6d6;
}
#latestdocs ul li a {
}
 
 
#latestdocs {
	background-color: #0238a4;
	height: 250px;
	width: 21.9%;
	margin-left: 75%;
	padding-top: 0px;
	padding-right: 1.5%;
	padding-bottom: 0px;
	padding-left: 1.5%;
	overflow: hidden;
	position: absolute;
	top: 101px;
}
 
#latestdocs h1 {
	color: #ffffff;
	margin-top: 10px;
}
 
#latestdocs ul {
	line-height: 0.9;
	color: #d6d6d6;
	width: 100%;
	margin-top: 0px;
	margin-right: 0px;
	margin-left: 0px;
	padding-left: 0px;
	list-style-position: inside;
	list-style-type: none;
	margin-bottom: 0px;
}
 
#latestdocs ul li a {
	font-weight: bold;
	color: #d6d6d6;
}
#latestdocs li {
	margin-bottom: 10px;
}
 
 
#left {
	padding: 0px;
	width: 20%;
	position: absolute;
	top: 101px;
	color: #ffffff;
	background-color: #fc661c;
}
 
#left h2 {
	letter-spacing: 0.1em;
}
 
#left #leftmenu a {
	font-family: Arial, Helvetica, sans-serif;
	font-size: 0.8em;
	font-style: normal;
	font-weight: bold;
	color: #ffffff;
	text-decoration: none;
	background-color: #5C6F90;
	display: block;
	margin: 0px;
	width: 88%;
	padding-top: 6px;
	padding-right: 6%;
	padding-bottom: 6px;
	padding-left: 6%;
}
 
#left #leftbar a {
	color: #ffffff;
}
#left #leftbar a:hover {
	color: #a4b5c5;
}
 
#left #leftbar h2 {
	color: #ffffff;
}
 
#left #leftmenu {
	margin: 0px;
	padding: 0px;
	list-style-type: none;
	background-color: #006699;
}
 
#left #leftmenu a:hover {
	color: #eeeeee;
	background-color: #43616B;
}
 
#left #leftbar {
	width: 88%;
	padding-top: 10px;
	padding-right: 6%;
	padding-bottom: 40px;
	padding-left: 6%;
}
 
#left #leftmenu li {
	display: block;
	border-top-width: 1px;
	border-top-style: solid;
	border-top-color: #A5B5C6;
}
 
#midmenu {
	position: absolute;
	width: 45%;
	left: 570px;
	top: 75px;
}
 
#midmenu ul {
	list-style-type: none;
	margin: 0px;
	padding-top: 5px;
	padding-bottom: 5px;
}
 
#midmenu ul li {
	display: inline;
	border-left-style: solid;
	border-left-width: 1px;
	border-left-color: #000000;
	padding-top: 1px;
	padding-bottom: 1px;
	padding-left: 10px;
	padding-right: 10px;
	margin-top: 0px;
	margin-right: 3px;
	margin-bottom: 0px;
	margin-left: 0px;
	border-right-color: #000000;
	border-right-style: solid;
	border-right-width: 1px;
	border-top-color: #000000;
	border-top-style: solid;
	border-top-width: 1px;
	background-color: #de5c3a;
}
 
#midmenu ul li a {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: small;
	color: #d6d6d6;
	font-weight: bold;
	text-decoration: none;
}
 
#midmenu ul li a:hover {
	color: #a4b5c5;
}
 
#midmenubar {
	background-color: #000000;
	height: 1px;
	margin-top: 0px;
	margin-right: 0px;
	margin-bottom: 0px;
	margin-left: 0px;
	padding-top: 0px;
	padding-right: 0px;
	padding-bottom: 0px;
	padding-left: 0px;
}
 
#stats {
	position: absolute;
	left: 370px;
	top: 5px;
}
#stats p {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-weight: bold;
	color: #ffffff;
}
 
#top {
	background-image: url(siteimages/bgtop.jpg);
	background-repeat: repeat-x;
	margin: 0px;
}
 
#topmenu {
	position: absolute;
	width: 80%;
	top: 10px;
	right: 0px;
}
#topmenu ul {
	margin-top: 0px;
	margin-right: 0px;
	margin-bottom: 40px;
	margin-left: 0px;
	list-style-type: none;
	position: absolute;
	right: 0px;
}
 
#topmenu ul li {
	display: inline;
	padding-top: 0px;
	padding-right: 0.5em;
	padding-bottom: 0px;
	padding-left: 0.5em;
	border-left-width: 1px;
	border-left-style: solid;
	border-left-color: #ffcc33;
}
 
#topmenu ul li.first {
	border-left-width: 0px;
	border-left-style: none;
}
 
#topmenu ul li a {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 0.7em;
	color: #ffcc33;
	font-weight: normal;
}
 
#topmenu ul li a:hover {
	color: #990000;
}
 
#widesearch {
	margin: 0px;
	position: absolute;
	left: 370px;
	top: 60px;
}
 
#wrapper {
	padding: 0px;
	margin-top: 3%;
	margin-right: 3%;
}
 
#wrapper #right {
	float: right;
	width: 26.9%;
	margin-top: 0px;
	margin-right: 0px;
	margin-bottom: 20px;
	padding-top: 0%;
	padding-right: 1%;
	padding-bottom: 1.5%;
	padding-left: 1%;
}
 
/* centre column */
 
#wrapper #centre {
	margin-top: 0%;
	margin-right: 35%;
	margin-bottom: 30px;
	margin-left: 25%;
	padding-top: 10px;
	padding-right: 0px;
	padding-bottom: 0px;
	padding-left: 0px;
}
 
#wrapper #centre #banneraccidents {
	background-color: #CC0033;
}
 
#wrapper #centre #bannerstories {
	background-color: #5c6f90;
	margin-top: 40px;
}
 
#wrapper #centre #bannersitenews {
	background-color: #C64301;
	margin-top: 40px;
}
 
#wrapper #centre .accident,  #wrapper #centre .story, #wrapper #centre .sitenews {
	padding-top: 0px;
	padding-right: 0px;
	padding-bottom: 10px;
	padding-left: 0px;
	color: #000000;
	margin-top: 20px;
}
 
#wrapper #centre .accident{
	background-color: #fff2f2;
	border: solid 1px #ffcccc;
	margin-right: 3%;
	padding-left: 10px;
	padding-right: 10px;
}
 
#wrapper #centre .story {
	background-color: #f2ffff;
	border: solid 1px #a8d0d4;
	margin-right: 3%;
	padding-left: 10px;
	padding-right: 10px;
}
 
#wrapper #centre .sitenews {
	background-color: #FFFBE6;
	border: solid 1px #e0a587;
	margin-right: 3%;
	padding-right: 10px;
	padding-left: 10px;
}
 
#wrapper #centre h1 {
	color: #ffffff;
	padding-top: 4px;
}
 
#wrapper #centre h2 {
	font-size: medium;
	display: block;
	padding-bottom: 0px;
	margin-bottom: 0px;
	margin-top: 5px;
}
 
#wrapper #centre .accident h2 {
	color: #B82E00;
}
 
#wrapper #centre .story h2 {
	color: #5c6f90;
}
 
#wrapper #centre .sitenews h2 {
	color: #B82E00;
}
 
#wrapper #centre p {
	margin-top: 0px;
	margin-bottom: 0px;
}
 
#wrapper #centre .posted {
	font-style: italic;
}
 
#wrapper #centre p.more {
	margin: 10px;
	padding-left: 0px;
}
 
#wrapper #centre p.note {
	margin-top: 0px;
	margin-bottom: 0px;
	padding-top: 0px;
	padding-bottom: 0px;
}
 
/* featured document */
 
#wrapper #right #featured img {
	border: 1px solid #000000;
}
 
#wrapper #right #bannerfeatured {
	background-color: #C64301;
	margin-top: 0px;
}
 
#wrapper #right #featured {
	text-align: center;
	margin-top: 0px;
	padding-top: 20px;
	padding-right: 10%;
	padding-left: 10%;
	color: #FFFFFF;
	background-color: #FFF4D5;
	padding-bottom: 20px;
	border: 1px solid #FFCC33;
	margin-right: 0px;
}
 
#wrapper #right #featured a {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-weight: bold;
}
 
#wrapper #right #wanted {
	text-align: left;
	margin-top: 20px;
	padding-left: 0px;
}
 
#wrapper #right #wanted li {
	margin-bottom: 10px;
}
 
#wrapper #right #wanted ul {
	list-style-type: none;
	list-style-position: inside;
}
 
#footer {
	background-color: #d6d6d6;
	clear: both;
	border-top-width: 1px;
	border-bottom-width: 1px;
	border-top-style: solid;
	border-bottom-style: solid;
	border-top-color: #5c6f90;
	border-bottom-color: #5c6f90;
}
 
p a img .w3c {
	display: inline;
}
 
#docsrss {
	position: absolute;
	top: 15px;
	right: 30px;
}
 
#wrapper #centre #bannerstories #newsrss {
	position: absolute;
	width: 16px;
	top: 3px;
	right: 3px;
}
 
#footer p {
	text-align: center;
	margin: 4px;
}
 
.w3c {
	display: inline;
}
h1 .small {
	font-size: 65%;
}
#wrapper #right #bannerfeatured h1 {
	color: #ffffff;
	padding-top: 4px;
}
#wrapper #centre #bannerstories #newsrss {
	position: absolute;
	width: 18px;
	top: 3px;
	right: 3px;
}

Stomme poes
Stomme poes's picture
Offline
Elder
Netherlands
Last seen: 9 years 47 weeks ago
Netherlands
Timezone: GMT+2
Joined: 2008-02-04
Posts: 1854
Points: 378

The tags that work here for

The tags that work here for wrapping code is the word "code" inside square brackets [like BB code].

Quote:

My understanding was that it would take its absolute position relative to the containing element. Can someone tell me where I'm going wrong?

Only if the containing element is set to "position: relative;" and IE has an issue with this-- supposedly, if say you had an element set to position: relative and a grandchild set to position: absolute, then that grandchild's position should be relative to the grandparent (the "nearest positioned ancestor" as the specs say) but IE can get this wrong sometimes. Otherwise it should work fine.

You don't have anyone relatively positioned. When there is no "nearest positioned ancestor" then everyone "absolutley positioned" is positioned relative to the body. I didn't look at your page link but this should be what the page is doing. Everyone who is absolutely positioned is taken out of the document flow (so, no longer affects or is affected by surrounding codes) and positioned relative to the body's top left corner (that sounds funny, cause I mean "position: absolute"). It's not all that different from taping pieces of paper to the user's monitor, except they can scroll-- they have no other interaction with the page. Which is why we generally avoid absolute positioning, except in small cases or while using CSS tricks (like CSS image maps or image replacement in menus).

Quote:

[full html and css code is at the bottom of this post. code validates to XHTML1.0 strict.]

A fair word of warning-- it is a good thing to have validated code. However, a validator is a stupid thing and it cannot tell you if your code is GOOD, only that it's following the rules set in your chosen DTD-- kinda like "uh" spell "chequer" can't tell "ewe" that "theirs" something wrong with "Eyes Before Ease, Except After Sea".

Various strange things are going on in the code:

p a img .w3c { <span style="font-weight:bold"><--this says, something with the class of "w3c" who is a child of an img who is a child of an anchor who is a child of a p...</span>
display: inline;
}
 
...
 
.w3c {
display: inline;
}

This says it's a child of an image (which isn't possible) and it's repeated twice, making your eyes work harder to find the code you're looking for. For the original display: block declaration, in case you don't want to do that to most of your images, here's another solution:
instead of

a img {
border-top-style: none;
border-right-style: none;
border-bottom-style: none;
border-left-style: none;
display: block;
}

You could

img {
  border: 0;
  vertical-align: bottom;
}

This also removes that space you may have seen on the bottom of images, without making huge changes to images. Blocks have such different properties from inlines that sometimes it's unhandy to make all images blocks, esp if you find yourself setting classes on everyone (not every sperm needs a name, they say, only the ones who do something special) just to make them inline again.

Finding bugs in CSS is harder when you have more code than necessary (though I realise it's hard to slim it down when you're just starting out with CSS). You may want to download Aardvark for Firefox at addons.mozilla.org and see where the outlines are of your boxes. For IE, there's a web developer toolbar which can do the same. This can help you find where and why boxes aren't where you expect them to be. So long as you don't have any spaces or comments in front of your doctype, IE should not be in Quirks mode so your biggest challenge will likely have to do with Haslayout (something you really notice when using floats!)

In general, you want to try as few names (classes and ids) on elements as possible, as little positioning (relative and absolute) as possible, and try first with the least specificity (say h1 instead of #element #element #element h1), otherwise overriding things gets even harder, and starts making your code more and more complicated, thus harder to figuer out and fix.

Let the flow of the document and the defaults (spec defaults that work, not browser defaults) do as much work for you as possible.

Notes: You should only have a single h1 per page. It is the title of your page, and each page should have only one, and each page's h1 should be different. Choose who the name of your page is, and let every else either become lower headers (h2, h3) or not headers at all (truth be told, I have trouble picking one, and this has to do with how the content is set on the page... there doesn't seem to be a whole-page name, except the name (your first Railways image).

Sweeping the page with Aardvark on a 1400px-wide screen shows boxes overlapping each other in places where they shouldn't. This should cause many problems in IE-- sometimes when a block overlaps the menu, the menu items can become unclickable. I also see the clouds image isn't wide enough and leaves a gap next to the menu-- I'd position the image starting form the left and let any extra space have the dark blue background on the right-hand side instead.

Maybe remove or comment out your background images, and stick ugly background colours on your main boxes, and look in FF and IE. This really, really helps you see what these boxes are doing, and unlike a browser extention, can be seen in all browsers. I use this technique for positioning testing all the time.

You could see if your local library has a copy of "HTML Utopia: Designing Without Tables Using CSS" by Rachel Andrew and Dan Shafer-- it's where I first got my feet under me regarding positioning with CSS. It sure doesn't have everything, but enough to learn further online.

Hope this gives you some ideas-- I know I didn't specifically go over the issue with IE7, but if I were given this page and asked to fix it cross-browser, I'd be changing large chunks of the code. If the window is crooked, make sure the foundation being crooked isn't the cause, rather than patching the window to match. Your foundation isn't terrible but needs some shoring up. Stripping it down to the simplest chunks, making sure they're straight and square, really helps.

I'm no expert, but I fake one on teh Internets

GazK
Offline
newbie
UK
Last seen: 12 years 29 weeks ago
UK
Joined: 2009-01-04
Posts: 5
Points: 0

Stomme, Thanks for the

Stomme,

Thanks for the quick and very detailed response. Your advice is excellent, and also gives rise to a couple of issues/questions. Hopefully you will indulge me a little longer in this respect - comments are below.

Quote:

The tags that work here for wrapping code is the word "code" inside square brackets [like BB code].

Noted - thanks.

Quote:

Only if the containing element is set to "position: relative;" and IE has an issue with this-- supposedly, if say you had an element set to position: relative and a grandchild set to position: absolute, then that grandchild's position should be relative to the grandparent (the "nearest positioned ancestor" as the specs say) but IE can get this wrong sometimes. Otherwise it should work fine.

You don't have anyone relatively positioned. When there is no "nearest positioned ancestor" then everyone "absolutley positioned" is positioned relative to the body. I didn't look at your page link but this should be what the page is doing. Everyone who is absolutely positioned is taken out of the document flow (so, no longer affects or is affected by surrounding codes) and positioned relative to the body's top left corner (that sounds funny, cause I mean "position: absolute"). It's not all that different from taping pieces of paper to the user's monitor, except they can scroll-- they have no other interaction with the page. Which is why we generally avoid absolute positioning, except in small cases or while using CSS tricks (like CSS image maps or image replacement in menus).

I must confess this part of your response took me hugely by surprise - especially since my apparently incorrect assumptions are taken directly from the book which you recommend later in your post. I have the May 2005 edition, and page 115 gives this code sample:

http://www.railwaysarchive.co.uk/temp/absolute.htm

<div class="bigtitle" style="position:absolute; left:125px; top:75px;">
This is the first line of text being positioned.
<div class="bigtitle" style="position:absolute; left:25px; top:30px;">
This is the second line.
</div>
</div>

and to quote from page 114 of the book: "Each time a block is positioned on the page (with a position setting other than static) it creates a new positioning context for its descendents., in which the upper left corner of its content area has the coordinates (0,Innocent. So, if you use CSS to position an element that is within the block, its position will be calculated relative to that new coordinate system."

On my first reading of your post, I assumed that the book was plain wrong on this item. But the code snippet above works; but my code, which uses the same principle, does not. Please understand, I accept your statement, but

a) why does the code snippet work? and,
b) accepting your statement that position:absolute will not work, what method should I use to place the img inside the div, anchored to the right border? float:right?

Quote:

A fair word of warning-- it is a good thing to have validated code. However, a validator is a stupid thing and it cannot tell you if your code is GOOD, only that it's following the rules set in your chosen DTD-- kinda like "uh" spell "chequer" can't tell "ewe" that "theirs" something wrong with "Eyes Before Ease, Except After Sea".

Understood. I know there is more to it than validation - hence the queries.

Quote:

This says it's a child of an image (which isn't possible) and it's repeated twice, making your eyes work harder to find the code you're looking for.

Quote:

In general, you want to try as few names (classes and ids) on elements as possible, as little positioning (relative and absolute) as possible, and try first with the least specificity (say h1 instead of #element #element #element h1), otherwise overriding things gets even harder, and starts making your code more and more complicated, thus harder to figuer out and fix.

Fair points - I hadn't understood the subtleties of the css cascade, and I have been letting Dreamweaver handle the CSS tags - unsurprisingly, this doesn't always result in the most elegant code. I will go through and strip things back. For the avoidance of doubt on my part, is:

p a img.w3c

the same as

p a img. w3c

? I assumed that both examples meant "an image of the class w3c which is a child of a link which is a child of a paragraph", Is:

p a .w3c

the correct reference, nothwithstanding your comment about simplifying references?

Quote:

Finding bugs in CSS is harder when you have more code than necessary (though I realise it's hard to slim it down when you're just starting out with CSS). You may want to download Aardvark for Firefox at addons.mozilla.org and see where the outlines are of your boxes. For IE, there's a web developer toolbar which can do the same. This can help you find where and why boxes aren't where you expect them to be. So long as you don't have any spaces or comments in front of your doctype, IE should not be in Quirks mode so your biggest challenge will likely have to do with Haslayout (something you really notice when using floats!)

Quote:

Sweeping the page with Aardvark on a 1400px-wide screen shows boxes overlapping each other in places where they shouldn't. This should cause many problems in IE-- sometimes when a block overlaps the menu, the menu items can become unclickable. I also see the clouds image isn't wide enough and leaves a gap next to the menu-- I'd position the image starting form the left and let any extra space have the dark blue background on the right-hand side instead.

It has been in the back of my mind that I haven't gone through and checked that the box widths add up to 100%, but I hadn't realised the impact this could have. I will go back and make corrections as necessary. Dreamweaver's design view is pretty good for that, and you can change a property and see the effect on the fly. Also a fair point about the clouds image - I will amend.

Quote:

Notes: You should only have a single h1 per page. It is the title of your page, and each page should have only one, and each page's h1 should be different. Choose who the name of your page is, and let every else either become lower headers (h2, h3) or not headers at all (truth be told, I have trouble picking one, and this has to do with how the content is set on the page... there doesn't seem to be a whole-page name, except the name (your first Railways image).

I hadn't realised that. I will change all the H1s to H2s and H2s to H3.

Quote:

You could see if your local library has a copy of "HTML Utopia: Designing Without Tables Using CSS" by Rachel Andrew and Dan Shafer-- it's where I first got my feet under me regarding positioning with CSS. It sure doesn't have everything, but enough to learn further online.

See comment above! A great book I agree, but page 115 has me puzzled!

Stomme poes
Stomme poes's picture
Offline
Elder
Netherlands
Last seen: 9 years 47 weeks ago
Netherlands
Timezone: GMT+2
Joined: 2008-02-04
Posts: 1854
Points: 378

Quote:and to quote from page

Quote:

and to quote from page 114 of the book: "Each time a block is positioned on the page (with a position setting other than static) it creates a new positioning context for its descendents., in which the upper left corner of its content area has the coordinates (0,Innocent. So, if you use CSS to position an element that is within the block, its position will be calculated relative to that new coordinate system."

The book is right, what's at issue is it's missing the phrase: "when an element is positioned absolutely, it is positioned relative to its most recently positioned ancestor".

In your example above, you have the first div (bigtitle) positioned (absolutely, but still positioned other than static).

"I" wrote:

Only if the containing element is set to "position: relative;"

I had earlier said that you needed "position: relative" and I was a bit miss in that-- I am so used to seeing and using relative positioning on a container to set the context, but it is correct that ANY positioned box will set the positining context for any (positioned) children. The book is right, and your test page is right. My bad.

I didn't look to see that all those positioned boxes you have are parent-children of each other, but where your first absolutely positioned box is, is taking its coordinates relative not to its immediate parent container, but the body. All further positioned children will act as you expected, because their parent is absolutely positioned.

Usually you'll see us doing something like this (for image replacement, for instance-- covering up an h1's text with a logo)
Cillit Bang! Cleans up the lot!

h1 {
  width: 300px;
  height: 200px;
  margin-left: 2em; (just positioning the h1 itself)
  <span style="font-weight:bold">position: relative;</span>
}

(so here, the h1 is still in the document, as I didn't absolutely position it, and didn't set any coordinates for it-- we WANT the h1 to remain IN the document flow, but also want it to set a positioning reference)

h1 span {
  position: absolute; /*this also makes it a block, so we can set a height and a width*/
  width: 100%; /*100% of its parent, the h1*/
  height: 100%;
  left: 0;
  top: 0;
  background: url(cillitbang.gif) 0 0 no-repeat;
}

This should follow what the book says. A static container can't set any positioning contexts, but a positioned container can and will. However setting it absolutely positioned will take it out of the document flow (other elements won't make room for it or anything), while relative positioning does exactly what we want

(now technically, according to the CSS specs, a new box is generated, sitting right over the "original" box, which has all the visual stuff you see-- this is why your book might say something like, setting coordinates on a relatively positioned box "leaves a space behind"-- this is NOT a space, it's actually the original box, who did not move. Only the "new, generated" box moved! And this generated box is also out of the document flow. But if I don't set any coordinates, then it's sitting right above my original box and as far as anyone's concerned, I didn't do anything to it at all. Only the positioned children know better : ) But you could ignore all this, it's theory).

Quote:

b) accepting your statement that position:absolute will not work, what method should I use to place the img inside the div, anchored to the right border? float:right?

Is this the img in a banner div? I'd have to look at it closer, but in general, I would use floats to position stuff-- so long as you are quite clear on the whole enclosing and clearing floats rules, and how IE improperly wraps (encloses) floats when the container has Haslayout.

Often I don't wrap banners in divs at all. I make those images blocks themselves (which floating them does) without containers and position them more precisely with margins. I'll often have something like:
AutoTrader r0x0rz

#auto {
float: right;
margin-right: 10px;
whatever else I want;
}

Quote:

For the avoidance of doubt on my part, is:

p a img.w3c

the same as

p a img. w3c

? [/code]

No, the second isn't even valid (a space denotes "descendent" and cannot be between a . or # and the name).

If the class is on the img itself, you don't need the "img" at all.

p a img.w3c is the same as
p a .w3c

with the exception that the second doesn't declare WHAT element has the class of .w3c, and so is a hair more specific.

Some people (sometimes myself) set the name of the element in front of the name so that, when looking at a large CSS sheet, which element had that class/id is clear.

ul id="menu" can be
#menu
or
ul#menu

with again the caveat that the second is a hair more specific and so if at some point you said "ul#menu a" and later said something like "#menu a", the first, if it has any conflicting rules with the second, will override.

Quote:

Dreamweaver's design view is pretty good for that, and you can change a property and see the effect on the fly

Better to use a real browser to see what's happening. Nobody surfs the interwebs with Dreamweaver (and I say this despite the older versions using an old rendering engine of, I forget, Safari's Webkit I think? And the newest using Opera's Presto? Or maybe I have that other way around). Always use a real browser rather than Design View, even though the whole point of Design View was to see your code. See it in the real bugs of a real browser, and you'll be seeing the real thing. I have a heap of browsers open while I code, and make a change, f5 f5 f5 f5 check check check check... for almost every change (if I'm in the middle of work... being lazy, sometimes I'm just on forums with only FF or Opera open : )

I'm no expert, but I fake one on teh Internets

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 28 weeks 6 days ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

More on containing blocks

IE's behavior with containing blocks is very buggy. Beyond being positioned, the ancestor must also have layout. Ingo Chao*, et al, cover this in his paper, On Having Layout: containing blocks, along with other containing block issues.

Sp's haslayout reference may also cover this (I haven't read it).

cheers,

gary

* Ingo, a member of this forum as IChao, has written a book, "Advanced CSS Techniques". I'll recommend it sight unseen based entirely on the quality of his articles and advice. See my blog entry for a link to the book at Amazon.de. (The link had naughty English words embedded in the German, so link is tiny-urled.) The book is in German, so we monolingual country bumpkins are at a loss. --gt

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Stomme poes
Stomme poes's picture
Offline
Elder
Netherlands
Last seen: 9 years 47 weeks ago
Netherlands
Timezone: GMT+2
Joined: 2008-02-04
Posts: 1854
Points: 378

My haslayout link wasn't

My haslayout link wasn't Chao's mainly because while I can easily remember "haslayout.net" I have trouble remembering santanez.de as it's like spanish-german-ish. Though I should just bookmark it like I do with the other ones I link to (cause I'm too lazy to Google).

Oh and I made a typo:

me wrote:

a img.w3c is the same as
p a .w3c

with the exception that the second doesn't declare WHAT element has the class of .w3c, and so is a hair more specific.

Ack, the one mentioning the element too (p a img.w3c) is MORE specific. Sometimes on rare occasions for IE I've needed to say the element. I'm not sure why, no other browsers needed this, but IE6 did. Its specificity model may be off a bit.

I'm no expert, but I fake one on teh Internets

GazK
Offline
newbie
UK
Last seen: 12 years 29 weeks ago
UK
Joined: 2009-01-04
Posts: 5
Points: 0

Stomme poes wrote:Quote:and

Stomme poes wrote:
Quote:

and to quote from page 114 of the book: "Each time a block is positioned on the page (with a position setting other than static) it creates a new positioning context for its descendents., in which the upper left corner of its content area has the coordinates (0,Innocent. So, if you use CSS to position an element that is within the block, its position will be calculated relative to that new coordinate system."

The book is right, what's at issue is it's missing the phrase: "when an element is positioned absolutely, it is positioned relative to its most recently positioned ancestor".

In your example above, you have the first div (bigtitle) positioned (absolutely, but still positioned other than static).

"I" wrote:

Only if the containing element is set to "position: relative;"

I had earlier said that you needed "position: relative" and I was a bit miss in that-- I am so used to seeing and using relative positioning on a container to set the context, but it is correct that ANY positioned box will set the positining context for any (positioned) children. The book is right, and your test page is right. My bad.

I didn't look to see that all those positioned boxes you have are parent-children of each other, but where your first absolutely positioned box is, is taking its coordinates relative not to its immediate parent container, but the body. All further positioned children will act as you expected, because their parent is absolutely positioned.

Aaah, now the mists have cleared! Thanks, thats a very clear explanation and now I understand why the book and your comments are both correct.

Quote:

Usually you'll see us doing something like this (for image replacement, for instance-- covering up an h1's text with a logo)
Cillit Bang! Cleans up the lot!

h1 {
  width: 300px;
  height: 200px;
  margin-left: 2em; (just positioning the h1 itself)
  <span style="font-weight:bold">position: relative;</span>
}

(so here, the h1 is still in the document, as I didn't absolutely position it, and didn't set any coordinates for it-- we WANT the h1 to remain IN the document flow, but also want it to set a positioning reference)

h1 span {
  position: absolute; /*this also makes it a block, so we can set a height and a width*/
  width: 100%; /*100% of its parent, the h1*/
  height: 100%;
  left: 0;
  top: 0;
  background: url(cillitbang.gif) 0 0 no-repeat;
}

This should follow what the book says. A static container can't set any positioning contexts, but a positioned container can and will. However setting it absolutely positioned will take it out of the document flow (other elements won't make room for it or anything), while relative positioning does exactly what we want

That's an interesting example; as an aside, can I ask what the advantage of this technique is?

Quote:

Is this the img in a banner div?

Not exactly; the div is a container for a small image - the icon which is floated left - and the banner title text. The div is given a background colour, and it is this which is bleeding into the margin (see mea culpa below).

Quote:

I'd have to look at it closer, but in general, I would use floats to position stuff-- so long as you are quite clear on the whole enclosing and clearing floats rules, and how IE improperly wraps (encloses) floats when the container has Haslayout.

I have now placed the images correctly using float:right - see

www.railwaysarchive.co.uk/new

Look much nicer in Firefox and IE7 (again, see serious mea culpa below).

Quote:

For the avoidance of doubt on my part, is:

p a img.w3c

the same as

p a img. w3c

? [/code]

No, the second isn't even valid (a space denotes "descendent" and cannot be between a . or # and the name).

If the class is on the img itself, you don't need the "img" at all.

p a img.w3c is the same as
p a .w3c

with the exception that the second doesn't declare WHAT element has the class of .w3c, and so is a hair more specific.

I see. Some more code-amendments are in order for me!

Quote:

Dreamweaver's design view is pretty good for that, and you can change a property and see the effect on the fly.

Better to use a real browser to see what's happening. Nobody surfs the interwebs with Dreamweaver (and I say this despite the older versions using an old rendering engine of, I forget, Safari's Webkit I think? And the newest using Opera's Presto? Or maybe I have that other way around). Always use a real browser rather than Design View, even though the whole point of Design View was to see your code. See it in the real bugs of a real browser, and you'll be seeing the real thing. I have a heap of browsers open while I code, and make a change, f5 f5 f5 f5 check check check check... for almost every change (if I'm in the middle of work... being lazy, sometimes I'm just on forums with only FF or Opera open : )

I absolutely agree. I've been F5ing like mad these last few days. But dreamweaver will allow you to click on a div, see its margins graphically, change the value, and see the result on screen. Useful as a first sweep, followed by F5 to check the result. I downloaded Aardvark by the way - great add-on.

And now, the mea culpa you have been waiting patiently for. My problem isn't in IE7, it is in IE6. I could have sworn that I upgraded a while back, but checking the version, I was still on 6.0. I dimly remember having a problem when I upgraded, rolling back to 6 and then carrying on using Firefox as before. Doh!

So I installed IE7 again last night, and the page renders just fine. Now, even a noob like me has heard of the IE6 box model problem. Am I right in thinking this is the problem? If so, I'm going to do some reading on the hasLayout issue and then approach my code with a mind to fixing it. 16% of my users are on IE 6 - including me, at work! So I have no choice but to make it play pretty.

I now have an additional problem - how do I test my code in IE6? I know that it is not poss to get 6 and 7 working side by side on the same install of Windows, so what's the alternative? Please don't say "virtual machine"!

Stomme poes
Stomme poes's picture
Offline
Elder
Netherlands
Last seen: 9 years 47 weeks ago
Netherlands
Timezone: GMT+2
Joined: 2008-02-04
Posts: 1854
Points: 378

Quote:That's an interesting

Quote:

That's an interesting example; as an aside, can I ask what the advantage of this technique is?

http://www.mezzoblue.com/tests/revised-image-replacement/ is an old page but it pretty much explains the issue. Image replacement kicks ass. It's also more code and has a few problems in x-situations (like text-enlarge).

See that CSSCreator logo near the top? Removing images just shows a link called "Home". Imagine you had this text (CSS Creator) and you had a logo (like what you see above) and because this logo is in a certain font that most other users don't have, you want to have this logo but not rely on alt text to give the information. You could instead have a regular tag, containing text, and that regular tag could have a span or an anchor inside it, empty, which sits on top of the regular text and covers it up with the logo. Often you see people moving the text out of the way with either a negative margin or a negative text-indent to get the text out of the way, but still have text for a screen reader. But there are folks on dial-up or whatever and if they surf without images, but with CSS on, you want the text to be there.

This is I think most important in menus. I tire of menus made up of images as this means if the images are gone I can't see what the menu link is. Title text helps, but only if you have a mouse (or listen in on a screen reader).

Quote:

Not exactly; the div is a container for a small image - the icon which is floated left - and the banner title text. The div is given a background colour, and it is this which is bleeding into the margin (see mea culpa below).

Which chunk of code or section of the page is this? One of your RSS icons gets out of place when thee browser is a certain width, so I assume it's one of those, but I think I see 3 of them.

One thing I see going on now is that even though you have a width, or a min-width on the page (if I go below a certain width I get the scrollbar), many elements don't retain their position like one would expect, but seem to be still positioned relative to the body, or at least the right side of my browser. This causes eventually the menus at the top to overlap and some of the icons to go wild.

People can argue over whether a fixed width or a flexible/liquid page is better, but one of the advantages of a fixed width should be that while people might have to scroll, the positions of things don't change and the page stays put. You have the disadvatage of the scrollbar without the advantage of stable design. We could go through how to pick one or the other, depending on what you ultimately would rather have (a liquid or flex page, no scrollbars, or a fixed width).

Quote:

I now have an additional problem - how do I test my code in IE6? I know that it is not poss to get 6 and 7 working side by side on the same install of Windows, so what's the alternative? Please don't say "virtual machine"!

I recommend Tredosoft's Multiple IE's for the testing of rendering. This is likely the easiest for you since you've now lost your IE6. You keep your regular IE7 and test rendering and layouts in IE6, 5.5, 5, 4 and 3.1 if you want (3.1 doesn't have any CSS but it does bring back memories).

The Javascript engine and the way Flash is handled by these IE's is not like their native counterparts, but like IE7. If you need to test stuff like Javascript then you'll need to get something like VirtualBox or Virtual PC and basically have another copy of Windows on your windows (this is legal with your current Windows license as they are on the same machine). I'm running Ubuntu Linux with 2 Virtual Boxes, one with IE6 native and the other with IE7 and Multiple IE's. Both are XP as Multiple IE's doesn't work (yet) on Vista.

But if you had IE6 then you don't have Vista. Good. Don't upgrade.

Quote:

Now, even a noob like me has heard of the IE6 box model problem. Am I right in thinking this is the problem?

Yes and no. IE 5.5 and below always follow a "broken box model" the details of which you can look up but basically when a width or a height is set on a box, adding padding should increase the total width or height. In the borked box model, the padding merely decreases the amount of room inside the box for the stuff inside.

IE6 and IE7 can follow this broken box model-- IF you have no or an incomplete doctype. Your doctype looks good to me, so you are not writing to Quirks mode. IE6 should follow the w3c box model, minus some bugs.

Haslayout is present in all IE's up to 8 (IE8 is rumoured to have no Layout which is friggin GREAT) and affects layout and is the cause of many IE bugs. However this is different from the box model.

The santanez.de site should be the first thing to popup on teh Googles re haslayout and you'll want to get familiar with the most basic Haslayout bugs as they are a necessity to know.

I'm no expert, but I fake one on teh Internets

GazK
Offline
newbie
UK
Last seen: 12 years 29 weeks ago
UK
Joined: 2009-01-04
Posts: 5
Points: 0

Thanks Gary, I'll look into

gary.turner wrote:

IE's behavior with containing blocks is very buggy. Beyond being positioned, the ancestor must also have layout. Ingo Chao*, et al, cover this in his paper, On Having Layout: containing blocks, along with other containing block issues.

Sp's haslayout reference may also cover this (I haven't read it).

cheers,

gary

Thanks Gary, I'll look into the paper you cite.

GazK
Offline
newbie
UK
Last seen: 12 years 29 weeks ago
UK
Joined: 2009-01-04
Posts: 5
Points: 0

Stomme poes

Stomme poes wrote:

http://www.mezzoblue.com/tests/revised-image-replacement/ is an old page but it pretty much explains the issue. Image replacement kicks ass. It's also more code and has a few problems in x-situations (like text-enlarge).

I see it's use now - thanks.

Stomme poes wrote:

One thing I see going on now is that even though you have a width, or a min-width on the page (if I go below a certain width I get the scrollbar), many elements don't retain their position like one would expect, but seem to be still positioned relative to the body, or at least the right side of my browser. This causes eventually the menus at the top to overlap and some of the icons to go wild.

People can argue over whether a fixed width or a flexible/liquid page is better, but one of the advantages of a fixed width should be that while people might have to scroll, the positions of things don't change and the page stays put. You have the disadvatage of the scrollbar without the advantage of stable design. We could go through how to pick one or the other, depending on what you ultimately would rather have (a liquid or flex page, no scrollbars, or a fixed width).

The page is loosely based on the footbag freaks site in the 1st edition of HTML utopia. See the sample site at http://footbagfreaks.com/1stedition . Looking at that site compared with mine, I can see that it degrades much more gracefully than mine at smaller window sizes - mainly due to the larger site logo image I have used and the additional tabbed menu. I do want to retain a fluid layout, but I clearly need to do a bit more work to get it to behave better.

The elements which are misbehaving can be see in these two screenshots. First the correct layout:

http://www.railwaysarchive.co.uk/temp/IE7-FF.jpg

and now the IE6 render:

http://www.railwaysarchive.co.uk/temp/IE6.jpg

I have helpfully circled one of the misbehaving banners - no the circle isnt part of the CSS! See how the red background colour extends below the ! icon?

The relevant HTML is:

<div class="banner" id="banneraccidents">
   <img class="latesticon" src="siteimages/latestaccidents.jpg" width="31" height="30" alt="" />
 
   <a href="accidents.xml"><img class="bannerrss" src="./siteimages/rss.gif" alt="RSS feed for accidents bulletin" title="RSS feed for accidents bulletin" height="18" width="18" /></a>
 
   <h2>&nbsp;Accident Alerts</h2>
</div>

The image is floated left.

All the banners exhibit this behaviour, as does the large signal image - see the dark blue bleed below the image in the 2nd screenshot.

Stomme poes wrote:

I recommend Tredosoft's Multiple IE's for the testing of rendering. This is likely the easiest for you since you've now lost your IE6. You keep your regular IE7 and test rendering and layouts in IE6, 5.5, 5, 4 and 3.1 if you want (3.1 doesn't have any CSS but it does bring back memories).

The Javascript engine and the way Flash is handled by these IE's is not like their native counterparts, but like IE7. If you need to test stuff like Javascript then you'll need to get something like VirtualBox or Virtual PC and basically have another copy of Windows on your windows (this is legal with your current Windows license as they are on the same machine). I'm running Ubuntu Linux with 2 Virtual Boxes, one with IE6 native and the other with IE7 and Multiple IE's. Both are XP as Multiple IE's doesn't work (yet) on Vista.

I fancied IE hacks even less than a VM, so I took a deep breath and installed Virtual PC and the free winXP IE6 image. Works a treat! I'm not bothered about 5.5 or netscape 4 - awstats shows 0% users for these. The site looks **** on punched cards as well!

Stomme poes wrote:

But if you had IE6 then you don't have Vista. Good. Don't upgrade.

Don't plan to! Ain't broke, put the spanner down, thats my motto.

Stomme poes wrote:

IE 5.5 and below always follow a "broken box model" the details of which you can look up but basically when a width or a height is set on a box, adding padding should increase the total width or height. In the borked box model, the padding merely decreases the amount of room inside the box for the stuff inside.

IE6 and IE7 can follow this broken box model-- IF you have no or an incomplete doctype. Your doctype looks good to me, so you are not writing to Quirks mode. IE6 should follow the w3c box model, minus some bugs.

Haslayout is present in all IE's up to 8 (IE8 is rumoured to have no Layout which is friggin GREAT) and affects layout and is the cause of many IE bugs. However this is different from the box model.

The santanez.de site should be the first thing to popup on teh Googles re haslayout and you'll want to get familiar with the most basic Haslayout bugs as they are a necessity to know.

OK. I'm homing in on it now - it's a hasLayout issue. Would I be right in thinking trial and error is the best way to flatten these bugs?

//mod edit: fixed mismatched quote tags. --gt

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 28 weeks 6 days ago
Dallas
Timezone: GMT-6
Joined: 2004-06-25
Posts: 9776
Points: 3858

Quote:Would I be right in

Quote:

Would I be right in thinking trial and error is the best way to flatten these bugs?

No. While there is definitely madness in their methods, don't let it affect you. hasLayout is methodical, and learning what it's doing will lead to a systematic extermination of the bugs. See PIE for a description of all the more egregious IE bugs. IE7 has fixed most of them, and even used the site as a check list for what to fix.

cheers,

gary

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 6 years 36 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Quote:and even used the site

Quote:

and even used the site as a check list for what to fix.

It amazed me that they needed to ask Shock numpty company or where they simply boxing clever and playing the politic card, "look were so concerned that we have gone to the spiritual home for all things CSS Standard and asked the oracles for guidance"

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me