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
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
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
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
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
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
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
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 =
> 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,
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
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
11 matches
Mail list logo
