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

They just don't work

P: n/a
"Now is the time for all good web developers to use stylesheets".

Hmm OK, so I start this commercial site design with the express intent
of using CSS entirely. (Something I haven't attempted in about 3 years
since I last wasted my time trying to get it to work).

The site layout is intended to look (nearly precisely) like this from
the CSS-2 spec:

http://www.w3.org/TR/REC-CSS2/visure...ed-positioning

Copy-paste, right?

Wrong.

IE doesn't place 'main' correctly, and leaves ugly margins. The latter
was easily resolvable with body { margin: 0px; } - the former is a big
headache.

Netscape (and Firebird). Hmmm looks OK... that is, until you fill the
'main' <div> with _actual_ content.

Netscape cuts off the overflow lines, denying your opportunity to read
the full page. IE behaves more like you expect, expanding main and
dropping the footer to cope. So the headache is there in both and
different in both.

Never mind - there must be a reasonably simple way to tweak the
stylesheet to work properly in both, right?

Wrong.

After 4-5 hours of attempting to resolve these issues, I gave up and
built it cross-compatible using <table>s in about 20 minutes.

No wonder CSS doesn't get used as intended... it never does what it
says on the tin. That's not the W3C's fault - just a reality that has
persisted for as many years as I have been working in IT/Web.

Prove me wrong? Can you make it work?

Here's a start...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>A frame document with CSS2</TITLE>
<STYLE type="text/css">
body {
margin: 0px;
}
#header {
position: fixed;
width: 100%;
height: 50px;
top: 0px;
right: 0px;
bottom: auto;
left: 0px;
background-color: blue;
}

#sidebar {
position: fixed;
width: 150px;
height: auto;
top: 50px;
right: auto;
bottom: 20px;
left: 0;
background-color: red;
}

#main {
position: fixed;
width: auto;
height: auto;
top: 50px;
right: 0;
bottom: 20px;
left: 150px;
background-color: green;
}

#footer {
position: fixed;
width: 100%;
height: 20px;
top: auto;
right: 0px;
bottom: 0px;
left: 0px;
background-color: yellow;
}
</STYLE>
</HEAD>
<BODY>
<DIV id="header"> ... </DIV>
<DIV id="sidebar"> ... </DIV>
<DIV id="main"> ... </DIV>
<DIV id="footer"> ... </DIV>
</BODY>
</HTML>

/k1
Jul 20 '05 #1
Share this Question
Share on Google+
40 Replies


P: n/a
komone wrote:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning

Copy-paste, right?
Wrong, you have to invest time and effort to learn CSS and how to use
it, and then there's the browser bugs and shortcomings to learn.
Prove me wrong? Can you make it work?


Sure, but you need to learn how to fish for yourself. CSS isn't easy,
don't start whining if you can't get something to work immediately.

--
Spartanicus
Jul 20 '05 #2

P: n/a
komone wrote:
"Now is the time for all good web developers to use stylesheets".
Correct, in fact, they should have started earlier.

Hmm OK, so I start this commercial site design with the express intent
of using CSS entirely. (Something I haven't attempted in about 3 years
since I last wasted my time trying to get it to work).
If you don't learn about stuff, you won't succeed. Read this:
<http://www.zeldman.com/dwws/>

The site layout is intended to look (nearly precisely) like this from
the CSS-2 spec:

http://www.w3.org/TR/REC-CSS2/visure...ed-positioning

Copy-paste, right?

Wrong.
Correct. IE doesn't support fixed positioning (without hacks)

IE doesn't place 'main' correctly, and leaves ugly margins. The latter
was easily resolvable with body { margin: 0px; } - the former is a big
headache.

Netscape (and Firebird). Hmmm looks OK... that is, until you fill the
'main' <div> with _actual_ content.

Netscape cuts off the overflow lines, denying your opportunity to read
the full page. IE behaves more like you expect, expanding main and
dropping the footer to cope. So the headache is there in both and
different in both.

Never mind - there must be a reasonably simple way to tweak the
stylesheet to work properly in both, right?

Wrong.

After 4-5 hours of attempting to resolve these issues, I gave up and
built it cross-compatible using <table>s in about 20 minutes.
Depends on your knowlodge, you will have to invest some time.

No wonder CSS doesn't get used as intended... it never does what it
says on the tin. That's not the W3C's fault - just a reality that has
persisted for as many years as I have been working in IT/Web.
blah blah blah

Prove me wrong? Can you make it work?


Nope, but I came close with fixed postioning in IE (it works in quite a
lot of browsers, but it is not the exact same layout):
<http://limpid.nl/lab/css/fixed/>
--
Anne van Kesteren
<http://www.annevankesteren.nl/>
Jul 20 '05 #3

P: n/a
You think 4 years isn't enough?

Truth is, you can't make it work.

And stop telling me I'm whining when I'm not. It simply won't work.

Try it.

/k1

"Spartanicus" <me@privacy.net> wrote in message
news:lb********************************@news.spart anicus.utvinternet.ie...
komone wrote:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning

Copy-paste, right?


Wrong, you have to invest time and effort to learn CSS and how to use
it, and then there's the browser bugs and shortcomings to learn.
Prove me wrong? Can you make it work?


Sure, but you need to learn how to fish for yourself. CSS isn't easy,
don't start whining if you can't get something to work immediately.

--
Spartanicus

Jul 20 '05 #4

P: n/a
On Tue, 11 Nov 2003, komone wrote:
IE doesn't place 'main' correctly,
"IE" comes in several versions, and has several different modes of
interpreting stylesheets, so your complaint isn't very useful.

