By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,423 Members | 2,466 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,423 IT Pros & Developers. It's quick & easy.

church website: having trouble with display in IE

P: n/a
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net

The site displays nicely in Firefox/Mozilla and Safari, but the stained
glass windows navigation portion is getting pushed down in IE, and the
"news" box is appearing over top of it. I would much appreciate any
pointers... I just don't really understand all the IE layout hacks
yet...

Of lesser worry is that the text in the left nav bar is cut off on
hover, and that none of my background images as defined in the css are
showing up...

Thanks for any help you can provide!

James

Oct 31 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a
fi******@gmail.com wrote:
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net
Completely irrelevant to your question, your Sermons page really ought
to have a sentence describing the content of each sermon. How many
people coming to that page are going to look at the links and say, "Hey,
I think I'll see what Jeffrey Fishwick had on his mind on August 27,
2006"? If the sermons are going to be of any interest to visitors at
all, it will be based on what the sermons are about. If you don't give
them some idea of what that is before they click on a link, especially
one for a PDF or an MP3, they're not going to bother.
Oct 31 '06 #2

P: n/a
Actually, as far as I'm told, the sermons are usually either downloaded
by:

1) regulars who are out of town and want to hear the sermon
irregardless

2) People who want to hear a sermon they've already heard again

Unfortunately, the site as it is now isn't really focused on
evagenlism, but catering to the regulars. I'm taking on what I can on
an volunteer basis, time will tell if I can find the time and skills to
get the site to where it needs to be...

Harlan Messinger wrote:
fi******@gmail.com wrote:
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net

Completely irrelevant to your question, your Sermons page really ought
to have a sentence describing the content of each sermon. How many
people coming to that page are going to look at the links and say, "Hey,
I think I'll see what Jeffrey Fishwick had on his mind on August 27,
2006"? If the sermons are going to be of any interest to visitors at
all, it will be based on what the sermons are about. If you don't give
them some idea of what that is before they click on a link, especially
one for a PDF or an MP3, they're not going to bother.
Oct 31 '06 #3

P: n/a
VK
I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net
Without saying that anything *you* do is right (in CSS sense) the first
step would be to fix the right things IE does in a wrong way.

IE - before the recent version 7 - expects that the first tag on the
page is either <htmlor <!doctype>. Anything else except comments
enforce BackCompat (Quirk) mode for IE. The outcome (besides other
ones) is that IE stays in its default box model. It means that if you
decided to use XHTML doctype you *never* use prolog with it or you may
get more troubles than you would expect.

So the first step is to change

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

to

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

That will bring IE's box model in accordance with the W3C box model
used by other UA's. Then let's see which problems will remain.

P.S. This bug is acknowledged by Microsoft and fixed in IE7 but for now
IE6 is still is wider use.

Oct 31 '06 #4

P: n/a
two7s_clash wrote:
Actually, as far as I'm told, the sermons are usually either downloaded
by:

1) regulars who are out of town and want to hear the sermon
irregardless
That may be so, but if that's the only consideration, then there isn't
much point in listing more than the list three or four of them! It also
begs the question: maybe other people WOULD download them if there was a
way to know in advance what the sermons were about. And you never know
who might stray in from the outside, through search engines.
2) People who want to hear a sermon they've already heard again
Is a person going to remember that the sermon of interest was "the
sermon given on such-and-such day in February" or is he going to
remember that it was "the sermon about respect for the environment" or
"the sermon about Peter's denial"?
Unfortunately, the site as it is now isn't really focused on
evagenlism, but catering to the regulars. I'm taking on what I can on
an volunteer basis, time will tell if I can find the time and skills to
get the site to where it needs to be...
I think my suggestion is a pretty low-effort one. You're taking the time
to add the link anyway. The effort-to-benefit ratio for adding a
sentence to describe the sermon seems pretty low to me.

Also, I recommend that you put (PDF) instead of (text). You should
always warn people that a link will lead to something that requires a
plug-in or an external application to load. Indicating the size is
helpful too, especially for the MP3s, so the user can decide in advance
whether he has the bandwidth and the time, instead of clicking, and then
realizing 30 seconds later that the darn thing is still loading.
Oct 31 '06 #5

