I like that approach. We already had the same discussion earlier this year: how to manage a quickly increasing number view attributes once we implement more and more of CSS2/CSS3 across runtimes. Using mixins will redruce complexity in the documentation as well, keeping the number of attributes lower for classes.
But here's an interesting question: does the documentation support mixins? If not, that's a huge problem! - Raju On Dec 3, 2009, at 9:21 PM, Max Carlson wrote: > That's done :) > > Rami Ojares / AMG Oy wrote: >> Just remember that Henry still needs to implement mixins for instances. >> Or is that already done? >> - rami >> Max Carlson wrote: >>> Agreed! A mixin is the way to go. I'll fix up the change, now that the >>> riskier version has been backed out. >>> >>> Rami Ojares / AMG Oy wrote: >>>> I am currently so in love with the mixins that I recommend that approach >>>> <view with="boxmodel" padding=".."/> >>>> >>>> - rami >>>> >>>> P T Withington wrote: >>>>> I think this is a great feature, but that it is too close to the end of >>>>> the 4.7 cycle to put in. We can't just add a whole bunch of public slots >>>>> to <view> without more community feedback. >>>>> >>>>> If you want to 'try this out', I would suggest putting these attributes >>>>> in another 'namespace'. E.g., name the attributes `future$padding`, etc. >>>>> (pick your meaningful prefix). That way, people who want to take >>>>> advantage of this code can, and their code will be easily marked so they >>>>> can adapt it when we finalize the API, but we will greatly reduce the >>>>> likelihood of breaking existing applications that subclass <view>. I >>>>> think it is correct to use the real CSS names for how these attributes >>>>> would be controlled by a style sheet. So you would do something like: >>>>> >>>>> <attribute name="future$padding" value="0" style="padding" /> >>>>> >>>>> etc. >>>>> >>>>> Of course, there is the issue that CSS actually specifies many of its >>>>> box-model attributes as 'trbl' vectors. For animation purposes, you >>>>> probably want each vector component to be a separate attribute. For API >>>>> compactness, you probably just want a single vector for each of, >>>>> margin/border/padding. Border also has a pile of other attributes, not >>>>> just the trbl dimensions... >>>>> >>>>> Bottom line, I think we should defer implementation of this to 4.8. If >>>>> you _must_ have it in 4.7, please 'namespace' it. >>>>> >>>>> And let's discuss what the ideal 4.8 API should be. >>>>> >>>>> [One other approach would be to break out the box-model extension as a >>>>> mixin, which would essentially namespace it because you'd have to >>>>> explicitly request it in a `with` clause.] >>>>> >>>>> On 2009-12-03, at 13:43, Max Carlson wrote: >>>>> >>>>>> See here for more details on how box model works: >>>>>> http://www.w3.org/TR/CSS2/box.html#box-dimensions >>>>>> >>>>>> I propose adding four attributes to view, to support CSS2 box model: >>>>>> >>>>>> padding: Specifies the number of pixels used for padding around the view >>>>>> margin: Specifies the number of pixels used for margins inside th view. >>>>>> borderwidth: Specifies the width of the border, in pixels. >>>>>> bordercolor: Specifies the color of the border, as a CSS color value. >>>>>> >>>>>> The risk is, padding, border and margin may be used in existing >>>>>> applications. I already found a case in lz/tabs.lzx that used >>>>>> 'padding'. In most cases, these attributes can simply be renamed. >>>>>> >>>>>> Please send your thoughts! I'd like to get this finalized in time for >>>>>> the 4.7 release. >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Max Carlson >>>>>> OpenLaszlo.org >>>>> >>>>> >>> > > -- > Regards, > Max Carlson > OpenLaszlo.org
