Re: What 'Advanced Layout' suggestions have been proposed?

I really like the pseudo-containers idea, this is something that I
have been doing with JS for a little while.

What bugs me about it is that the rule-driven syntax just doesn't seem
right with this type of structs. Also, how would one go about defining
conditional reodering, i.e. changing the way content is
pseudo-structured based on momental presentational qualities (current
min width of content, etc.)?

:DG<


On 9/27/05, Jacob Floyd <techgurufloyd@gmail.com> wrote:
>
> It seems that a lot of people have suggested a lot of different ways
> to do 'advanced layout' or at least, features that might end up in
> CSS3 advanced layout module. It seems like a royal pain for the WG to
> have to keep track of every suggestion, so let's make a list for them,
> then they can evaluate them (hopefully) and choose what they think
> is/are the best solution(s) and/or CSS improvements for advanced
> layout.
>
> Please offer other suggested solutions, other wordings for the current
> solutions, and references to the original location of the suggestion.
>
> Here's what I have so far (perspectives in regard to layout):
>
> =====
> WHAT: move-to
> TYPE: property
> REFERENCE: ? - Currently in the 'Generated Content' Module
> DESIGN NOTE(S): Designed for footnotes. It'll probably be used for
> layout as well, though that's not the purpose (kind of like floats,
> not the purpose, but a use).
> AUTHOR PERSPECTIVE: 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 of sense.
> USER-AGENT PERSPECTIVE: 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.)
>
> =====
> WHAT: Parent pseudo-containers
> TYPE: Syntax addition
> REFERENCE: http://lists.w3.org/Archives/Public/www-style/2005Apr/0058.html
> DESIGN NOTE(S): Designed for better (awesome) author control
> AUTHOR PERSPECTIVE: Ultimate control. Easy to use, though a different
> syntax will confuse some, or many, developers. Allows for fine-grained
> control that many crave.
> USER-AGENT PERSPECTIVE: Progressive Rendering is harder to implement
> (see REFERENCE for description of how it works)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)
>
> =====
> WHAT: absolute-containing-block
> TYPE: property
> REFERENCE:http://lists.w3.org/Archives/Public/www-style/2005Sep/0189.html
> DESIGN NOTE(S): Designed with fairly easy implementation and use in mind
> AUTHOR PERSPECTIVE: 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, with the restriction that this
> applies only for absolutely positioned elements.
> USER-AGENT PERSPECTIVE: 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.)
>
>

Received on Monday, 3 October 2005 13:44:31 UTC