P: n/a
In article
<11**********************@e3g2000cwe.googlegroups. com>,
fi******@gmail.com wrote:
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net

The site displays nicely in Firefox/Mozilla and Safari, but the stained
glass windows navigation portion is getting pushed down in IE, and the
"news" box is appearing over top of it. I would much appreciate any
pointers... I just don't really understand all the IE layout hacks
yet...

Of lesser worry is that the text in the left nav bar is cut off on
hover, and that none of my background images as defined in the css are
showing up...

Thanks for any help you can provide!

James
In Safari, the site appears as if the stylesheet is turned off.
Safari is very picky and you have errors there. As well as
following the doctype advice posted by another (do you really
need the xhtml business, why not stay with html doc type?),
check your css:

You have:

div.pdf_wrap {/
border-top:1px dotted #300;
font: normal 10px/12px arial, helvetica, san-serif;}

What is that / doing? Some sort of hack? And it is "sans serif",
not "san serif"

--
dorayme
Oct 31 '06 #6

P: n/a
VK schrieb:
So the first step is to change

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

to

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Then without information on a protocol level about the character
encoding, an XML processor will assume UTF-8 or UTF-16, but not
iso-8859-1 as specified in the XML declaration.

Additionally the question arises, why XHTML 1.0 Transitional is used.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
Oct 31 '06 #7

P: n/a
fi******@gmail.com wrote:
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.

http://www.christchurchinfo.net

The site displays nicely in Firefox/Mozilla and Safari, but the stained
glass windows navigation portion is getting pushed down in IE, ...
Hello, James

First step in this situation is to run your page through the validator.
http://validator.w3.org/check?verbos...rchinfo.net%2F
says you've got 47 errors, but most of them are the same one. The
first problem relates to XHTML and XML, and that's the first question:
why not try HTML 4.01 (strict), and eliminate a lot of complexity?

But most of the rest of the errors are because you've got multiple lines
(table rows, actually) containing stuff like
<td><img src="spacer.gif" alt="" name="undefined_2" border="0"
height="1" width="47" id="undefined_2" /></td>

You can use an id only once on a page. And anyway, what does an id like
"undefined_2" mean? To say nothing of the name.

But if you're using CSS, why do you want to mess with width=47 (or
whatever) in every cell? Especially when every cell in the row is empty?
Why use the spacer.gifs at all?

I know why: you want to achieve pixel-perfect layout, so you are using
tables to layout non-tabular content, specifying font-size in px, and
hoping the user will see everything just as you see it. But apart from
the specific problems you mention in your OP (which I won't explicitly
address), the page doesn't really "display nicely in Firefox," no matter
how it looks in IE.

If I increase the font size even one notch in FF, the text grows out of
the nav boxes (upper-left). That's *before* I hover over them. The
"Forming Christians" motto (upper-right) starts to overlap the window
frame (so the purple text fades into the brown bg).

Even before I upsize the font, the e-mail address is partially obscured
by the job opening box (I see "e-mail: cec@ntel"). I don't see the phone
or fax numbers at all.

When my viewport is less than 985px wide, I get a horiz. scrollbar, for
no apparent reason. Your content isn't more than about 803px wide.

Drifting even farther from your query (but still in what I hope you will
find a constructive direction):
The stained glass links look like text, but are really graphics (one
smaller; another larger for the "hover"). You have no alt or title
attributes on the links, so we never see any tooltips, and if an image
doesn't load, there's no chance to follow its link (except true blind
luck). Also, I notice you've got some Dreamweaver-type javascript to
preload the "hover" images, but it looks like you don't call the code.
So I see a delay the first time I try to hover over the link before the
"large" version appears. Those with poorer eyesight than myself might
not call the link text large, though.

The upper-left nave links look a little funny to me, like they snuck in
from another website. I don't personally care for the effect on hover;
it looks broken to me.

From the other (non-home) pages, the navigation is completely
inaccessible when images are turned off or not usable. But maybe you're
re-doing those pages to match the style of the (new) Home page?

<link rel="stylesheet" href="jesus.css" type="text/css" />
Now *that's* a stylesheet to pay attention to! Talk about !important!