In spite of MS's spectacular reputation for adherence to published
interworking specifications, their trend in this area is, maybe
surprisingly, towards actually doing what the spec says.
Netscape
"Netscape" have produced various browsers. The older one simply isn't
going to get any better. The current one is based on Mozilla, so if
you use it right, it's likely to aim at conforming to specifications.

I didn't see where you told us that you had validated your HTML and
successfully passed the CSS checker?
cuts off the overflow lines, denying your opportunity to read
the full page.
If you get overflow, then you're probably doing something inflexible.

Inflexible designs are no less bad in CSS than they were in
pseudo-presentational HTML/3.2(spit).
IE behaves more like you expect,
Like _I_ expect? _I_ expect some kind of attempt to conform with
specifications. If you're expecting what you got with IE, then it's
my experience that your expectations are probably at fault.
expanding main and dropping the footer to cope. So the headache is
there in both and different in both.
That sounds like a typical behaviour provoked by inflexible design.
Never mind - there must be a reasonably simple way to tweak the
stylesheet to work properly in both, right?
Oh, we're back at the "both browsers" syndrome again. I thought that
had died out by now... Don't forget Opera, Safari, MacIE, (webTV
even).
After 4-5 hours of attempting to resolve these issues, I gave up and
built it cross-compatible using <table>s in about 20 minutes.
Let's see your URLs.
Prove me wrong?


Not really. Rigid, fragile design is a problem in any language.

I'd recommend these, if you really want to get ahead.

http://www.hut.fi/u/hsivonen/standards.html
http://gutfeldt.ch/matthias/articles/doctypeswitch.html

http://w3development.de/css/hide_css_from_browsers/

But if you'd rather dig yourself back into that old HTML3.2 rut, I'm
sure you'll find plenty of company. Sturgeon's law, hmmm?
Jul 20 '05 #5

P: n/a
komone wrote:

No wonder CSS doesn't get used as intended... it never does what it
says on the tin. That's not the W3C's fault - just a reality that has
persisted for as many years as I have been working in IT/Web.

Prove me wrong? Can you make it work?


People that understand CSS use it because it speeds up development
time, makes a site smaller & faster, easier to maintain, easier to
target cross-media, and so on. People don't usually use CSS to prove
anything. If you don't want to use it, that's really your choice, and
have fun using table-layout, <font>, and so on. For me just looking at
a typical table-layout HTML source is enough to remind why I don't do
that.
Jul 20 '05 #6

P: n/a
Funny post!

OK, ahem, Mr. P. I take it you understand CSS (as I apparently don't, LOL)?
If so, show me how stupid I have been. The source is available in my
original post.

It ain't possible, y'know.

/k1
"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:bo*************@ID-203055.news.uni-berlin.de...
komone wrote:

No wonder CSS doesn't get used as intended... it never does what it
says on the tin. That's not the W3C's fault - just a reality that has
persisted for as many years as I have been working in IT/Web.

Prove me wrong? Can you make it work?


People that understand CSS use it because it speeds up development
time, makes a site smaller & faster, easier to maintain, easier to
target cross-media, and so on. People don't usually use CSS to prove
anything. If you don't want to use it, that's really your choice, and
have fun using table-layout, <font>, and so on. For me just looking at
a typical table-layout HTML source is enough to remind why I don't do
that.

Jul 20 '05 #7

P: n/a
I see things haven't changed around here much.

Remember "Deep Blue" Alan, Jukka, etc.? :)
Not really. Rigid, fragile design is a problem in any language.


Interesting that you seem to believe that an almost direct copy/paste of the
CSS-2 Spec counts as "fragile design". Show me where.

And HELLO, but real people use IE or Netscape. I very, very rarely see
anything else on any site I have access logs to, and those tend to resolve
to casual visitors.

Truth is, I'd put $50 on the fact that you couldn't make it work either, for
all the huffin' and puffin' that's going on.

/k1
Jul 20 '05 #8

P: n/a
Steve Davis wrote:

OK, ahem, Mr. P. I take it you understand CSS (as I apparently don't,
LOL)? If so, show me how stupid I have been. The source is available
in my original post.

It ain't possible, y'know.


Maybe. Not all things are possible in popular browsers using CSS2. So
you need to use what works and stay away from what is know to break.
This takes initial learning and the W3C specs you quoted won't be of
any help in knowing what often breaks. If you show an image of what you
want to do, or describe it, maybe someone can help.
Jul 20 '05 #9

P: n/a
*Spartanicus* <me@privacy.net>:

Sure, but you need to learn how to fish for yourself. CSS isn't easy,
IBTD, CSS is easy. Rebuilding table or frames layouts with CSS is not,
though. Neither is knowing about all those implementation bugs.
don't start whining if you can't get something to work immediately.


Sometimes it helps, if you don't stop there.

--
"Anyone who slaps a 'this page is best viewed with Browser X' label on a
Web page appears to be yearning for the bad old days, before the Web, when
you had very little chance of reading a document written on another computer,
another word processor, or another network." Tim Berners-Lee, 1996
Jul 20 '05 #10

P: n/a
Sheesh I've been using CSS for years for my thin client applications. The
point was to split presentation from content entirely. And it can't be done.

Before you accuse me of "whining" I suggest you either:

1) Accept that the layout cannot be achieved effectively.
2) Prove that it can.

/k1
"Spartanicus" <me@privacy.net> wrote in message
news:lb********************************@news.spart anicus.utvinternet.ie...
komone wrote:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning

Copy-paste, right?


Wrong, you have to invest time and effort to learn CSS and how to use
it, and then there's the browser bugs and shortcomings to learn.
Prove me wrong? Can you make it work?


