On 12/1/16, 4:01 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>to separate things:
>Such as? Depending on your layout, left, top, width, and height will be
>> set in CSS. In UIBase, setting the x value sets style.left, etc. If
>> there is an alternative, please let me know what it is.
>I get this:
><div style="position: relative;"><span class="Label" style="white-space:
>nowrap; cursor: default; pointer-events: none;">some text</span><button
>type="button" class="TextButton" style="position: relative;">a
> <js:Label text="some text"/>
> <js:TextButton text="a button"/>
Ah, ok, I didn't understand what you meant by "kilometric".
>in my MDLExample (take into account that I use exclude default CSS
>So as you see there's lots of "style" properties above that should not be.
>The right output should be:
><div><span class="Label">some text</span><button type="button"
>So as I use compiler option exclude default css file I ensure my app only
>has the css I put, and not carry anything I don't want.
>why this is happen? To take only one example. In js:Container line 104
>positioner.style.position = 'relative';
>this should remove from there and put in defaults.css line 93
> position = 'relative';
>Do you agree with that?
I wish I could agree, but I don't think I can. IMO, some component
features can only be implemented by setting style properties. In the
example above, to keep Label as single-line (so you don't have to us
and can just use space), we must set white-space:no-wrap. Allowing folks
to tweak things like that in the CSS seems dangerous to me.
Similarly, Label isn't supposed to be interactive, so we turn off mouse
events. It is the equivalent of mouseEnabled in SWF. The way we found to
do it is to set a style. Again, I'm not sure that should be settable in a
The way we handle visible=false also sets a style: display:none. And as I
mentioned, setting x,y,width,height also set style properties, so I think
it is ok for style properties to be set in component code.
I would agree that most or maybe all style properties that affect the
visuals (border, padding, margin, color, fonts) should not be set in
component code and only via defaults.css.
But position is a tricky and separate topic. Someone needs to prove that
none of the examples break if we don't set position to relative or
absolute the way we do it now. The comment in Container.as says:
// absolute positioned children need a non-null
// position value in the parent. It might
// get set to 'absolute' if the container is
// also absolutely positioned
So that implies that if you put a child in a Container and set its x or y
value, it won't work unless we set position to absolute or relative.
That's making me think that the test case is a nested set of Containers
with a child in the inner container with x,y position. IIRC, having
BasicLayout which supports x,y values set the position style on the
Container isn't good enough. Maybe it needs to walk the parent chain and
set position an all parents, but that seems dangerous as well. If you
have time to test that out and propose a better solution, that would be