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

Faux Absolute Positioning

P: n/a
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)

I've came across this CSS layout technique:
http://alistapart.com/articles/fauxabsolutepositioning

It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.

This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.

Some people though, have presented an Argument Against Faux Absolute
Positioning:
http://www.cssnewbie.com/argument-ag...e-positioning/

I'd like to have your valuable opinion.
Many Thanks.

Sep 14 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
"Fistro" <ra******@gmail.comwrote in message
news:d4**********************************@m44g2000 hsc.googlegroups.com...
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)

I've came across this CSS layout technique:
http://alistapart.com/articles/fauxabsolutepositioning

It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.

This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.

Some people though, have presented an Argument Against Faux Absolute
Positioning:
http://www.cssnewbie.com/argument-ag...e-positioning/
His argument is essentially that it bloats the markup.

He makes a good point but his approach is not pragmatic for anything but
fairly simple layouts.

At this point in time given current browser support for CSS (particularly
from you-know-who) it is impossible to make any graphically rich layout that
doesn't need extra "hooks" in the form of wrapper divs, extra ids and
classes etc.

The problem is that if you don't know exactly what you're doing you are
going to end up with a *lot* of hooks. The aim should be to minimize the
number you use rather than eliminate them entirely, which is sadly not
possible at this point.

Sep 15 '08 #2

P: n/a
In article <ga**********@registered.motzarella.org>,
"Nik Coughlin" <nr******@gmail.comwrote:
"Fistro" <ra******@gmail.comwrote in message
news:d4**********************************@m44g2000 hsc.googlegroups.com...
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)

I've came across this CSS layout technique:
http://alistapart.com/articles/fauxabsolutepositioning

It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.

This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.

Some people though, have presented an Argument Against Faux Absolute
Positioning:
http://www.cssnewbie.com/argument-ag...e-positioning/

His argument is essentially that it bloats the markup.

He makes a good point but his approach is not pragmatic for anything but
fairly simple layouts.

At this point in time given current browser support for CSS (particularly
from you-know-who) it is impossible to make any graphically rich layout that
doesn't need extra "hooks" in the form of wrapper divs, extra ids and
classes etc.

The problem is that if you don't know exactly what you're doing you are
going to end up with a *lot* of hooks. The aim should be to minimize the
number you use rather than eliminate them entirely, which is sadly not
possible at this point.
All good points. But I like the idea that if you are having to go to so
much trouble, maybe you are wanting unnecessarily rich graphical
layouts. There is a real issue here. Given that you want such things, I
agree with your points. But I rather think there is too much graphic
richness altogether in this world and I doubt if it is all that
appreciated beyond very superficially in websites.

--
dorayme
Sep 15 '08 #3

P: n/a
"dorayme" <do************@optusnet.com.auwrote in message
news:do**********************************@web.aioe .org...
>
All good points. But I like the idea that if you are having to go to so
much trouble, maybe you are wanting unnecessarily rich graphical
layouts. There is a real issue here. Given that you want such things, I
agree with your points. But I rather think there is too much graphic
richness altogether in this world and I doubt if it is all that
appreciated beyond very superficially in websites.
Yes.... but... a requirement for what I do. Spent any time around graphic
designers or marketing people? :)

I can just see myself trying to tell them that I think that their pretty
design is unnecessarily rich because it would require a few extra divs in
the markup, hence offending my sense of markup purism and that I therefore
won't do it, even though I know how to. Bye bye client, bye bye job!

With tongue now out of cheek, good graphic design done well can add a lot to
the user experience, and sometimes what appears to superficially be a clean,
simple graphical design can easily fall under the category of "graphically
rich" when it comes to marking it up as HTML/CSS

Sep 15 '08 #4

P: n/a
In article <ga**********@registered.motzarella.org>,
"Nik Coughlin" <nr******@gmail.comwrote:
"dorayme" <do************@optusnet.com.auwrote in message
news:do**********************************@web.aioe .org...