Sure, but you need to learn how to fish for yourself. CSS isn't easy,
don't start whining if you can't get something to work immediately.

--
Spartanicus

Jul 20 '05 #11

P: n/a
In article <bo**********@reader11.wxs.nl>,
Anne van Kesteren <ma**@annevankesteren.nl> wrote:

:Correct. IE doesn't support fixed positioning (without hacks)

My IE 5.17 (Mac) supports my fixed positioning, straight out of the CSS
style manual, no hacks.
--
Looks like more of Texas to me.
.... Arizona, where the nights are warm and the roads are straight.
Jul 20 '05 #12

P: n/a
OK.

Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variable
Bottom (info): 20px height, drops down to cope with long sidebar or main, or
sits at the bottom of the window if either are shorter then the window size.

Hardly rocket science is it?

As I said I have done a functional version using tables and css modifiers,
so this is now entirely academic... until I next build.

You should know that I've worked with CSS since the inception of CSS-P so
I'm not exactly uninformed about this stuff.

/k1

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:bo*************@ID-203055.news.uni-berlin.de...
Steve Davis wrote:

OK, ahem, Mr. P. I take it you understand CSS (as I apparently don't,
LOL)? If so, show me how stupid I have been. The source is available
in my original post.

It ain't possible, y'know.


Maybe. Not all things are possible in popular browsers using CSS2. So
you need to use what works and stay away from what is know to break.
This takes initial learning and the W3C specs you quoted won't be of
any help in knowing what often breaks. If you show an image of what you
want to do, or describe it, maybe someone can help.

Jul 20 '05 #13

P: n/a
Steve Davis / 2003-11-11 18:42:
"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:bo*************@ID-203055.news.uni-berlin.de...
komone [a.k.a. Steve Davis] wrote:
Prove me wrong? Can you make it work?


People that understand CSS use it because it speeds up
development time, makes a site smaller & faster, easier[...]
For me just looking at a typical table-layout HTML source is
enough to remind why I don't do that.