I hope some of the verbose drivel above is of some use to you. I think
you'll have trouble as long as you try to use px and pt to nail down
every element, and the vagaries of XHTML won't help you, esp. with IE.
Consider a design with images optional, and varying sizes of text and
browser windows.

--
John
Nov 1 '06 #8

P: n/a
Hi John-

Thanks for your thoughtful and constructive feedback. A lot to consider
and rework!

The odd stained-glass window menu is not of my design, but a relic from
the former home page, which, as bad as mine is, was a hundred time
worse. I'm taking on this site as a volunteer, with a plan to rework
all the pages, but right now I just want it to display mostly legibly
in the default view in the major three browsers... is there anyway I
can insititute a temporary fix just so IE doesn't drop the window below
the left-hand nav and the script?

Beyond that, any concrete suggestions/examples for instituting your
final suggestion, while keeping the window in some central element?

Thanks,

-J

On Oct 31, 10:01 pm, John Hosking <J...@Hosking.name.DROPTHE.invalid>
wrote:
fishw...@gmail.com wrote:
I haven't really done any css in quite a while, and am banging my head
against the wall trying get the rudimentary layout together of a church
website home page to display correctly - I don't want to continue work
until I understand what I'm doing wrong.
http://www.christchurchinfo.net
The site displays nicely in Firefox/Mozilla and Safari, but the stained
glass windows navigation portion is getting pushed down in IE, ...Hello, James

First step in this situation is to run your page through the validator.http://validator.w3.org/check?verbos...2Fwww.christch...
says you've got 47 errors, but most of them are the same one. The
first problem relates to XHTML and XML, and that's the first question:
why not try HTML 4.01 (strict), and eliminate a lot of complexity?

But most of the rest of the errors are because you've got multiple lines
(table rows, actually) containing stuff like
<td><img src="spacer.gif" alt="" name="undefined_2" border="0"
height="1" width="47" id="undefined_2" /></td>

You can use an id only once on a page. And anyway, what does an id like
"undefined_2" mean? To say nothing of the name.

But if you're using CSS, why do you want to mess with width=47 (or
whatever) in every cell? Especially when every cell in the row is empty?
Why use the spacer.gifs at all?

I know why: you want to achieve pixel-perfect layout, so you are using
tables to layout non-tabular content, specifying font-size in px, and
hoping the user will see everything just as you see it. But apart from
the specific problems you mention in your OP (which I won't explicitly
address), the page doesn't really "display nicely in Firefox," no matter
how it looks in IE.

If I increase the font size even one notch in FF, the text grows out of
the nav boxes (upper-left). That's *before* I hover over them. The
"Forming Christians" motto (upper-right) starts to overlap the window
frame (so the purple text fades into the brown bg).

Even before I upsize the font, the e-mail address is partially obscured
by the job opening box (I see "e-mail: cec@ntel"). I don't see the phone
or fax numbers at all.

When my viewport is less than 985px wide, I get a horiz. scrollbar, for
no apparent reason. Your content isn't more than about 803px wide.

Drifting even farther from your query (but still in what I hope you will
find a constructive direction):
The stained glass links look like text, but are really graphics (one
smaller; another larger for the "hover"). You have no alt or title
attributes on the links, so we never see any tooltips, and if an image
doesn't load, there's no chance to follow its link (except true blind
luck). Also, I notice you've got some Dreamweaver-type javascript to
preload the "hover" images, but it looks like you don't call the code.
So I see a delay the first time I try to hover over the link before the
"large" version appears. Those with poorer eyesight than myself might
not call the link text large, though.

The upper-left nave links look a little funny to me, like they snuck in
from another website. I don't personally care for the effect on hover;
it looks broken to me.

From the other (non-home) pages, the navigation is completely
inaccessible when images are turned off or not usable. But maybe you're
re-doing those pages to match the style of the (new) Home page?

<link rel="stylesheet" href="jesus.css" type="text/css" />
Now *that's* a stylesheet to pay attention to! Talk about !important!

I hope some of the verbose drivel above is of some use to you. I think
you'll have trouble as long as you try to use px and pt to nail down
every element, and the vagaries of XHTML won't help you, esp. with IE.
Consider a design with images optional, and varying sizes of text and
browser windows.

--
John
Nov 1 '06 #9