All good points. But I like the idea that if you are having to go to so
much trouble, maybe you are wanting unnecessarily rich graphical
layouts. There is a real issue here. Given that you want such things, I
agree with your points. But I rather think there is too much graphic
richness altogether in this world and I doubt if it is all that
appreciated beyond very superficially in websites.

Yes.... but... a requirement for what I do. Spent any time around graphic
designers or marketing people? :)

I can just see myself trying to tell them that I think that their pretty
design is unnecessarily rich because it would require a few extra divs in
the markup, hence offending my sense of markup purism and that I therefore
won't do it, even though I know how to. Bye bye client, bye bye job!
No, of course.... a buck is a buck.
With tongue now out of cheek, good graphic design done well can add a lot to
the user experience, and sometimes what appears to superficially be a clean,
simple graphical design can easily fall under the category of "graphically
rich" when it comes to marking it up as HTML/CSS
True words indeed. I sometimes worry that what I end up doing for a
client looks too simple and he will wonder why it took so damn long or
cost so much. It never starts simple, I tell them, I work hard to get it
down to this. Now pay up. <g>

There is a serious issue in all of this stuff, about whether the world
would be a much better place if humans stopped wanting to cheer
themselves up with - to put it politely - more beauty than function
requires. I believe it would.

--
dorayme
Sep 15 '08 #5

P: n/a
On 2008-09-14, Fistro <ra******@gmail.comwrote:
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)

I've came across this CSS layout technique:
http://alistapart.com/articles/fauxabsolutepositioning

It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.

This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.

Some people though, have presented an Argument Against Faux Absolute
Positioning:
http://www.cssnewbie.com/argument-ag...e-positioning/

I'd like to have your valuable opinion.
Top marks for ingenuity.

One problem is that each "item" has to have a width smaller than its
margin-left, or the margins no longer work as offsets from the right
edge.

Here's a test page: http://www.tidraso.co.uk/misc/faux.html

Try putting display: none back on #item1 (it's commented out) and you
will see #item2 moves.

This is because #item1 has a positive outer margin width, which moves
#item2 "real" position right a bit, so it can fit to the right of
#item1. It's moved back a constant amount from there with the negative
margin-left, so it stays too far right.

Too many items with positive outer margin widths, and the floats will
start to wrap eventually and then things will look really weird.

So the first problem is that each item has to have a negative or zero
outer margin width.

This brings me to the second problem: he's relying on browsers treating
negative outer margin widths on floats as zero, but that isn't specified
in CSS 2.1 (or not that I can find) so it's just lucky it works. It
might not work in all browsers, and a new browser could legitimately do
it differently.

So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique.
Sep 15 '08 #6

P: n/a
On Sep 15, 11:05*am, Ben C <spams...@spam.eggswrote:
On 2008-09-14, Fistro <rafam...@gmail.comwrote:
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)
I've came across this CSS layout technique:
http://alistapart.com/articles/fauxabsolutepositioning
It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.
This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.
Some people though, have presented an Argument Against Faux Absolute
Positioning:
http://www.cssnewbie.com/argument-ag...e-positioning/
I'd like to have your valuable opinion.

Top marks for ingenuity.

One problem is that each "item" has to have a width smaller than its
margin-left, or the margins no longer work as offsets from the right
edge.

Here's a test page:http://www.tidraso.co.uk/misc/faux.html

Try putting display: none back on #item1 (it's commented out) and you
will see #item2 moves.

This is because #item1 has a positive outer margin width, which moves
#item2 "real" position right a bit, so it can fit to the right of
#item1. It's moved back a constant amount from there with the negative
margin-left, so it stays too far right.

Too many items with positive outer margin widths, and the floats will
start to wrap eventually and then things will look really weird.

So the first problem is that each item has to have a negative or zero
outer margin width.

This brings me to the second problem: he's relying on browsers treating
negative outer margin widths on floats as zero, but that isn't specified
in CSS 2.1 (or not that I can find) so it's just lucky it works. It
might not work in all browsers, and a new browser could legitimately do
it differently.