OK, ahem, Mr. P. I take it you understand CSS (as I apparently don't, LOL)?
If so, show me how stupid I have been. The source is available in my
original post.

It ain't possible, y'know.


How do you know? If *you* don't know how to do something, it doesn't
make it impossible, does it?

The example you provided (that doesn't validate, by the way) uses
CSS2 features and behaves to the spec in Mozilla. The problems
you've "noticed" are caused by two things: MSIE doesn't support CSS2
well enough so you have to emulate the same behaviour with CSS1 plus
the parts of CSS2 that MSIE does support. That's the hard part.
Another problem is that you've misunderstood CSS box model and
expect it to behave like MSIE does. However, as I said, your example
works to the spec in Mozilla and if you think otherwise, then I must
conclude that you've misunderstood the spec.

See also the demo that Anne mentioned:
http://limpid.nl/lab/css/fixed/

--
Mikko

Jul 20 '05 #14

P: n/a
Mikko wrote:
How do you know? If *you* don't know how to do something, it doesn't
make it impossible, does it?
I've yet to see evidence to the contrary.
The example you provided (that doesn't validate, by the way) uses
Hmm. Did you also try to validate:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning
Interesting, no?
CSS2 features and behaves to the spec in Mozilla. The problems
you've "noticed" are caused by two things: MSIE doesn't support CSS2
well enough so you have to emulate the same behaviour with CSS1 plus
the parts of CSS2 that MSIE does support. That's the hard part.
Another problem is that you've misunderstood CSS box model and
expect it to behave like MSIE does. However, as I said, your example
works to the spec in Mozilla and if you think otherwise, then I must
conclude that you've misunderstood the spec.

Perhaps.... what did I misunderstand there? I personally believe that the
behaviour to which I referred was in actual fact "unspecified", but am
certainly willing to be proven wrong.

The fact remains, that the target layout is not possible entirely through
the use of CSS.

Is it.

/k1
Jul 20 '05 #15

P: n/a
"Steve Davis" <s.******@chello.nl> wrote in message
news:lF*********************@amsnews02.chello.com. ..
OK.

Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variable
Bottom (info): 20px height, drops down to cope with long sidebar or main, or sits at the bottom of the window if either are shorter then the window size.
Hardly rocket science is it


Steve, I assure you... it IS possible. If you want to see some great
examples, check out:
www.csszengarden.com
This site uses 1 very basic HTML file, and people submit CSS files which
display it very differently. You can see the entire list of submissions
here:
http://www.mezzoblue.com/zengarden/alldesigns/

I doubt very much that anyone will post a solution for you here, but I am
very confident that it can be done. Good luck.

Regards,
Peter Foti
Jul 20 '05 #16

P: n/a
"Steve Davis" <s.******@chello.nl> wrote in message
news:jc*********************@amsnews02.chello.com. ..
Hmm. Did you also try to validate:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning
Interesting, no?


Interesting? Not really... it validates as HTML 4.0 Transitional... were
you suggesting that it doesn't validate?
Jul 20 '05 #17

P: n/a
Thanks, Peter. I was aware of that site and it's excellent.

Sadly, however, it does not cover the precise issue as posted originally
(you have to wonder why not also :)

Regards,

/k1


"Peter Foti" <pe****@systolicnetworks.com> wrote in message
news:vr************@corp.supernews.com...
"Steve Davis" <s.******@chello.nl> wrote in message
news:lF*********************@amsnews02.chello.com. ..

<snip>
Jul 20 '05 #18

P: n/a
Not being specific enough there. The reason my original code fails
validation is for the same reason as the HTML embedded in that section of
the spec. Not the spec page itself!

best,
/k1

"Peter Foti" <pe****@systolicnetworks.com> wrote in message
news:vr************@corp.supernews.com...
"Steve Davis" <s.******@chello.nl> wrote in message
news:jc*********************@amsnews02.chello.com. ..
Hmm. Did you also try to validate:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning
Interesting, no?


Interesting? Not really... it validates as HTML 4.0 Transitional... were
you suggesting that it doesn't validate?

Jul 20 '05 #19

P: n/a
"Steve Davis" <s.******@chello.nl> wrote:
Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variable
Bottom (info): 20px height, drops down to cope with long sidebar or main, or
sits at the bottom of the window if either are shorter then the window size.
Why, if you wanted the above, did you try to do it with position:
fixed? There's nothing about the above that requires fixed
positioning, is there?
Hardly rocket science is it?


The only thing in the above description that is not trivially easy to
achieve is placing the footer at the bottom of the window if the page
content is shorter than the window. Everything else is very basic in
CSS.

Anyway, I did this quickly -

http://steve.pugh.net/test/test62.html

Works just fine in IE5+ and Gecko based browsers. Positions the footer
just below the window bottom in Opera, which is very annoying but
could probably be worked around.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #20

P: n/a
Steve Davis wrote:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height
variable Bottom (info): 20px height, drops down to cope with long
sidebar or main, or sits at the bottom of the window if either are
shorter then the window size.

Hardly rocket science is it?

As I said I have done a functional version using tables and css
modifiers, so this is now entirely academic... until I next build.

I've done something somewhat similar to what you describe on my
homepage:
http://www.outer-court.com/tech/goog...ch-tricks.html

Don't know if that helps you. Basically you use absolute positioning
and width: auto; and stuff. Above CSSs have many workarounds to cope
with Netscape 4x. I wouldn't do that anymore these days.

Actually, you might do better by reading CSS articles on sites like
<http://www.zeldman.com>. Or maybe someone else finds the right sample
CSS for you.
You should know that I've worked with CSS since the inception of
CSS-P so I'm not exactly uninformed about this stuff.


OK.
Jul 20 '05 #21

P: n/a
"Steve Davis" <s.******@chello.nl> wrote:
Hmm. Did you also try to validate:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning
Interesting, no?

It validates perfectly using the W3C validator, do you get different
results? Anyways, it's not related to the problem, I think.

To stop this little CSS war I would propose that we should all take into
account that nowadays the W3C standards develop faster than browsers can
implement them. The fact, that the W3C publishes a standard is in no way
a guarantee, that it works in every browser at once. This shouldn't be
seen as a problem. I prefer to have standards set before anyone
implemented them, because they usually develop much "cleaner" then. So,
let's be patient, use only things that are well-implemented in major
browsers and don't blame the W3C, MS or anyone else for this
"inconsistency".

--
Andreas
To reply via e-mail, please remove the fruit and the ".invalid" top
level domain from my address.
Jul 20 '05 #22

P: n/a
Now I can say (thankfully), yes, I was wrong, it is possible.

I also know who knows what they are doing.

Thanks, Steve. That demo showed me a lot.

You rock!

/k1

"Steve Pugh" <st***@pugh.net> wrote in message
news:ee********************************@4ax.com...
"Steve Davis" <s.******@chello.nl> wrote:
Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variableBottom (info): 20px height, drops down to cope with long sidebar or main, orsits at the bottom of the window if either are shorter then the window
size.
Why, if you wanted the above, did you try to do it with position:
fixed? There's nothing about the above that requires fixed
positioning, is there?
Hardly rocket science is it?


The only thing in the above description that is not trivially easy to
achieve is placing the footer at the bottom of the window if the page
content is shorter than the window. Everything else is very basic in
CSS.

Anyway, I did this quickly -

http://steve.pugh.net/test/test62.html

Works just fine in IE5+ and Gecko based browsers. Positions the footer
just below the window bottom in Opera, which is very annoying but
could probably be worked around.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>

Jul 20 '05 #23

P: n/a
*Steve Davis* <s.******@chello.nl>:

Layout target is:
With which mark-up? Assuming

<body>
<X id="banner"/>
<X id="navigator"/>
<X id="content"/>
<X id="info"/>
</body>

X {display: block}

One could try 'table-cell' and "body {display: table}" instead, if it wasn't
for browsers.
Top (banner): 100% width, 50px height.
#banner {height: 50px}
Sidebar (a navigator): On the left, 150px width, height variable
#navigator {float: left; width: 150px; padding: 50px 0 20px 0;}
Main (content): next to the sidebar, width rest of window, height variable
#content {margin: 150px 0 20px 150px;}
Bottom (info): 20px height, drops down to cope with long sidebar or main, or
#info {height: 20px; clear: left;}
sits at the bottom of the window if either are shorter then the window size.
That's harder to achieve, probably best tried with "position: absolute;
bottom: 0;".

You'll pretty surely run into problems, though, because of using pixels.
Hardly rocket science is it?


There's more than one working approach to build a rocket.

--
Useless Fact #14:
There are 102,981,500 ways to combine six of the 8-studed LEGO bricks of one
color.
Since 1949, the LEGO company, based in Denmark, has produced more than
200,000,000,000 of the plastic elements that make up the Lego System.
Jul 20 '05 #24

P: n/a
Great links. Thanks, Mr. P.

I may actually get better at this stuff as a result!

regards,
/k1

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:bo*************@ID-203055.news.uni-berlin.de...
Steve Davis wrote:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height
variable Bottom (info): 20px height, drops down to cope with long
sidebar or main, or sits at the bottom of the window if either are
shorter then the window size.

Hardly rocket science is it?

As I said I have done a functional version using tables and css
modifiers, so this is now entirely academic... until I next build.


I've done something somewhat similar to what you describe on my
homepage:
http://www.outer-court.com/tech/goog...ch-tricks.html

Don't know if that helps you. Basically you use absolute positioning
and width: auto; and stuff. Above CSSs have many workarounds to cope
with Netscape 4x. I wouldn't do that anymore these days.

Actually, you might do better by reading CSS articles on sites like
<http://www.zeldman.com>. Or maybe someone else finds the right sample
CSS for you.
You should know that I've worked with CSS since the inception of
CSS-P so I'm not exactly uninformed about this stuff.


OK.

Jul 20 '05 #25

P: n/a
Steve Davis wrote:
I see things haven't changed around here much.
I see that you came in here shooting from the hip. Not much incentive
to help out.
And HELLO, but real people use IE or Netscape.
Real people also use Opera, Lynx, Safari, and lots of other user-agents.
I very, very rarely see
anything else on any site I have access logs to,
But of course the clueful know the real value of such server logs.
(Think proxy for a moment.)
Truth is, I'd put $50 on the fact that you couldn't make it work either, for
all the huffin' and puffin' that's going on.


In at least 4 messages in this thread, you have dared us to write your
code for you, as if that's going to reel in some sucker. What is
this, a Huck Finn novel? If you're willing to pay, then do so. But I
bet it'll cost you more than $50.00 to code a site.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #26

P: n/a
Steve Davis wrote:

Did you also try to validate:
http://www.w3.org/TR/REC-CSS2/visure...ed-positioning
Interesting, no?


I don't see what you're on about. I valiated the page, and validated
the example html to which that url points. Both validate. If you
have a criticism to make, then be more specific.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #27

P: n/a
In message <vr************@corp.supernews.com>, Peter Foti
<pe****@systolicnetworks.com> writes
"Steve Davis" <s.******@chello.nl> wrote in message
news:lF*********************@amsnews02.chello.com ...
OK.

Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variable
Bottom (info): 20px height, drops down to cope with long sidebar or main,or
sits at the bottom of the window if either are shorter then the window

size.

Hardly rocket science is it


Steve, I assure you... it IS possible. If you want to see some great
examples, check out:
www.csszengarden.com
This site uses 1 very basic HTML file, and people submit CSS files which
display it very differently.


Not necessarily a good example as few of those designs produce a fluid
page, and in many cases don't produce resizable text.

Nice graphics, though ;-)

[snip]

Regards,
Peter Foti


--
Jake
Jul 20 '05 #28

P: n/a
"Steve Davis" <s.******@chello.nl> wrote in message news:<jc*********************@amsnews02.chello.com >...
Perhaps.... what did I misunderstand there? I personally believe that the
behaviour to which I referred was in actual fact "unspecified", but am
certainly willing to be proven wrong.
The reason it doesn't work is because you have div#main set as
position: fixed. By definition this causes that div to stay fixed to
the viewport. It may have grown with extra content but because it was
fixed you never would have seen it. Mozilla was just doing what you
asked it to do.

You can get the original example working as you expected (in Mozilla
and Opera at least) by changing the main div to position: absolute and
fixing z-indexs so that the main content scrolls under the
header/footer.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<TITLE>A frame document with CSS2</TITLE>
<STYLE type="text/css">
body {
margin: 0px;
background-color: green;
}

#header {
position: fixed;
z-index: 1;
width: 100%;
height: 50px;
top: 0px;
right: 0px;
bottom: auto;
left: 0px;
background-color: blue;
}

#sidebar {
position: fixed;
width: 150px;
height: auto;
top: 50px;
right: auto;
bottom: 20px;
left: 0;
background-color: red;
}

