Fonts displaying larger in IE

Hiya,

I’ve always been aware that different browsers will display the a font at a different size. But I’ve just been shocked to see just how different this seems to be. This relatively simple page displays so differently in IE than Chrome and Firefox, that the layout at the bottom of the page is also totally different. Even on such a short page.

http://www.andthecat.co.uk/gill/sitepoint/2.html

Admittedly this is my first attempt using ems rather than px to set the font size, so it could be that I’m doing something silly.

If not, is there a work-around, or a clever piece of code which can make IE display the text to look more like Chrome and Firefox? Or do we just have to accept that a design that works well in Chrome and Firefox will look less great in IE?

Thanks for your help and support!

13adger

Having continued to look at this, it looks as if Chrome and Firefox are ignoring my line-height command, which seems to be the main culprit. I’ve never had that problem before. Is that a result of using ems for my font-size? I’ve fiddled with the line-height settings and tried using ems and % as well as value, but nothing seems to be working.

Hi Tessie, I did look at your thread but I’m afraid it went way over my head with regards to how this would help me.
B

I think IE gives any designer/developer issues. It is really trial and error trying to fix it, in most cases, I always use PX to set font though.

Me too Tree. But these days I’m getting more and more people wanting their sites to be accessible (to some extent at least) so I’m being told that ems are the way to go. To be honest, I’m not convinced that is the cause of this problem - unless someone on here tells me otherwise?
B

Well, first off one of the reasons to USE em’s is so that the fonts automatically enlarge to the size the user expects them to be – Are you running 120dpi/large fonts on Windows where you are testing? Gecko and Webkit based browsers ignore that by default – IE does not.

Looking at your code so far, it’s a bit hard to decipher with the “throwing all the properties on one line”… but I’m seeing a number of things re-declared for no reason, values like “left” on elements that aren’t set up to even RECEIVE positioning, and font-size declarations all over the place without matching line-heights. A good mantra to get into is if you change the font-size, redeclare the line-height, at which point you’ve blown enough characters one typically might as well use the full condensed font property.

You’re also declaring it ‘all over the place’ instead of just ONCE on body… Set your most common size on BODY, (like what your content text is going to be) and then adjust off of that.

The markup has issues too – like some of the DIV serving no real purpose, your comment placements “after” closing tags running the risk of ending up between floats – which can trip some REALLY annoying rendering bugs in legacy IE and some versions of FF… and have the typical oddball redundancies like saying “end” – </div> is the end of something? REALLY? Never would have guessed… That’s a joke

You could probably also simplify your CSS greatly by using a ‘reset’ to target the paddings and margins that have inconsistent default values across browsers… It’s also worth mentioning that DIV start out at ‘auto’ width, so saying width:100% on them is typically a waste of time.

Though also, if this is a new page, why did you write it “in transition” from 1997 to 1998? That’s what a “transitional” doctype means – probably not your fault, you’re probably just learning from a decade out of date source (like most books published in the past three years). that’s a joke too… almost

If I was trying to code the same thing, I’d open a LOT of it up more dynamic. Probably using a semi-fluid width declaration since fixed width blows chunks from an accessibility standpoint.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<title>
	Layout Demo
</title>

</head><body>

