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

About "external" scrollbars.

See:
The viewport is using  background attributes of <body> element to fill its 
background.
It would be natural if viewport's scrollbars also will reflect  body scroll 
position.

<root>
  <header1>...</header1>
  <header2>...</header2>
  <body overflow=auto width=100%% height=100%%>
     ... body content....
  </body>
  <footer1>...</footer1>
  <footer2>...</footer2>
</root>

Let's <body> be a real body - body of the page - its content.

I think that having stuff in natural flow is always better then to use any 
kind of absolute positioning.

For example:
for page like http://www.w3.org/Style/CSS/ I don't know how to define 
cliping area properly.
I mean that  right margin of body (content) clipping area should follow 
width of right side bar.
Otherwise you will always get this 
http://terrainformatica.com/w3/ff-css-main.png
And no one designer could solve this - this a direct consequence of 'fixed' 
design flaw.

| > And yet this will easy solve other fundamental problem with scrollbars 
in
| > HTML.
|
| Which is what?

As you know straightforward implementation of overflow:auto when size of 
content
is close to the size of viewport is potentially oscillating function. And 
could not be implemented
without use of heuristics limiting the number of oscillations. (Size of 
viewport is changing when scrollbars appear). If you will move scrollbars 
out of the viewport calculation become stable two step process.

And no one UA handles this 'properly'  as there are no solution at all in 
the given model.

E.g. here is the document http://www.terrainformatica.com/w3/overflow.htm
and here is a screenshot in FireFox 
http://www.terrainformatica.com/w3/overflow-ff.gif
As you may see scrollbars are gone but they should be there. "Heuristics" in 
effect.

IE handles this particular situation better but it has problems with 
overflow:auto in different
places.

And what does Opera in such situations I do not understand - too complex and 
unpredictable behavior.

Again, these are not bugs of implementations - it is just pure mathematical 
problem - no solution in theory.

| Note that the desiderata here are to (1) preserve compatibility with
| existing content and UAs as much as possible and (2) allow making things
| "pinned" when one scrolls without changing the content model.
| The problem with any proposal that just puts things in flow is that it
| forces changes to the content model when different styling is desired...

In fact this 'fixed' does change the content model dramaticly.

I cannot see any problems with:

<root>
  <body>
      <header1>...</header1>

      <real-body overflow=auto-external>

          ... real content of the page ....

      </real-body>

      <footer2>...</footer2>
  </body>
</root>

It does not break any existing rules.

Again, 'fixed' as propsed is not a solution even for toolbars, sidebars, 
etc.:

<header1  position=fixed top=0px height=40px />
<header2  position=fixed top=20px height=40px />
<content>
.....
</content>

What is top bound of the <content> scrollable area supposed to be?

Andrew Fedoniouk.
http://terrainformatica.com






Original Message from: "Boris Zbarsky":
| Andrew Fedoniouk wrote:
| > OK. Let's take a look from other prospective on this page:
| >
| > Formally speaking this page just has scrollbars detached from scrollable
| > area.
|
| One could think of it this way, yes...
|
| > Lets think that scrollbars of the view are just "observers" of the state 
of
| > ***any*** scrollable area (overflow:auto) in the document. Wouldn't it 
be
| > better?
|
| Then how do I have different scroll positions for different overflowing
| things?  Or am I misunderstanding your proposal?
|
| > And yet this will easy solve other fundamental problem with scrollbars 
in
| > HTML.
|
| Which is what?
|
| > With the fixed and other artificial positionings you will never
| > stop fighting with problems like this:
| > http://terrainformatica.com/w3/ff-css-main.png
|
| It's not clear to me why that shows anything but an authoring error in
| the page...
|
| Note that the desiderata here are to (1) preserve compatibility with
| existing content and UAs as much as possible and (2) allow making things
| "pinned" when one scrolls without changing the content model.
|
| The problem with any proposal that just puts things in flow is that it
| forces changes to the content model when different styling is desired...
|
| -Boris
|

Received on Tuesday, 9 November 2004 20:26:31 UTC