#main {
position: absolute;
width: auto;
height: auto;
top: 50px;
right: 0;
left: 150px;
}

#footer {
position: fixed;
z-index: 1;
width: 100%;
height: 20px;
top: auto;
right: 0px;
bottom: 0px;
left: 0px;
background-color: yellow;
}
</STYLE>
</HEAD>
<BODY>
<DIV id="header"> ... </DIV>
<DIV id="sidebar"> ... </DIV>
<DIV id="main"> ... </DIV>
<DIV id="footer"> ... </DIV>
</BODY>
</HTML>
The fact remains, that the target layout is not possible entirely through
the use of CSS.

Is it.


I don't know for sure but IE's lack of support for position: fixed,
probably means you're right. However, I don't see how that invalidates
the use of CSS Positioning as a whole, as other people have shown you
can get fairly close even with IE's poor CSS2 support.
Jul 20 '05 #29

P: n/a
"jake" <ja**@gododdin.demon.co.uk> wrote in message
news:Ny**************@gododdin.demon.co.uk...
Steve, I assure you... it IS possible. If you want to see some great
examples, check out:
www.csszengarden.com
This site uses 1 very basic HTML file, and people submit CSS files which
display it very differently.


Not necessarily a good example as few of those designs produce a fluid
page, and in many cases don't produce resizable text.

Nice graphics, though ;-)


A good example for the purpose of showing how layout and presentation can be
controlled via CSS... but you are correct, there are many examples on there
that could have been done better. :)

Pete
Jul 20 '05 #30

P: n/a
In article Steve Pugh wrote:
"Steve Davis" <s.******@chello.nl> wrote:
Layout target is:

Top (banner): 100% width, 50px height.
Sidebar (a navigator): On the left, 150px width, height variable
Main (content): next to the sidebar, width rest of window, height variable
Bottom (info): 20px height, drops down to cope with long sidebar or main, or
sits at the bottom of the window if either are shorter then the window size.
Why, if you wanted the above, did you try to do it with position:
fixed? There's nothing about the above that requires fixed
positioning, is there?


Yes, And there is about nothing you can do using fixed positioning that
you can do with tables, and other way around.
Hardly rocket science is it?

http://steve.pugh.net/test/test62.html

Works just fine in IE5+ and Gecko based browsers. Positions the footer
just below the window bottom in Opera, which is very annoying but
could probably be worked around.


Opera correctly collapses margins, so you need to use bottom padding for
content. (99% of times when you have broken design on Opera or Mozilla
and can't find it, it is margin collapsing - in this case margin is
collapsed outside HTML element content area.)

Replace this line with
#content {margin-left: 150px; margin-bottom: 20px; height: auto;}
with
#content {margin-left: 150px; padding-bottom: 20px; height: auto;}

Not tested if it breaks on other browsers, but I think it is pretty
unlikely.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #31

P: n/a
Lauri Raittila <la***@raittila.cjb.net> wrote:
In article Steve Pugh wrote:
http://steve.pugh.net/test/test62.html

Works just fine in IE5+ and Gecko based browsers. Positions the footer
just below the window bottom in Opera, which is very annoying but
could probably be worked around.


Opera correctly collapses margins, so you need to use bottom padding for
content. (99% of times when you have broken design on Opera or Mozilla
and can't find it, it is margin collapsing - in this case margin is
collapsed outside HTML element content area.)

Replace this line with
#content {margin-left: 150px; margin-bottom: 20px; height: auto;}
with
#content {margin-left: 150px; padding-bottom: 20px; height: auto;}

Not tested if it breaks on other browsers, but I think it is pretty
unlikely.


Yep, I discovered that myself earlier today and was meaning to post an
update, but I seem to have a shortage of round tuits at the moment.

With that change it works fine in IE5+, Gecko and Opera 7.21. I don't
have older Operas installed for testing at the moment.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 20 '05 #32

P: n/a
On Tue, 11 Nov 2003, Steve Davis wrote:

[quoting me:]
Not really. Rigid, fragile design is a problem in any language.
Interesting that you seem to believe that an almost direct
copy/paste of the CSS-2 Spec counts as "fragile design".


CSS-2 addresses much more than just displaying on a typical desktop
screen. It considers also print media, handhelds, speech, TV etc.
etc. and makes no warranty that all of the possibilities that it
specifies are also useful and relevant for all of the media types
covered.

Plenty of the specific examples that are shown for syntax in
the spec are inappropriate for use "as such" in a general WWW
authoring context.

And to make matters worse, browser developers have made no effort to
follow the recommendations in regard to CSS px units, so, when px
units are displayed on a ~ 65dpi display they're more than double the
physical size that one gets on a display at ~ 135dpi or more. These
are by no means extreme values encountered in practice.

px units can be useful in some limited circumstances, but - at least
for the WWW context - they were not useful in the way that they had
been specified in the design that you presented; and that would be
true in any language.

The CSS specifications also show text being sized in pt units, and
width in centimetres, and so on, but I doubt if you're going to find
any informed opinion here who'd agree with using that in the general
WWW authoring context, either.

The examples, in other words, are provided in order to show how the
specification is meant to be interpreted; they aren't meant to be
taken verbatim as recommendations of good practice in a general WWW
authoring context. Some of them are excellent for print-specific
stylesheets, for example...
Show me where.
The px units were only a start of the problems with such an approach.
And HELLO, but real people use IE or Netscape.
Erm. There's really no point in going down _that_ road again, other
than to remark that, by mentioning these browsers specifically, you
seem to be implying that you don't believe they are capable of
browsing pages that have been designed for the WWW. Well, I'd agree
that NN4 is a real problem in a number of ways, but there are
workarounds for many of those problems, as long as there's any point
in still pandering to that old and broken thing. The Netscape folks
made a very remarkable and very perceptive move when they originally
set the Mozilla project going: I'd recommend that folks take advantage
of the fruits of that work. But I'm still going to make my content
available to as many different browsing situations as I can.
I very, very rarely see anything else
So why do you bother with (any version of) Netscape? You *know*
there's only One True Browser, and that it does what _you_ expect,
rather than what the specifications mandate. Simple, really.
on any site I have access logs to,
As you're evidently impervious to all the counter-arguments that
you've been able to read over the years, it hardly seems worth trying
to help your understanding on this issue again.

Incidentally, the two most important *individual* "browsers" recorded
in our departmental server log are Googlebot and WebVac.

But if one _summarises_ the browsers into rough categories, then a bit
over 50% of accesses are by clients claiming to be MSIE, while
Googlebot and WebVac are then at positions 2 and 3. Followed by
"Netscape Compatible", Mozilla, Scooter, and then Netscape.

See what one can achieve by selective grouping?

The rest (I mean, other than those I just named) still account for
over 5% of all accesses, amongst which, in the period under review,
analog claimed to have seen about 60 different other "browsers".
Some folks make a nice living selling stuff that's only bought by less
than 5% of the population, you know.
Truth is, I'd put $50 on the fact that you couldn't make it work
Quite right - as I already said, what you showed was too rigid and
fragile to *work*, in any language, in the general WWW context.
either, for all the huffin' and puffin' that's going on.


Truth is, I've been trying so hard _not_ to make rigid, fragile, web
pages that can only be successfully browsed on a standard desktop at
standard display settings in only two browsers, that you'd need to pay
much more than $50 for me to even consider *trying* to make such a
thing.

