W3C home > Mailing lists > Public > www-style@w3.org > June 2004

Re: CSS3 and better support for table free designs

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 27 Jun 2004 10:33:47 -0700
Message-ID: <001901c45c6c$eb3d1a10$0201a8c0@ATHLON>
To: "Dave Hyatt" <hyatt@apple.com>
Cc: <www-style@w3.org>

Hi, Dave,

> I agree CSS3 needs a spring and strut layout system
I agree with your "agree" too. (recursion agree :)

May I ask you question?
What is this "dialog intrinsic width"? Is it its initial viewport size?
If yes then it shouldn't be in the scope of CSS.
And "dialog intrinsic width" is not an intrinsic width actualy but rather
"predefined width"  or "desired width". As far as I understand it.
Flexibility of the window itself (dialog) should be defined somewhere else
but not in CSS - something like window.resize:on/off.

And more, compound elements (e.g. paragraphs but not images) have at least
two intrinsic widths:
p.min-width: min-intrinsic - its content will never overflow.
p.min-width: max-intrinsic -  its content will never wrap.
Dialogs are also such compound elements, am I right?

In my case width: X%% means that element has a) flexible width and b) its
min-width and/or max-width define constraints.

Flex constraints are also in effect when margins collapse:

<p margin-bottom:25%%>..
<p margin-top:10px>...

Also produce 'flex' value with constraints :  flex = { v: 25%%,  minv: 10px,
maxv: any }

> flexing springs before and after the margin box

This probably will work in some cases as you are speaking only about
transparent "springs" and
what about width:25%% case? Or padding?

>... I think that's
> better done with new CSS properties that can insert flexing springs
> before and after the margin box...

I personally don't like the abilitiy of CSS to modify DOM structure though -
these anonymous tables, rows, etc. That is indeed a "fundamental flaw". DOM
transformations is in other discipline I guess.

Andrew Fedoniouk.

> From: "Dave Hyatt":
> I agree CSS3 needs a spring and strut layout system, and I'm working on
> a module that describes the XUL box layout system (implemented in both
> Mozilla and Safari).  I'll reiterate one more time that I believe
> overloading width has a fundamental flaw, since you effectively prevent
> flexible layouts from laying out objects at their intrinsic widths (or
> specified widths) before the flex is applied.  This is critical for
> example when opening dialogs to an intrinsic size, but still allowing
> them to resize.  The flexing doesn't kick in until the user resizes the
> window, and the system still needs to have a notion of preferred
> intrinsic width to use for initial display.
> As for flex applied to the other components of the box, I think that's
> better done with new CSS properties that can insert flexing springs
> before and after the margin box.  I don't think margins should be
> overloaded.  Flex is not a unit of length, and should not be
> represented as such in CSS.
> I also think it's better to just use a new display type in CSS and not
> to attempt to overload normal block and line layout with this behavior.
>   It's far easier to describe and far less complex if this feature is
> done with new display types in a separate CSS3 module.
> dave
> On Jun 26, 2004, at 4:35 PM, Andrew Fedoniouk wrote:
Received on Sunday, 27 June 2004 13:34:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:14 UTC