If anyone's interested in trying to see if they can break the pages again, I'd
love to have you try :) Some of the places I previously spotted it happening
are below:
http://www.kenyon.edu/x12366.xml
http://www.kenyon.edu/x7904.xml
http://www.kenyon.edu/x14305.xml
Rebecca Mazur wrote:
If anyone's interested in trying to see if they can break the pages again,
I'd
love to have you try :) Some of the places I previously spotted it happening
are below:
All checked in IE/6.0 (only) on a cleared cache.
http://www.kenyon.edu/x12366.xml
Footer
Certainly.
Here's the way it should look:
http://theredsetter.com/test/ie7mistake_good.jpg
Here's what it does sometimes that it shouldn't:
http://theredsetter.com/test/ie7mistake_bad.jpg
Note that the good screenshot was taken after refreshing the bad, so you're
looking at the same page in
Rebecca Mazur wrote:
If someone could just recognize and name the bug for me, that would
be a help, as then I could go searching for solutions.
http://www.kenyon.edu/x12305.xml
The bug is clear enough, but finding a fix isn't.
I found it easier to reproduce the problem in IE6 - multiple
I did a copy-and-paste validation and only found a couple of unencoded two
missing alts, and an xmlns attribute that I need to get rid of--I can't imagine
those being the trouble. They're not things I want in there, and I should find
and fix them regardless, but they're not the sort of thing
Rebecca Mazur wrote:
Have you had experience with browsers breaking on those particular
validation errors?
No. Old IE will eat, ignore or correct such minor errors, same as
other browsers.
I have seen IE do many strange things when served compacted source-code
though, and your markup is
Gunlaug Sørtun wrote:
Rebecca Mazur wrote:
Have you had experience with browsers breaking on those particular
validation errors?
No. Old IE will eat, ignore or correct such minor errors, same as
other browsers.
I have seen IE do many strange things when served compacted
Rebecca Mazur wrote:
The big difference is that our stuff shouldn't ride all the way to the
bottom of the screen like that. Bottom of footer and bottom of
content should line up (with content just being content; no big gaps),
unless footer + subnavigation content, in which case the
Rebecca Mazur wrote:
Hi David,
I think I ran the same scan that you did, but I'm not sure, since the
only issues I got were some unescaped 's, a couple of missing alts,
and those blasted xmlns attributes that I can't seem to get rid of
(we're CMS based). Just wanted to check that that's
No good, though I wish that was all it would take. That's what lines up the
bottom of the footer with the bottom of the content; take that out and the top
of the footer lines up with the bottom of the content. If there was some other
way to get the cussed thing to do that, the positioning
On Apr 8, 2009, at 11:36 AM, Rebecca Mazur wrote:
No good, though I wish that was all it would take. That's what
lines up the
bottom of the footer with the bottom of the content; take that out
and the top
of the footer lines up with the bottom of the content. If there was
some other
Rebecca Mazur wrote:
Here is one page that has definitely done it to me more than once:
http://www.kenyon.edu/x12305.xml
~Rebecca
Dunno. Up for a shot in the dark, Rebecca?
The file is proprietary html.
Change the doctype and character encoding and validate the markup to:
!DOCTYPE
Sweet code there :) Not quite what I'm looking for, though, and I probably
wasn't clear with my prose in my original email.
The footer is kind of funky because it shares a column with the subnavigation
*but* should align bottom-to-bottom with the content column *unless* the
Hmm, I might have to resort to that. The trouble with min-height, of course,
is
that our subnavs don't have a consistent height so I would either have some
pages that are taller than they should be or risk having it still happen in
some
cases. I could probably prevent it on a larger number
14 matches
Mail list logo
