IE6 doesn't always fully redraw DIV container, contents, ULs

Sorry, this is probably a newbie problem but after everything looked good in FF1.5, viewing pages in IE6 sucks!

Basic description: When I use a div to hide/show contents, I see 3 different problems.

1) contents aren't always redrawn at the bottom, especially if you scroll quickly. Like IE gave up and said "It's too much trouble." Though it is redrawn when I click the button which toggles the display:none setting. I also see this with ULs inside divs. Sometimes it even spreads above hidden divs! The content/box container also skips drawing some content when I bring the browser window back to the front after having a window in front of it.

2) the containing div (originally hidden) is rarely drawn at the bottom. It can end up shorter than the content, but usually content and container come up short the same amount. For example, the last 50 pixels never get drawn.

3) using div/span combo to replace the ULs, FF doesn't pay attention to my text-indent: -15px in the span.

User solution: If you scroll relatively slowly, usually everything draws fine

Bad solution: The only way it always works in IE6 is if I specify a pixel height for the DIVs. Problem is both that I don't want to limit the content, and that FF and IE are rendering differently to give 2 very different heights.

The content, well, is inside several other nested DIVs. I tried a couple different things like putting the content in tables (still needs to contain divs and spans for formatting) or clear:both/overflow:hidden with no changes. I did try:

* html ul { position: relative }

with no change, and:

ul,{display:inline;zoom:1;vertical-align:top;}

which just made the ULs look pretty bad in IE. Also diagnostically I tried giving the divs various color backgrounds but anything not drawn just has the color of the container's container. While I do know from that that nothing else is expanding, it gets me no closer to a solution.

So... where's the secret IE6 stash I haven't found yet? Alternatively, does IE6 have inherent problems when a page is too long? Or does anyone here have direct advice or questions which might help me? Or am I just scrolling too fast? 8)

Thanks!

 

CODE? URL?

Testing against 1.5? How's 2.x working on it? Opera? Safari? Konqueror? IE7?

The problem could be anything from setting inline on a UL (which rarely works right in any browser) to improper placement of comments (which can completely flake IE out) - and the full gamut of oddities like haslayout in the middle.

A couple lines of CSS snippets are gibberish without the full code.

 

The 'secret' IE6 stash ?

rather than a height, set zoom: 1; on the affected element, if that works too, then hasLayout it is

 

deathshadow: Of course, you're correct - so I'm trying to get the Rails app working on Dreamhost... and hit a snag. I'll reply again when it's actually functioning.

Suzy: Well, you know, when I don't know about it, "It's new to me!" Actually it is more like there are 449 million CSS pages and more than 5 million CSS+IE pages, and either I'm lost on some keywords or my Google-fu isn't up to par because I wasn't finding useful information on my own.

Thank you for that link, though, and for the suggestion! I tried applying zoom:1; to div,ul, and it has helped - it looks like the content is in fact redrawing itself. But the unpretty part is my ULs lost their bullets and hidden divs seem to have added a lot more blank space to the page

I'd be happy to hear any other suggestions, and I'll try different creative commenting to make it valid CSS while I wait for some Dreamhost tech support.

 

Don't just read Suzy's link alone-- read it again and look a little further. Consider Haslayout (and a few other quirks) as the cause for a whole slew of seemingly unrelated problems... whitespace problems and various bugs seem to occur and vanish without reason or warning... and often it's because something might normally not have Haslayout yet get it (changes it to "true") when something happens, like something gets hovered, something gets added or rendered (dynamically), something changes (like display or visibility)...
Teh Googles are the resource for "Haslayout" and there's a lot written about it out there, so if that one link doesn't have everything then the other sites will pick up the slack.

Hidden stuff is taking up space anyway... if more space is added when something else gets layout... we'd need code. Is this document in Quirks mode? Is there a universal CSS reset of margins and paddings? etc.

Also, I too develop in FF1.5 and while it's nice, you need FF2 for the same testing. FF1.5 looks different and has some spacing differences (or at least I see them, though I have 1.5 on a Unix laptop with ginormous screen and FF2 on a Windows machine with 1024 resolution).

 

No, no quirks mode. Yet. Yes, universal reset of padding and margins (then set UL margin-left to 25px), actually a little too tight in one place on FF1.5, but waaaaaaaay too much space on IE6 (only vertical). The display:none's are taking up space - I haven't removed all space between their tags, but I remember having to do that in the past.

