Hi Carlos,

IMO, we want to abstract away platform/runtime-specific implementations in the 
API surface.  It is not a good idea to have our user's application rely on API 
practices that may not work on all targets.  So first, we have to agree on what 
width/height is in Royale.

I do not think that UIBase width/height should map directly to CSS 'width' in 
the browser.  That's mainly because we know that Flash/AIR .width does not 
support units (px, em, etc) and also because I think width/height should 
operate like it did in Flex.  You set it to a number and it sets the size in 
pixels, you set it to % and it sets the percentWidth.  You read it and you get 
the current size of the component in pixels.  I believe we can make this 
behavior work on all targets going forward.  It does not have any 
platform-specific behavior, IMO.

IIRC, we also know that Flash/AIR will not accept NaN as a value for 
Sprite.width.  And then, IMO, it isn't a good practice to tell our users to set 
any Number property to NaN.  Things can start out as NaN in some cases, but 
setting things back to NaN doesn't seem right.  NaN checks are good for testing 
that your code is operating correctly.  There are a few places where the 
framework sets NaN like in the pairing of explicitWidth/percentWidth, but the 
app developers shouldn't have to do that (in fact they are not supposed to do 
that), they should just be setting a new non-NaN value to explicitWidth or 
percentWidth.

So, I would like to better understand the "why" you need to set CSS width to 
"initial".  The places I've run into that in Royale have to do with 
sizeToContent.  If a component is sizedToContent, there are scenarios where a 
layout has set CSS width to some value because it is a layout that doesn't rely 
completely on the browser for layout.  The emulation components set 
position="absolute" and set CSS width to numbers because Flex layouts don't use 
CSS in a conforming way.  So I've been setting CSS width="" (or "initial") in 
certain places in the lifecycle of the component, like in the Flex layouts or 
in a component's setActualSize in order to "clear the temporary value" of width 
so it can be computed properly again for the platform/runtime target.  I'm 
guessing that if you look at why you want to set width to initial, it is for a 
similar "meaning" and you might have an protected/framework API called 
"clearTemporaryWidth" if you need to but hopefully, our app developers won't 
ever need to call it.

My 2 cents,
-Alex

On 1/15/19, 3:58 AM, "Carlos Rovira" <[email protected]> wrote:

    Hi Alex,
    
    El lun., 14 ene. 2019 a las 18:37, Alex Harui (<[email protected]>)
    escribió:
    
    >  Right now there are some places where we unset by setting width/height to
    > "".  I think those will have to change to "initial" but it is the same
    > principle.
    
    
    But changing "" to "initial" seems to me focus just in HTML platform. What
    happens with SWF or future targets...or maybe I'm not understanding your
    proposal?
    
    
    > So think about the "meaning" behind the need to unset width/height and
    > whether there is a place in the implementation that is the right time to 
do
    > that.
    >
    >
    I think already did with this code right?
    
    public function setWidth(value:Number, noEvent:Boolean = false):void
    {
    if (_width !== value)
    {
    _width = value;
    COMPILE::JS
    {
     this.positioner.style.width = isNaN(_width) ? "initial" : value.toString()
    + 'px';
    }
    if (!noEvent)
    dispatchEvent(new Event("widthChanged"));
    }
    }
    
    Let me know if is ok for you
    
    Thanks
    
    Carlos
    

Reply via email to