On 12/1/16, 1:57 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote:
>In MDL we don't need any style tag and percents works ok. But if I use
>HTML.swc comps I get the styles bloating my html and I don't want that. So
>for that reason I think we should refactor styles to CSS. As well this is
>basic separation of concerns and we should avoid that always as a golden
Can you be more specific? I thought most components were picking up all
of their styles from defaults.css. Which components aren't doing this?
>Another problem is that sometimes we get div inside div (or other tags)
>that we don't need. I already don't know how to get rid of this. I think
>VIEW comps what make that magic, but I'd need some example to see how it
>works (for example my problems with List that I need to solve).
Peter just spend some time on this. Historically, we wanted Container to
be able to generalize to create a Panel. It could be we haven't designed
Panel properly, but AFAICT, the TitleBar for a Panel isn't describable in
CSS. It is really an additional content area and offsets the y position
of the children of the Panel. So, having a contentArea allows for non-CSS
chrome, and makes it easier to manage x,y without doing translations on
every read/write. IOW, it wouldn't be any fun if, in order to place a
component in the upper left of a panel you couldn't just set y=0, but had
to set y to titleBar.height.
I don't remember if this is the main reason we have to propagate relative
or absolute positioning in order to get percentages to work "everywhere",
but these are the kinds of issues we faced. Folks are welcome to test out
different implementations on the examples.
So most recently, Peter changed MXMLItemRenderer to get rid of its inner
content area and just be more like the lightweight Container that Harbs
mentioned earlier in this thread. We could make that the default
Container and have a ContainerWIthNonCSSChrome that has the inner
contentArea and Panel could extend that.