Only tried IE6,FF1.5@XPSP2 so far - it is just a tiny personal site concept so far, but I wanted things to at least display for most users. Well, I really want them to be pretty, but it looks like that's a pretty tall mountain to climb.

Well I'm pretty embarrassed about it now (at least my claim to know CSS...), but I did throw up a static copy of the most troublesome page at:

http://test.chris.dagnon.net/resume.html

Only the span-buttons are working to show/hide the divs. But maybe its time I got some more machines so I can test across more browsers.

Thanks for any further suggestions!

 

OUCH, classitus, divitus, presentational classes (defeating the entire POINT of CSS), use of &nbsp for indents, and several dozen unneeded containers... As evidenced by the 18 validation errors and an ungodly 105k of HTML for 32k of content...

There is NO reason for that page to be more than 50k of markup - and really, once you break 8k of content that should be separate pages, not 'stupid javascript tricks'.

My advice - chuck the whole thing for clean semantic minimalist markup, using classnames that say what something is, NOT how it appears, marking your headers as headers and lists as lists (right now you have lists as headers, improper header flow, etc, etc).

Time spent now reducing the code to something sane will save your sanity when it comes time to maintain the page later.... because right now you have MINIMUM 55k of code in there that isn't doing ANYTHING for you.

 

Considering some of your posts, I thought you might say that 8) But I do like your idea of dropping half the size if it is doing nothing useful and I'm going to take some time this week to pursue that.

I one basic difference is that I haven't quite adopted the practice of specifying by HTML structure in CSS markup. I've had too many times where I had to tweak something and it's just more reliable for me on large projects to include those changes on the elements themselves instead of in a CSS file that could change the look-and-feel of other parts of the website. (No, no project-level CSS management, or even guidelines...) I would certainly call my practice tactical instead of strategic (holistic?), but, well, how many "x y z {}'s does it take to screw in a lightbulb?" and if you have enough for one page, how does it compare time or bytes versus including format information in the HTML page itself? Unfortunately I haven't practiced unifying formatting in those kinds of ways.

On the other hand, if you've got a solution to divitus, I'd be happy to hear it. In years past we had to make too many sites all in tables (it looks like the W3C site is full of them) to reliably display across browsers (IE5 and 5.5 included, let alone IE on Mac over AOL), and while divs are the only thing I've had work for me so far consistently across primary browsers, I'd certainly consider alternatives. However building a page around stylized LIs seems a bit... extreme. Definitely something that would take time for me to get used to using. But hey, it is time for big changes for me.

I've been making revisions throughout Sunday, though primarily only to improve content and layout and to get the display to look acceptable on IE6 as well as FF1.5. So yes, some validation is in my near future too. But you'd have to give some reasoning for me to nix the javascript divs - I'm not that fond of AJAX (and this was easier), but I wanted the information available all on one page and this was the first obvious metaphor. It met my goals to give a brief clean page, and let the user get more information if they want it without moving them away, and in slightly different views without requiring form inputs. But it definitely needs some close buttons.

To your last point, well it's not that hard for me to maintain the page as-is, but that's because I'm only maintaining the code that generates the page instead of the page you see as a static HTML file. But like I said, I do value efficiency and quality so I'll be working to add both (by taking away) in the days to come, and otherwise improving my CSS-fu.

Thanks for the constructive criticism!

 

