The string literal "px" is scattered throughout our code.  For example:

UIBase.as
                    this.positioner.style.height = value.toString() + 'px';     
   

This could be changed to:

public static const CSSUnits:String = "px";

                    this.positioner.style.height = value.toString() + CSSUnits;

IIRC, in Flash, a string lookup is actually faster than a string literal.  I 
was wondering if Closure would in-line it or look it up so we could hack that 
string.  Or maybe if we define it as a "var" instead of "const"  it will always 
look it up, but not sure.

Also note that other parts of our code should be reacting to the size of 
elements (which would react to browser changing fonts).  So there may be a 
different solution entirely, which is to see where in the code the things that 
didn't change size were making assumptions.
        
Thoughts?
-Alex

On 1/14/19, 10:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:

    
    > On Jan 14, 2019, at 8:04 PM, Alex Harui <aha...@adobe.com.INVALID> wrote:
    > 
    > Harbs,
    > 
    > What did you learn about constants and in-lining regarding Closure 
Compiler?  Could we put "px" in a variable/constant and have the option to 
replace it with "em”?
    
    I can’t think of a way to do that off-hand.
    
    > That said, are we sure that you can just switch to "em" and all other 
computations will "do the right thing”?
    
    No. I don’t think we can be sure of that at all. That was the gist of what 
I was saying about it being a bad idea.
    > 
    > My first reaction is that Basic is basic and works in pixels and that 
adding other units can happen in other component sets and beads.
    
    Maybe that’s the way to go, but I would prefer some way to change the units 
via some kind of bead or something on standard sets. Not sure what that would 
be though…
    
    > Of course, I could be wrong,
    > -Alex
    > 
    > On 1/14/19, 8:39 AM, "Harbs" <harbs.li...@gmail.com> wrote:
    > 
    >    There are tons of discussions on the web about the pros and cons of 
pixels vs em/rem. Some examples:[1][2][3][4][5]
    > 
    >    My takeaway is that there’s no one right answer. For predictable 
layout, pixels is safer, but for better reading with accessibility, em/rem 
might work better.
    > 
    >    Simply changing from pixels sounds like a very bad idea. For pixel 
perfect web apps pixels is probably the better choice. It might be a good idea 
to add the possibility of using em and/or rem, but adding more methods to 
UIBase is probably not the way to go about it.
    > 
    >    Maybe all the specifications of “px” should be changed to some utility 
function and a mixin could determine the actual value.
    > 
    >    My $0.02,
    >    Harbs
    > 
    >    
[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbenfrain.com%2Fjust-use-pixels%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=WFiUn4fMJG4tOJvnzNU1XF2c0wDnEZooVHSRCxYvv14%3D&amp;reserved=0
    >    
[2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-px&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=4Yo2A5fUq7KidRTM%2FDulBnElY2wK3QnWIYq0aNCKs84%3D&amp;reserved=0
    >    
[3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percent&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=CIOgFzac6y50hSHsfXludv5M%2FUNhgiVti%2BenoigMHDo%3D&amp;reserved=0
    >    
[4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=a6ohFKIGRTnga3ZqT%2FjC5KveWWl%2BamoqxqBd3Cu1Dhc%3D&amp;reserved=0
    >    
[5]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-px&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=bBffOQLT7DPeDr1NStzGyX20vFeRitOreVSO2RsMRFY%3D&amp;reserved=0
    > 
    >> On Jan 14, 2019, at 5:04 PM, Carlos Rovira <carlosrov...@apache.org> 
wrote:
    >> 
    >> Hi Mark,
    >> 
    >> very good question. And I don't know what would be the best...
    >> 
    >> Hope others (Alex, Harbs, Piotr, etc...) could give some thoughts about
    >> this since I'm not sure.
    >> 
    >> To put people on track; Mark states that using font size (only) browser
    >> increase/decrease (notice that Firefox has a built-in control, but Chrome
    >> needs a plugin), makes Apache Royale
    >> fonts bigger or smaller while the rest of drawings are not affected. If 
we
    >> change from PX to EM units, seems Mark gets right results.
    >> 
    >> So, the question is...how should we adapt Royale codebase to manage this?
    >> 
    >> Current width/height in UIBase, uses PX and is hardcoded...could we make
    >> some decoupling or "plug" the right units as we want?, so instead of 
"px",
    >> we have a constant or some modifier that could be configured in some part
    >> (Maybe in Application), so we can set to EM instead to PX??
    >> 
    >> I think we need some config here, but that respect actual config, so 
people
    >> can use actual PX or change to EM if they want. For example, I think 
Jewel
    >> should change to use EM in a global way.
    >> 
    >> Thanks
    >> 
    >> 
    >> 
    >> El lun., 14 ene. 2019 a las 13:39, Mark Kessler (<
    >> kesslerconsult...@gmail.com>) escribió:
    >> 
    >>> Carlos,
    >>>   I can give it a shot when I'm at home.  However, what about the
    >>> direct width/height assignments.  Should they do EM assignment too or
    >>> should there be a new widthEM heightEM property added?
    >>> 
    >>> --
    >> Carlos Rovira
    >> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519&amp;sdata=HjIHZ7QfXVtOTIkk3i%2FrUWzlWFGmsnvMeyO%2B4gtwFxA%3D&amp;reserved=0
    > 
    > 
    > 
    
    

Reply via email to