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

CSS: %% length unit. Illustration.

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 14 May 2004 22:28:52 -0700
Message-ID: <001301c43a3d$95cd6ae0$0301a8c0@ATHLON>
To: "David Hyatt" <hyatt@apple.com>
Cc: <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>

Sorry guys, it's me again about %% :)

Here are sample renderings and final source of the document illustartes
scrollbar layout using %% units and  min-height and max-height constraints.
http://terrainformatica.com/w3/p2/scrollbar.htm
As we can see here combination of  %% and min/max barriers can be very
useful even without
flex'es and flex groups.

Andrew Fedoniouk.
http://terrainformatica.com



From: "David Hyatt" <hyatt@apple.com>
>
> The problem I have with your proposal is that you are overloading the
> concept of flexing onto the concept of width.  These are two
> independent concepts.  It should be possible to say that object A has a
> width of 100px but a flex of 5, but that object B has a width of 200px
> and a flex of 1 (or no flex at all, etc.).
>
> If you overload the flexing concept onto width, then you prevent the
> separate specification of width and flex for a single element.
>
> XUL solves this problem by introducing a separate CSS property,
> box-flex, that is implemented by Mozilla and Safari.
>
> Another important flexing concept for UI elements (like scrollbars) is
> levels of flexing.  We call these flex groups in XUL.  Currently only
> Safari implements flex-group support.  The idea is that objects can be
> placed at different flex levels, so that - for example - you might want
> the track of a scrollbar to flex as you shrink the scrollbar, but once
> the track is completely gone, then the up/down buttons on the scrollbar
> could start flexing as you get even smaller.
>
> I think flexing works best when used with a specific new display type
> (a new type of container), so that the rules can be easily specified,
> and you don't have to handle how flexing works in arbitrary line layout
> (which I think would be unnecessarily complicated given the use cases I
> would expect for such a feature) or in the presence of floats.
>
> dave
>
> On May 11, 2004, at 2:57 PM, Andrew Fedoniouk wrote:
>
> >
> > For me personally the concept of "auto" is one of the most confusing
> > things
> > in CSS:
> > Bad dream of implementor: "...'auto' replaced by some suitable value,
> > but
> > there are exceptions...".
> >
> > E.g. why margin-left/right:auto in some cases is exactly 50%% and
> > margin-top/bottom:auto is nothing in most(or in all?) cases?
> >
> > %% is an attempt to formalize this 'auto' concept if you wish.
> >
> > width:50%  and width:50%%  are basicly the same entities
> > but in first place ContainerContentWidth is used as base for computing
> > percents and
> > in second place it is FreeSpace which is function of
> > ContainerContentWidth.
> >
> > Andrew Fedoniouk.
> > http://terrainformatica.com
> >
> >
> > L. David Baron  wrote:
> > "This means that, while it's a value for the 'width' property, it's not
> > actually describing the width, but rather a factor to be added to an
> > 'auto' width.  That seems confusing, and might lead authors to expect
> > that of 'width' in other cases as well (as some buggy browsers already
> > do, especially for 'height')"
> >
> >> first:
> >>    compute everything as %% does not exist at all.
> >>    apply all paragraph wrapping rules as usual.
> >> second:
> >>    compute free space for each line box which we've got on first step.
> >>    compute all elements which have %% according to free space.
> >>    replace elements in line boxes.
> >
> >
>
Received on Saturday, 15 May 2004 01:30:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:30 GMT