Re: css3 absolute positioning and containing blocks question/suggestion

Hello again.

I can see, after reading the indicated thread, that this particular
topic is a large can of worms that trails into other cans of worms,
but I'll take the plunge anyway, hoping this doesn't take too much
time away from more important projects (like finishing the web design
that prompted my writing). I think different ideas are good for
different facets, and some ideas seem not to be implemented despite
the power they afford the [user/author/user-agent] (choose the one
that applies). So I'll take a quick stab at explanation.
(NOTE: I'm not trying to bash your, nor anyone else's, idea(s) just
explain what I perceive as possible problems. If you see any possible
problems with my idea please elaborate as well, if not for me, then
for the WG in hopes that a good solution can be reached...):

move-to
*Designed for things like footnotes, possible uses include layout
   AUTHOR: Not the most powerful, but allows some manipulation of
presentation dependent on semantics of the information (the structure
of the data). Is most useful when used in connection with inline
footnotes where a simple 'move-to' the end of the document makes a
whole lot more sense than, absolute positioning or creating a parent
container around it that they would then have to implement. I think
this is really designed with layout as more of an afterthought, a
possible use, not the intended use.
   USER-AGENT: Fairly easy to implement. Just don't display the
element during progressive rendering, until it meets one of the
clearly defined rules for display. Adopting this will be very
beneficial in displaying things like e-books, and a lot of
hyper-information (whether online or off). (e.g. think of the help for
programs. That's HTML generally and those user-agents will want to
make it easier to store their own help files, so this is very likely
to be widely implemented I believe.)

absolute-containing-block
*designed for easy implementation and fairly easy use
   AUTHOR: Still, not the most powerful, but allows control over
display, without dependance on semantics, as it is taken out of flow.
Easier to work with than move-to, witht the restriction that this
applies only for absolutely positioned elements
   USER-AGENT: Again, Fairly easy to implement. Not displayed until
the containing block is shown, then can be positioned on top without
causing a reflow. Also, when the element is after the containing
block, you can just put it on top (higher z-index, unless explicitly
defined by a style sheet), no reflow. Easy for progressive rendering.
not as likely to be implemented as the move-to, but still fairly easy,
so I think fairly likely to be widely implemented.)

pseudo parent containers
*designed for better author control
   AUTHOR: Ultimate control. Easy to use, though a different syntax
will confuse some, to many, developers. Allows for fine-grained
control that many crave.
   USER-AGENT: Progressive Rendering suddenly becomes a bit harder,
creating blocks could cause re-flow, though you went over how a
browser could deal with this, so I won't go there. Also, will cause
some slow down in rendering (albeit most-likely un-noticeable) because
the browser will have to parse for the 'exception' to the syntax
rules. In the CSS3 syntax, the user-agent is supposed to parse all
rules, even those they don't understand, ignoring the ones that it
doesn't understand, however when you change the rules for parsing, we
might run up against backward-incompatibility because older browser
will choke on a different syntax, thus the CSS, by shear nature of the
goals of its design, must degrade gracefully (to an extent) throwing
this in could cause significant problems. (I say could because I don't
know for sure) it sounds risky/problematic to me, so I'm sure the WG
is also concerned. They might have other reasons as well. As the WG is
so skeptical about implementation, they probably won't include this as
they don't like to go back to candidate recommendation all the time,
they want to be able to provide solid 'recommendations'

I decided not to look at the USER perspective, because I'd probably
end up saying the same thing for all of them, "possibly useful in an
accessibility sense" and then echoing some of the author section.

Does anyone else have links to the things they've suggested as better
ways to achieve layout in CSS (yes I know about style vs layout and I
said that on purpose).

Slight disclaimer: None of the statistical statements made are based
on anything but a guess, they are hypothesis not based on any
expirament, but on some observation, so no conclusion can accurately
be drawn from it according to the laws of statistics. Again, they are
just statements of opinion.

On 9/21/05, Emrah BASKAYA <emrahbaskaya@hesido.com> wrote:
> I had earlier suggested using pseudo parent containers to move and group
> objets to place anywhere in layout:
> http://lists.w3.org/Archives/Public/www-style/2005Apr/0058.html .
>
> Move-to is *at best* a half-hearted attempt to moving things around, and I
> don't know how it could be useful without total freedom. But there you
> have it in css3, it is obvious it somehow got the liking of the working
> group, which still amazes me.
>

Received on Thursday, 22 September 2005 04:13:23 UTC