P: n/a
Hi, James

It works better if you bottom-post (as I am doing here, rather than
top-post, as you did in your reply to me. I've fixed it for you (so your
response is now at the bottom).

two7s_clash wrote:
On Oct 31, 10:01 pm, John Hosking wrote:
>>fishw...@gmail.com wrote:
>>>http://www.christchurchinfo.net
>>[bunch of tips and criticisms snipped]

I hope some of the verbose drivel above is of some use to you. I think
you'll have trouble as long as you try to use px and pt to nail down
every element, and the vagaries of XHTML won't help you, esp. with IE.
Consider a design with images optional, and varying sizes of text and
browser windows.

Hi John-

Thanks for your thoughtful and constructive feedback. A lot to consider
and rework!

The odd stained-glass window menu is not of my design, but a relic from
the former home page, which, as bad as mine is, was a hundred time
worse. I'm taking on this site as a volunteer, with a plan to rework
all the pages, but right now I just want it to display mostly legibly
in the default view in the major three browsers... is there anyway I
can insititute a temporary fix just so IE doesn't drop the window below
the left-hand nav and the script?

Beyond that, any concrete suggestions/examples for instituting your
final suggestion, while keeping the window in some central element?
Well, I've found what's happening, but I can't say *why* it is. I can
explain it in its most simplified form, though, and maybe somebody can
tell what you can do about it.

You're facing this fundamental situation:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>Christ Episcopal Church</TITLE>
<style type="text/css">
body { margin:0; padding:0; background-color:aqua; }
..word { WIDTH:175px; FLOAT:left; }
</style>
</HEAD><BODY>

<DIV class="word">Forming Christians in order that they might serve
....</DIV>

<TABLE><TR><TD><IMG src="window3_r1_c1.jpg" width=697 height=96>
</TD></TR></TABLE>

</BODY></HTML>

The table with all your sliced up stained glass imagelets stays up where
you want it in Firefox, even at the height of the "word" DIV at the top
of the page. In IE6, however, the table always bumps down below the
"word" DIV, *unless* there is enough room for both in the width of the
viewport. So when the IE window is at least 697 + 175 pixels wide, both
elements are at the top, but if you reduce the size of the window, the
table drops down below the div.

If the image is not in a table, but in another DIV, then the img DIV
drops in Firefox as well as in IE6.

I'm sure the others here know about this and why it is. I do not. :-(
also don't know what to search for. Probably "replaced elements," if
only because that's the part of the W3C specs I understand least.

Originally, I hadn't realized you had sliced up images. I just assumed
the stained glass was a background image. So maybe that's the best idea
for a solution involves a large containing div w/ stained glass bg
image, and the .word DIV as well as a table for your links contained
inside the container. You could use text links rather than GIFs, so they
expand to suit the user's needs. Ergo no probs when no images.

BTW, as I was narrowing things down to make a simplified case of your
site, I noticed several instances in your CSS where top, right, bottom,
and left values where all identical for a given selector. For example,
#frame { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
MARGIN-LEFT: auto; WIDTH: 900px; MARGIN-RIGHT: auto; PADDING-TOP: 0px }

Maybe you know this, but things like this can be simplified to
#frame {PADDING:0px; MARGIN-LEFT:auto; WIDTH:900px; MARGIN-RIGHT:auto; }

I also think you don't need
#frame { WIDTH: 900px; } or
#container { WIDTH: 740px }, but you'll have to check.
Nov 1 '06 #10

P: n/a
In article <45**********@news.bluewin.ch>,
John Hosking <Jo**@Hosking.name.DROPTHE.invalidwrote:
Hi, James

