Thinking about this a bit more, it reminds me a bit of a similar issue with mobile devices and pixel resolution. I think it may also be an issue with Retina displays on Macs and probably some equivalents in Windows.
The most Basic applications shouldn't care about that stuff and if you ask for 100 pixels you get 100 pixels even if that takes up 1/4 inch on some displays. But, IIRC, many other layouts "should be" driven by screen-size in a top-down manner. You want something to cover half the screen or something like that. So percentages are used. There is some additional code needed for this and I think it is baked into Basic already. Then there are "sizeToContent" scenarios. In theory, in Royale's JS implementations, the HTMLElement should get the right size if the CSS for the element specifies a font-size in any units. We shouldn't have to run any code to compute that value in pixels. The offsetWidth/height should be calculated for us by the browser. Then the top-level component should be reporting the right width/height and things "should" work. There should be code in Basic for this already. So that makes me want to know more about what wasn't working. Theoretically, if the component just composits a bunch of HTMLElements and doesn't try to set their size when sizedToContent, the UI should stretch/shrink appropriately. If there isn't an event when the browser changes that size we might need a bead to detect it and run some layouts. The Emulation components won't react properly because they do absolute positioning on everything since MX and Spark layouts are not CSS compliant. But hopefully most of our components use CSS for layout and should react properly. Helper functions and all that shouldn’t be needed. The result of our component code should be a DOM with few specified width/height values if the user is not specifying values in their code. Thoughts? -Alex On 1/14/19, 10:42 AM, "Harbs" <[email protected]> wrote: I was thinking about maybe some helper function of toUnit() which would return a string. There could be some kind of mixin which could alter the output of the helper function to em or rem or whatever. There would likely need to be more than one toUnit() helper because I would imagine that different cases would need different handling. Figuring those out might not be so simple... > On Jan 14, 2019, at 8:36 PM, Alex Harui <[email protected]> wrote: > > 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" <[email protected] <mailto:[email protected]>> wrote: > > >> On Jan 14, 2019, at 8:04 PM, Alex Harui <[email protected]> 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" <[email protected]> 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&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=FSmQOghVtyktcNjYC%2FqkL3z4PRCYJeuKvED%2BlxClWtg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbenfrain.com%2Fjust-use-pixels%2F&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=FSmQOghVtyktcNjYC%2FqkL3z4PRCYJeuKvED%2BlxClWtg%3D&reserved=0> >> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-px&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=xMfHqXkd8c%2BSDtryfZFcEAHzn80msejeV4hyAAEQGAU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-px&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=xMfHqXkd8c%2BSDtryfZFcEAHzn80msejeV4hyAAEQGAU%3D&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&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=CTmOpMV2m9jyJ92pcS0pCdFKMGwbQL%2Ff4AZfc3b1Ll4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percent&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=CTmOpMV2m9jyJ92pcS0pCdFKMGwbQL%2Ff4AZfc3b1Ll4%3D&reserved=0> >> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660635240&sdata=Zp%2Bo6gwfdaIseyePtSxDJRTVSbUi8BirbeiEuisNSUc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660645250&sdata=rmb0BXbW%2BWXlwqd4r%2BuMHflKQ5LIb4EKNTo6WsE9l8k%3D&reserved=0> >> [5]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-px&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660645250&sdata=Mu%2F9e9889Q36sQffh33DWup4%2BfjChKQbl0c3WFjRuHU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-px&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660645250&sdata=Mu%2F9e9889Q36sQffh33DWup4%2BfjChKQbl0c3WFjRuHU%3D&reserved=0> >> >>> On Jan 14, 2019, at 5:04 PM, Carlos Rovira <[email protected] <mailto:[email protected]>> 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 (< >>> [email protected] <mailto:[email protected]>>) 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&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660645250&sdata=tJl0WrjAMBjwUEJvUP7diBhyseg62CvqjHBJCnaaOZw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8019b9549a2c435a50a408d67a501286%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830881660645250&sdata=tJl0WrjAMBjwUEJvUP7diBhyseg62CvqjHBJCnaaOZw%3D&reserved=0>