So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique.
That was my main fear, that the layout could break apart with new
browsers.
But since it works well even in Quirks mode, I can safely assume that
it will "upgrade" just fine?
Sep 15 '08 #7

P: n/a
On 2008-09-15, Fistro <ra******@gmail.comwrote:
On Sep 15, 11:05*am, Ben C <spams...@spam.eggswrote:
[...]
>So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique.

That was my main fear, that the layout could break apart with new
browsers.
But since it works well even in Quirks mode, I can safely assume that
it will "upgrade" just fine?
Working in quirks mode is no indication of future-proofness.

The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.

That way if it doesn't work, you know it's a browser bug, can make a bug
report, and most browser makers will go and fix it. There's also a
better chance it will work in arbitrary browsers in the first place.
Sep 15 '08 #8

P: n/a
On Sep 15, 1:50*pm, Ben C <spams...@spam.eggswrote:
On 2008-09-15, Fistro <rafam...@gmail.comwrote:
On Sep 15, 11:05*am, Ben C <spams...@spam.eggswrote:
[...]
So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique.
That was my main fear, that the layout could break apart with new
browsers.
But since it works well even in Quirks mode, I can safely assume that
it will "upgrade" just fine?

Working in quirks mode is no indication of future-proofness.
Here's someone that would surely disagree:
"My mostly mode-independent and progressive design methods with IE6 in
Quirks mode, seems to hit right with future development of IE/win. IE/
win will handle my creations more or less identical in all modes
anyway.
I can keep on designing this way well into the future, and be able to
take advantage of whatever standard-support improvement they manage to
get into those future IE-versions."
http://www.gunlaug.no/contents/wd_additions_16.html
The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.
w3 specs, you mean?
That way if it doesn't work, you know it's a browser bug, can make a bug
report, and most browser makers will go and fix it. There's also a
better chance it will work in arbitrary browsers in the first place.
You are probably right, most browser makers will go and fix it.
Problem is that the most popular "browser maker" would most likely
blissfully ignore it.

Sep 15 '08 #9

P: n/a
On 2008-09-15, Fistro <ra******@gmail.comwrote:
On Sep 15, 1:50*pm, Ben C <spams...@spam.eggswrote:
>On 2008-09-15, Fistro <rafam...@gmail.comwrote:
On Sep 15, 11:05*am, Ben C <spams...@spam.eggswrote:
[...]
>So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique.
That was my main fear, that the layout could break apart with new
browsers.
But since it works well even in Quirks mode, I can safely assume that
it will "upgrade" just fine?

Working in quirks mode is no indication of future-proofness.
Here's someone that would surely disagree:
"My mostly mode-independent and progressive design methods with IE6 in
Quirks mode, seems to hit right with future development of IE/win. IE/
win will handle my creations more or less identical in all modes
anyway.
I can keep on designing this way well into the future, and be able to
take advantage of whatever standard-support improvement they manage to
get into those future IE-versions."
http://www.gunlaug.no/contents/wd_additions_16.html
There is an argument that while they might try to fix their broken
standards-mode they're more likely to leave their quirks mode alone
(since it's supposed to be broken, and is therefore correct in the
Albert Wiersch sense of the word).

But targetting IE's quirks mode is a reasonably good way to make sure
that things won't work properly in future browsers.
>The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.
w3 specs, you mean?
Yes.
Sep 15 '08 #10

P: n/a
On Sep 15, 2:49*pm, Ben C <spams...@spam.eggswrote:
On 2008-09-15, Fistro <rafam...@gmail.comwrote:
On Sep 15, 1:50*pm, Ben C <spams...@spam.eggswrote:
On 2008-09-15, Fistro <rafam...@gmail.comwrote:
On Sep 15, 11:05*am, Ben C <spams...@spam.eggswrote:
[...]
So while it's good if you can test something and show it works in the
current generation of main browsers, it's much better if you can also
show that you're relying only on behaviour that's clearly defined by the
specification. I'm not convinced you can do that for this technique..
That was my main fear, that the layout could break apart with new
browsers.
But since it works well even in Quirks mode, I can safely assume that
it will "upgrade" just fine?
Working in quirks mode is no indication of future-proofness.
Here's someone that would surely disagree:
"My mostly mode-independent and progressive design methods with IE6 in
Quirks mode, seems to hit right with future development of IE/win. IE/
win will handle my creations more or less identical in all modes
anyway.
I can keep on designing this way well into the future, and be able to
take advantage of whatever standard-support improvement they manage to
get into those future IE-versions."
http://www.gunlaug.no/contents/wd_additions_16.html