Holy Jebebus! I saw the page (running NoScript, so there might be more that I'm just not seeing cause I block teh scriptz) and thought, oh, what a nice little page. But the html... whooooa.

Here's what you do. Grab a piece of paper and write out all the content for that page (or type it, whatever). Just the text-- how you would want this printed out. Then take that paper and draw your boxes around it, and think about the fewest number of boxes to do the job. Give the boxes names. Keep it simple!

For styling, think of the main page, or the biggest (most content) page. That way you can get 99% of your styles thought out properly and only need tweaks for a page or two or three. Small ones.
For the other stylsheets, you can set them as rel="alternative" and many browsers let people choose the stylesheet of their choice from View or somewhere. IE of course needs some Javascript help but that's helping the retarded which needs to be done because we're compassionate beings.

I could rewrite the HMTL easily enough. What I would do for the extra stuff is either have users be able to click the boxes to go to another, more in-depth page, OR simply have the content below and have the buttons be in-page skippie links. People can get the overview but skimming the top like now, and can click to skip to some particular area that's more interesting. I don't have JS. Even if this is a personal project, always think of Javascript as taking something that already works and making it prettier or fancier or easier (forms) or whatever. Javascript does no work. It enhances something that already works. Which is why I think I hate it. it's getting used way too much on many many sites to do the work of HTML and CSS. A site that can't work without JS is to me a broken site that does not work period.

But that's a personal opinion : )

A neat and useful trick: if only one or two pages have the same elements but significantly different CSS because of the type of pages they are, you could give an id to the body element. I've used it for putting different settings on large, main-page elements.

 

-chuckle- Yes, sweet Jebus!

That sounds like a much more direct version of part of deathshadow's suggestion, so thanks for it definitely. I think I can follow up on that. The 'rel=' concept sounds good too. I'm going to keep coming back to this thread in order to follow up on so much new information!

I'm a little iffy about it though as, well, if the styling requires Javascript -that- seems broken to my old-school thinking. Then again, that was pre-FF2/IE7, so it could be totally unrealistic now. I don't know whether those commands are still run if the browser's JS is turned off, but I'm curious to find out.

I will agree that Javascript seems to be majorly overused currently, yes. I also agree that if it does exist, there should be alternatives for those without or disallowing Javascript (the PDF is partially a nod to that). Ideally there should also be other interactive(interactivity?) paradigms available - it should be designable without the JS. While this and other pages can be made in different ways, the simple fact is that most people - especially at work - don't read anything they don't have to unless it is on slashdot or digg. Giving collapsible content at headers seems like a good bet so users don't have to wait for page reloads, yet can skim information immediately and it is a 0.5 second decision as to whether something is useful to them rather than navigate+0.5+reverseNavigate time, and they can even pop it open again quickly later. And hugely long pages of sectioned information seem to promote glazing-over-of-the-eyes Syndrome. That is one reason I see wikis as ineffective - partially because few people want the job of organizing them.

Then again I've got several design/web design books to pour through this week, so maybe they'll have some bright ideas I haven't seen yet. I hope!

Thank you Stomme poes!

 

I've started a rewrite of just the HTML but because I've let my vi-fu skills seriously atrophy, it's slow going (cause I'm using gEdit which is NOT cool with this kind of page).

The crustier ones on this forum will surely have a better way of writing such a thing, but if I were to keep all the content (a lot of it repeats itself because of the set-up using a skim/overview version AND an in-depth version on the same page), I'd put most of that in definition lists. Where you have all these spans with the same classes over and over, I've been making them Dt's and dd's and they could all be styled in on fell swoop:
dt {
font-weight: bold;
clear: left;
float: left;
}
dd {
font-weight: normal;
}
And the company names having a class of "name" so youse can underline it and with the years being right before the list-- both so it can be floated right : ) and seems to head up the various lists anyway as it's chronological.

I dunno if I'll have it tomorrow as it's on the other machine, but I hope so.

 

Bleh, I dunno if I'll do the second half. The Skills by Category and Experience part, I'd likely also have that in a definition list, with a ul as a child of the dd and each of the li's floated left and given side padding (where you have all those nbsp's everywhere). Not sure if this would set off the whitespace bug in IE but then so we could use something funky to set it... maybe a height on the li's or something.
I've been removing the nbsp's in between items like "Javascript (extensive)" because it's not like anyone can't read it if it wraps seperately... and this was an XHTML page, and while that means it will stay html as a web page, if for some reason you ever turn it into an XML document (which I can image a resume doing), that's not a valid character entity. If you really want it, use the &# 160 method.

Here's what I have so far: http://stommepoes.nl/chrisresume.html
only half done, and with some ideas for the clicking to new pages or in-page links to other sections.

If you still want to keep the whole Javascript thing (which does work pretty cool when Javascript is enabled), then do it backwards-- the whole page should show by default, and those with Javascript would have the first function hiding everything you want hidden, and then showing on the clicks. That way, the whole long page is there (with skippie links of course) for those without JS and neat extra clickie-showie for those with. Now the JS is being an enhancement, not a crutch.

 

First, sorry it has been so long - holiday weekend and other personal matters...