bye now, and you can cut out the personal emailing. If you've got
anything needing to be said, then say it in public.

ttfn
Jul 20 '05 #33

P: n/a
AD.
On Tue, 11 Nov 2003 23:03:13 +0000, jake wrote:
Steve, I assure you... it IS possible. If you want to see some great
examples, check out:
www.csszengarden.com
This site uses 1 very basic HTML file, and people submit CSS files which
display it very differently.


Not necessarily a good example as few of those designs produce a fluid
page, and in many cases don't produce resizable text.

Nice graphics, though ;-)


I'd still like to see a similar site/project promoting full CSS2 usage
that didn't have the IE 5.0 support requirement - or preferably no IE at
all :)

I have a feeling there'd be more scope for fluid designs without having to
support IE.

And while I'm dreaming, throw in some SVG ;)

Cheers
Anton
Jul 20 '05 #34

P: n/a

"Steve Pugh" <st***@pugh.net> wrote in message
news:4q********************************@4ax.com...
Lauri Raittila <la***@raittila.cjb.net> wrote:
In article Steve Pugh wrote:
http://steve.pugh.net/test/test62.html

Works just fine in IE5+ and Gecko based browsers. Positions the footer
just below the window bottom in Opera, which is very annoying but
could probably be worked around.


Opera correctly collapses margins, so you need to use bottom padding for
content. (99% of times when you have broken design on Opera or Mozilla
and can't find it, it is margin collapsing - in this case margin is
collapsed outside HTML element content area.)

Replace this line with
#content {margin-left: 150px; margin-bottom: 20px; height: auto;}
with
#content {margin-left: 150px; padding-bottom: 20px; height: auto;}

Not tested if it breaks on other browsers, but I think it is pretty
unlikely.


Yep, I discovered that myself earlier today and was meaning to post an
update, but I seem to have a shortage of round tuits at the moment.

With that change it works fine in IE5+, Gecko and Opera 7.21. I don't
have older Operas installed for testing at the moment.

I tries the padding-bottom but no success in Opera 7.11
I have noticed that the footer is in the correct position if you hit the
back button and then return to the page!
David
Jul 20 '05 #35

P: n/a

"David Graham" <da************@ntlworld.com> wrote in message
news:Jz*****************@newsfep2-win.server.ntli.net...

"Steve Pugh" <st***@pugh.net> wrote in message
news:4q********************************@4ax.com...
Lauri Raittila <la***@raittila.cjb.net> wrote:
In article Steve Pugh wrote:

> http://steve.pugh.net/test/test62.html
>
> Works just fine in IE5+ and Gecko based browsers. Positions the footer> just below the window bottom in Opera, which is very annoying but
> could probably be worked around.

Opera correctly collapses margins, so you need to use bottom padding forcontent. (99% of times when you have broken design on Opera or Mozilla
and can't find it, it is margin collapsing - in this case margin is
collapsed outside HTML element content area.)

Replace this line with
#content {margin-left: 150px; margin-bottom: 20px; height: auto;}
with
#content {margin-left: 150px; padding-bottom: 20px; height: auto;}

Not tested if it breaks on other browsers, but I think it is pretty
unlikely.


Yep, I discovered that myself earlier today and was meaning to post an
update, but I seem to have a shortage of round tuits at the moment.

With that change it works fine in IE5+, Gecko and Opera 7.21. I don't
have older Operas installed for testing at the moment.

I tries the padding-bottom but no success in Opera 7.11
I have noticed that the footer is in the correct position if you hit the
back button and then return to the page!
David

BTW - this has nothing to do with cache problems - it behaved like that
before the padding fix. I would like to know what the logic is behind this
'fix'. Surely, if margins are collapsing, wouldn't that result in the footer
moving up the viewport?
David
Jul 20 '05 #36

P: n/a
In article David Graham wrote:
I would like to know what the logic is behind this 'fix'. Surely, if
margins are collapsing, wouldn't that result in the footer moving up
the viewport?


Hm. No, I think.

HTML/BODY element is 100% height of viewport as specified. So as margins
collapse, it makes canvas bigger than 100% of viewport as margin is
added. So scrollbar is as spec says.

It is not specified how collapsed margins and absolute positioning
behave. As margin is actually margin of inner block, it makes some sence
to count bottom from point after it. I can't see any interpretation which
would make more sence.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #37

P: n/a

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.cis.dfn.de...
In article David Graham wrote:
I would like to know what the logic is behind this 'fix'. Surely, if
margins are collapsing, wouldn't that result in the footer moving up
the viewport?
Hm. No, I think.

HTML/BODY element is 100% height of viewport as specified. So as margins
collapse, it makes canvas bigger than 100% of viewport as margin is
added. So scrollbar is as spec says.


I think I don't understand how you are using the 'margins collapse' part of
your reply. I understand this to refer to the way in which the distance
between elements is calculated when they both have a margin set in the
vertical direction

example <p id="first">some text</p>
<p id="second">some more text</p>

and in the css

#first {margin-bottom: 10px; border: solid 2px red;}
#second {margin-top: 5px; border: solid 2px blue;}

There would be a gap of 10px between the two paragraphs and not 15px because
vertical margins collapse and not add - if my interpretation is correct,
then how does:

'So as margins collapse, it makes canvas bigger than 100% of viewport as
margin is added'
- support your answer.

It is not specified how collapsed margins and absolute positioning
behave. As margin is actually margin of inner block, it makes some sence
to count bottom from point after it. I can't see any interpretation which
would make more sence.


Sorry Lauri - I need a little more help with what you mean by this.

David
Jul 20 '05 #38

