IMO, regarding layouts, there will be many kinds of layouts. In Royale we want
to give people choices.
-The emulation component sets will mimic Flex layout behavior where % is
calculated on available space. I'm pretty sure these will use absolute
positioning and never set element.style.width to a percentage. In these
layouts, replicating Flex behavior is more important than performance.
-Most of the Basic layouts (and hopefully lots of other layouts) are simply
intended to produce common patterns in the DOM. No promise of backward
compatibility with Flex. Instead of thinking about Flex layouts when writing
these Basic layouts, the goal should be to work from the browser backwards.
IOW, if you looked at how 100 different existing websites handle some aspect of
layout, find the common/popular pattern, and create a Royale layout bead that
sets styles on the parent and/or children in that pattern. That's why
VerticalLayout just sets display:block on every child, or some other layout
sets display:flex. The goal is to be able to have Royale efficiently produce
the same DOM that other sites are using successfully today.
-Other layouts may address common problems. If you go to StackOverflow you can
find lots of people running into the same HTML layout problem over and over
again. If we can encapsulate the solution on SO, we will save lots of people
lots of time. We won't worry too much about performance and code size of these
solutions. I think we sort of have a few like that already for handling nested
divs with percentage sizes in display:flex layouts.
-Custom layouts. We might someday make a 3DividedPanes layout that handles the
layout of 3 panes like many email clients or our ASDoc if that helps save
people time and hassle. And there will be custom layouts for DataGrid and
other complex components.
So yeah, % works differently in Royale compared to Flex for some layouts, but
may not for other layouts. It is ok if Harbs app couldn't use some of our
Basic layouts without adding calc(). If other sites can go to production
without using calc() then our simplest layouts should allow them to do so. If
there is a pattern where many apps use calc() a certain way, that should be
encapsulated into another layout in Royale.
My 2 cents,
-Alex
On 6/11/18, 4:27 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
I think Yishay is on track. I'm still changing my mind on how things are on
html, different to flex.
For example, in flexbox there's no gap number, but the layout knows it
should be gap between elements (with "space-between").
So Flexbox put the space, how many? that depends on parent sizes...to make
the simulation without space-between we use margins...
At the end, are different approaches, and sometimes is very difficult to
handle as we did in Flex, maybe not impossible. What I'm trying
to do now is see get more experience and see how to get the best solution
of both worlds...
2018-06-11 12:25 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> The problem is that the child does not have a way of knowing what the
> extra space surrounding the parent (such as padding) will be.
>
> One day, I’m probably going to work on a constrained layout…
>
> > On Jun 11, 2018, at 1:20 PM, Yishay Weiss <yishayj...@hotmail.com>
> wrote:
> >
> > I guess we’re a bit prejudiced coming from Flex. Once you let go of the
> notion that percentages are not of the available space but of the total
> parent space, it sort of makes sense.
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C78b99b908a0c471ac54d08d5cf8e48b6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636643132375937723&sdata=xj27KElCDdfT%2BH5%2FSB%2FwCaF7JIcvJ%2FNyDHslDtqLhak%3D&reserved=0
