Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Carlos Rovira]

Ok Alex,

for what I read, I understand that we already has mechanism in Royale to
handle this. So I think Mark, should try to do some easy test case that
showcase the problem and he/we can work over that to see the easiest
solution. Maybe is just a matter of supporting that in Jewel cause I wasn't
aware of that when I implemented that components. As well maybe Marks
function proposal could be part of Royale as an utility function to manage
conversions between px to em and viceversa and put as easy as possible for
people that wants to use it

@Mark, do you want to work on that? Alex and I can support and test over
concrete app test and discuss how to go further.

One thing I get from Alex's words is that Ems could be problematic at some
point due to inconsistencies, while Px seems to have more consistency.
Since Apps is a mix of text and drawings, while increasing/decreassing
sized Px could give as a better control over different targets/runtimes,
while Ems could be problematic. But I don't have clear the right response
since all of this is new for me, so maybe we should explore this a bit more
to get some final thoughts and rules to go with.

Thanks








El mar., 15 ene. 2019 a las 19:52, Alex Harui ()
escribió:

> Hi Carlos,
>
> In theory, nobody is "forcing" anything in Basic.  Hopefully everything is
> PAYG.  If there is a PAYG way to support "em" in Basic then great.  Maybe
> having a units var/const is good enough.
>
> One thing I just thought of is that there is typically a
> 'get-what-you-set' rule for Flex properties that would be nice to have in
> Royale.   And a similar 'set-what-you-get' rule.  This makes other things
> simpler, such as animations.
>
> As I mentioned in the "missing", width is read to get the current
> displayed width in pixels.  In the browser it reads back offsetWidth,
> IIRC.  Then if you want to run a resize effect, you can just do:
>
>someDisplayObject.width++;
>
> or in layouts:
>
>   someDisplayObject.width = someOtherDisplayObject.x;   // widen to line
> up with left side of other object
>   someDisplayObject.x = someOtherDisplayObject.width;   // horizontally
> position first object just after other object.
>
> This may not do the expected/right thing if the units are ems.
>
> The more I think about it, it starts to feel like em is more like
> percentWidth.  These are ways of specifying relative sizes.  Width is for
> specifying explicit sizes and reading back the current size in pixels.
> Percentage is probably easy for us to implement an all future
> targets/runtimes.  But is 'em' going to be a popular enough unit for us to
> want to support it forever on all platforms?
>
> As I mentioned recently, there are top-down layouts and sizeToContent
> layouts.  sizeToContent gets broken on occasion and then I fix it when
> needed.  I just fixed it in the emulation components for Spark TabBar and
> ViewStack.  There are probably still bugs in it in other components.
>
> Anyway, percentage is for top-down.  You have to know the parent's size
> for percentage to make any sense.  It looks like 'em' and 'rem' are for
> sizeToContent.  One article said that 'em' has serious problems when
> nested.  I don't know if 'rem' was a fad or is the future.  But I'm
> wondering if we need to support these content- relative units anywhere but
> in the CSS.
>
> That's why I'm wondering where we get stuck in our sizeToContent
> scenarios.  SizeToContent in Basic is PAYG.  Dynamic changes to things is
> PAYG.  It takes more and more code to handle the various ways things can
> change at runtime that affect sizeToContent.  The Basic support is just
> that, if you haven't specified a fixed size or percent size, then we size
> to content but we don't watch for all kinds of changes to content.  Other
> PAYG code can come in and add more logic to check for other kinds of
> changes.  It may be that the code we need is the code to detect that the
> browser changed the font size and then send layoutNeeded events to the
> layouts and/or components.
>
> By doing that, we are again abstracting away platform/runtime details.
> Royale will support changes that affect the size of components that are
> sized to content.  The app developer may not need to specify "em" other
> than in their CSS.  That might be a platform-specific way of specifying the
> font-size of a component.  But regardless of how they specify their font
> sizes, if they change the font size at runtime (which they could also do by
> altering the CSS font-size in px), Royale components that are sizeToContent
> should know how to respond to that (via PAYG code).
>
> HTH,
> -Alex
>
> On 1/15/19, 4:41 AM, "Carlos Rovira" 
> wrote:
>
> Hi,
>
> very interesting discussion
>
> @Alex : 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.
>
> Although Basic is just Basic, people using it could want to switch
> from PX
> to EM at 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Alex Harui]

Hi Carlos,

In theory, nobody is "forcing" anything in Basic.  Hopefully everything is 
PAYG.  If there is a PAYG way to support "em" in Basic then great.  Maybe 
having a units var/const is good enough.

One thing I just thought of is that there is typically a 'get-what-you-set' 
rule for Flex properties that would be nice to have in Royale.   And a similar 
'set-what-you-get' rule.  This makes other things simpler, such as animations.

