Re: [CSS21] Contradiction in the spec with auto-offset fixed-position elements

Sorry, gentlemen, for interrupting you....
but I have a question:
What for is this fixed positioning at all?

Combination of elements in normal flow and scrollable areas whould be far 
enough, no?
I think it is better to design really simple vertical aligning/positioning 
for elements
in normal flow than to darn design by the fixed.

I would like to remind again %% units I propsed before:

So using them this:

<root>
<node style="position: fixed">Fixed</node>
Lots
of
content
on
many
lines.
</root>

willl be just:

<root style="height: 100%" >
<node style="height: XXpx">Fixed</node>
<scrollable style="height:100%%; overflow:auto">
  Lots
  of
  content
  on
  many
  lines.
</scrollable>
</root>

Easy and natural - read - could be implemented reliably.
This fixed positioning creates more questions than answers as far as I can 
see.
The law: bad design - bad implementations.

Andrew Fedoniouk.
http://terrainformatica.com


|
| Ian Hickson wrote:
|
| > Maybe we should change it to "For the purposes of calculating the static
| > position, the containing block of fixed positioned elements is the 
initial
| > containing block instead of the viewport, and all scrollable boxes
| > should be assumed to be scrolled to their origin." or some such?
|
| I think that would be reasonably unambiguous, but then I have a followup
| question.  Do actual implementations behave this way?  Mozilla up
| through a few days ago may, but I'm not even sure about that...
|
| That is, is there a reason for specifying a complicated algorithm here,
| just enough different from the absolute positioning one that you
| probably have to implement them separately, instead of specifying
| something simple?  If there are existing implementations that behave in
| this way and pages depending on it, I suppose that could be considered
| such a reason... are there?
|
| -Boris
|
|

Received on Sunday, 7 November 2004 06:22:00 UTC