There is an argument that while they might try to fix their broken
standards-mode they're more likely to leave their quirks mode alone
(since it's supposed to be broken, and is therefore correct in the
Albert Wiersch sense of the word).

But targetting IE's quirks mode is a reasonably good way to make sure
that things won't work properly in future browsers.
The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.
w3 specs, you mean?

Yes.
Can the CSS float model be considered as a black-and-white w3 spec?
Sep 15 '08 #11

P: n/a
On 2008-09-15, Fistro <ra******@gmail.comwrote:
On Sep 15, 2:49*pm, Ben C <spams...@spam.eggswrote:
[...]
>The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.
w3 specs, you mean?

Yes.

Can the CSS float model be considered as a black-and-white w3 spec?
It's pretty good. But if you read it, quite a lot of it is written in
terms of the "outer margin boxes" of floats.

What's not so black and white is where the left and right edges of the
outer margin box are for a float with a negative margin larger than its
width.

You could say, well it has a negative width ergo its left edge is
actually on the right (not what most browsers do).

Or you could say, this is silly, just treat its width as zero (basically
what most browsers do do).

But it's not wise to rely on that.

The spec is a little bit unhelpful on this. If you set a negative width
explicitly on something, that's illegal, so gets ignored altogether.
Fine, but if you follow the other rules in the spec, you can quite
easily end up with a "used" negative width, and there's no guidance on
what you're supposed to do with that.

So safer to avoid setting things that result in used negative widths.
But the faux-absolute-positioning layout _relies_ on used negative
widths and on the way browsers treat them.
Sep 15 '08 #12

P: n/a
On Sep 15, 3:16*pm, Ben C <spams...@spam.eggswrote:
On 2008-09-15, Fistro <rafam...@gmail.comwrote:
On Sep 15, 2:49*pm, Ben C <spams...@spam.eggswrote:
[...]
The point is, for maximum robustness only rely on things that are
absolutely black-and-white in the spec.
w3 specs, you mean?
Yes.
Can the CSS float model be considered as a black-and-white w3 spec?

It's pretty good. But if you read it, quite a lot of it is written in
terms of the "outer margin boxes" of floats.

What's not so black and white is where the left and right edges of the
outer margin box are for a float with a negative margin larger than its
width.

You could say, well it has a negative width ergo its left edge is
actually on the right (not what most browsers do).

Or you could say, this is silly, just treat its width as zero (basically
what most browsers do do).

But it's not wise to rely on that.

The spec is a little bit unhelpful on this. If you set a negative width
explicitly on something, that's illegal, so gets ignored altogether.
Fine, but if you follow the other rules in the spec, you can quite
easily end up with a "used" negative width, and there's no guidance on
what you're supposed to do with that.

So safer to avoid setting things that result in used negative widths.
But the faux-absolute-positioning layout _relies_ on used negative
widths and on the way browsers treat them.
Now, that's a real argument.
Thank you.
Sep 15 '08 #13

P: n/a
Faux Absolute Positioning
On 15 Sep, 01:08, Fistro <rafam...@gmail.comwrote:
I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)
I've came across this CSS layout technique:http://alistapart.com/articles/fauxabsolutepositioning
First of all. This is certainly not how CSS is supposed to work.
Ben C, is making some points about that.

I my opinion, emulating tables with css is almost as bad as tables
themselves. They are imposing the same problems that we are trying
to avoid. Uh, oh, but tables isn't semantic correct. Well, that has
more to do about feelings than anything else. Ten years ago, some
browsers
had problem to make a difference between tables for layout and tables
for 'tablular data'. Sorry to say, to day, all browsers handles that.