<div id="pageWrapper">

	<div id="pageHeader">

		<h1>
			Site title
			<span><!-- image replacement sandbag for logo --></span>
		</h1>
		
		<ul>
			<li><a href="#">Link 1</a></li>
			<li><a href="#">Link 2</a></li>
			<li><a href="#">Link 3</a></li>
			<li><a href="#">Link 4</a></li>
			<li><a href="#">Link 5</a></li>
		</ul>
		
	<!-- #pageHeader --></div>
	
	<div id="sideBar">
		<ul>
			<li><a href="#">Link 1</a></li>
			<li><a href="#">Link 2</a></li>
			<li><a href="#">Link 3</a></li>
			<li><a href="#">Link 4</a></li>
			<li><a href="#">Link 5</a></li>
		</ul>
	<!-- #sideBar --></div>
	
	<div id="content">

		<div class="trailingPlate">
			<img src="images/dummy.png" alt="Image Here" />
			<img src="images/dummy.png" alt="Image Here" />
		<!-- .trailingPlate --></div>
	
		<h2>Subject Title</h1>
		<p>
			Consectetur adipiscing elit. Aliquam eu sem quis lacus lobortis malesuada. In posuere libero non nunc gravida in dictum nibh auctor. Nunc nunc libero, iaculis vel molestie sed, facilisis a tortor. Donec arcu tellu
		</p><p>
			Is, placerat id suscipit sed, mattis eu diam. Duis nec eros at est dictum ultrices. Cras non metus vel lectus tempus euismod. Mauris tincidunt ante vel arcu tincidunt nec lacinia augue condimentum. Nam libero justo, convallis quis lobortis non, posuere id tellus.
		</p><p>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec dapibus nisl et elit posuere facilisis. Curabitur aliquet dictum lectus ultricies ornare. Nulla at dui sit amet ante malesuada condimentum eget ut erat. Sed commodo tellus iaculis nibh euismod tempor. Mauris vehicula, massa et consequat fermentum, turpis urna ornare urna, non feugiat mauris purus sit amet purus.
		</p><p>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec dapibus nisl et elit posuere facilisis. Curabitur aliquet dictum lectus ultricies ornare. Nulla at dui sit amet ante malesuada condimentum eget ut erat. Sed commodo tellus iaculis nibh euismod tempor. Mauris vehicula, massa et consequat fermentum, turpis urna ornare urna, non feugiat mauris purus sit amet purus.
		</p>

	<!-- #content --></div>
	
	<div id="footer">
		<ul>
			<li><a href="#">Link 1</a></li>
			<li><a href="#">Link 2</a></li>
			<li><a href="#">Link 3</a></li>
			<li><a href="#">Link 4</a></li>
			<li><a href="#">Link 5</a></li>
		</ul>
	<!-- #footer --></div>

<!-- #pageWrapper --></div>

</body></html>

With this for the screen.css file:


/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

body {
	padding:10px 0;
	text-align:center; /* center #pageWrapper IE 5.x */
	font:normal 85%/150% arial,helvetica,sans-serif;
	background:#333;
}

#pageWrapper {
	width:95%;
	min-width:752px;
	max-width:68em;
	margin:0 auto;
	text-align:left;
	background:#699;
}

#pageHeader {
	padding:10px;
	overflow:hidden; /* wrap floats */
	zoom:1; /* trip haslayout, wrap floats legacy IE */
	background:#6CC;
}

h1 {
	position:relative;
	width:300px;
	padding:34px 0;
	text-indent:10px; /* since padding would be added to width, cheat! */
	font:normal 28px/32px arial,helvetica,sans-serif;
	color:#FFF;
	background:#66C;
}

h1 span {
	position:absolute;
	top:0;
	left:0;
	width:300px;
	height:100px;
	/* put logo/title image here as background-image! */
}

#pageHeader ul {
	list-style:none;
	margin:-1.5em 0 0 310px;
}

#pageHeader li {
	display:inline;
}

#pageHeader li a {
	margin-left:1em;
	text-decoration:none;
	color:#666;
}

#pageHeader li a:active,
#pageHeader li a:focus,
#pageHeader li a:hover {
	color:#FFF;
}

#sideBar {
	float:left;
	width:8em;
	padding:10px 0;
}

#sideBar ul {
	list-style:none;
	margin:0 10px;
	font:normal 120%/150% arial,helvetica,sans-serif;
}

#sideBar li a {
	display:block;
	padding:5px 10px;
	text-decoration:none;
	color:#FFF;
}

#sideBar li a:active,
#sideBar li a:focus,
#sideBar li a:hover {
	color:#FC0;
	background:#573;
}

#content {
	overflow:hidden; /* make not indent past float */
	zoom:1; /* trip haslayout, make legacy IE not indent past float */
	padding:1em 1em 0;
	background:#FFF;
}

#content h2 {
	margin-bottom:0.5em;
	font:bold 150%/120% arial,helvetica,sans-serif;
	color:#666;
}

#content p {
	padding-bottom:1em;
}

.trailingPlate {
	float:right;
	margin:0 0 10px 10px;
}

.trailingPlate img {
	display:block;
	width:250px;
	height:150px;
	margin-bottom:10px;
	color:#FFF;
	background:#609;
}