As I mentioned in the "missing", width is read to get the current displayed 
width in pixels.  In the browser it reads back offsetWidth, IIRC.  Then if you 
want to run a resize effect, you can just do:

   someDisplayObject.width++;

or in layouts:

  someDisplayObject.width = someOtherDisplayObject.x;   // widen to line up 
with left side of other object
  someDisplayObject.x = someOtherDisplayObject.width;   // horizontally 
position first object just after other object.

This may not do the expected/right thing if the units are ems.

The more I think about it, it starts to feel like em is more like percentWidth. 
 These are ways of specifying relative sizes.  Width is for specifying explicit 
sizes and reading back the current size in pixels.  Percentage is probably easy 
for us to implement an all future targets/runtimes.  But is 'em' going to be a 
popular enough unit for us to want to support it forever on all platforms?

As I mentioned recently, there are top-down layouts and sizeToContent layouts.  
sizeToContent gets broken on occasion and then I fix it when needed.  I just 
fixed it in the emulation components for Spark TabBar and ViewStack.  There are 
probably still bugs in it in other components.

Anyway, percentage is for top-down.  You have to know the parent's size for 
percentage to make any sense.  It looks like 'em' and 'rem' are for 
sizeToContent.  One article said that 'em' has serious problems when nested.  I 
don't know if 'rem' was a fad or is the future.  But I'm wondering if we need 
to support these content- relative units anywhere but in the CSS.

That's why I'm wondering where we get stuck in our sizeToContent scenarios.  
SizeToContent in Basic is PAYG.  Dynamic changes to things is PAYG.  It takes 
more and more code to handle the various ways things can change at runtime that 
affect sizeToContent.  The Basic support is just that, if you haven't specified 
a fixed size or percent size, then we size to content but we don't watch for 
all kinds of changes to content.  Other PAYG code can come in and add more 
logic to check for other kinds of changes.  It may be that the code we need is 
the code to detect that the browser changed the font size and then send 
layoutNeeded events to the layouts and/or components.

By doing that, we are again abstracting away platform/runtime details.  Royale 
will support changes that affect the size of components that are sized to 
content.  The app developer may not need to specify "em" other than in their 
CSS.  That might be a platform-specific way of specifying the font-size of a 
component.  But regardless of how they specify their font sizes, if they change 
the font size at runtime (which they could also do by altering the CSS 
font-size in px), Royale components that are sizeToContent should know how to 
respond to that (via PAYG code).

HTH,
-Alex

On 1/15/19, 4:41 AM, "Carlos Rovira"  wrote:

Hi,

very interesting discussion

@Alex : 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.

Although Basic is just Basic, people using it could want to switch from PX
to EM at sometime. I think it should not be good to force PX in any part of
Royale

One thing is clear: we should not have "px" hardcoded in UIBase, so the
const proposal seems ok to me to fix it at UIBase level. If that is ok for
all we should do it.

In the other hand, about using "sizeToContent", I only remember to deal
with that method in one Jewel component, so don't know if that is used
"internally" in more parts (without the need for me to deal with it in the
component) or if I need to do something for each component. But as well
that seems to me like a theory, and maybe you should check if that is
working as you think, for for that you first need to be able to switch from
PX to EM right?

I think Jewel could be configured to "em" out-of-the-box, since seems for
me more "font oriented", and applications are, from my point of view more
text oriented, since we are showing list of textual item, buttons with
labels, labels (texts) and more...

@Mark, maybe you could do a PR with your proposal in a form of a function
class so we can use in the same way we use for example "
org.apache.royale.html.util.addElementToWrapper"

Thanks



El mar., 15 ene. 2019 a las 1:29, Alex Harui ()
escribió:

> Yes, that 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Carlos Rovira]

Hi,

very interesting discussion

@Alex : 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.

Although Basic is just Basic, people using it could want to switch from PX
to EM at sometime. I think it should not be good to force PX in any part of
Royale

One thing is clear: we should not have "px" hardcoded in UIBase, so the
const proposal seems ok to me to fix it at UIBase level. If that is ok for
all we should do it.

In the other hand, about using "sizeToContent", I only remember to deal
with that method in one Jewel component, so don't know if that is used
"internally" in more parts (without the need for me to deal with it in the
component) or if I need to do something for each component. But as well
that seems to me like a theory, and maybe you should check if that is
working as you think, for for that you first need to be able to switch from
PX to EM right?

I think Jewel could be configured to "em" out-of-the-box, since seems for
me more "font oriented", and applications are, from my point of view more
text oriented, since we are showing list of textual item, buttons with
labels, labels (texts) and more...

@Mark, maybe you could do a PR with your proposal in a form of a function
class so we can use in the same way we use for example "
org.apache.royale.html.util.addElementToWrapper"