It works better if you bottom-post (as I am doing here, rather than
top-post,
Is there a name for text that makes what it says clearly untrue?

--
dorayme
Nov 1 '06 #11

P: n/a
dorayme wrote:
In article <45**********@news.bluewin.ch>,
John Hosking <Jo**@Hosking.name.DROPTHE.invalidwrote:

>>Hi, James

It works better if you bottom-post (as I am doing here, rather than
top-post,


Is there a name for text that makes what it says clearly untrue?
Heh. Heh heh. Well, I *meant* "bottom-posting, as I am doing here in
this post with the rest of the content, not this little bit that so
poorly explains what I mean."

It's an abbreviation...

--
John
Nov 1 '06 #12

P: n/a
On 2006-11-01, John Hosking <Jo**@Hosking.name.DROPTHE.invalidwrote:
[snip]
Well, I've found what's happening, but I can't say *why* it is. I can
explain it in its most simplified form, though, and maybe somebody can
tell what you can do about it.

You're facing this fundamental situation:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML><HEAD><TITLE>Christ Episcopal Church</TITLE>
<style type="text/css">
body { margin:0; padding:0; background-color:aqua; }
.word { WIDTH:175px; FLOAT:left; }
</style>
</HEAD><BODY>

<DIV class="word">Forming Christians in order that they might serve
...</DIV>

<TABLE><TR><TD><IMG src="window3_r1_c1.jpg" width=697 height=96>
</TD></TR></TABLE>

</BODY></HTML>

The table with all your sliced up stained glass imagelets stays up where
you want it in Firefox, even at the height of the "word" DIV at the top
of the page. In IE6, however, the table always bumps down below the
"word" DIV, *unless* there is enough room for both in the width of the
viewport. So when the IE window is at least 697 + 175 pixels wide, both
elements are at the top, but if you reduce the size of the window, the
table drops down below the div.

If the image is not in a table, but in another DIV, then the img DIV
drops in Firefox as well as in IE6.

I'm sure the others here know about this and why it is. I do not. :-(
This is an interesting phenomenon I have observed before. I think it's a
quirk. I have not not seen where this specified, but Firefox, Opera and
Konqueror all do it.

The table in this case is not behaving like a block-level box, which
according to the CSS spec, it should (if it's display: table). If it
were a block level box, it should go below the float, always, whether
there's room or not. If it were behaving like an inline-level box, it
should go to the right of the float unless there isn't enough room, in
which case it should go below. It doesn't consistently behave like
either in FF.

It sounds like IE is treating the table as if it were display:
inline-table rather than display: table. So a possible fix might be to
add

table { display: table; }

but I don't hold out much hope for that making any difference.
also don't know what to search for. Probably "replaced elements," if
only because that's the part of the W3C specs I understand least.
If there's an explanation, it's likely in an HTML spec under "tables".
This is either not in CSS 2.1 or I haven't found it.

You get this behaviour with any table, whether it contains a "replaced
element" or not.

I would also like to know where and in what spec this is explained.

I think the fix here is not to use a float, but use positioning instead.

..word
{
width: 175px;
position: absolute;
left: 0px;
}

Then make the table

{
position: absolute;
left: 175px;
}
Nov 1 '06 #13

P: n/a
VK
This is an interesting phenomenon I have observed before. I think it's a
quirk. I have not not seen where this specified, but Firefox, Opera and
Konqueror all do it.
That is not a "quirk" but the principal difference of how tables and
other block elements are rendered.

A block element like DIV will not be rendered intil the closing tag for
this DIV is parsed (thus all nested elements are parsed as well). It is
because the engine cannot define exact width and position of the said
DIV until it knows all about its children.

At the contrary the engine starts rendering TABLE element as soon as it
has enough data to define the width of the first row (which is defined
either by COLSPAN descriptor or by the content of the cells in the
first row).

That is why it is a very bad idea to nest tables into some fancy
div-based "liquid" layouts. It is also one of reasons why table layouts
remain widely used, especially for low-bandwidth environments. Namely
table layout displays "right on arrival" and it fixes the page elements
positions right away. Delayed CSS only adds "more flash" on it, but
generally it stays wherever first seen. On DIV-based layout with a low
bandwidth it is often to see the irritating "creation in action" effect
when something first appears on say left, then jumps down, then up and
at the moment one is ready to click it jumps to the right and finally
remains.

That is *not* about "DIV layouts are a failure, table layouts rule";
yet something to keep in mind - at least for "liquid" layouts with
nested tables.

Nov 1 '06 #14

P: n/a
On 2006-11-01, VK <sc**********@yahoo.comwrote:
>This is an interesting phenomenon I have observed before. I think it's a
quirk. I have not not seen where this specified, but Firefox, Opera and
Konqueror all do it.

That is not a "quirk" but the principal difference of how tables and
other block elements are rendered.

A block element like DIV will not be rendered intil the closing tag for
this DIV is parsed (thus all nested elements are parsed as well). It is
because the engine cannot define exact width and position of the said
DIV until it knows all about its children.
It does know the width before descendents are visited in all cases
except those in which the DIV is shrink-to-fit (i.e. floated, positioned
or display: inline-block with width: auto). In those cases the UA needs
to examine (not lay out, just examine to determine content minimum and
preferred widths) the descendents of the DIV in order to determine the
used width.

But it does not know the final height until all descendents have been
fully laid out.
At the contrary the engine starts rendering TABLE element as soon as it
has enough data to define the width of the first row (which is defined
either by COLSPAN descriptor or by the content of the cells in the
first row).
It also needs to know the height of the first row before it can render
anything. More precisely, it can't render anything until it reaches the
end of a row that does not contain the start but not the end of any
rowspanning cells.
That is why it is a very bad idea to nest tables into some fancy
div-based "liquid" layouts.
I do not follow you here. As you said, the DIV's height isn't known (if
it's height: auto) until its content has been laid out. This is equally
true whether its content consists of tables or other things. So what's
wrong with putting tables in div-based liquid layouts? I can see no
fundamental problem with that and have not observed any problems with it
in Firefox, Opera or Konqueror.
It is also one of reasons why table layouts remain widely used,
especially for low-bandwidth environments. Namely table layout
displays "right on arrival" and it fixes the page elements positions
right away.
The situation is no different with nested divs. If you represent the
nested block-level boxes of a formatted document as a tree, then each
box can be displayed on the screen as soon as it visited in a post-order
traversal of the tree.

If we treat table rows with no overhanging spanning cells as
"block-level boxes" for the purposes of this representation, they fit
into the model just like any other block-level box.

I do not see how any of this explains the strange behaviour of tables
next to floats observed in many browsers.
Nov 1 '06 #15

P: n/a
In article <45**********@news.bluewin.ch>,
John Hosking <Jo**@Hosking.name.DROPTHE.invalidwrote:
dorayme wrote:
In article <45**********@news.bluewin.ch>,
John Hosking <Jo**@Hosking.name.DROPTHE.invalidwrote:

>Hi, James

It works better if you bottom-post (as I am doing here, rather than
top-post,

Is there a name for text that makes what it says clearly untrue?
Heh. Heh heh.
Don't worry, I know what you meant. :)

"palindrome" is for a string that reads same back or forward, and
there may be a word or two to capture the idea of saying
something that has to be true (or false) by the mere saying it.

--
dorayme
Nov 1 '06 #16

P: n/a
VK
It does know the width before descendents are visited in all cases
except those in which the DIV is shrink-to-fit (i.e. floated, positioned
or display: inline-block with width: auto).
That is in the beautiful theory. In the miserable practice :-) by
meeting
<div class="div021"...current parsing point
or
<div id="container"...current parsing point
the browser doesn't have a slightest clue what the final width or
even position will be for this element. The external stylesheet link
with rules for #div001 or .container was parsed just a tick or two
before and still starving in the request queue together with a bunch of
other <link>'s and <scripts>'s to load. That can be anything from 1sec
up to timeout before UA will be informed of what did you actually want
to do with this div. Moreover it can be a broken layout so UA will have
to quickly construct something more-or-less reasonable out of
"creative" author's ideas about the HTML markup :-)

Truthfully in such situations it is pretty much poker game between the
author and UA.
UA may try to guess your combination and start lying out based on this
guess. Or it may wait until more cards will be open. In the first case
it will be "more responsive rendering engine", but it is bad if UA did
not guess right, the page may get screwed or/and it will have to make
emergency re-arrangements at the end.
UA may choose do not risk and "call to open". In this case users will
envisage blank screen until the whole page jumps out.
Historically there were both kind of "players" implemented but it seems
that users do not like overly careful ones ("non-responsive rendering
engine") so they never did well. So everyone had to risk more or less
pleasing us.

Now you may see that the draw gets really interesting if the next card
is an old-fashioned TABLE:

<div id="container">
<table width="100%" cellpadding="2" cellspacing="2">
<tr>
<td width="50%">content</td>
<td width="50%">content</td>
</tr>
....current parsing point

UA still has no idea about #container but it has seemly all necessary
info to draw the first row in the table. Well, you know, if I was on
that green table I would be all sweating over the decision... :-)

P.S. Just came to me: what if try to set the most important rules for
involved div's over style attribute right in tags? ("to give more
hints" to the parser) Will it help?

Nov 1 '06 #17

P: n/a
P.S. Just came to me: what if try to set the most important rules for
involved div's over style attribute right in tags? ("to give more
hints" to the parser) Will it help?
How would this look?

Nov 2 '06 #18

P: n/a
On 2006-11-01, VK <sc**********@yahoo.comwrote:
>It does know the width before descendents are visited in all cases
except those in which the DIV is shrink-to-fit (i.e. floated, positioned
or display: inline-block with width: auto).

That is in the beautiful theory. In the miserable practice :-) by
meeting
<div class="div021"...current parsing point
or
<div id="container"...current parsing point
the browser doesn't have a slightest clue what the final width or
even position will be for this element. The external stylesheet link
with rules for #div001 or .container was parsed just a tick or two
before and still starving in the request queue together with a bunch of
other <link>'s and <scripts>'s to load. That can be anything from 1sec
up to timeout before UA will be informed of what did you actually want
to do with this div.
[snip]
UA may try to guess your combination and start lying out based on this
guess. Or it may wait until more cards will be open. In the first case
it will be "more responsive rendering engine", but it is bad if UA did
not guess right, the page may get screwed or/and it will have to make
emergency re-arrangements at the end.
Now I see what you're talking about. Yes, it's true that the UA may
start rendering before all style information is available, and if
necessary reflow.
UA may choose do not risk and "call to open". In this case users will
envisage blank screen until the whole page jumps out. Historically
there were both kind of "players" implemented but it seems that users
do not like overly careful ones ("non-responsive rendering engine") so
they never did well. So everyone had to risk more or less pleasing us.
Yes, most people prefer to see something sooner even if it means the
page reflows a couple of times.

Long before stylesheets, UAs used to start rendering the text before all
the images had arrived (and still do). This is definitely useful over a
slow link. The page often needs to reflow because the size of the image
is often not known until the actual image file has arrived.
Now you may see that the draw gets really interesting if the next card
is an old-fashioned TABLE:

<div id="container">
<table width="100%" cellpadding="2" cellspacing="2">
<tr>
<td width="50%">content</td>
<td width="50%">content</td>
</tr>
...current parsing point

UA still has no idea about #container but it has seemly all necessary
info to draw the first row in the table.
Not necessarily, the table may be styled into something completely
different by CSS that hasn't been loaded yet. But, yes, if all the style
information for the table is in the attributes and markup then it's all
in one place.

I should point out though that once everything has arrived, the UA
should make a final reflow if necessary, and end up with a correct
layout.

I've never known this not to be the case with a mainstream browser
(although I don't use the most mainstream IE, and from what I read here,
nothing surprises me any more about its awfulness).

This is definitely no reason not to use external stylesheets, and
definitely no reason to "not mix tables and liquid layouts".

If a liquid layout contains some tabular data use <table>, if it
contains data that needs to be laid out like a grid, or you just need to
borrow a table-formatting feature that doesn't exist in the rest of CSS,
use display: table and display: table-cell. May not work in IE, but that
goes for everything I say.
P.S. Just came to me: what if try to set the most important rules for
involved div's over style attribute right in tags? ("to give more
hints" to the parser) Will it help?
It might alter the intermediate results you see on the screen depending
on UA and network timing. The final result should look the same. I
wouldn't bother. One thing that may be worth doing is specifying sizes
for images that are the same as their intrinsic sizes anyway.

For example, suppose your page contains "photo.png" which is 400x300px.
If you put <img src="photo.png"the UA will guess the size, and reflow
when photo.png has actually been loaded. If you put <img src="photo.png"
style="width: 400px; height: 300px"(or use the width and height
attributes), the UA will leave a gap the right size, and may be smart
enough not to reflow when the image file has loaded. A hassle, but
perhaps worth doing if you are generating the content programmatically.
Nov 2 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.