- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 14 May 2004 22:28:52 -0700
- 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 UTC