- From: Shelby Moore <shelby@coolpage.com>
- Date: Tue, 19 Oct 2010 23:30:33 -0400
- To: shelby@coolpage.com
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "Sylvain Galineau" <sylvaing@microsoft.com>, "www-style list" <www-style@w3.org>
More typos... >> What I mean is that other layout modes offer a "flow", where a bunch >> of carefully designed implicit constraints are used to relate boxes to >> each other in various ways. Positioned Layout instead gives the user >> explicit control over the constraints, which opens up the possibility >> of accidentally creating dependency cycles (which don't exist in the >> flow-based models, if designed correctly). > > I dealt with this in another reply: > > http://lists.w3.org/Archives/Public/www-style/2010Oct/0401.html > >> Handling the explicit dependency cycles is complex enough. Trying to >> mix that with the implicit constraints of other layout flows would be >> hellish. As it is, I'll have to do some work to minimize the contact >> that this layout mode has with others. > > Agreed. I think perhaps I provided the solution at the link above. Perhaps better explained my solution in my latest post: http://lists.w3.org/Archives/Public/www-style/2010Oct/0411.html [snip] >> We explicitly don't design the CSS language to be used in that manner. >> It certainly *can* be used in that way (there's absolutely nothing >> wrong with preprocessors like LESS), but an argument that it's okay to >> design something that's too complex for regular authors because you >> can write libraries on top of it won't fly. > > I don't think my example above is less complex, and it is certainly more > general. I meant I don't see my generalized example as MORE complex. The Flexbox is more explicit about "this is a class of flexing sub-elements", but my generalized example is pretty explicit about that too 'rsize:0.5' with more orthogonal generality available for power users.
Received on Wednesday, 20 October 2010 03:31:07 UTC