P: n/a

"David Graham" <da************@ntlworld.com> wrote in message
news:CE*******************@newsfep2-win.server.ntli.net...

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.cis.dfn.de...
In article David Graham wrote:
I would like to know what the logic is behind this 'fix'. Surely, if
margins are collapsing, wouldn't that result in the footer moving up
the viewport?
Hm. No, I think.

HTML/BODY element is 100% height of viewport as specified. So as margins
collapse, it makes canvas bigger than 100% of viewport as margin is
added. So scrollbar is as spec says.


I think I don't understand how you are using the 'margins collapse' part

of your reply. I understand this to refer to the way in which the distance
between elements is calculated when they both have a margin set in the
vertical direction

example <p id="first">some text</p>
<p id="second">some more text</p>

and in the css

#first {margin-bottom: 10px; border: solid 2px red;}
#second {margin-top: 5px; border: solid 2px blue;}

There would be a gap of 10px between the two paragraphs and not 15px because vertical margins collapse and not add - if my interpretation is correct,
then how does:

'So as margins collapse, it makes canvas bigger than 100% of viewport as
margin is added'

The link below is quite useful - it outlines bugs in Opera
http://nontroppo.org/wiki/Opera7CSSIssues

OT - There is an example that may be of interest relating to margins and
float
http://www.suziperry.utvinternet.ie/...rgin_issue.htm

David
Jul 20 '05 #39

P: n/a
In article David Graham wrote:

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.cis.dfn.de...
In article David Graham wrote:
I would like to know what the logic is behind this 'fix'. Surely, if
margins are collapsing, wouldn't that result in the footer moving up
the viewport?


Hm. No, I think.

HTML/BODY element is 100% height of viewport as specified. So as margins
collapse, it makes canvas bigger than 100% of viewport as margin is
added. So scrollbar is as spec says.


I think I don't understand how you are using the 'margins collapse' part of
your reply. I understand this to refer to the way in which the distance
between elements is calculated when they both have a margin set in the
vertical direction

example <p id="first">some text</p>
<p id="second">some more text</p>

and in the css

#first {margin-bottom: 10px; border: solid 2px red;}
#second {margin-top: 5px; border: solid 2px blue;}

There would be a gap of 10px between the two paragraphs and not 15px because
vertical margins collapse and not add - if my interpretation is correct,
then how does:

'So as margins collapse, it makes canvas bigger than 100% of viewport as
margin is added'


p {margin-bottom:2em;}
html {margin-bottom:1em}
body {margin-bottoma:1.5em;}

<html><body><p></p></body><html>

All vertical margins of those elements collapse (so there will be one
margin of 2em under them). Margins collapse not only on sibling elements
but child and parent elements also, if there is no padding or border. See
spec for example. And since content height of elements is specified
(100%) and margin goes outside it, result is bigger than 100%.
It is not specified how collapsed margins and absolute positioning
behave. As margin is actually margin of inner block, it makes some sence
to count bottom from point after it. I can't see any interpretation which
would make more sence.


Well, it is not said how things should be positioned, when margins of
parent and child element is collapsed. At least I haven't seen anything.
There is two choises: 1. use content edge of child. 2. use box edge of
parent.

1. might be more correct way. So browsers seem to have bug here. IE and
Moz don't collapse margins correctly, or ignore margin on bottom of
outmost element, Opera positions footer in wrong place, as margin
propably shouldn't be positioned by 2. even if it does make more sence.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.

Jul 20 '05 #40

P: n/a

"Lauri Raittila" <la***@raittila.cjb.net> wrote in message
news:MP************************@news.cis.dfn.de...
In article David Graham wrote:


'So as margins collapse, it makes canvas bigger than 100% of viewport as
margin is added'
p {margin-bottom:2em;}
html {margin-bottom:1em}
body {margin-bottoma:1.5em;}

<html><body><p></p></body><html>

All vertical margins of those elements collapse (so there will be one
margin of 2em under them). Margins collapse not only on sibling elements
but child and parent elements also, if there is no padding or border.


Thanks - I did think collapsing margins only occurred between adjacent
siblings. Your last bit of the sentence above 'if there is no padding or
border' does that really negate what you have just stated - I will take your
advice and see what the spec has to say on this.
See spec for example. And since content height of elements is specified
(100%) and margin goes outside it, result is bigger than 100%.
It is not specified how collapsed margins and absolute positioning
behave. As margin is actually margin of inner block, it makes some sence to count bottom from point after it. I can't see any interpretation which would make more sence.

Well, it is not said how things should be positioned, when margins of
parent and child element is collapsed. At least I haven't seen anything.
There is two choises: 1. use content edge of child. 2. use box edge of
parent.


By 'box edge' do you mean the edge running around the perimeter of the
parent margin or the parent border. In other words, is a box defined by the
outer edge of the border or the outer edge of the margin. I have consulted
the spec many times on this but it never seems to make it very clear which
it is.
1. might be more correct way. So browsers seem to have bug here. IE and
Moz don't collapse margins correctly, or ignore margin on bottom of
outmost element, Opera positions footer in wrong place, as margin
propably shouldn't be positioned by 2. even if it does make more sence.

Thanks, I think I understand what you are stating here. To be certain that I
understand, I will rephrase in my own words:

"Opera is positioning the footer so that the footers left bottom corner
coincides with the left bottom corner of the page, which is a point lying
outside of the viewport because of the height 100% on the html element and
the collapsed bottom margin which renders itself on the parent element -
which in this case happens to be the root element i.e. html element"

David
Jul 20 '05 #41

This discussion thread is closed

Replies have been disabled for this discussion.