- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 14 Dec 2007 19:45:45 -0800
- To: Christoph Päper <christoph.paeper@crissov.de>
- CC: WWW Style <www-style@w3.org>
Christoph Päper wrote: > > Andrew Fedoniouk: >> De facto multicol[1] and grid[2] introduce different layout managers. >> >> 1) These layout schemas use their own subsets of attributes - not a >> single attribute but a number of dependent attributes. >> 2) These attribute subsets are independent by nature so if one schema >> is applied then secondary attributes - remnants from previous >> schema shall be discarded as a whole; > > I'm following you through here, but the syntax you propose just looks > wrong and is unlikely compatible to CSS grammar. Yes, it is incompatible but is it look wrong? > >> #eid >> { >> layout: columns >> { count: 3; >> width: 45px; >> gap: 0; >> rule: none; >> } >> } > > #eid { > layout: columns; /* ain't it LtRTtB-centristic? */ > columns: 3; /* now |column-count| */ > rows: 3; /* ignored */ > column-width: 45px; > column-gap: 0; > column-rule: none; > } > > #eid { > layout: grid; > columns: 3; /* or |column-count| */ > rows: 3; > column-width: 45px; /* probably ignored */ > column-gap: 0; /* perhaps ignored */ > column-rule: none; /* perhaps ignored */ > } > That is exactly the problem. If, say, column-gap is used in both: grid and columns then you cannot r rely on default values of attributes anymore - you *must* redefine all attributes. That is somehow conflicting with idea of cascading and inheritance. As deeper in the forest as more wolves around: we are getting more and more compound function alike values of properties. Think about that gradients as an example. I believe that the gradient() function proposal is also an example of need of "structural attributes". Function notation is bad as it does not support named arguments. Technically flat notation #eid { column-count: 3; column-width: 45px; column-gap: 0; column-rule: none; } is equivalent to #eid { layout: columns { count: 3; width: 45px; gap: 0; rule: none; }; } in terms of internal representation of attributes in UAs - so no need to change implementations dramatically. Benefits of structural attributes are: 1) they create local name spaces so future side effect free expansion is possible; 2) conglomerates of attributes are applied in all or nothing manner so cascading of values of attributes like the layout above is by itself also free from side effects: #eid { layout: default; } will discard the whole bunch of attributes. More on this gradient thing... Example: #eid { background-color: #DDD; background: gradient-radial { position: 50% 50%; stops: 0%/#CCC 100%/#FFF; }; } and later you may redefine it completely as: #eid { background: gradient-linear { start: 0% 0%; start: 100% 100%; stops: 0%/#CCC 100%/#FFF; }; } but if you will want later to render it with just an image then you can do it as: #eid { background: image-repeat { src: url(...); position: 50% 50%; }; } Think about this: we almost near to have five different background drawing methods: nothing(transparent background), solid color, gradient, image(that has 5 or so sub methods) and the border-image thing. At least last three conflict with each other. Say you have gradient and image defined for the same element. Whichever wins? They have to be mutually exclusive. Otherwise redefining solid background color for some element requires explicit disabling of all other background attributes like images and gradients. Imagine now that in future we will want one more background method, say, background-fractal-cloud. This will require one more item to be disabled explicitly while cascading. That is not user and future friendly and very far from being modular. -- Andrew Fedoniouk. http://terrainformatica.com
Received on Saturday, 15 December 2007 03:48:06 UTC