The semantic meaning of tables isn't 'tabular data'. The phrase
'tabluar
data' isn't mention in the recommendations at all. Uh, oh, but is
should.
Well, if you can't trust the vendors of browsers, who can you trust.

It's recommended that we start to use positioning, instead of tables
when that is supported by major browsers. That hasn't happened.
It calculates the left offset from a fixed position, as opposed to
calculating it from the right edge of the preceding element by using a
combination of position: relative, left: 100% and a negative margin-
left.

This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.
The hole style sheet is one big Internet Explorer hack. Safari, Opera,
Firefox
and all other modern browsers supports CSS tables.
http://www.w3.org/TR/CSS21/tables.html#table-display
Some people though, have presented an Argument Against Faux Absolute
Positioning:http://www.cssnewbie.com/argument-ag...e-positioning/

I'd like to have your valuable opinion.
Use em instead of pixels. It works. Get rid of 'overflow: hidden' and

..column { /* all columns have continous background color */
margin-bottom: -5000px;
padding-bottom: 5000px;
}

You have at least four elements that you can use to emulate that
behavior
with background images/colors: html, body, #canvas, #main.

Include the whole style sheet in an conditional comment
<!--[if IE]><link rel="stylesheet" type="text/css"
href="ie6_7_hack.css"><![endif]-->

And use CSS tables for all other browsers.

Comment out unnecessary divs:

<!--[if IE]><div id="canvas"><![endif]-->
<div class="line">
<div class="item" id="item1">
<!--[if IE]><div class="sap-content">content here</div><![endif]-->
</div>
</div>
<!--[if IE]></div><![endif]-->

And use CSS tables for any other browsers:

..line { display: table-row }
..item { display: table-cell }

You could also change the class names to something more meaningful.

canvas -table
line -tr
item -td
sap-content -inner-wrapper

i.e.:

<div id="table">
<div class="tr">
<div class="td" id="left">
<div class="inner-wrapper">content here</div>
</div>
</div>
</div>
Sep 16 '08 #14

P: n/a
On 2008-09-16, Roy A. <ro*********@gmail.comwrote:
Faux Absolute Positioning
On 15 Sep, 01:08, Fistro <rafam...@gmail.comwrote:
>I'm trying to find a design that would allow me to build web pages
without having to worry about compatibility issues (not too much, in
any case,,,)
>I've came across this CSS layout technique:http://alistapart.com/articles/fauxabsolutepositioning

First of all. This is certainly not how CSS is supposed to work.
Ben C, is making some points about that.

I my opinion, emulating tables with css is almost as bad as tables
themselves. They are imposing the same problems that we are trying
to avoid. Uh, oh, but tables isn't semantic correct.
As you say, there has been a solution to that for years: display:
table-cell etc. Semantically whatever you want but looks like a table
so everyone's happy. But IE doesn't support it...

The other factor is that people got so used to layouts that looked like
nested tables they still think like that. I see quite a few big sites
that used to be done with nested tables, and looked like nested tables,
that now look the same but are done with unbelievably maniacal CSS
instead.

You have to be careful what you wish for because you might get it.

[...]
>This approach requires no hacks and it works with all modern browsers
(Safari, Opera, Firefox, IE7) as well as IE6 and even IE5.5/Win, which
is more than I had ever hoped for.

The hole style sheet is one big Internet Explorer hack. Safari, Opera,
Firefox and all other modern browsers supports CSS tables.
http://www.w3.org/TR/CSS21/tables.html#table-display
In principle I agree but the layout they're achieving here isn't quite
like tables, it's more like absolute positioning.

The basic idea is to be able to give each "cell" an absolute offset from
the left of the "row" it's in, with no wrapping or stretching and even
if it makes things overlap.

Tables don't generally do that, although you might be able to get
something similar with table-layout: fixed.
Sep 16 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.