Thanks



El mar., 15 ene. 2019 a las 1:29, Alex Harui ()
escribió:

> Yes, that might be possible as well.  We don't really have to pick one
> strategy.  Different component sets can have different strategies.  We
> could have an "all em" set if we wanted.  It would be nice to share code in
> UIBase, but not a requirement.  Hopefully, IUIBase doesn't really presume
> pixels (although it still wants width/height to be a Number), and hopefully
> we don't have lots of expectations on UIBase instead of IUIBase.
>
> Another way to think about Royale is that our components (really the
> beads) spit little bits of JS, CSS, and HTMLElements into the browser.  So,
> for any website you could build without Royale, you should be able to
> fashion Royale components that automate and encapsulate the building of
> that site and similar sites.  So whatever pattern needs to be added to the
> final JS/CSS/HTML, we should be able to encapsulate anything that isn't a
> one-off and provide parameters to tweak the pattern.
>
> My 2 cents,
> -Alex
>
> On 1/14/19, 12:26 PM, "Mark Kessler"  wrote:
>
> As a comment on the helper functions, we could also just have
> something that does on the fly conversion.  In other words if I say
> 300 pixels, I want it to translate that into EM / other unit in the
> background. The reason I bring that up is to allow exact PX still be
> used for the Flex / Air side and converted for the js/css side.
>
> pixelTotal / fontSize = em
>
> 300 / 14 = 21.429 (rounded)
>
> Soo 300px for flex and 21.429 for JS side.
>
> -Mark K
>
>
>

-- 



Carlos Rovira

Presidente Ejecutivo

M: +34 607 22 60 05

http://www.codeoscopic.com


Conócenos en 1 minuto! 


AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email a...@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:d...@codeoscopic.com

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Alex Harui]

Yes, that might be possible as well.  We don't really have to pick one 
strategy.  Different component sets can have different strategies.  We could 
have an "all em" set if we wanted.  It would be nice to share code in UIBase, 
but not a requirement.  Hopefully, IUIBase doesn't really presume pixels 
(although it still wants width/height to be a Number), and hopefully we don't 
have lots of expectations on UIBase instead of IUIBase.

Another way to think about Royale is that our components (really the beads) 
spit little bits of JS, CSS, and HTMLElements into the browser.  So, for any 
website you could build without Royale, you should be able to fashion Royale 
components that automate and encapsulate the building of that site and similar 
sites.  So whatever pattern needs to be added to the final JS/CSS/HTML, we 
should be able to encapsulate anything that isn't a one-off and provide 
parameters to tweak the pattern.

My 2 cents,
-Alex

On 1/14/19, 12:26 PM, "Mark Kessler"  wrote:

As a comment on the helper functions, we could also just have
something that does on the fly conversion.  In other words if I say
300 pixels, I want it to translate that into EM / other unit in the
background. The reason I bring that up is to allow exact PX still be
used for the Flex / Air side and converted for the js/css side.

pixelTotal / fontSize = em

300 / 14 = 21.429 (rounded)

Soo 300px for flex and 21.429 for JS side.

-Mark K

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Mark Kessler]

As a comment on the helper functions, we could also just have
something that does on the fly conversion.  In other words if I say
300 pixels, I want it to translate that into EM / other unit in the
background. The reason I bring that up is to allow exact PX still be
used for the Flex / Air side and converted for the js/css side.

pixelTotal / fontSize = em

300 / 14 = 21.429 (rounded)

Soo 300px for flex and 21.429 for JS side.

-Mark K

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Greg Dove]

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.

I think that for swf bytecode output and for GCL release mode build, both
have consolidated string tables approach where common string literals are
held as a single copy. I'm not sure if that has a small size threshold
(e.g. 2 chars like 'px' might be more compact expressed as a literal each
time it repeats instead of using a reference to a string table entry)

As an aside: at one point I mentioned that some of the reflection data
might be best expressed as things like 'org.apache.royale.' +
'collections.' + 'ArrayList' because perhaps it could reduce the overall
size of the string references in GCL release mode, because it would (I
guess, not verified) reduce the number of unique longer strings in the
table. But it might depend on whether GCL 'optimizes' the string concat of
constant strings to a single string as another type of optimization or not,
before adding to its version of the 'string table'.




On Tue, Jan 15, 2019 at 7:36 AM Alex Harui  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"  wrote:
>
>
> > On Jan 14, 2019, at 8:04 PM, Alex Harui 
> 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"  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%2Fdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=WFiUn4fMJG4tOJvnzNU1XF2c0wDnEZooVHSRCxYvv14%3Dreserved=0
> >[2]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-pxdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=4Yo2A5fUq7KidRTM%2FDulBnElY2wK3QnWIYq0aNCKs84%3Dreserved=0
> >[3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percentdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=CIOgFzac6y50hSHsfXludv5M%2FUNhgiVti%2BenoigMHDo%3Dreserved=0
> >[4]
> 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Alex Harui]

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"  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  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" mailto:harbs.li...@gmail.com>> wrote:
> 
> 
>> On Jan 14, 2019, at 8:04 PM, Alex Harui  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"  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. 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Alex Harui]

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"  wrote:


> On Jan 14, 2019, at 8:04 PM, Alex Harui  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"  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%2Fdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=WFiUn4fMJG4tOJvnzNU1XF2c0wDnEZooVHSRCxYvv14%3Dreserved=0
>
[2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-pxdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=4Yo2A5fUq7KidRTM%2FDulBnElY2wK3QnWIYq0aNCKs84%3Dreserved=0
>
[3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percentdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=CIOgFzac6y50hSHsfXludv5M%2FUNhgiVti%2BenoigMHDo%3Dreserved=0
>
[4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9data=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=a6ohFKIGRTnga3ZqT%2FjC5KveWWl%2BamoqxqBd3Cu1Dhc%3Dreserved=0
>
[5]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-pxdata=02%7C01%7Caharui%40adobe.com%7C7665d25e270c40f5d22608d67a4e43b0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830873890782519sdata=bBffOQLT7DPeDr1NStzGyX20vFeRitOreVSO2RsMRFY%3Dreserved=0
> 
>> On Jan 14, 2019, at 5:04 PM, Carlos Rovira  
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.
>> 
>> 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Harbs]

> On Jan 14, 2019, at 8:04 PM, Alex Harui  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"  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%2Fdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=OqPiErny2yEEK3idQHYBr7Hgw3rlQY54v60oBdAC2RM%3Dreserved=0
>
> [2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-pxdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=rOapw6TeaGalJWgCSarZL0m8E%2BkpMm4Mx1junGLvN5w%3Dreserved=0
>
> [3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percentdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=vn7BOgw2zEWeNJjwidFSMfJ1NQnnZHdiFgT3544lI18%3Dreserved=0
>
> [4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9data=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=hgA%2FCiAW3%2F4OC9Z8LZNO9nhbypQd0h8LfxfbuJIwUGI%3Dreserved=0
>
> [5]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-pxdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=GSJOOTSYWvSqCW4isrC4EHro7Dbk6GMj4PFqi2D32S8%3Dreserved=0
> 
>> On Jan 14, 2019, at 5:04 PM, Carlos Rovira  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
>> 

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Alex Harui]

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"?

That said, are we sure that you can just switch to "em" and all other 
computations will "do the right thing"?

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.

Of course, I could be wrong,
-Alex

On 1/14/19, 8:39 AM, "Harbs"  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%2Fdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=OqPiErny2yEEK3idQHYBr7Hgw3rlQY54v60oBdAC2RM%3Dreserved=0

[2]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fengageinteractive.co.uk%2Fblog%2Fem-vs-rem-vs-pxdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=rOapw6TeaGalJWgCSarZL0m8E%2BkpMm4Mx1junGLvN5w%3Dreserved=0

[3]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkyleschaeffer.com%2Fcss-font-size-em-vs-px-vs-pt-vs-percentdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=vn7BOgw2zEWeNJjwidFSMfJ1NQnnZHdiFgT3544lI18%3Dreserved=0

[4]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40julienetienne%2Fpixels-are-dead-faa87cd8c8b9data=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=hgA%2FCiAW3%2F4OC9Z8LZNO9nhbypQd0h8LfxfbuJIwUGI%3Dreserved=0

[5]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F609517%2Fwhy-em-instead-of-pxdata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600922851sdata=GSJOOTSYWvSqCW4isrC4EHro7Dbk6GMj4PFqi2D32S8%3Dreserved=0

> On Jan 14, 2019, at 5:04 PM, Carlos Rovira  
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%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7Ca76a385efb904626fa7d08d67a3ed42b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636830807600932856sdata=fbF68iMSN5QZnK3eMSUT%2FKybfkr5T8ZHQwfGOX7h848%3Dreserved=0

Re: Should we change width/height to use EM instead PX?? (was: Re: Using em vs px)

[Harbs]

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://benfrain.com/just-use-pixels/
[2]https://engageinteractive.co.uk/blog/em-vs-rem-vs-px
[3]https://kyleschaeffer.com/css-font-size-em-vs-px-vs-pt-vs-percent
[4]https://medium.com/@julienetienne/pixels-are-dead-faa87cd8c8b9
[5]https://stackoverflow.com/questions/609517/why-em-instead-of-px

> On Jan 14, 2019, at 5:04 PM, Carlos Rovira  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
> http://about.me/carlosrovira