Next, No, no need to do more, I definitely understand where you're coming from. And the class/style-less version is so much nicer to review! As I work to redesign the content (and the code) I'll see how close I can come to such a clean example.

And yes, show everything and then only with Javascript hide it since we know they have it enabled then. Though I may in that case have additional pages so it isn't so overwhelming... We'll see.

Thanks so much!

 

Well, thinking over it again, I'd have the main sections be links to different pages, but go ahead and use JS within those pages for show/hide because it's actually a common technique on websites (so long as it's enhancing an already-working site and not needed for the page to just work) and indeed does keep everything clean looking.

What you'll want to have in order to keep the HTML as clean as possible is study up on the cascading part of CSS. You can refer to things by mentioning the parents, and stick a class on something only because it's the only way to really differentiate that one thing. (If everyone supported first-child, last-child, nth-child we might never need classes, eh?)

I've had lines like this:

#container dl dd div.foo div dl dd {
not this exactly, that's some crazy nesting, but it can be done, and keeps the HTML clean.

If you've really used all those programming languages, remember that even though CSS isn't one, it holds by a lot of the same principles. A box with everything inside having the same class should always be a red flag.

 

Cascading is sometimes useful, but refer back to my earlier question: how many x y z{ }'s does it take to screw in a lightbulb? 8)

Anyways, I've worked on the revision a bunch and reduced the HTML size by 2/3rds and aggregated the CSS into a single slightly smaller file (with more cascading than I've ever used before) - however it no longer works on IE6 again... I'm about ready to try FrontPage I'm so frustrated with this, though if anyone has a better tool to suggest, I'm all ears.

test.chris.dagnon.net/resume.html

Thanks for all helpful notes!

 

I did get HTML validation to work, though haven't looked at CSS validation yet.

 

It takes as many x y z's as needed to screw in a lightbulb. Cascading is a fundamental tool. It's the wheel on our wagons.

Okay, I only started looking through your css. Some things are proprietary and that doesn't mean you can't use them, but they will not validate. zoom: 1 on your div, ul will not validate. It's IE only. The reason Suzy suggested it was to see if Haslayout WAS an issue. There are lots of Haslayout triggers besides zoom which both work and are CSS valid. But ultimately it's not a big deal either way. There are no CSS police. I've got some invalid IE stuff myself.

It is an error to state a property and then give no value. At the very least, you can do background: transparent ("none" is not valid for background). But...
That's Haslayout biting you in the ass, or it's the very-similar problem it has where it's reluctant to change display states on :hover, so you gave it a boost with a background colour. Here's a way to do it without changing appearance (add bold):

[b]a.staticLink:hover {
  visibility: visible;
}[/b]

a.staticLink:hover span {
  position: absolute;
  display: block; [b]<--- don't need this, pos: abs IS a block magically[/b]
/*  border: 1px solid red; */
  border: 2px solid #aaa;
  background: black;
  font-weight: bold;
  color: white;
  padding: 0px 2px 2px 2px;
  top: 1em;
  left: 2em;
}

Code (markup):

The visibility declaration must be by itself, and it's on the :hover. It causes no problems I'm aware of, and get's IE going. IE7 has a similar issue, but worse, because it recognises more pseudoclasses and considers Haslayout on :hover itself.

a.txt
{ text-decoration: none;
}
/*
a.txt:link, a.txt:visited, a.txt:active
{ text-decoration: none;
}

Code (markup):

Redundancy. Anything you set on "a" can be inherited by the specific children (visited, hover). If you say a {text-decoration: none;} then every "a" will hold that until you say otherwise (a:hover {text-decoration: underline;} will override "a").
I've found setting :link properties to be next to useless : )

If the a.txt:active etc do NOT inherit a {text-decoration: none;} then you've got it set up where a:active somewheres may be set to underline. Since a:active can override "a", then any other actives can also follow the first. So then you look at what's most numerous on your page, a:actives with underline or those without? Then you set the most popular one as a generality (a:active {whatever;}) and only have to declare the others as they come.

/* 20070519 09:20 Adding this since the 'pure CSS' version above lets other links' text bleed through! */
.tooltipLink
{ text-decoration: none;
color: black;
}