#footer {
	padding:10px;
	background:#36C;
}

#footer ul {
	list-style:none;
	margin-left:8em; /* == sidebar width */
}

#footer li {
	display:inline;
}

#footer li a {
	margin-right:1em;
	text-decoration:none;
	color:#FFF;
}

#footer li a:active,
#footer li a:focus,
#footer li a:hover {
	color:#306;
}

Though that may or may not address your font-sizing issue and/or line-height issues. As a rule of thumb line-height can’t be trusted to remain properly scaled when you change the font-size in all browsers. It’s why I take the time to use the entire condensed font property to state it.

In case you’ve not seen it before:
font:normal 85%/150% arial,helvetica,sans-serif;

first word or two is style and weight (like normal, bold or italic), do NOT assume omitting it will give you normal. The next value is the font-size, I like 85% on body since that rounds off to 14px on 96dpi/small font computers/browsers and 17px on large font/120dpi browsers – at least when using sans-serif fonts like Arial. (serif fonts typically need larger size due to the higher detail needed for their glyphs). That 150% is the line-height I use (I like 'em big) and then the font family stack.

Notice I avoid declaring a lot of heights on the page, and instead let flow do the work for me wherever possible. This is the key to using EM’s. As a rule of thumb unless you’ve got some form of image interaction going on, declaring fixed heights on ANYTHING is a bad idea… You’ll notice I use no floats in the heading either – neat trick called ‘negative margins’ – I know generally how tall my UL is going to be, so I just use a negative top margin to “ride it up” over the H1’s natural position. This retains ‘flow’ and allows that menu to be bottom positioned while still allowing it’s text to scale upwards since again, it’s all declared in EM.

The H1 (site title/logo, of which ALL OTHER SECTIONS STARTED USING HEADING TAGS ARE SUBSECTIONS) got PX fonts and line-height so that it will stay fixed to the size of the image replacement. I put in image replacement code, so you can just add the image as a background there, overlapping/erasing the text. This is important so your top-most heading has meaningful text in it and is actually useful to people who turn images off.

The width code:
width:95%;
min-width:752px;
max-width:68em;

Should be fairly easy to follow – desired width, minimum allowed width, maximum allowed width. The percentage overall width gives a nice bit of the background showing at the sides when bigger than the min-width, the px min-width prevents the layout from being so small as to be ‘broken’ (at which point CSS3 media queries should be used to ‘adjust’ the layout), and the em max-width prevents lines from getting too long, while also adjusting to the font-size the user agent (browser) has set.

I imagine you’ll have lots of other questions, feel free to fire away, I’ll answer when I can.

… and don’t take my criticism above too hard – if this is your first time out with EM’s you’re head and shoulders over many developers who’ve been doing this for years. At least you are TRYING for accessibility, let’s see if we can get you over the conceptual hurdle on how to do it. There’s a lot of outdated learning materials, misconceptions, misunderstandings of the specifications and just plain bad advice out there – let’s get you past all that and into the good stuff.

Whoa. Thanks for that. A lot to take in there! Will work through it slowly, and yes, I’m pretty sure there will be questions!

Thanks for your help, and talk soon

Hi again. Well there is so much good stuff in your response Death I’m going to work through it in stages, making sure I understand it all. So here’s Part 1

“Are you running 120dpi/large fonts on Windows where you are testing? Gecko and Webkit based browsers ignore that by default – IE does not.”

I’m afraid I haven’t a clue - as you will have already picked up I’m not remotely technical, and I don’t even understand the question! (Good start, huh?) Let me know how I can find out, and I’ll tell you the answer.

"A good mantra to get into is if you change the font-size, redeclare the line-height, at which point you’ve blown enough characters one typically might as well use the full condensed font property. You’re also declaring it ‘all over the place’ instead of just ONCE on body… Set your most common size on BODY, (like what your content text is going to be) and then adjust off of that. "

Ok, that all makes perfect sense. I’ll be doing that from now on. So just to confirm, in Body I set my font to a percentage of ‘normal’ which is the size that the browser would display the font at, if it is not told to do so otherwise, is that right? And at the same time I set the line-height, to which the same rules apply?

"your comment placements “after” closing tags running the risk of ending up between floats – which can trip some REALLY annoying rendering bugs in legacy IE and some versions of FF… "

Ok, can I clarify that? Are you saying I should not put comments after a closing div tag but I can put them before it? Point taken about the ‘end’ … blush!

"You could probably also simplify your CSS greatly by using a ‘reset’ to target the paddings and margins that have inconsistent default values across browsers… "

Good point. Will start all CSS with that in future.

“It’s also worth mentioning that DIV start out at ‘auto’ width, so saying width:100% on them is typically a waste of time.”

Yup, again, I see the logic now. Will remember that.

“Though also, if this is a new page, why did you write it “in transition” from 1997 to 1998? That’s what a “transitional” doctype means – probably not your fault, you’re probably just learning from a decade out of date source”

Yeah, this is all written in by Dreamweaver. I don’t even know what it means. I’m using CS5.5 so am surprised if it is giving me outdated code. Am I doing something wrong in my initial page set-up?

Ok, next I’m going to copy your code into Dreamweaver and play with it and make sure I understand what all the elements are doing. No doubt there will be more questions when I’m doing that, but I thought this would give you enough to get your teeth into!

Thanks again for your patience.

Wow, that’s amazing! Your version has made a HUGE improvement in the consistency, thanks so much!

Now to carry on reading through it, and making sense of it.

It hinges on what version of windows you are running, though windows has supported different “system metrics” – basically different “default” font sizes since version 3.0 way way back in 1990 – though at the time the larger size was called “8514 fonts” as it was designed for the IBM 8514 graphics adapter. For several windows versions it was called “small fonts” and “large fonts” – which related to the OS “thinking” the screen was 96 or 120dpi (which with all the different size and resolution displays was bull)… It’s an option that in older versions of windows could be set from “display properties” -> Advanced, and today can be set in Win7 under the default starting page for “display” in the control panel… Though in win7 it’s called “Small”, “medium” and “large” allowing for 100% (96dpi), 120% (120 dpi) or 150% (144 dpi) – and you can also set custom sizes in most windows versions.

It’s actually WHY we’re supposed to use EM’s for fonts, as any browser that actually cares about accessibility (Opera and IE) will pick up on that setting automatically… while other browsers generally let you set the default size in the browser.

Quite some time ago I threw together a little demo to show the difference between large/120dpi and small/96dpi and how each browser handles the setting.
http://battletech.hopto.org/html_tutorials/fontCompare/template.html

Which is why you SHOULD use %/em’s on content elements, but also why you should NOT ever plan on fonts rendering the same size cross browser/cross OS.

Pretty much. Using the ‘long form’ condensed property may seem like excess code, but the explicit declaration every time avoids a mountain of headaches.

There are rendering bugs in IE8 and earlier (unable to recreate them in IE9 thankfully) AND some versions of firefox where if you put a comment between floats, between certain types of positioned elements, or between a handful of other testcases the COMMENT trips rendering bugs… In IE one of the worst of these bugs is called the “Double render” bug – where quite literally IE will render the content of one of those tags TWICE. In both IE and FF it can trip the “disappearing content” bug - where things like backgrounds, borders and colors on the element render normally, but none of the ‘textnodes’ inside it actually render on the page.

While it’s a handful of specific cases this happens, simply reversing the ending comment and tag order dodges this bug entirely. It’s why you’ll generally see:

<!-- #footer –></div>

As my commenting style… as I do find having a comment to say what is being closed handy, I also like avoiding the possibility of having one of the “WHAT IS GOING ON?!?” moments bugs like double-render can cause… because, well… IT’S REALLY STUPID that comments can trip rendering bugs. Kind of like how for a short while Gecko was treating SCRIPT tags as block-level containers – it’s a real head scratcher trying to debug as it’s something which SHOULDN’T by definition effect rendering.

There’s a very good article on the IBM Linux developers site about using meaningful names and good commenting practices. While it’s meant for C programmers, I think anyone writing code can benefit from it.
http://www.ibm.com/developerworks/linux/library/l-clear-code/

I’m particularly fond of the “Oh? We’re done? Thanks for letting me know. That big right bracket and the infinite expanse of empty space beyond really didn’t tip me off to that.” part.

RE:resets
A word of warning about ‘resets’ – there are shorter ones like the ‘universal reset’ of * html { margin:0; padding:0; } – but that can cause problems with form elements and sometimes other tags since it basically nukes everything. On the flip side of the coin we have massively bloated resets like Eric Meyer’s “Reset Reloaded” which to be frank, isn’t a reset, it’s a framework. The point of a reset is to set values that have inconsistent defaults across browsers the same – NOT as a template for building the entire layout. When you have 1 to 2k of CSS before you even start applying your own style, you’re probably doing it all wrong… (just part of why CSS frameworks like grid960 or YUI are total rubbish).

The reset I use:


/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

Just nabs the elements that ‘need’ to be nabbed, leaving everything else alone… at less than a quarter K the overhead it adds is typically a fraction what you save by not having to declare margins and padding on every one of those elements every time you use one… and that’s a good thing.

Oh lord people… there it is, the flame-bait :smiley:

It’s generally well known 'round these parts that I have a very, VERY low opinion of Dreamweaver. As a dearly departed friend of mine used to say, “The only thing you can learn from Dreamweaver is how NOT to build a website” – which is very true.

I’m not surprised at all – that steaming pile of manure has been making outdated code since it was introduced by Macromedia in 1997. The ONLY way to get quality code out of Dreamweaver is to NOT use it’s templating system, NOT use any of their example code, NOT use anything that makes code for you, NOT use the WYSIWYG part of the editor, and NOT use any of it’s tools/aids…

Even the Dreamweaver apolists will basically tell you “You can make good sites if all you use is code view” – at which point congratulations you have spent a small fortune on a overglorified version of Notepad with a couple cute utilities tacked on for bloat.

At which point, why use it? Do yourself a favor, burn the manuals, make microwave art out of the DVD, and forget that it even EXISTS. Go get a simple flat text editor and test in the actual browsers… There are plenty of really good editors out there for FREE, that let you get right down into the code instead of letting some half-assed tool lead you down the garden path. As that same friend of mine used to say “The only thing about Dreamweaver that qualifies as professional grade tools are the people promoting it’s use.”

I suggest (if you are on windows) using Notepad2
http://www.flos-freeware.ch/notepad2.html

But that’s because it lets you turn off all the annoying garbage like code completion, tabs instead of separate windows, or that illegible acid trip known as color syntax highlighting.

There are plenty of other perfectly good editors out there – EditPlus, NotePad++, Crimson Editor, gEdit (GNOME/*nix), Text Wrangler (Mac)

Basically beware of anything that tries to use automated tools that tell you how to code – even the simple ones like Bluefish or Coffee Cup will start nagging you with pointless warnings and bad advice. Take the time to learn to do it for yourself, and you’ll laugh at how pathetic most ‘programmers aids’ really are.

A final word of warning, more than once simply loading my code into DW and hitting ‘save’ has broken stuff I’ve written thanks to their automatically trying to ‘fix’ things that aren’t wrong or mess with the formatting… which is again why I suggest you pitch that bloated overpriced trash and get just a plain text editor.

Brilliant, thanks for all that. Some of it is going to take me a little bit of time and experimentation to get my head round, so I’ll come back that those bits later. But in the meantime:

I totally get your point about Dreamweaver, and I’m not going to go near that debateas I’m sure it’s been covered endlessly on here!

Ok, so working through slowly, can you explain
overflow:hidden; /* wrap floats /
zoom:1; /
trip haslayout, wrap floats legacy IE /
and also
Content {
overflow:hidden; /
make not indent past float /
zoom:1; /
trip haslayout, make legacy IE not indent past float */
I presume they are similar?

Moving on to the title/h1 tag, if I only have one H1 tag, as the site title, does this affect the SEO? Are H2 tags given SEO priority too?
Also, normally isn’t an background image is displayed BELOW the text? This one is on top of (or instead of) it. I understand the reasoning for doing this, and for setting the h1 in px, but the whole h1 and h1 span system you’re using iss befuddling me a bit.

That’s all for now. There will be more! (If you can cope!) when life gives me time to get back to it.

Thanks so much for your patience.

The first of those is ‘float wrapping’ – a floated div inside a container does NOT get counted as part of the height of that container unless you either ‘clear’ the float, or trip a rendering state that wraps the float.

the latter of those deals with indent after a float. If you float some content left before a paragraph taller than it, the paragraph will indent. If you trip a wrapping behavior on that sibling element, it doesn’t indent.

One sec, lemme toss together a simple example of that. It’s easier to understand if you can see it in action.

http://www.cutcodedown.com/for_others/13adger/demo.html

The first two green boxes have a tall red float inside them with short content. The first green box lacks float clearing (overflow and haslayout), the latter has it.

The next two green boxes both have clearing on them, but they both have short (line-height tall) red floats in them. The first one is a normal paragraph, the second one has those same two properties (overflow and haslayout) on them.

Which shows the four major behaviors you need to be aware of with floats and clearing. There are other ways of making clearing, but as a rule of thumb they’re either pointless bloat (the so called ‘clearfix’ nonsense) or not as reliable… the only other one I use from time to time is that float… wrap floats. So you can “float:left; width:100%;” to also wrap floats – but that can cause other difficulties in your layout (like different margin collapse across browsers).

If you are choosing your tags for SEO reasons, you’re probably choosing the wrong tags in the wrong manner – and buying into some of the SEO “snake oil” instead of building your document with a logical structure.

Generally speaking a heading tag indicates the start of a section or subsection of a page – a lower order (higher numbered) heading meaning a subsection of the heading preceding it. The ‘root’ heading (h1) by definition is the top-most heading of which everything else on the page is a subsection… this is why the SEO bull of stuffing the ‘page title’ instead of the site title into it makes little to no sense the moment you have other headings on the page – REGARDLESS of their presentation.

Think of a newspaper and it’s headlines AND it’s category headings. While “MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE” might be the massive headline on the page, does that make “K-6 gets new building”, “Distressed disabled woman assaults postmaster” or “Section Index” subsections of that massive headline? Of course not – they’re ALL H2, regardless of their PRESENTATION. The H1 is the name of the paper, which occurs on EVERY page at the top, even if on the sub-pages it’s smaller. Its’ the first heading that ties all the pages together so you know what ‘paper’ they are part of…

It’s also why skipping heading levels (for example H4 with no H3 before it) is nonsensical/gibberish. Headings are there to divide your content into a logical tree-like structure. You have the site (h1), the various topics/sections (h2’s), subsections of those H2’s (h3) and so forth. Likewise if you have a change in topic/subject or major section of the page that doesn’t warrant a heading, that’s what a HR (horizontal rule) is there to indicate. (though you have to dig back into HTML 3.2 and 2 to find that description of it).

Its insanely simple – which is why it seems nobody actually bothers following or understanding the purpose of heading tags.

The technique is called Gilder-levin image replacement, and is best used in cases where you are using an image as text or a logo so that there’s REAL text present for things that don’t show the image. (and no, ALT text or TITLE aren’t REAL text in HTML). The text is there for non-image user agents (search engines, screen readers, people browsing with CSS disabled, people browsing with images disabled) while the image is there for our screen.css images on users. You just place your logo image on the span as it’s background, then position it over the text to hide it.

It goes back to one of the core concepts of … what IMHO is modern coding techniques – separation of presentation from content. Images like borders, backgrounds and even some logos are not content, so they don’t belong in IMG tags. HTML is for content and saying what that content IS – NOT what it looks like. We got away from that during the browser wars and a LOT of ‘experts’ out there still haven’t pulled their heads out of 1997’s backside on that, but it’s the entire point of HTML… To markup the content in an APPEARANCE INDEPENDENT manner. It’s why even presentational classes like “left” or “smallFont” or “widthOneQuarter” defeat the POINT of HTML… and CSS. HTML is for saying what things are, CSS is for saying what they look like.

… and what they look like is NOT going to be uniform across targets – semantic markup gets you CSS off and lets ‘self targeting’ user agents present the content in the best manner for the device… CSS media targets let you target specific devices for customized appearance. If all you think about is what it’s going to look like on a 1024 or wider desktop display, you’re missing the point of even using HTML/CSS to build a site in the first place! (hence why fixed width layouts are shortsighted rubbish)

As one of my old signatures on these forums said, “If you choose your tags based on the default appearance you’re probably choosing the wrong tags.”

Amazing! I’ve been spending almost 18 months wondering why my divs fall out of my wrappers seemingly unpredictably! And never found anyone to explain it to me. I’m going to go away and play with all of those - as well as the rest of the ‘homework’ you’ve given me. It may be a while, but I’ll be back. You’ve no idea how great it is to suddenly understand all sorts of things that I’ve been vaguely aware of, but never been able to find any articles or posts written in a language that I understand. I SO appreciate your help, and can’t believe how much I’ve learnt over the last few days. Hopefully it will result in better, more accessible sites, not just from me but from many others who I hope are reading and learning from this.
B

Right. I’ve worked my way through that, played with the demo, and recreated the site slowly, making sure I understood everything that you’ve done. And I think I’ve learnt more from this post than I have in the last 12 months from books and tutorials. So I really appreciate your help, and hopefully this thread will have other readers who will have been doing the same. I do have one final section that is puzzling me? Which is the images, or what you call ‘trailingPlate’ - not an expression I’ve heard before.

The code I used myself seemed to be simple, and seemed to be working, so can you talk me through your code, explain why you’ve done it this way, and what the benefits are? To save you looking it up, I simply used
<div class=“flt_rt” id=“image_space”>IMAGE HERE</div>
<div class=“flt_rt” id=“image_space”>IMAGE HERE</div>
and
.flt_rt { float: right; clear: right; margin-top: 10px; margin-right: 0px; margin-bottom: 10px; margin-left: 30px; }

I was also surprised to see
.trailingPlate img {
display:block;
This seems to have stacked the images, but when I tried playing with display:block on floated divs, it didn’t seem to have the same affect. I’ve only seen display:block used in li’s before.

Cheers
Badger

You had two images, you wanted them floated together, hence the single container. It’s the DIV.trailingplate that’s floated. The display:block on the images makes certain that they are stacked one atop the other INSIDE the div, and prevents certain oddball alignment issues that IMG tags can have.

As to ‘trailingPlate’ – that’s a old print term, and while the web is not print, some of the names are often handy. A “plate” is a image or other content element, from the days of print where a large plate was inserted into the press… I use three different types of plates – a leading plate, which ‘leads’ into the content that follows (float:left), a trialingPlate, which is supplemental to the text that follows (float:right), and a just plain plate, which is centered without text around it. Mind you, that left/right/whatever is strictly a suggestion and not actual presentation as I may end up using all sorts of different alignments or behaviors depending on the capabilities of the target… again, good web development means thinking about more than just “1024 or wider desktop screens”.

In terms of the relationship of display:block to floats – floats are INHERENTLY display:block, and nothing you set for display will change that! It’s display:block on NON-floated inline-level (display:inline or inline-block by default) elements – like B, IMG, SPAN, etc.

Basically, look closely:


<div class="trailingPlate">
	<img src="images/dummy.png" alt="Image Here" />
	<img src="images/dummy.png" alt="Image Here" />
<!-- .trailingPlate --></div>

the DIV.trailingplate is wrapping both IMG tags.


.trailingPlate {
	float:right;
	margin:0 0 10px 10px;
}

The DIV is floated with margins…


.trailingPlate img {
	display:block;
	width:250px;
	height:150px;
	margin-bottom:10px;
	color:#FFF;
	background:#609;
}

The images ARE NOT floated, they are simply placing themselves as appropriate inside the floated DIV.

The other two types of ‘plate’ I declare typically (but not always) get this for screen.css:


.leadingPlate {
	float:left;
	margin:0 10px 10px 0;
}

.plate {
	display:block; /* in case we put it on IMG instead of a wrapper */
	margin:0 auto 10px;
}

Again though, I’m saying what they are in the markup (a type of plate), NOT what they look like… many people would use classes like ‘left’, ‘right’ or ‘centered’ – but say… single column handheld.css is that going to make sense when I’m NOT floating them? How about print where I might want to omit plates entirely to save people on their ink? That’s part of the key to good naming practices.

Yeah, that all makes sense now.

Thanks so much, a fab tutorial, and loads for me to think about.

Hopefully my sites will all be much more accessible, and much improved from here on in.

B