- From: Shelby Moore <shelby@coolpage.com>
- Date: Tue, 19 Oct 2010 13:22:29 -0400
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "Sylvain Galineau" <sylvaing@microsoft.com>, "www-style list" <www-style@w3.org>
[snip] >> And I have generalized your proposal, to propose that we should also >> offer >> relative sizing of the box width and height, so as to combine and >> generalize the Flex-Layout proposal: >> >> http://lists.w3.org/Archives/Public/www-style/2010Oct/0372.html > > I don't believe it is worthwhile to attempt to generalize this enough > to somehow solve the problems of both Positioned Layout and Flexbox > Layout. Afaics, the constraint and layout rendering algorithms issues they create are the same. I think you kill 2 birds with one stone. If you do one, the other comes nearly for free. Position and size are the same constraint category. > The two are intended to solve different features, and involve > different types of constraints. Afaics, they are the same generalized constraint category. My mind works very abstractly at times. The layout engine is going to have to consider the position and size in each of it's computations of layout constraint. > While it is possible in principle to > merge them, I believe it would be too confusing to authors and too > expensive for browsers (as you'd probably need to do something like > simulated annealing to solve the constraints). Why do you think so? I see the opposite. The model becomes very clear and fully generalized. No more special cases. For example, your proposal eliminates position:fixed as a special case. The problem with CSS direction now is the potential proliferation of special cases, rather than employing a simpler to specify generalized model, e.g. making tooltips a special category is a special case. > Instead, I believe it's best to design separate layout models that are > powerful by themselves and well-designed for solving particular > use-cases. The current set of new layout models I'm pushing > (Positioned, Flexbox, and Template) all satisfy this. What is Template? I will help you generalize all 3 into one simple and robust model. >>> 2) Abpos a child above, below, or to the side of its parent to reveal >>> extra information on hover. (CSS currently fails for this because >>> each edge is measured relative to the same edge of the containing >>> block. Thus you can only, for example, position an element below its >>> containing block if you know the height of the element (to set >>> 'bottom' to an appropriate negative length).) >> >> >> Agreed. >> >> Can't do absolute positioning (positive:absolute) with relativity in CSS >> without scripting. You must mean that the element you are positioning >> relative to, is also absolutely positioned. So this isn't relative at >> all, it is hard-coded pre-computed positioning relationship. Yeah >> absolute positioning as you said. >> >> And if you use position:relative, you reflow the normal flow in current >> CSS, which isn't a popup functionality. > > No, I just meant what I said. Given a normal-flow parent, I missed the word "parent". Now it makes sense. [snip] >>> 3) Abspos an element relative to the body while an ancestor is relpos >>> for an unrelated styling reason. (CSS currently fails for this >>> because you can't specify what you want to position yourself relative >>> to - you're automatically relative to the nearest positioned ancestor, >>> even if that ancestor's positioning is completely unrelated.) >> >> >> Agreed. >> >> There is no relative positioning in current CSS that doesn't remove from >> normal flow. > > Be careful with your terms here - relative positioning (with > "position:relative") keeps the element in normal flow. Typo. I meant "...that removes from...". The word "doesn't" shouldn't be there.
Received on Tuesday, 19 October 2010 17:23:02 UTC