Usually something positioned absolutley stay above the page, but if it doesn't (most likely with IE) then a nice z-index usually takes care of it. Are you doing CSS popups/tooltips? I've done a bunch of them, they're fun, but I've run into problems usually with form controls in IE showing through. But otherwise, z-index: 1000; does the trick.

  width: 656px;         /* NEEDS TO BE: #content{ width + 2*padding + 2*border-width */
  margin: 0;
  margin-left: auto;    /* OTHERWISE this centering works incorrectly! */
  margin-right: auto;

Code (markup):

margin: 0 auto; should work and when something standard doesn't work, it means you have to look around, because something's not kosher.

div.splitHdr > div:first-child {
  float: left;
  width: 50%;
}
div.splitHdr > div:last-child {
  float: right;
  width: 50%;
  text-align: right;
}

Code (markup):

You probably know that > isn't recognised by IE6 nor are first/last/whatever child, (in fact I think only FF2 recognises last-child right now unless the Opera update has it) but did you also know IE was bad at math? It can add 50% and 50% on two floats and get 101%! Awesome, huh?

div.empContent > div.hdr > div:not(:first-child),
div.expContent > div.hdr > div:not(:first-child)
{
  float: left;
  width: 15%;
}

Code (markup):

Here you're starting into territory of unsupported CSS3. It may well be in the future, but seeing results today will be hit-and-miss. Esp with IE, as the IE team is still way behind everyone else. Just so you know. If you are testing in FF3 beta you'll probably see most of the CSS working.

--------------------------------------------------------------------
So we have not only Cascade, we have Inheritance and Specificity. I'm still wading through these myself, as some things by default inherit while others don't and I don't have them memorised so sometimes I either look it up or just look at my browsers. I get bloat that way, but life's a learning experience : )

You reduce your code through inheritance. Find who can give their gifts to their children and who can't. Those who can, lets their children be free from extra, redundant code.

Override inheritance with Specificity. There's actually a point system given to things based on whether something's a class, an id, or a combination of the two. I don't remember it but it's in like every CSS book. ID's get higher scores than classes, who get higher scores than naked elements. To get a class to override an id, name it's parent with an id or, if not possible, name as many parents as it takes to make them overcome someone's id.

<div id="foo">
<p class="bar">lalala</p>
</div>

#foo has precedence. Color: #f00; will make p's text red.

p.bar {color: #00f;} Here you have both an element and a class. By their powers combined, they will override #foo and make the text blue. But heck, you don't even need the two, because .bar is targetting only the text in p, not everything else in the div called #foo, AND it should be coming after #foo's declaration.

#foo {
color: #f00;
}
then
.bar {
color: #00f;
}

Bar came later and overrode #foo. But what if #foo was more specific?

#foo p {
color: #f00;
}
.bar {
color: #00f;
}

bar has lost its power over #foo, because now the declaration lists both #foo AND an element. In fact, you'll find even p.bar can't change #foo either. Text remains red.

So you're in this situation:

<div id="foo">
<p>foo foo foo</p>
<p class="bar">lalala</p>
</div>

Code (markup):

You gave a class to the second p because it's easier or because IE doesn't understand last-child or whatever. You want it blue, what to do?
#foo p {
color: #f00;
}
p.bar {
color: #00f;
}
It's not working! All the text is red! What to do?

#foo p {
color: #f00;
}
#foo p.bar {
color: #00f;
}

(or use earlier code where you use #foo instead of #foo p... making stuff more general is sometimes better)
Done. You need the class only to differentiate that one P from the others in the #foo div. But you can run into issues like above. I usually have to play with it to figure it out, but I know making stuff more specific can override stuff... or sometimes I go back and make the original declarations more general.

So... your CSS still looks a little messy to me, like a template, but that's me looking at it. If you keep doing this, playing with CSS on pages, you'll be able to come back to this page in just a few months and say, My God, I could've done this and that and that too! We all do.

But for the sake of the sweet baby Buddha, do NOT go to Frontpage. There's a reason Microsoft left it to die; it's a horrible creature who should have never been released. CSS can get frustrating but there IS a system behind it. I've noticed programmers seem to have the most trouble with it. Part of the problem is multiple user agents not following the rules, but also just the way CSS is set up. You can read spec pages until you're blue (and that's not a bad idea), but really you learn it by doing, and by watching others do it. You'll see someone post a new trick and you'll see immediately what it does and you'll be like, wow! I want to do that. You bookmark it and next project you play with it.