You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/02/21 18:42:30 UTC
[FlexJS]Layout redux
We’re really struggling with layout.
Yishay just mentioned the fact that padding is not working, but the problems seem to go much deeper than that.
1. VerticalLayout has the following code:
for (i = 0; i < n; i++)
{
var child:WrappedHTMLElement = children[i];
child.flexjs_wrapper.setDisplayStyleForLayout('block');
if (child.style.display === 'none')
{
child.flexjs_wrapper.setDisplayStyleForLayout('block');
}
else
{
// block elements don't measure width correctly so set to inline for a second
child.style.display = 'inline-block';
maxWidth = Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
child.style.display = 'block';
}
child.flexjs_wrapper.dispatchEvent('sizeChanged');
}
There is a number of problems that I can see with this. Firstly, it’s horribly inefficient:
child.style.display = 'inline-block';
maxWidth = Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
The above will force a browser redraw at every step of the loop. If you have hundreds of children, there will be hundreds of redraws just to figure out the children width. If anything, there should probably be three loops: One to set the inline-blocks, The second to measure all the children (the first measure would trigger a redraw, but subsequent ones not) The third to set inline-block back.
Secondly, there’s only a need to measure the children if the container is sized to content. If the container has a fixed width or a percentage width, I don’t see why the children should be measured at all. The only exception I can see is if there is overflow:auto.
Thirdly, I don’t understand how setting the child to inline-block helps. What about the grandchildren? Don’t those need to be measured too?
Fourthly, Both Horizontal and VerticalLayout have code which temporarily sets inline-block. BasicLayout does not, and I don’t understand why there’s a difference. (BasicLayout has the same re-rendering problem though.)
2.
if (!hasWidth && n > 0 && !isNaN(maxWidth)) {
var pl:String = scv['padding-left'];
var pr:String = scv['padding-right'];
var npl:int = parseInt(pl.substring(0, pl.length - 2), 10);
var npr:int = parseInt(pr.substring(0, pr.length - 2), 10);
maxWidth += npl + npr;
contentView.width = maxWidth;
}
This seems totally wrong. Why is the padding being added when we’re using box-sizing: border-box?
3. Percentage size seems to be set based on the children rather than the parents.
4. I’m not sure I understand the layout lifecycle very well. We have had cases where children did not seem to be layout, and forcing a layout seemed to be very difficult to do.
Harbs
Re: [FlexJS]Layout redux
Posted by piotrz <pi...@gmail.com>.
+1 for that.
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layout-redux-tp59725p59736.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS]Layout redux
Posted by yishayw <yi...@hotmail.com>.
Alex Harui wrote
> For sure, we need to the the JS side right and then worry about the SWF
> side. I think there are way fewer behavior issues on the SWF side to deal
> with.
If there are less issues with the SWF side, wouldn't it make sense to try
and emulate the SWF side by using absolute positioning? It would have the
benefit of being easier to maintain, as bugs would probably appear in both
versions and fixed together. There can also be more code reused across
implementations.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Layout-redux-tp59725p59747.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS]Layout redux
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Peter,
although I still not look into the code, that seems very promising. As you
say we need
a component with just one div, and then we could have more of then for
chrome and other things.
in old Flex Group was a container that doesn't have the width of subitems
into account, so maybe
the FlexJS Group should not be the same as the Flex Group...
2017-02-22 22:40 GMT+01:00 Peter Ent <pe...@adobe.com>:
> Hi,
>
> I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
> well as a change to DataBindingExample to use them. I consider these
> temporary and would like to make them be the VerticalLayout and
> HorizontalLayout in the near future.
>
> If you look at their code you will see the COMPILE::JS side is very, very
> short now. All it does it set the display:flex and flow-flow: row|column
> on the contentView of the layout host. The SWF side remains unchanged for
> now. I did not make it possible yet to use Flexbox properties of
> align-items, justify-content, etc.
>
> I spent most of the time coming to terms with the Container. I've left it
> alone for now, but I think it needs work. First, padding is not working
> for the container, so that will not have any affect.
>
> I think the Container needs to be redone. I also think it does too much or
> we need a lighter weight component like Group. Container generates two
> <div>s for the HTML side. This is to allow for "chrome" such as headers
> and footers. More specifically, it was designed to make it possible to
> write Panel (maybe Panel should be a composite component and moved into
> Express).
>
> The JS code generated for Container <div>s provides style information that
> is too much, really, unless you add in a chrome item. I think if there is
> a lighter component that just provides a box that surrounds its children
> it would help clean things up. The JS side should then be easier to style.
>
> If you want scrolling, then you'd have to use a Container and we can make
> the Container use a scrolling viewport by default then, since Group would
> be the default non-scrolling offering.
>
> Regards,
> Peter
>
>
> On 2/22/17, 12:03 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >Hi Peter, that sound very good :)
> >thanks!
> >
> >2017-02-22 16:53 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >
> >> That's a good strategy. My experiments this morning look like Flexbox is
> >> the way to go. Its widely supported now and seems pretty easy to use.
> >>
> >> I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
> >> them extend the current versions just so the SWF side stays the same for
> >> right now. The JS side will implement Flexbox. Then we can all try it
> >>out
> >> and see how it behaves. If that's good, I can replace the current JS
> >> version with the Flexbox version and then work on the SWF side to make
> >>it
> >> compatible.
> >>
> >> Will keep you all posted.
> >>
> >> —peter
> >>
> >> On 2/22/17, 10:16 AM, "carlos.rovira@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >> wrote:
> >>
> >> >That looks very promising Peter. Look forward to see some progress :)
> >> >If flexbox is the future, I think we should always look to go with that
> >> >specs, and in case that still is not in some browsers, search for a
> >> >polyfill that could do the job for not supported browsers for now. At
> >>the
> >> >end browsers will support it, and polyfill will end in no use (and we
> >> >could
> >> >eventually remove)
> >> >
> >> >2017-02-22 14:47 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >> >
> >> >> I'm going to try some experiments in my own space. Basically,
> >>figuring
> >> >>out
> >> >> the best way to do simple layouts using CSS - vertical and horizontal
> >> >>with
> >> >> alignment options (center, left, right for vertical, top, middle,
> >>bottom
> >> >> for horizontal). Because alignment will probably require more cycles
> >> >>when
> >> >> implemented in SWF, I will look to making these beads or
> >> >> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
> >> >> percentage sizes as well. A better understanding, on my part, of
> >> >>HTML/CSS
> >> >> capabilities will really help.
> >> >>
> >> >> Once I think the JS side is simple enough, I'll mimic then for the
> >>SWF
> >> >> side. I really don't see why this should be complex. The big issue on
> >> >>the
> >> >> SWF side is not always knowing the size of the item that you want to
> >> >> position and size.
> >> >>
> >> >> I have been reading about CSS Flexbox which seems like it is the
> >>future
> >> >>of
> >> >> layout for HTML/CSS. It seems to be widely supported at this point.
> >>The
> >> >> next generation, Grid, is still in the W3C draft phase, but that
> >>will be
> >> >> handy too once it gets adopted. I'll look into using various
> >>settings of
> >> >> display and position first before resorting to Flexbox.
> >> >>
> >> >> —peter
> >> >>
> >> >> On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
> >> >>
> >> >> >
> >> >> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
> >> >> >>
> >> >> >> It is probably time for our annual "revisiting of the layout
> >>code".
> >> >>I
> >> >> >> think if you look at source code history, Peter or I do this
> >>every so
> >> >> >> often as we get more examples to work with.
> >> >> >>
> >> >> >> From memory, there are issues like whether we have to set
> >> >> >> position:relative or not that came out of the MDL swc. And
> >>when/if
> >> >>we
> >> >> >> need to set the width on a parent for percentage width to work in
> >>the
> >> >> >> children/grandchildren.
> >> >> >>
> >> >> >> It is great to finally have some people actually paying attention
> >> >>that
> >> >> >> know how this stuff is actually normally done in JS. Peter and I
> >> >>were
> >> >> >> mostly guessing since, if you think about it, we were basically
> >>doing
> >> >> >>Flex
> >> >> >> until we got into FlexJS and are not experienced in HTML/JS.
> >> >> >>
> >> >> >> So, fundamentally, if you have to stack things vertically, should
> >>you
> >> >> >>use
> >> >> >> display:block? If you have to line up a bunch of divs
> >>horizontally,
> >> >> >> should you use display:inline-block?
> >> >> >
> >> >> >It depends. If everything is position:relative, then theoretically,
> >> >>yes.
> >> >> >The problem with position:relative in my experience is that it’s too
> >> >> >unpredictable. I can’t give examples right now, but I know I spent
> >> >> >countless hours struggling with getting HTML to correctly position
> >> >> >elements using relative positioning. So while theoretically, using
> >>CSS
> >> >> >and built-in browser positioning sounds good, I think there are
> >>enough
> >> >> >edge cases to make it really difficult to be reliable in practice.
> >> >> >
> >> >> >> Is there a better way to do BasicLayout? We ended up using a
> >> >>completely
> >> >> >> handwritten set of code to essentially make everything use
> >>absolute
> >> >> >> positioning.
> >> >> >>
> >> >> >> Is border-box working as expected? Do you set the height/width to
> >> >> >>include
> >> >> >> the padding or not?
> >> >> >
> >> >> >Yes. The size includes the padding, but padding only serves a
> >>function
> >> >>if
> >> >> >the children are positioned relative. Currently, that’s not the case
> >> >> >AFAICT.
> >> >> >
> >> >> >
> >> >> >> I think some layouts can use CSS but others have to be written in
> >> >>code
> >> >> >>to
> >> >> >> override default browser behavior. But I'd love to be wrong about
> >> >>that
> >> >> >> (at least, without relying on latest browsers or polyfills).
> >> >> >>
> >> >> >> And finally, are there ways we can call the layout fewer times
> >>than
> >> >>we
> >> >> >> currently do?
> >> >> >
> >> >> >I don’t understand the current layout lifecycle well enough. I do
> >>know
> >> >> >that we’ve observed layouts consistently happening twice, so I’d
> >>guess
> >> >> >that the answer would be yes.
> >> >> >
> >> >> >Ultimately, it would be great to have a layout which relies
> >>exclusively
> >> >> >on CSS, and if that can be achieved, it would be the most efficient
> >>way
> >> >> >to lay things out in HTML.
> >> >> >
> >> >> >My belief is that it’s unattainable for anything but the simplest
> >> >>layouts
> >> >> >to rely on CSS. If we are not relying on CSS, then I believe the
> >>best
> >> >>way
> >> >> >to go is to calculate the layout almost exclusively in javascript
> >>and
> >> >> >layout pretty much everything with position:absolute. The only
> >> >>exception
> >> >> >for that would be elements which should truly reflow based on the
> >>HTML
> >> >> >layout (i.e. text and inline images, possibly image grids, etc.) The
> >> >>more
> >> >> >reliance we have on CSS, the more we’re opening the layout to bugs.
> >> >> >Additionally, the more the code has to examine the results of
> >>browser
> >> >> >rendering, the less efficient the JS code will be. Javascript alone
> >>is
> >> >> >really fast in modern engines. It’s when there’s DOM interactions
> >>that
> >> >> >Javascript hits a performance wall. The more we can keep the
> >> >>calculations
> >> >> >in pure JS and avoid DOM interaction, the better.
> >> >> >
> >> >> >So I would propose two sets of Layouts:
> >> >> >CSSLayout which might or might not have sub-layouts to do bare-b
> >>ones
> >> >> >layout optimized for as little JS code to run as possible and allow
> >> >> >settings to be set using CSS. (cheap as possible PAYG layout)
> >> >> >FlexLayout which would have vertical,horizontal,absolute,grid, etc.
> >> >> >
> >> >> >FlexLayout would use FlexJS properties to calculate layout, and
> >>support
> >> >> >percentage, left,right,top,bottom properties to do proper
> >>constrained
> >> >> >layout. I think that constrained layout (right,left,top,bottom) is
> >> >>common
> >> >> >enough that it doesn’t warrant a separate layout as long as we have
> >>the
> >> >> >bare-bones CSSLayout for cases that need it.
> >> >> >
> >> >> >> For sure, we need to the the JS side right and then worry about
> >>the
> >> >>SWF
> >> >> >> side. I think there are way fewer behavior issues on the SWF
> >>side to
> >> >> >>deal
> >> >> >> with.
> >> >> >
> >> >> >Agreed.
> >> >> >
> >> >> >Harbs
> >> >> >
> >> >> >> My 2 cents,
> >> >> >> -Alex
> >> >> >>
> >> >> >> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
> >> >> >>
> >> >> >>> I think this is generally a good approach.
> >> >> >>>
> >> >> >>> I've been thinking that we have some refactoring to do which
> >>might
> >> >> >>>help.
> >> >> >>> For instance, Core should probably be edited to include
> >>interfaces,
> >> >> >>> events, and whatever else works across all packages. HTML should
> >> >> >>>probably
> >> >> >>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that
> >> >>wants
> >> >> >>> HTML+ActionScript can use that and then use CSS to do all their
> >> >> >>>layouts;
> >> >> >>> HTML would not have a SWF version.
> >> >> >>>
> >> >> >>> Then Basic could be SWF & JS with layouts that are light on the
> >>JS
> >> >>side
> >> >> >>> using CSS and AS code to mimic them on the SWF side. Express
> >>would
> >> >>do
> >> >> >>>what
> >> >> >>> it is doing now and compose components by extending the Basic set
> >> >>and
> >> >> >>> adding common beads.
> >> >> >>>
> >> >> >>> I've been hung up with the JS side having stuck on the display
> >>and
> >> >> >>> position values and deferring them might be the best solution.
> >> >> >>>
> >> >> >>> —peter
> >> >> >>>
> >> >> >>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of
> Carlos
> >> >> >>>Rovira"
> >> >> >>> <carlos.rovira@gmail.com on behalf of
> >>carlos.rovira@codeoscopic.com
> >> >
> >> >> >>> wrote:
> >> >> >>>
> >> >> >>>> Hi Peter,
> >> >> >>>>
> >> >> >>>> it seems HTML rely for this task heavily on CSS to the point
> >>that
> >> >> >>>>almost
> >> >> >>>> nothing is done in html or js code.
> >> >> >>>> So maybe we are not in the right way for HTML platform and we
> >> >>should
> >> >> >>>>make
> >> >> >>>> our code be mainly CSS.
> >> >> >>>> An example is here:
> >> >> >>>>
> >> >> >>>> https://css-tricks.com/snippets/sass/placing-items-circle/
> >> >> >>>>
> >> >> >>>> Another point is SWF. I'm not focusing in that output and even I
> >> >> >>>>didn't
> >> >> >>>> compile to SWF for long time, so don't know how
> >> >> >>>> is looking, but for what I saw in other discussions seems that
> >> >>Flash
> >> >> >>>> needs
> >> >> >>>> to implement the old Flex architecture of
> >> >> >>>> updateDisplayList to manage refresh to avoid continuous
> >>redrawing
> >> >>of
> >> >> >>>>the
> >> >> >>>> screen.
> >> >> >>>>
> >> >> >>>> So my bet is that our AS3 layout components should do:
> >> >> >>>>
> >> >> >>>> 1.- In JS -> add className to "some-class-layout" (for example
> >>for
> >> >> >>>> circle,
> >> >> >>>> if we have circle-layout, we should have a "circleLayout" css
> >>class
> >> >> >>>> selector, that we could assign to out flexjs "list component"
> >> >> >>>>
> >> >> >>>> 2.- in SWF -> we should stick with the way this was done in
> >>Flex4
> >> >>but
> >> >> >>>> implementing as a bead and with the "updateDisplayList"
> >>performance
> >> >> >>>>
> >> >> >>>> What do you think?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >> >> >>>>
> >> >> >>>>> A lot of this work is mine and it seems to need to be thought
> >> >>through
> >> >> >>>>> once
> >> >> >>>>> again. The dichotomy of SWF & JS has presented problems for me
> >>in
> >> >>the
> >> >> >>>>> past.
> >> >> >>>>>
> >> >> >>>>> Maybe the layouts, for JS platform, should do as little as
> >> >>possible,
> >> >> >>>>> replying on CSS as much as possible. Then make the SWF platform
> >> >>mimic
> >> >> >>>>> that.
> >> >> >>>>>
> >> >> >>>>> One issue that comes up for me is that we automatically set
> >> >>display
> >> >> >>>>>and
> >> >> >>>>> position for every element soon after its created. If you were
> >>to
> >> >> >>>>> hand-write the HTML you probably would not do that.
> >> >> >>>>>
> >> >> >>>>> So perhaps FlexJS should not set these styles at all and
> >>instead
> >> >>let
> >> >> >>>>> the
> >> >> >>>>> layout set them if the layout even needs to do that.
> >> >> >>>>>
> >> >> >>>>> Thoughts?
> >> >> >>>>> ‹peter
> >> >> >>>>>
> >> >> >>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
> >> >> >>>>>
> >> >> >>>>>> We¹re really struggling with layout.
> >> >> >>>>>>
> >> >> >>>>>> Yishay just mentioned the fact that padding is not working,
> >>but
> >> >>the
> >> >> >>>>>> problems seem to go much deeper than that.
> >> >> >>>>>>
> >> >> >>>>>> 1. VerticalLayout has the following code:
> >> >> >>>>>> for (i = 0; i < n; i++)
> >> >> >>>>>> {
> >> >> >>>>>> var
> >> >>child:WrappedHTMLElement =
> >> >> >>>>> children[i];
> >> >> >>>>>> child.flexjs_wrapper.
> >> >> >>>>> setDisplayStyleForLayout('block');
> >> >> >>>>>> if (child.style.display
> >>===
> >> >> >>>>> 'none')
> >> >> >>>>>> {
> >> >> >>>>>>
> >> >>child.flexjs_wrapper.
> >> >> >>>>> setDisplayStyleForLayout('block');
> >> >> >>>>>> }
> >> >> >>>>>> else
> >> >> >>>>>> {
> >> >> >>>>>> // block elements
> >> >>don't
> >> >> >>>>> measure width correctly so set to inline
> >> >> >>>>>> for a second
> >> >> >>>>>>
> >>child.style.display
> >> >>=
> >> >> >>>>> 'inline-block';
> >> >> >>>>>> maxWidth =
> >> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >> >> >>>>>>
> >>child.style.display
> >> >>=
> >> >> >>>>> 'block';
> >> >> >>>>>> }
> >> >> >>>>>> child.flexjs_wrapper.
> >> >> >>>>> dispatchEvent('sizeChanged');
> >> >> >>>>>> }
> >> >> >>>>>>
> >> >> >>>>>> There is a number of problems that I can see with this.
> >>Firstly,
> >> >> >>>>>>it¹s
> >> >> >>>>>> horribly inefficient:
> >> >> >>>>>>
> >>child.style.display
> >> >>=
> >> >> >>>>> 'inline-block';
> >> >> >>>>>> maxWidth =
> >> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >> >> >>>>>> The above will force a browser redraw at every step of the
> >>loop.
> >> >>If
> >> >> >>>>> you
> >> >> >>>>>> have hundreds of children, there will be hundreds of redraws
> >> >>just to
> >> >> >>>>>> figure out the children width. If anything, there should
> >> >>probably be
> >> >> >>>>>> three loops: One to set the inline-blocks, The second to
> >>measure
> >> >>all
> >> >> >>>>> the
> >> >> >>>>>> children (the first measure would trigger a redraw, but
> >> >>subsequent
> >> >> >>>>> ones
> >> >> >>>>>> not) The third to set inline-block back.
> >> >> >>>>>>
> >> >> >>>>>> Secondly, there¹s only a need to measure the children if the
> >> >> >>>>>>container
> >> >> >>>>> is
> >> >> >>>>>> sized to content. If the container has a fixed width or a
> >> >>percentage
> >> >> >>>>>> width, I don¹t see why the children should be measured at all.
> >> >>The
> >> >> >>>>> only
> >> >> >>>>>> exception I can see is if there is overflow:auto.
> >> >> >>>>>>
> >> >> >>>>>> Thirdly, I don¹t understand how setting the child to
> >>inline-block
> >> >> >>>>> helps.
> >> >> >>>>>> What about the grandchildren? Don¹t those need to be measured
> >> >>too?
> >> >> >>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
> >> >> >>>>> temporarily
> >> >> >>>>>> sets inline-block. BasicLayout does not, and I don¹t
> >>understand
> >> >>why
> >> >> >>>>>> there¹s a difference. (BasicLayout has the same re-rendering
> >> >>problem
> >> >> >>>>>> though.)
> >> >> >>>>>> 2.
> >> >> >>>>>> if (!hasWidth && n > 0 &&
> >> >> >>>>> !isNaN(maxWidth)) {
> >> >> >>>>>> var pl:String =
> >> >> >>>>> scv['padding-left'];
> >> >> >>>>>> var pr:String =
> >> >> >>>>> scv['padding-right'];
> >> >> >>>>>> var npl:int =
> >> >> >>>>> parseInt(pl.substring(0, pl.length - 2), 10);
> >> >> >>>>>> var npr:int =
> >> >> >>>>> parseInt(pr.substring(0, pr.length - 2), 10);
> >> >> >>>>>> maxWidth += npl + npr;
> >> >> >>>>>> contentView.width =
> >> >>maxWidth;
> >> >> >>>>>> }
> >> >> >>>>>>
> >> >> >>>>>> This seems totally wrong. Why is the padding being added when
> >> >>we¹re
> >> >> >>>>> using
> >> >> >>>>>> box-sizing: border-box?
> >> >> >>>>>>
> >> >> >>>>>> 3. Percentage size seems to be set based on the children
> >>rather
> >> >>than
> >> >> >>>>> the
> >> >> >>>>>> parents.
> >> >> >>>>>>
> >> >> >>>>>> 4. I¹m not sure I understand the layout lifecycle very well.
> >>We
> >> >>have
> >> >> >>>>> had
> >> >> >>>>>> cases where children did not seem to be layout, and forcing a
> >> >>layout
> >> >> >>>>>> seemed to be very difficult to do.
> >> >> >>>>>>
> >> >> >>>>>> Harbs
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> --
> >> >> >>>>
> >> >> >>>> Carlos Rovira
> >> >> >>>> Director General
> >> >> >>>> M: +34 607 22 60 05
> >> >> >>>> http://www.codeoscopic.com
> >> >> >>>> http://www.avant2.es
> >> >> >>>>
> >> >> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
> >> >> >>>>contener
> >> >> >>>> información privilegiada o confidencial. Si ha recibido este
> >> >>mensaje
> >> >> >>>>por
> >> >> >>>> error, le rogamos que nos lo comunique inmediatamente por esta
> >> >>misma
> >> >> >>>>vía
> >> >> >>>> y
> >> >> >>>> proceda a su destrucción.
> >> >> >>>>
> >> >> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >> >> >>>> comunicamos
> >> >> >>>> que sus datos forman parte de un fichero cuyo responsable es
> >> >> >>>>CODEOSCOPIC
> >> >> >>>> S.A. La finalidad de dicho tratamiento es facilitar la
> >>prestación
> >> >>del
> >> >> >>>> servicio o información solicitados, teniendo usted derecho de
> >> >>acceso,
> >> >> >>>> rectificación, cancelación y oposición de sus datos
> >>dirigiéndose a
> >> >> >>>> nuestras
> >> >> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
> >> >> >>>>documentación
> >> >> >>>> necesaria.
> >> >> >>>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >
> >> >Carlos Rovira
> >> >Director General
> >> >M: +34 607 22 60 05
> >> >http://www.codeoscopic.com
> >> >http://www.avant2.es
> >> >
> >> >Este mensaje se dirige exclusivamente a su destinatario y puede
> >>contener
> >> >información privilegiada o confidencial. Si ha recibido este mensaje
> >>por
> >> >error, le rogamos que nos lo comunique inmediatamente por esta misma
> >>vía y
> >> >proceda a su destrucción.
> >> >
> >> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >> >comunicamos
> >> >que sus datos forman parte de un fichero cuyo responsable es
> >>CODEOSCOPIC
> >> >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> >> >servicio o información solicitados, teniendo usted derecho de acceso,
> >> >rectificación, cancelación y oposición de sus datos dirigiéndose a
> >> >nuestras
> >> >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> >> >necesaria.
> >>
> >>
> >
> >
> >--
> >
> >Carlos Rovira
> >Director General
> >M: +34 607 22 60 05
> >http://www.codeoscopic.com
> >http://www.avant2.es
> >
> >Este mensaje se dirige exclusivamente a su destinatario y puede contener
> >información privilegiada o confidencial. Si ha recibido este mensaje por
> >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> >proceda a su destrucción.
> >
> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >comunicamos
> >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> >servicio o información solicitados, teniendo usted derecho de acceso,
> >rectificación, cancelación y oposición de sus datos dirigiéndose a
> >nuestras
> >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> >necesaria.
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
First, I like the idea of moving as much into CSS as possible, at least to
the extent we can support in on the SWF side.
Secondly, I think the layouts setting the display makes sense in this
case, based on what Harbs said.
I was thinking of this:
A. UIBase does not set position and display. The values of x, y, width,
height also do not set the corresponding styles (left, top, width, right).
Because we have wrapped elements now and not derived on the SWF side,
setting x, y, width, height do not have to automatically set the
corresponding values on the wrapped element; this will be done by a layout.
B. Container is lightweight and wraps its children so that it can be moved
and displayed as a single unit. Effects would also apply to all items in a
Container.
C. You may size a Container explicitly, but it will clip its children. No
support for scrolling.
D. Containers have layouts and it is the layouts that use the properties
set on the UIBase children. So the BasicLayout would set the children of
the div to display:block, position:absolute and then use the x, y, width,
height properties to set the corresponding styles. This goes against the
above idea of putting everything in CSS, but the point of a layout is to
programmatically size and position items. The VerticalLayout would set the
display:flex of the Container/div and NOT set display/position, etc styles
on its children. Then CSS can be used to set the children's styles; CSS
can also be used to set alignment values on the entire Container.
E. We could have a NoLayout layout that does nothing (the default for a
Container being BasicLayout).
F. Views (every application needs a View) as Containers and in CSS, have
their display:block, position:absolute. This enables the position:absolute
of their children and so forth to have their top, left, bottom, right
styles work correctly.
G. We have ScrollableContainer and ChromeContainer to supply the missing
parts in the PAYG system.
This approach (or something like it) would be in keeping with HTML/CSS
leading the way and then we'd just have to get SWF to follow along. I
don't think that's too much of a problem as long as the SWF version of the
layouts can read the CSS and get the values.
I'm sure there are conditions when a layout isn't used, such as building a
component via its ViewBead, but I think they can be handled by either
introducing the layout concept to those component (e.g. DataGridLayout to
be used by the DataGrid component) or having the ViewBead explicitly
change the values or have them pre-set in defaults.css.
Whew.
‹peter
On 2/22/17, 5:10 PM, "Harbs" <ha...@gmail.com> wrote:
>For that to work, the bead will need to append the class name of the
>component. It cannot be applied to the bead itself.
>
>Harbs
>
>> On Feb 23, 2017, at 12:05 AM, Carlos Rovira
>><ca...@codeoscopic.com> wrote:
>>
>> Hi Peter,
>>
>> one of the things I'd want to do is remove "styles" in source code and
>>move
>> to css.
>> For example:
>>
>> viewBead.contentView.element.style["display"] = "flex";
>>
>> What do you think about to move this to default.css class, i.e.:
>>
>> HorizontalFlexLayout {
>> display: flex;
>> ...
>> }
>>
>> I think we should move all that kind of code to css so we could tweak
>> (change/modifiy) easily if we need
>>
>> thanks
>>
>>
>> 2017-02-22 23:00 GMT+01:00 Harbs <ha...@gmail.com>:
>>
>>> I totally agree with this.
>>>
>>> There should be a simple Container (with H and V variants) and a
>>>separate
>>> ChromeContainer. The vast majority of Containers do not need the extra
>>>div.
>>>
>>> Moving Panel to Express is an option, but I¹m not sure it¹s necessary.
>>>
>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pe...@adobe.com> wrote:
>>>>
>>>> I think the Container needs to be redone. I also think it does too
>>>>much
>>> or
>>>> we need a lighter weight component like Group. Container generates two
>>>> <div>s for the HTML side. This is to allow for "chrome" such as
>>>>headers
>>>> and footers. More specifically, it was designed to make it possible to
>>>> write Panel (maybe Panel should be a composite component and moved
>>>>into
>>>> Express).
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Carlos Rovira
>> Director General
>> M: +34 607 22 60 05
>> http://www.codeoscopic.com
>> http://www.avant2.es
>>
>> Este mensaje se dirige exclusivamente a su destinatario y puede contener
>> información privilegiada o confidencial. Si ha recibido este mensaje por
>> error, le rogamos que nos lo comunique inmediatamente por esta misma
>>vía y
>> proceda a su destrucción.
>>
>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>comunicamos
>> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>> servicio o información solicitados, teniendo usted derecho de acceso,
>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>>nuestras
>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>> necesaria.
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
For that to work, the bead will need to append the class name of the component. It cannot be applied to the bead itself.
Harbs
> On Feb 23, 2017, at 12:05 AM, Carlos Rovira <ca...@codeoscopic.com> wrote:
>
> Hi Peter,
>
> one of the things I'd want to do is remove "styles" in source code and move
> to css.
> For example:
>
> viewBead.contentView.element.style["display"] = "flex";
>
> What do you think about to move this to default.css class, i.e.:
>
> HorizontalFlexLayout {
> display: flex;
> ...
> }
>
> I think we should move all that kind of code to css so we could tweak
> (change/modifiy) easily if we need
>
> thanks
>
>
> 2017-02-22 23:00 GMT+01:00 Harbs <ha...@gmail.com>:
>
>> I totally agree with this.
>>
>> There should be a simple Container (with H and V variants) and a separate
>> ChromeContainer. The vast majority of Containers do not need the extra div.
>>
>> Moving Panel to Express is an option, but I’m not sure it’s necessary.
>>
>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pe...@adobe.com> wrote:
>>>
>>> I think the Container needs to be redone. I also think it does too much
>> or
>>> we need a lighter weight component like Group. Container generates two
>>> <div>s for the HTML side. This is to allow for "chrome" such as headers
>>> and footers. More specifically, it was designed to make it possible to
>>> write Panel (maybe Panel should be a composite component and moved into
>>> Express).
>>
>>
>>
>>
>
>
> --
>
> Carlos Rovira
> Director General
> M: +34 607 22 60 05
> http://www.codeoscopic.com
> http://www.avant2.es
>
> Este mensaje se dirige exclusivamente a su destinatario y puede contener
> información privilegiada o confidencial. Si ha recibido este mensaje por
> error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> proceda a su destrucción.
>
> De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> servicio o información solicitados, teniendo usted derecho de acceso,
> rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> necesaria.
Re: [FlexJS]Layout redux
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Peter,
one of the things I'd want to do is remove "styles" in source code and move
to css.
For example:
viewBead.contentView.element.style["display"] = "flex";
What do you think about to move this to default.css class, i.e.:
HorizontalFlexLayout {
display: flex;
...
}
I think we should move all that kind of code to css so we could tweak
(change/modifiy) easily if we need
thanks
2017-02-22 23:00 GMT+01:00 Harbs <ha...@gmail.com>:
> I totally agree with this.
>
> There should be a simple Container (with H and V variants) and a separate
> ChromeContainer. The vast majority of Containers do not need the extra div.
>
> Moving Panel to Express is an option, but I’m not sure it’s necessary.
>
> > On Feb 22, 2017, at 11:40 PM, Peter Ent <pe...@adobe.com> wrote:
> >
> > I think the Container needs to be redone. I also think it does too much
> or
> > we need a lighter weight component like Group. Container generates two
> > <div>s for the HTML side. This is to allow for "chrome" such as headers
> > and footers. More specifically, it was designed to make it possible to
> > write Panel (maybe Panel should be a composite component and moved into
> > Express).
>
>
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
I totally agree with this.
There should be a simple Container (with H and V variants) and a separate ChromeContainer. The vast majority of Containers do not need the extra div.
Moving Panel to Express is an option, but I’m not sure it’s necessary.
> On Feb 22, 2017, at 11:40 PM, Peter Ent <pe...@adobe.com> wrote:
>
> I think the Container needs to be redone. I also think it does too much or
> we need a lighter weight component like Group. Container generates two
> <div>s for the HTML side. This is to allow for "chrome" such as headers
> and footers. More specifically, it was designed to make it possible to
> write Panel (maybe Panel should be a composite component and moved into
> Express).
Re: [FlexJS]Layout redux
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/17, 11:42 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Hi,
>
>I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout
>that adds code for the SWF side. In general, the SWF and JS sides look the
>same. There are some differences which I'm working on, but these should be
>usable.
Sounds promising!
>
>In doing this I've uncovered some incomplete work and/or exposed some
>issues. These are, in no particular order:
>
>UIBase vs. IUIBase. Since some of our components do not inherit from
>UIBase, you cannot cast everything to this class. Now as we should really
>use interfaces and not classes, casting to IUIBase generally works.
>However, IUIBase is missing a lot of useful function prototypes which is
>why there is a lot of casting to UIBase. I'd like to see IUIBase become
>more complete. The layout code does a lot of extra, unnecessary casts on
>the SWF side.
IUIBase is intended to be the minimum interface for being a displayable
object. Interfaces should be PAYG just like everything else. Some
displayable objects will never be subjects of a re-usable layout
algorithm. Some code will simply create two IUIBases and place them at
known locations. Like in the up/down buttons in a NumericStepper.
There should be other interfaces already like ILayoutXXX that are meant to
be the contract between layouts and parents of children. Layout classes
should be using those interfaces instead of UIBase. Feel free to
composite interfaces into a single "uber" interface, but be careful about
making the contract too difficult or heavy.
>
>JS vs SWF layouts. When you think about it, once you've set up your <div>
>to have the property display style, adding/removing/changing elements gets
>taken care by the browser. If I set up my <div> with display:flex and then
>put in a number of elements and start changing them via JavaScript, they
>just change. Of course that doesn't work on the SWF side because there
>isn't anything to size and position elements except the layout algorithms.
>But the events that trigger those algorithms to execute are in the
>Container class which causes the layout - SWF or JS - to execute.
>Basically, it seems unnecessary to re-execute JS layouts every time since
>the browser does the work. I think this should be revisited.
The JS side of layouts should only be listening for child added/removed if
they need to touch the child in some way (set a display style or
position:relative). Otherwise yes, JS layouts do not need to run on
added/removed changes.
>
>Padding. This still isn't working right for the Container with layout.
>Part of the problem is that padding on the SWF side isn't really padding.
>What it does it offset the inner contentArea. This was done so that when
>you have a Container with padding=10 and you place a child into it, the
>child's (x,y) reads as (0,0) and not (10,10). When I did a test with a
><div> that had padding:10px, the first item in it reported left:10,
>top:10. So I wonder if we shouldn't treat padding the same way?
Padding should work the same between JS and SWF. I think once we switched
to border-box we never verified how the coordinate system worked. But
also keep in mind Panel and chrome-containers and how they will need to
work.
My 2 cents,
-Alex
Re: [FlexJS]Layout redux
Posted by Alex Harui <ah...@adobe.com>.
On 2/25/17, 6:33 AM, "Peter Ent" <pe...@adobe.com> wrote:
>Maybe we need a big refactor. Things like effects are pretty advanced and
>maybe they should get coupled with more advanced/complex layouts that are
>in a different package than HTML.
Well, I don't know how to define "big", but we do need to get it right,
and I think we have more good real-world use cases to consider. Effects
should plug-in and be PAYG like anything else, so sure there might be
Effects-knowledgable layouts, or Effects-capable components (where setting
x,y,w,h first dispatches a cancelable "changing" event that the Effects
system cancels. Or maybe Effects is a completely different API than
regular Flex where you use EffectInstances as proxies to change the actual
properties on the display objects.
Or all of the above since there doesn't have to be only one way to do
things. If you can live with visual cruft you can have a smaller, more
primitive effects system. I just noticed on my phone that when it is
running slowly, that the slide switch that turns on my mobile hotspot
actually gets reset back to the off position and animated to on.
>
>The basic packages could be simpler layouts that do minimal settings. The
>HTML package could be JS only and just wrap the HTML elements for use
>with ActionScript.
In the dual branch, the HTML package only contains the <a><h1> kinds of
components. Basic contains the more Flex-like controls.
My 2 cents,
-Alex
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
Maybe we need a big refactor. Things like effects are pretty advanced and maybe they should get coupled with more advanced/complex layouts that are in a different package than HTML.
The basic packages could be simpler layouts that do minimal settings. The HTML package could be JS only and just wrap the HTML elements for use with ActionScript.
Then another pancake has the SWF and JS components and beads with light layouts and accessories.
This seems more PAYG.
Peter
> On Feb 25, 2017, at 1:46 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
>> On 2/24/17, 10:37 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>>
>> One more thing to consider is how effects will fit in here. I can imagine
>> scenarios where items inside of a container need to have an effect
>> applied to them. Currently, the move effect relies on changing x, y
>> values, which implies absolute positioning. If they’re all part of a
>> flexbox I’m not sure how effects would apply.
>>
>>
>>
>> I ran into these issues when implementing LayoutTweener and
>> EasyCollapseBead for the Accordion component.
>>
>>
>>
>> If we’re serious about having swf feature parity, I think we’ll end up
>> doing everything with absolute positioning on the swf side anyway, so we
>> might as well implement it the same way on the JS side. The only downside
>> to this that I see is possible performance issues.
>>
>>
>>
>> What are your thoughts on this?
>
> That's a valid approach, but I'd much rather let the browser do the work
> and try to emulate that in the SWF. Leveraging the browser should result
> in smaller faster applications. However, if it turns out to do anything
> reasonably "nice" in JS requires absolute positioning then, sure it may be
> time to give up on the browser and write the code once to run in both SWF
> and JS.
>
> It isn't wrong to have both choices so folks can use the browser when it
> works for them and switch to a fatter/slower but perfect-
> across-all-browsers version if needed.
>
> My 2 cents,
> -Alex
>
Re: [FlexJS]Layout redux
Posted by Alex Harui <ah...@adobe.com>.
On 2/24/17, 10:37 PM, "Yishay Weiss" <yi...@hotmail.com> wrote:
>One more thing to consider is how effects will fit in here. I can imagine
>scenarios where items inside of a container need to have an effect
>applied to them. Currently, the move effect relies on changing x, y
>values, which implies absolute positioning. If they’re all part of a
>flexbox I’m not sure how effects would apply.
>
>
>
>I ran into these issues when implementing LayoutTweener and
>EasyCollapseBead for the Accordion component.
>
>
>
>If we’re serious about having swf feature parity, I think we’ll end up
>doing everything with absolute positioning on the swf side anyway, so we
>might as well implement it the same way on the JS side. The only downside
>to this that I see is possible performance issues.
>
>
>
>What are your thoughts on this?
>
That's a valid approach, but I'd much rather let the browser do the work
and try to emulate that in the SWF. Leveraging the browser should result
in smaller faster applications. However, if it turns out to do anything
reasonably "nice" in JS requires absolute positioning then, sure it may be
time to give up on the browser and write the code once to run in both SWF
and JS.
It isn't wrong to have both choices so folks can use the browser when it
works for them and switch to a fatter/slower but perfect-
across-all-browsers version if needed.
My 2 cents,
-Alex
RE: [FlexJS]Layout redux
Posted by Yishay Weiss <yi...@hotmail.com>.
One more thing to consider is how effects will fit in here. I can imagine scenarios where items inside of a container need to have an effect applied to them. Currently, the move effect relies on changing x, y values, which implies absolute positioning. If they’re all part of a flexbox I’m not sure how effects would apply.
I ran into these issues when implementing LayoutTweener and EasyCollapseBead for the Accordion component.
If we’re serious about having swf feature parity, I think we’ll end up doing everything with absolute positioning on the swf side anyway, so we might as well implement it the same way on the JS side. The only downside to this that I see is possible performance issues.
What are your thoughts on this?
From: Peter Ent<ma...@adobe.com>
Sent: Friday, February 24, 2017 9:42 PM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: [FlexJS]Layout redux
Hi,
I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout
that adds code for the SWF side. In general, the SWF and JS sides look the
same. There are some differences which I'm working on, but these should be
usable.
In doing this I've uncovered some incomplete work and/or exposed some
issues. These are, in no particular order:
UIBase vs. IUIBase. Since some of our components do not inherit from
UIBase, you cannot cast everything to this class. Now as we should really
use interfaces and not classes, casting to IUIBase generally works.
However, IUIBase is missing a lot of useful function prototypes which is
why there is a lot of casting to UIBase. I'd like to see IUIBase become
more complete. The layout code does a lot of extra, unnecessary casts on
the SWF side.
JS vs SWF layouts. When you think about it, once you've set up your <div>
to have the property display style, adding/removing/changing elements gets
taken care by the browser. If I set up my <div> with display:flex and then
put in a number of elements and start changing them via JavaScript, they
just change. Of course that doesn't work on the SWF side because there
isn't anything to size and position elements except the layout algorithms.
But the events that trigger those algorithms to execute are in the
Container class which causes the layout - SWF or JS - to execute.
Basically, it seems unnecessary to re-execute JS layouts every time since
the browser does the work. I think this should be revisited.
Padding. This still isn't working right for the Container with layout.
Part of the problem is that padding on the SWF side isn't really padding.
What it does it offset the inner contentArea. This was done so that when
you have a Container with padding=10 and you place a child into it, the
child's (x,y) reads as (0,0) and not (10,10). When I did a test with a
<div> that had padding:10px, the first item in it reported left:10,
top:10. So I wonder if we shouldn't treat padding the same way?
Basically, I'm wondering if we should revisit the concept of container
components again and nail it down. The SWF and JS platforms are very, very
different here and I think we need to put more thought into it. For
example, maybe layouts should be SWF only and then only to mimic what you
can do with CSS. That might be too complex though.
What I still need to do for the Flex layouts is handle visibility. Or more
specifically, state changes. The DataBindingExample doesn't work right
when the state changes.
The next thing is to add just a couple of Flexbox features. Specially, I
think justify-content, align-items, and align-content. Easy enough to add
for JS of course.
—peter
On 2/23/17, 8:25 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>
>On 2/23/17, 1:54 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>A few comments/questions:
>>
>>What does flex-box do when it runs out of room? Doesn't it wrap to a new
>>row/column? Or can that be controlled? I think most folks expect
>>VerticalLayout to not create a new column but to keep going vertically
>>and
>>be clipped or scrolled.
>
>Flexbox has a number of options. Wrapping is one of them but is not the
>default. It set these layouts to not wrap so you get a single column or
>row. I did not set overflow, but it probably should be set to hidden or
>auto; trying to match up what we want the SWF side - which takes much more
>effort/code to mimic - requires us to make a choice for default behavior.
>
>I think that using the Flexbox layout will give good results on the JS
>side. I deliberately didn't add more features just to see what people
>think of using it. It has some cool layout features and seems to solve a
>lot of layout problems people have had using CSS. It might not be right
>for all situations of course.
>
>>
>>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
>>again. That's what the dual branch is all about.
>>
>>+1 for lighterweight (one div) Container. I thought we'd already done
>>something like that in one of the Item Renderers. But Panel and other
>>ChromContainers probably need to extend Container because people expect
>>it, although I'd be fine if they both just implemented some sort of
>>IContainer.
>>
>>As an alternative to flex-box, it is totally fine to have more than one
>>VerticalLayout. One that tries to use display:block and another one that
>>runs a bunch of code and does position:absolute on everything.
>>
>>In reality, how many of you use position:absolute or position:relative in
>>a real-world HTML/JS UI? It still feels like we are going to end up
>>using
>>it too much, but maybe that's what has to happen in order to solve some
>>of
>>the common layout issues, like making one thing stretch to fill all
>>available space.
>
>I agree. When you look at the generated HTML, there's way too much forcing
>of size and position that a natural HTML author would not use. But I'm not
>sure how to really do this programmatically while allowing all sorts of
>situations to work.
>
>>
>>My 2 cents,
>>-Alex
>>
>>On 2/22/17, 2:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>>Great. Thanks. I will take a look at these tomorrow.
>>>‹peter
>>>
>>>On 2/22/17, 5:19 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>>This too:
>>>>https://philipwalton.github.io/solved-by-flexbox/
>>>>
>>>>> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> BTW, this might be useful:
>>>>> https://github.com/philipwalton/flexbugs
>>>>><https://github.com/philipwalton/flexbugs>
>>>>>
>>>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com
>>>>>><ma...@gmail.com>> wrote:
>>>>>>
>>>>>> How well do these work in IE?
>>>>>>
>>>>>> It looks like Flexbox is not supported at all in IE prior to IE10
>>>>>>and
>>>>>>even in IE10 and 11, it only has buggy support.[1]
>>>>>>
>>>>>> [1]http://caniuse.com/#feat=flexbox
>>>>>><http://caniuse.com/#feat=flexbox>
>>>>>>
>>>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com
>>>>>>><ma...@adobe.com>> wrote:
>>>>>>>
>>>>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>>>>HorizontalFlexLayout as
>>>>>>> well as a change to DataBindingExample to use them. I consider
>>>>>>>these
>>>>>>> temporary and would like to make them be the VerticalLayout and
>>>>>>> HorizontalLayout in the near future.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I've pushed an update to the HorizontalFlexLayout and VerticalFlexLayout
that adds code for the SWF side. In general, the SWF and JS sides look the
same. There are some differences which I'm working on, but these should be
usable.
In doing this I've uncovered some incomplete work and/or exposed some
issues. These are, in no particular order:
UIBase vs. IUIBase. Since some of our components do not inherit from
UIBase, you cannot cast everything to this class. Now as we should really
use interfaces and not classes, casting to IUIBase generally works.
However, IUIBase is missing a lot of useful function prototypes which is
why there is a lot of casting to UIBase. I'd like to see IUIBase become
more complete. The layout code does a lot of extra, unnecessary casts on
the SWF side.
JS vs SWF layouts. When you think about it, once you've set up your <div>
to have the property display style, adding/removing/changing elements gets
taken care by the browser. If I set up my <div> with display:flex and then
put in a number of elements and start changing them via JavaScript, they
just change. Of course that doesn't work on the SWF side because there
isn't anything to size and position elements except the layout algorithms.
But the events that trigger those algorithms to execute are in the
Container class which causes the layout - SWF or JS - to execute.
Basically, it seems unnecessary to re-execute JS layouts every time since
the browser does the work. I think this should be revisited.
Padding. This still isn't working right for the Container with layout.
Part of the problem is that padding on the SWF side isn't really padding.
What it does it offset the inner contentArea. This was done so that when
you have a Container with padding=10 and you place a child into it, the
child's (x,y) reads as (0,0) and not (10,10). When I did a test with a
<div> that had padding:10px, the first item in it reported left:10,
top:10. So I wonder if we shouldn't treat padding the same way?
Basically, I'm wondering if we should revisit the concept of container
components again and nail it down. The SWF and JS platforms are very, very
different here and I think we need to put more thought into it. For
example, maybe layouts should be SWF only and then only to mimic what you
can do with CSS. That might be too complex though.
What I still need to do for the Flex layouts is handle visibility. Or more
specifically, state changes. The DataBindingExample doesn't work right
when the state changes.
The next thing is to add just a couple of Flexbox features. Specially, I
think justify-content, align-items, and align-content. Easy enough to add
for JS of course.
—peter
On 2/23/17, 8:25 AM, "Peter Ent" <pe...@adobe.com> wrote:
>
>
>On 2/23/17, 1:54 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
>>A few comments/questions:
>>
>>What does flex-box do when it runs out of room? Doesn't it wrap to a new
>>row/column? Or can that be controlled? I think most folks expect
>>VerticalLayout to not create a new column but to keep going vertically
>>and
>>be clipped or scrolled.
>
>Flexbox has a number of options. Wrapping is one of them but is not the
>default. It set these layouts to not wrap so you get a single column or
>row. I did not set overflow, but it probably should be set to hidden or
>auto; trying to match up what we want the SWF side - which takes much more
>effort/code to mimic - requires us to make a choice for default behavior.
>
>I think that using the Flexbox layout will give good results on the JS
>side. I deliberately didn't add more features just to see what people
>think of using it. It has some cool layout features and seems to solve a
>lot of layout problems people have had using CSS. It might not be right
>for all situations of course.
>
>>
>>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
>>again. That's what the dual branch is all about.
>>
>>+1 for lighterweight (one div) Container. I thought we'd already done
>>something like that in one of the Item Renderers. But Panel and other
>>ChromContainers probably need to extend Container because people expect
>>it, although I'd be fine if they both just implemented some sort of
>>IContainer.
>>
>>As an alternative to flex-box, it is totally fine to have more than one
>>VerticalLayout. One that tries to use display:block and another one that
>>runs a bunch of code and does position:absolute on everything.
>>
>>In reality, how many of you use position:absolute or position:relative in
>>a real-world HTML/JS UI? It still feels like we are going to end up
>>using
>>it too much, but maybe that's what has to happen in order to solve some
>>of
>>the common layout issues, like making one thing stretch to fill all
>>available space.
>
>I agree. When you look at the generated HTML, there's way too much forcing
>of size and position that a natural HTML author would not use. But I'm not
>sure how to really do this programmatically while allowing all sorts of
>situations to work.
>
>>
>>My 2 cents,
>>-Alex
>>
>>On 2/22/17, 2:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>>Great. Thanks. I will take a look at these tomorrow.
>>>‹peter
>>>
>>>On 2/22/17, 5:19 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>>This too:
>>>>https://philipwalton.github.io/solved-by-flexbox/
>>>>
>>>>> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> BTW, this might be useful:
>>>>> https://github.com/philipwalton/flexbugs
>>>>><https://github.com/philipwalton/flexbugs>
>>>>>
>>>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com
>>>>>><ma...@gmail.com>> wrote:
>>>>>>
>>>>>> How well do these work in IE?
>>>>>>
>>>>>> It looks like Flexbox is not supported at all in IE prior to IE10
>>>>>>and
>>>>>>even in IE10 and 11, it only has buggy support.[1]
>>>>>>
>>>>>> [1]http://caniuse.com/#feat=flexbox
>>>>>><http://caniuse.com/#feat=flexbox>
>>>>>>
>>>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com
>>>>>>><ma...@adobe.com>> wrote:
>>>>>>>
>>>>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>>>>HorizontalFlexLayout as
>>>>>>> well as a change to DataBindingExample to use them. I consider
>>>>>>>these
>>>>>>> temporary and would like to make them be the VerticalLayout and
>>>>>>> HorizontalLayout in the near future.
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
On 2/23/17, 1:54 AM, "Alex Harui" <ah...@adobe.com> wrote:
>A few comments/questions:
>
>What does flex-box do when it runs out of room? Doesn't it wrap to a new
>row/column? Or can that be controlled? I think most folks expect
>VerticalLayout to not create a new column but to keep going vertically and
>be clipped or scrolled.
Flexbox has a number of options. Wrapping is one of them but is not the
default. It set these layouts to not wrap so you get a single column or
row. I did not set overflow, but it probably should be set to hidden or
auto; trying to match up what we want the SWF side - which takes much more
effort/code to mimic - requires us to make a choice for default behavior.
I think that using the Flexbox layout will give good results on the JS
side. I deliberately didn't add more features just to see what people
think of using it. It has some cool layout features and seems to solve a
lot of layout problems people have had using CSS. It might not be right
for all situations of course.
>
>On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
>again. That's what the dual branch is all about.
>
>+1 for lighterweight (one div) Container. I thought we'd already done
>something like that in one of the Item Renderers. But Panel and other
>ChromContainers probably need to extend Container because people expect
>it, although I'd be fine if they both just implemented some sort of
>IContainer.
>
>As an alternative to flex-box, it is totally fine to have more than one
>VerticalLayout. One that tries to use display:block and another one that
>runs a bunch of code and does position:absolute on everything.
>
>In reality, how many of you use position:absolute or position:relative in
>a real-world HTML/JS UI? It still feels like we are going to end up using
>it too much, but maybe that's what has to happen in order to solve some of
>the common layout issues, like making one thing stretch to fill all
>available space.
I agree. When you look at the generated HTML, there's way too much forcing
of size and position that a natural HTML author would not use. But I'm not
sure how to really do this programmatically while allowing all sorts of
situations to work.
>
>My 2 cents,
>-Alex
>
>On 2/22/17, 2:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>>Great. Thanks. I will take a look at these tomorrow.
>>‹peter
>>
>>On 2/22/17, 5:19 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>>This too:
>>>https://philipwalton.github.io/solved-by-flexbox/
>>>
>>>> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>> BTW, this might be useful:
>>>> https://github.com/philipwalton/flexbugs
>>>><https://github.com/philipwalton/flexbugs>
>>>>
>>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com
>>>>><ma...@gmail.com>> wrote:
>>>>>
>>>>> How well do these work in IE?
>>>>>
>>>>> It looks like Flexbox is not supported at all in IE prior to IE10 and
>>>>>even in IE10 and 11, it only has buggy support.[1]
>>>>>
>>>>> [1]http://caniuse.com/#feat=flexbox
>>>>><http://caniuse.com/#feat=flexbox>
>>>>>
>>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com
>>>>>><ma...@adobe.com>> wrote:
>>>>>>
>>>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>>>HorizontalFlexLayout as
>>>>>> well as a change to DataBindingExample to use them. I consider these
>>>>>> temporary and would like to make them be the VerticalLayout and
>>>>>> HorizontalLayout in the near future.
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
I just checked. I have 24 classes with position: absolute and 16 classes with position: relative in a responsive app we use for PrintUI.
The default for the app is absolute.
It also has three media queries to set the percentage size of the main (relative) sections for responsive layout. It also has keyframes, but I don’t remember why.
> On Feb 23, 2017, at 8:54 AM, Alex Harui <ah...@adobe.com> wrote:
>
> In reality, how many of you use position:absolute or position:relative in
> a real-world HTML/JS UI?
Re: [FlexJS]Layout redux
Posted by Alex Harui <ah...@adobe.com>.
A few comments/questions:
What does flex-box do when it runs out of room? Doesn't it wrap to a new
row/column? Or can that be controlled? I think most folks expect
VerticalLayout to not create a new column but to keep going vertically and
be clipped or scrolled.
On the SWF side, I am hopefully going to get buy-in to unwrap the Sprites
again. That's what the dual branch is all about.
+1 for lighterweight (one div) Container. I thought we'd already done
something like that in one of the Item Renderers. But Panel and other
ChromContainers probably need to extend Container because people expect
it, although I'd be fine if they both just implemented some sort of
IContainer.
As an alternative to flex-box, it is totally fine to have more than one
VerticalLayout. One that tries to use display:block and another one that
runs a bunch of code and does position:absolute on everything.
In reality, how many of you use position:absolute or position:relative in
a real-world HTML/JS UI? It still feels like we are going to end up using
it too much, but maybe that's what has to happen in order to solve some of
the common layout issues, like making one thing stretch to fill all
available space.
My 2 cents,
-Alex
On 2/22/17, 2:31 PM, "Peter Ent" <pe...@adobe.com> wrote:
>Great. Thanks. I will take a look at these tomorrow.
>‹peter
>
>On 2/22/17, 5:19 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>This too:
>>https://philipwalton.github.io/solved-by-flexbox/
>>
>>> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>> BTW, this might be useful:
>>> https://github.com/philipwalton/flexbugs
>>><https://github.com/philipwalton/flexbugs>
>>>
>>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com
>>>><ma...@gmail.com>> wrote:
>>>>
>>>> How well do these work in IE?
>>>>
>>>> It looks like Flexbox is not supported at all in IE prior to IE10 and
>>>>even in IE10 and 11, it only has buggy support.[1]
>>>>
>>>> [1]http://caniuse.com/#feat=flexbox <http://caniuse.com/#feat=flexbox>
>>>>
>>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com
>>>>><ma...@adobe.com>> wrote:
>>>>>
>>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>>HorizontalFlexLayout as
>>>>> well as a change to DataBindingExample to use them. I consider these
>>>>> temporary and would like to make them be the VerticalLayout and
>>>>> HorizontalLayout in the near future.
>>>>
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
Great. Thanks. I will take a look at these tomorrow.
‹peter
On 2/22/17, 5:19 PM, "Harbs" <ha...@gmail.com> wrote:
>This too:
>https://philipwalton.github.io/solved-by-flexbox/
>
>> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>>
>> BTW, this might be useful:
>> https://github.com/philipwalton/flexbugs
>><https://github.com/philipwalton/flexbugs>
>>
>>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com
>>><ma...@gmail.com>> wrote:
>>>
>>> How well do these work in IE?
>>>
>>> It looks like Flexbox is not supported at all in IE prior to IE10 and
>>>even in IE10 and 11, it only has buggy support.[1]
>>>
>>> [1]http://caniuse.com/#feat=flexbox <http://caniuse.com/#feat=flexbox>
>>>
>>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com
>>>><ma...@adobe.com>> wrote:
>>>>
>>>> I just pushed new layouts: VerticalFlexLayout and
>>>>HorizontalFlexLayout as
>>>> well as a change to DataBindingExample to use them. I consider these
>>>> temporary and would like to make them be the VerticalLayout and
>>>> HorizontalLayout in the near future.
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
This too:
https://philipwalton.github.io/solved-by-flexbox/
> On Feb 23, 2017, at 12:16 AM, Harbs <ha...@gmail.com> wrote:
>
> BTW, this might be useful:
> https://github.com/philipwalton/flexbugs <https://github.com/philipwalton/flexbugs>
>
>> On Feb 23, 2017, at 12:08 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> How well do these work in IE?
>>
>> It looks like Flexbox is not supported at all in IE prior to IE10 and even in IE10 and 11, it only has buggy support.[1]
>>
>> [1]http://caniuse.com/#feat=flexbox <http://caniuse.com/#feat=flexbox>
>>
>>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com <ma...@adobe.com>> wrote:
>>>
>>> I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
>>> well as a change to DataBindingExample to use them. I consider these
>>> temporary and would like to make them be the VerticalLayout and
>>> HorizontalLayout in the near future.
>>
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
BTW, this might be useful:
https://github.com/philipwalton/flexbugs
> On Feb 23, 2017, at 12:08 AM, Harbs <ha...@gmail.com> wrote:
>
> How well do these work in IE?
>
> It looks like Flexbox is not supported at all in IE prior to IE10 and even in IE10 and 11, it only has buggy support.[1]
>
> [1]http://caniuse.com/#feat=flexbox <http://caniuse.com/#feat=flexbox>
>
>> On Feb 22, 2017, at 11:40 PM, Peter Ent <pent@adobe.com <ma...@adobe.com>> wrote:
>>
>> I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
>> well as a change to DataBindingExample to use them. I consider these
>> temporary and would like to make them be the VerticalLayout and
>> HorizontalLayout in the near future.
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
How well do these work in IE?
It looks like Flexbox is not supported at all in IE prior to IE10 and even in IE10 and 11, it only has buggy support.[1]
[1]http://caniuse.com/#feat=flexbox
> On Feb 22, 2017, at 11:40 PM, Peter Ent <pe...@adobe.com> wrote:
>
> I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
> well as a change to DataBindingExample to use them. I consider these
> temporary and would like to make them be the VerticalLayout and
> HorizontalLayout in the near future.
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
Hi,
I just pushed new layouts: VerticalFlexLayout and HorizontalFlexLayout as
well as a change to DataBindingExample to use them. I consider these
temporary and would like to make them be the VerticalLayout and
HorizontalLayout in the near future.
If you look at their code you will see the COMPILE::JS side is very, very
short now. All it does it set the display:flex and flow-flow: row|column
on the contentView of the layout host. The SWF side remains unchanged for
now. I did not make it possible yet to use Flexbox properties of
align-items, justify-content, etc.
I spent most of the time coming to terms with the Container. I've left it
alone for now, but I think it needs work. First, padding is not working
for the container, so that will not have any affect.
I think the Container needs to be redone. I also think it does too much or
we need a lighter weight component like Group. Container generates two
<div>s for the HTML side. This is to allow for "chrome" such as headers
and footers. More specifically, it was designed to make it possible to
write Panel (maybe Panel should be a composite component and moved into
Express).
The JS code generated for Container <div>s provides style information that
is too much, really, unless you add in a chrome item. I think if there is
a lighter component that just provides a box that surrounds its children
it would help clean things up. The JS side should then be easier to style.
If you want scrolling, then you'd have to use a Container and we can make
the Container use a scrolling viewport by default then, since Group would
be the default non-scrolling offering.
Regards,
Peter
On 2/22/17, 12:03 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>Hi Peter, that sound very good :)
>thanks!
>
>2017-02-22 16:53 GMT+01:00 Peter Ent <pe...@adobe.com>:
>
>> That's a good strategy. My experiments this morning look like Flexbox is
>> the way to go. Its widely supported now and seems pretty easy to use.
>>
>> I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
>> them extend the current versions just so the SWF side stays the same for
>> right now. The JS side will implement Flexbox. Then we can all try it
>>out
>> and see how it behaves. If that's good, I can replace the current JS
>> version with the Flexbox version and then work on the SWF side to make
>>it
>> compatible.
>>
>> Will keep you all posted.
>>
>> —peter
>>
>> On 2/22/17, 10:16 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>> wrote:
>>
>> >That looks very promising Peter. Look forward to see some progress :)
>> >If flexbox is the future, I think we should always look to go with that
>> >specs, and in case that still is not in some browsers, search for a
>> >polyfill that could do the job for not supported browsers for now. At
>>the
>> >end browsers will support it, and polyfill will end in no use (and we
>> >could
>> >eventually remove)
>> >
>> >2017-02-22 14:47 GMT+01:00 Peter Ent <pe...@adobe.com>:
>> >
>> >> I'm going to try some experiments in my own space. Basically,
>>figuring
>> >>out
>> >> the best way to do simple layouts using CSS - vertical and horizontal
>> >>with
>> >> alignment options (center, left, right for vertical, top, middle,
>>bottom
>> >> for horizontal). Because alignment will probably require more cycles
>> >>when
>> >> implemented in SWF, I will look to making these beads or
>> >> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
>> >> percentage sizes as well. A better understanding, on my part, of
>> >>HTML/CSS
>> >> capabilities will really help.
>> >>
>> >> Once I think the JS side is simple enough, I'll mimic then for the
>>SWF
>> >> side. I really don't see why this should be complex. The big issue on
>> >>the
>> >> SWF side is not always knowing the size of the item that you want to
>> >> position and size.
>> >>
>> >> I have been reading about CSS Flexbox which seems like it is the
>>future
>> >>of
>> >> layout for HTML/CSS. It seems to be widely supported at this point.
>>The
>> >> next generation, Grid, is still in the W3C draft phase, but that
>>will be
>> >> handy too once it gets adopted. I'll look into using various
>>settings of
>> >> display and position first before resorting to Flexbox.
>> >>
>> >> —peter
>> >>
>> >> On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
>> >>
>> >> >
>> >> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
>> >> >>
>> >> >> It is probably time for our annual "revisiting of the layout
>>code".
>> >>I
>> >> >> think if you look at source code history, Peter or I do this
>>every so
>> >> >> often as we get more examples to work with.
>> >> >>
>> >> >> From memory, there are issues like whether we have to set
>> >> >> position:relative or not that came out of the MDL swc. And
>>when/if
>> >>we
>> >> >> need to set the width on a parent for percentage width to work in
>>the
>> >> >> children/grandchildren.
>> >> >>
>> >> >> It is great to finally have some people actually paying attention
>> >>that
>> >> >> know how this stuff is actually normally done in JS. Peter and I
>> >>were
>> >> >> mostly guessing since, if you think about it, we were basically
>>doing
>> >> >>Flex
>> >> >> until we got into FlexJS and are not experienced in HTML/JS.
>> >> >>
>> >> >> So, fundamentally, if you have to stack things vertically, should
>>you
>> >> >>use
>> >> >> display:block? If you have to line up a bunch of divs
>>horizontally,
>> >> >> should you use display:inline-block?
>> >> >
>> >> >It depends. If everything is position:relative, then theoretically,
>> >>yes.
>> >> >The problem with position:relative in my experience is that it’s too
>> >> >unpredictable. I can’t give examples right now, but I know I spent
>> >> >countless hours struggling with getting HTML to correctly position
>> >> >elements using relative positioning. So while theoretically, using
>>CSS
>> >> >and built-in browser positioning sounds good, I think there are
>>enough
>> >> >edge cases to make it really difficult to be reliable in practice.
>> >> >
>> >> >> Is there a better way to do BasicLayout? We ended up using a
>> >>completely
>> >> >> handwritten set of code to essentially make everything use
>>absolute
>> >> >> positioning.
>> >> >>
>> >> >> Is border-box working as expected? Do you set the height/width to
>> >> >>include
>> >> >> the padding or not?
>> >> >
>> >> >Yes. The size includes the padding, but padding only serves a
>>function
>> >>if
>> >> >the children are positioned relative. Currently, that’s not the case
>> >> >AFAICT.
>> >> >
>> >> >
>> >> >> I think some layouts can use CSS but others have to be written in
>> >>code
>> >> >>to
>> >> >> override default browser behavior. But I'd love to be wrong about
>> >>that
>> >> >> (at least, without relying on latest browsers or polyfills).
>> >> >>
>> >> >> And finally, are there ways we can call the layout fewer times
>>than
>> >>we
>> >> >> currently do?
>> >> >
>> >> >I don’t understand the current layout lifecycle well enough. I do
>>know
>> >> >that we’ve observed layouts consistently happening twice, so I’d
>>guess
>> >> >that the answer would be yes.
>> >> >
>> >> >Ultimately, it would be great to have a layout which relies
>>exclusively
>> >> >on CSS, and if that can be achieved, it would be the most efficient
>>way
>> >> >to lay things out in HTML.
>> >> >
>> >> >My belief is that it’s unattainable for anything but the simplest
>> >>layouts
>> >> >to rely on CSS. If we are not relying on CSS, then I believe the
>>best
>> >>way
>> >> >to go is to calculate the layout almost exclusively in javascript
>>and
>> >> >layout pretty much everything with position:absolute. The only
>> >>exception
>> >> >for that would be elements which should truly reflow based on the
>>HTML
>> >> >layout (i.e. text and inline images, possibly image grids, etc.) The
>> >>more
>> >> >reliance we have on CSS, the more we’re opening the layout to bugs.
>> >> >Additionally, the more the code has to examine the results of
>>browser
>> >> >rendering, the less efficient the JS code will be. Javascript alone
>>is
>> >> >really fast in modern engines. It’s when there’s DOM interactions
>>that
>> >> >Javascript hits a performance wall. The more we can keep the
>> >>calculations
>> >> >in pure JS and avoid DOM interaction, the better.
>> >> >
>> >> >So I would propose two sets of Layouts:
>> >> >CSSLayout which might or might not have sub-layouts to do bare-b
>>ones
>> >> >layout optimized for as little JS code to run as possible and allow
>> >> >settings to be set using CSS. (cheap as possible PAYG layout)
>> >> >FlexLayout which would have vertical,horizontal,absolute,grid, etc.
>> >> >
>> >> >FlexLayout would use FlexJS properties to calculate layout, and
>>support
>> >> >percentage, left,right,top,bottom properties to do proper
>>constrained
>> >> >layout. I think that constrained layout (right,left,top,bottom) is
>> >>common
>> >> >enough that it doesn’t warrant a separate layout as long as we have
>>the
>> >> >bare-bones CSSLayout for cases that need it.
>> >> >
>> >> >> For sure, we need to the the JS side right and then worry about
>>the
>> >>SWF
>> >> >> side. I think there are way fewer behavior issues on the SWF
>>side to
>> >> >>deal
>> >> >> with.
>> >> >
>> >> >Agreed.
>> >> >
>> >> >Harbs
>> >> >
>> >> >> My 2 cents,
>> >> >> -Alex
>> >> >>
>> >> >> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>> >> >>
>> >> >>> I think this is generally a good approach.
>> >> >>>
>> >> >>> I've been thinking that we have some refactoring to do which
>>might
>> >> >>>help.
>> >> >>> For instance, Core should probably be edited to include
>>interfaces,
>> >> >>> events, and whatever else works across all packages. HTML should
>> >> >>>probably
>> >> >>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that
>> >>wants
>> >> >>> HTML+ActionScript can use that and then use CSS to do all their
>> >> >>>layouts;
>> >> >>> HTML would not have a SWF version.
>> >> >>>
>> >> >>> Then Basic could be SWF & JS with layouts that are light on the
>>JS
>> >>side
>> >> >>> using CSS and AS code to mimic them on the SWF side. Express
>>would
>> >>do
>> >> >>>what
>> >> >>> it is doing now and compose components by extending the Basic set
>> >>and
>> >> >>> adding common beads.
>> >> >>>
>> >> >>> I've been hung up with the JS side having stuck on the display
>>and
>> >> >>> position values and deferring them might be the best solution.
>> >> >>>
>> >> >>> —peter
>> >> >>>
>> >> >>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos
>> >> >>>Rovira"
>> >> >>> <carlos.rovira@gmail.com on behalf of
>>carlos.rovira@codeoscopic.com
>> >
>> >> >>> wrote:
>> >> >>>
>> >> >>>> Hi Peter,
>> >> >>>>
>> >> >>>> it seems HTML rely for this task heavily on CSS to the point
>>that
>> >> >>>>almost
>> >> >>>> nothing is done in html or js code.
>> >> >>>> So maybe we are not in the right way for HTML platform and we
>> >>should
>> >> >>>>make
>> >> >>>> our code be mainly CSS.
>> >> >>>> An example is here:
>> >> >>>>
>> >> >>>> https://css-tricks.com/snippets/sass/placing-items-circle/
>> >> >>>>
>> >> >>>> Another point is SWF. I'm not focusing in that output and even I
>> >> >>>>didn't
>> >> >>>> compile to SWF for long time, so don't know how
>> >> >>>> is looking, but for what I saw in other discussions seems that
>> >>Flash
>> >> >>>> needs
>> >> >>>> to implement the old Flex architecture of
>> >> >>>> updateDisplayList to manage refresh to avoid continuous
>>redrawing
>> >>of
>> >> >>>>the
>> >> >>>> screen.
>> >> >>>>
>> >> >>>> So my bet is that our AS3 layout components should do:
>> >> >>>>
>> >> >>>> 1.- In JS -> add className to "some-class-layout" (for example
>>for
>> >> >>>> circle,
>> >> >>>> if we have circle-layout, we should have a "circleLayout" css
>>class
>> >> >>>> selector, that we could assign to out flexjs "list component"
>> >> >>>>
>> >> >>>> 2.- in SWF -> we should stick with the way this was done in
>>Flex4
>> >>but
>> >> >>>> implementing as a bead and with the "updateDisplayList"
>>performance
>> >> >>>>
>> >> >>>> What do you think?
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>> >> >>>>
>> >> >>>>> A lot of this work is mine and it seems to need to be thought
>> >>through
>> >> >>>>> once
>> >> >>>>> again. The dichotomy of SWF & JS has presented problems for me
>>in
>> >>the
>> >> >>>>> past.
>> >> >>>>>
>> >> >>>>> Maybe the layouts, for JS platform, should do as little as
>> >>possible,
>> >> >>>>> replying on CSS as much as possible. Then make the SWF platform
>> >>mimic
>> >> >>>>> that.
>> >> >>>>>
>> >> >>>>> One issue that comes up for me is that we automatically set
>> >>display
>> >> >>>>>and
>> >> >>>>> position for every element soon after its created. If you were
>>to
>> >> >>>>> hand-write the HTML you probably would not do that.
>> >> >>>>>
>> >> >>>>> So perhaps FlexJS should not set these styles at all and
>>instead
>> >>let
>> >> >>>>> the
>> >> >>>>> layout set them if the layout even needs to do that.
>> >> >>>>>
>> >> >>>>> Thoughts?
>> >> >>>>> ‹peter
>> >> >>>>>
>> >> >>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>> >> >>>>>
>> >> >>>>>> We¹re really struggling with layout.
>> >> >>>>>>
>> >> >>>>>> Yishay just mentioned the fact that padding is not working,
>>but
>> >>the
>> >> >>>>>> problems seem to go much deeper than that.
>> >> >>>>>>
>> >> >>>>>> 1. VerticalLayout has the following code:
>> >> >>>>>> for (i = 0; i < n; i++)
>> >> >>>>>> {
>> >> >>>>>> var
>> >>child:WrappedHTMLElement =
>> >> >>>>> children[i];
>> >> >>>>>> child.flexjs_wrapper.
>> >> >>>>> setDisplayStyleForLayout('block');
>> >> >>>>>> if (child.style.display
>>===
>> >> >>>>> 'none')
>> >> >>>>>> {
>> >> >>>>>>
>> >>child.flexjs_wrapper.
>> >> >>>>> setDisplayStyleForLayout('block');
>> >> >>>>>> }
>> >> >>>>>> else
>> >> >>>>>> {
>> >> >>>>>> // block elements
>> >>don't
>> >> >>>>> measure width correctly so set to inline
>> >> >>>>>> for a second
>> >> >>>>>>
>>child.style.display
>> >>=
>> >> >>>>> 'inline-block';
>> >> >>>>>> maxWidth =
>> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >> >>>>>>
>>child.style.display
>> >>=
>> >> >>>>> 'block';
>> >> >>>>>> }
>> >> >>>>>> child.flexjs_wrapper.
>> >> >>>>> dispatchEvent('sizeChanged');
>> >> >>>>>> }
>> >> >>>>>>
>> >> >>>>>> There is a number of problems that I can see with this.
>>Firstly,
>> >> >>>>>>it¹s
>> >> >>>>>> horribly inefficient:
>> >> >>>>>>
>>child.style.display
>> >>=
>> >> >>>>> 'inline-block';
>> >> >>>>>> maxWidth =
>> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >> >>>>>> The above will force a browser redraw at every step of the
>>loop.
>> >>If
>> >> >>>>> you
>> >> >>>>>> have hundreds of children, there will be hundreds of redraws
>> >>just to
>> >> >>>>>> figure out the children width. If anything, there should
>> >>probably be
>> >> >>>>>> three loops: One to set the inline-blocks, The second to
>>measure
>> >>all
>> >> >>>>> the
>> >> >>>>>> children (the first measure would trigger a redraw, but
>> >>subsequent
>> >> >>>>> ones
>> >> >>>>>> not) The third to set inline-block back.
>> >> >>>>>>
>> >> >>>>>> Secondly, there¹s only a need to measure the children if the
>> >> >>>>>>container
>> >> >>>>> is
>> >> >>>>>> sized to content. If the container has a fixed width or a
>> >>percentage
>> >> >>>>>> width, I don¹t see why the children should be measured at all.
>> >>The
>> >> >>>>> only
>> >> >>>>>> exception I can see is if there is overflow:auto.
>> >> >>>>>>
>> >> >>>>>> Thirdly, I don¹t understand how setting the child to
>>inline-block
>> >> >>>>> helps.
>> >> >>>>>> What about the grandchildren? Don¹t those need to be measured
>> >>too?
>> >> >>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
>> >> >>>>> temporarily
>> >> >>>>>> sets inline-block. BasicLayout does not, and I don¹t
>>understand
>> >>why
>> >> >>>>>> there¹s a difference. (BasicLayout has the same re-rendering
>> >>problem
>> >> >>>>>> though.)
>> >> >>>>>> 2.
>> >> >>>>>> if (!hasWidth && n > 0 &&
>> >> >>>>> !isNaN(maxWidth)) {
>> >> >>>>>> var pl:String =
>> >> >>>>> scv['padding-left'];
>> >> >>>>>> var pr:String =
>> >> >>>>> scv['padding-right'];
>> >> >>>>>> var npl:int =
>> >> >>>>> parseInt(pl.substring(0, pl.length - 2), 10);
>> >> >>>>>> var npr:int =
>> >> >>>>> parseInt(pr.substring(0, pr.length - 2), 10);
>> >> >>>>>> maxWidth += npl + npr;
>> >> >>>>>> contentView.width =
>> >>maxWidth;
>> >> >>>>>> }
>> >> >>>>>>
>> >> >>>>>> This seems totally wrong. Why is the padding being added when
>> >>we¹re
>> >> >>>>> using
>> >> >>>>>> box-sizing: border-box?
>> >> >>>>>>
>> >> >>>>>> 3. Percentage size seems to be set based on the children
>>rather
>> >>than
>> >> >>>>> the
>> >> >>>>>> parents.
>> >> >>>>>>
>> >> >>>>>> 4. I¹m not sure I understand the layout lifecycle very well.
>>We
>> >>have
>> >> >>>>> had
>> >> >>>>>> cases where children did not seem to be layout, and forcing a
>> >>layout
>> >> >>>>>> seemed to be very difficult to do.
>> >> >>>>>>
>> >> >>>>>> Harbs
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>>
>> >> >>>> Carlos Rovira
>> >> >>>> Director General
>> >> >>>> M: +34 607 22 60 05
>> >> >>>> http://www.codeoscopic.com
>> >> >>>> http://www.avant2.es
>> >> >>>>
>> >> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
>> >> >>>>contener
>> >> >>>> información privilegiada o confidencial. Si ha recibido este
>> >>mensaje
>> >> >>>>por
>> >> >>>> error, le rogamos que nos lo comunique inmediatamente por esta
>> >>misma
>> >> >>>>vía
>> >> >>>> y
>> >> >>>> proceda a su destrucción.
>> >> >>>>
>> >> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> >> >>>> comunicamos
>> >> >>>> que sus datos forman parte de un fichero cuyo responsable es
>> >> >>>>CODEOSCOPIC
>> >> >>>> S.A. La finalidad de dicho tratamiento es facilitar la
>>prestación
>> >>del
>> >> >>>> servicio o información solicitados, teniendo usted derecho de
>> >>acceso,
>> >> >>>> rectificación, cancelación y oposición de sus datos
>>dirigiéndose a
>> >> >>>> nuestras
>> >> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> >> >>>>documentación
>> >> >>>> necesaria.
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>> >
>> >--
>> >
>> >Carlos Rovira
>> >Director General
>> >M: +34 607 22 60 05
>> >http://www.codeoscopic.com
>> >http://www.avant2.es
>> >
>> >Este mensaje se dirige exclusivamente a su destinatario y puede
>>contener
>> >información privilegiada o confidencial. Si ha recibido este mensaje
>>por
>> >error, le rogamos que nos lo comunique inmediatamente por esta misma
>>vía y
>> >proceda a su destrucción.
>> >
>> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> >comunicamos
>> >que sus datos forman parte de un fichero cuyo responsable es
>>CODEOSCOPIC
>> >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>> >servicio o información solicitados, teniendo usted derecho de acceso,
>> >rectificación, cancelación y oposición de sus datos dirigiéndose a
>> >nuestras
>> >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>> >necesaria.
>>
>>
>
>
>--
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.
Re: [FlexJS]Layout redux
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Peter, that sound very good :)
thanks!
2017-02-22 16:53 GMT+01:00 Peter Ent <pe...@adobe.com>:
> That's a good strategy. My experiments this morning look like Flexbox is
> the way to go. Its widely supported now and seems pretty easy to use.
>
> I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
> them extend the current versions just so the SWF side stays the same for
> right now. The JS side will implement Flexbox. Then we can all try it out
> and see how it behaves. If that's good, I can replace the current JS
> version with the Flexbox version and then work on the SWF side to make it
> compatible.
>
> Will keep you all posted.
>
> —peter
>
> On 2/22/17, 10:16 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> wrote:
>
> >That looks very promising Peter. Look forward to see some progress :)
> >If flexbox is the future, I think we should always look to go with that
> >specs, and in case that still is not in some browsers, search for a
> >polyfill that could do the job for not supported browsers for now. At the
> >end browsers will support it, and polyfill will end in no use (and we
> >could
> >eventually remove)
> >
> >2017-02-22 14:47 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >
> >> I'm going to try some experiments in my own space. Basically, figuring
> >>out
> >> the best way to do simple layouts using CSS - vertical and horizontal
> >>with
> >> alignment options (center, left, right for vertical, top, middle, bottom
> >> for horizontal). Because alignment will probably require more cycles
> >>when
> >> implemented in SWF, I will look to making these beads or
> >> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
> >> percentage sizes as well. A better understanding, on my part, of
> >>HTML/CSS
> >> capabilities will really help.
> >>
> >> Once I think the JS side is simple enough, I'll mimic then for the SWF
> >> side. I really don't see why this should be complex. The big issue on
> >>the
> >> SWF side is not always knowing the size of the item that you want to
> >> position and size.
> >>
> >> I have been reading about CSS Flexbox which seems like it is the future
> >>of
> >> layout for HTML/CSS. It seems to be widely supported at this point. The
> >> next generation, Grid, is still in the W3C draft phase, but that will be
> >> handy too once it gets adopted. I'll look into using various settings of
> >> display and position first before resorting to Flexbox.
> >>
> >> —peter
> >>
> >> On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >> >
> >> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
> >> >>
> >> >> It is probably time for our annual "revisiting of the layout code".
> >>I
> >> >> think if you look at source code history, Peter or I do this every so
> >> >> often as we get more examples to work with.
> >> >>
> >> >> From memory, there are issues like whether we have to set
> >> >> position:relative or not that came out of the MDL swc. And when/if
> >>we
> >> >> need to set the width on a parent for percentage width to work in the
> >> >> children/grandchildren.
> >> >>
> >> >> It is great to finally have some people actually paying attention
> >>that
> >> >> know how this stuff is actually normally done in JS. Peter and I
> >>were
> >> >> mostly guessing since, if you think about it, we were basically doing
> >> >>Flex
> >> >> until we got into FlexJS and are not experienced in HTML/JS.
> >> >>
> >> >> So, fundamentally, if you have to stack things vertically, should you
> >> >>use
> >> >> display:block? If you have to line up a bunch of divs horizontally,
> >> >> should you use display:inline-block?
> >> >
> >> >It depends. If everything is position:relative, then theoretically,
> >>yes.
> >> >The problem with position:relative in my experience is that it’s too
> >> >unpredictable. I can’t give examples right now, but I know I spent
> >> >countless hours struggling with getting HTML to correctly position
> >> >elements using relative positioning. So while theoretically, using CSS
> >> >and built-in browser positioning sounds good, I think there are enough
> >> >edge cases to make it really difficult to be reliable in practice.
> >> >
> >> >> Is there a better way to do BasicLayout? We ended up using a
> >>completely
> >> >> handwritten set of code to essentially make everything use absolute
> >> >> positioning.
> >> >>
> >> >> Is border-box working as expected? Do you set the height/width to
> >> >>include
> >> >> the padding or not?
> >> >
> >> >Yes. The size includes the padding, but padding only serves a function
> >>if
> >> >the children are positioned relative. Currently, that’s not the case
> >> >AFAICT.
> >> >
> >> >
> >> >> I think some layouts can use CSS but others have to be written in
> >>code
> >> >>to
> >> >> override default browser behavior. But I'd love to be wrong about
> >>that
> >> >> (at least, without relying on latest browsers or polyfills).
> >> >>
> >> >> And finally, are there ways we can call the layout fewer times than
> >>we
> >> >> currently do?
> >> >
> >> >I don’t understand the current layout lifecycle well enough. I do know
> >> >that we’ve observed layouts consistently happening twice, so I’d guess
> >> >that the answer would be yes.
> >> >
> >> >Ultimately, it would be great to have a layout which relies exclusively
> >> >on CSS, and if that can be achieved, it would be the most efficient way
> >> >to lay things out in HTML.
> >> >
> >> >My belief is that it’s unattainable for anything but the simplest
> >>layouts
> >> >to rely on CSS. If we are not relying on CSS, then I believe the best
> >>way
> >> >to go is to calculate the layout almost exclusively in javascript and
> >> >layout pretty much everything with position:absolute. The only
> >>exception
> >> >for that would be elements which should truly reflow based on the HTML
> >> >layout (i.e. text and inline images, possibly image grids, etc.) The
> >>more
> >> >reliance we have on CSS, the more we’re opening the layout to bugs.
> >> >Additionally, the more the code has to examine the results of browser
> >> >rendering, the less efficient the JS code will be. Javascript alone is
> >> >really fast in modern engines. It’s when there’s DOM interactions that
> >> >Javascript hits a performance wall. The more we can keep the
> >>calculations
> >> >in pure JS and avoid DOM interaction, the better.
> >> >
> >> >So I would propose two sets of Layouts:
> >> >CSSLayout which might or might not have sub-layouts to do bare-b ones
> >> >layout optimized for as little JS code to run as possible and allow
> >> >settings to be set using CSS. (cheap as possible PAYG layout)
> >> >FlexLayout which would have vertical,horizontal,absolute,grid, etc.
> >> >
> >> >FlexLayout would use FlexJS properties to calculate layout, and support
> >> >percentage, left,right,top,bottom properties to do proper constrained
> >> >layout. I think that constrained layout (right,left,top,bottom) is
> >>common
> >> >enough that it doesn’t warrant a separate layout as long as we have the
> >> >bare-bones CSSLayout for cases that need it.
> >> >
> >> >> For sure, we need to the the JS side right and then worry about the
> >>SWF
> >> >> side. I think there are way fewer behavior issues on the SWF side to
> >> >>deal
> >> >> with.
> >> >
> >> >Agreed.
> >> >
> >> >Harbs
> >> >
> >> >> My 2 cents,
> >> >> -Alex
> >> >>
> >> >> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
> >> >>
> >> >>> I think this is generally a good approach.
> >> >>>
> >> >>> I've been thinking that we have some refactoring to do which might
> >> >>>help.
> >> >>> For instance, Core should probably be edited to include interfaces,
> >> >>> events, and whatever else works across all packages. HTML should
> >> >>>probably
> >> >>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that
> >>wants
> >> >>> HTML+ActionScript can use that and then use CSS to do all their
> >> >>>layouts;
> >> >>> HTML would not have a SWF version.
> >> >>>
> >> >>> Then Basic could be SWF & JS with layouts that are light on the JS
> >>side
> >> >>> using CSS and AS code to mimic them on the SWF side. Express would
> >>do
> >> >>>what
> >> >>> it is doing now and compose components by extending the Basic set
> >>and
> >> >>> adding common beads.
> >> >>>
> >> >>> I've been hung up with the JS side having stuck on the display and
> >> >>> position values and deferring them might be the best solution.
> >> >>>
> >> >>> —peter
> >> >>>
> >> >>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >> >>>Rovira"
> >> >>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com
> >
> >> >>> wrote:
> >> >>>
> >> >>>> Hi Peter,
> >> >>>>
> >> >>>> it seems HTML rely for this task heavily on CSS to the point that
> >> >>>>almost
> >> >>>> nothing is done in html or js code.
> >> >>>> So maybe we are not in the right way for HTML platform and we
> >>should
> >> >>>>make
> >> >>>> our code be mainly CSS.
> >> >>>> An example is here:
> >> >>>>
> >> >>>> https://css-tricks.com/snippets/sass/placing-items-circle/
> >> >>>>
> >> >>>> Another point is SWF. I'm not focusing in that output and even I
> >> >>>>didn't
> >> >>>> compile to SWF for long time, so don't know how
> >> >>>> is looking, but for what I saw in other discussions seems that
> >>Flash
> >> >>>> needs
> >> >>>> to implement the old Flex architecture of
> >> >>>> updateDisplayList to manage refresh to avoid continuous redrawing
> >>of
> >> >>>>the
> >> >>>> screen.
> >> >>>>
> >> >>>> So my bet is that our AS3 layout components should do:
> >> >>>>
> >> >>>> 1.- In JS -> add className to "some-class-layout" (for example for
> >> >>>> circle,
> >> >>>> if we have circle-layout, we should have a "circleLayout" css class
> >> >>>> selector, that we could assign to out flexjs "list component"
> >> >>>>
> >> >>>> 2.- in SWF -> we should stick with the way this was done in Flex4
> >>but
> >> >>>> implementing as a bead and with the "updateDisplayList" performance
> >> >>>>
> >> >>>> What do you think?
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >> >>>>
> >> >>>>> A lot of this work is mine and it seems to need to be thought
> >>through
> >> >>>>> once
> >> >>>>> again. The dichotomy of SWF & JS has presented problems for me in
> >>the
> >> >>>>> past.
> >> >>>>>
> >> >>>>> Maybe the layouts, for JS platform, should do as little as
> >>possible,
> >> >>>>> replying on CSS as much as possible. Then make the SWF platform
> >>mimic
> >> >>>>> that.
> >> >>>>>
> >> >>>>> One issue that comes up for me is that we automatically set
> >>display
> >> >>>>>and
> >> >>>>> position for every element soon after its created. If you were to
> >> >>>>> hand-write the HTML you probably would not do that.
> >> >>>>>
> >> >>>>> So perhaps FlexJS should not set these styles at all and instead
> >>let
> >> >>>>> the
> >> >>>>> layout set them if the layout even needs to do that.
> >> >>>>>
> >> >>>>> Thoughts?
> >> >>>>> ‹peter
> >> >>>>>
> >> >>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
> >> >>>>>
> >> >>>>>> We¹re really struggling with layout.
> >> >>>>>>
> >> >>>>>> Yishay just mentioned the fact that padding is not working, but
> >>the
> >> >>>>>> problems seem to go much deeper than that.
> >> >>>>>>
> >> >>>>>> 1. VerticalLayout has the following code:
> >> >>>>>> for (i = 0; i < n; i++)
> >> >>>>>> {
> >> >>>>>> var
> >>child:WrappedHTMLElement =
> >> >>>>> children[i];
> >> >>>>>> child.flexjs_wrapper.
> >> >>>>> setDisplayStyleForLayout('block');
> >> >>>>>> if (child.style.display ===
> >> >>>>> 'none')
> >> >>>>>> {
> >> >>>>>>
> >>child.flexjs_wrapper.
> >> >>>>> setDisplayStyleForLayout('block');
> >> >>>>>> }
> >> >>>>>> else
> >> >>>>>> {
> >> >>>>>> // block elements
> >>don't
> >> >>>>> measure width correctly so set to inline
> >> >>>>>> for a second
> >> >>>>>> child.style.display
> >>=
> >> >>>>> 'inline-block';
> >> >>>>>> maxWidth =
> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >> >>>>>> child.style.display
> >>=
> >> >>>>> 'block';
> >> >>>>>> }
> >> >>>>>> child.flexjs_wrapper.
> >> >>>>> dispatchEvent('sizeChanged');
> >> >>>>>> }
> >> >>>>>>
> >> >>>>>> There is a number of problems that I can see with this. Firstly,
> >> >>>>>>it¹s
> >> >>>>>> horribly inefficient:
> >> >>>>>> child.style.display
> >>=
> >> >>>>> 'inline-block';
> >> >>>>>> maxWidth =
> >> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >> >>>>>> The above will force a browser redraw at every step of the loop.
> >>If
> >> >>>>> you
> >> >>>>>> have hundreds of children, there will be hundreds of redraws
> >>just to
> >> >>>>>> figure out the children width. If anything, there should
> >>probably be
> >> >>>>>> three loops: One to set the inline-blocks, The second to measure
> >>all
> >> >>>>> the
> >> >>>>>> children (the first measure would trigger a redraw, but
> >>subsequent
> >> >>>>> ones
> >> >>>>>> not) The third to set inline-block back.
> >> >>>>>>
> >> >>>>>> Secondly, there¹s only a need to measure the children if the
> >> >>>>>>container
> >> >>>>> is
> >> >>>>>> sized to content. If the container has a fixed width or a
> >>percentage
> >> >>>>>> width, I don¹t see why the children should be measured at all.
> >>The
> >> >>>>> only
> >> >>>>>> exception I can see is if there is overflow:auto.
> >> >>>>>>
> >> >>>>>> Thirdly, I don¹t understand how setting the child to inline-block
> >> >>>>> helps.
> >> >>>>>> What about the grandchildren? Don¹t those need to be measured
> >>too?
> >> >>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
> >> >>>>> temporarily
> >> >>>>>> sets inline-block. BasicLayout does not, and I don¹t understand
> >>why
> >> >>>>>> there¹s a difference. (BasicLayout has the same re-rendering
> >>problem
> >> >>>>>> though.)
> >> >>>>>> 2.
> >> >>>>>> if (!hasWidth && n > 0 &&
> >> >>>>> !isNaN(maxWidth)) {
> >> >>>>>> var pl:String =
> >> >>>>> scv['padding-left'];
> >> >>>>>> var pr:String =
> >> >>>>> scv['padding-right'];
> >> >>>>>> var npl:int =
> >> >>>>> parseInt(pl.substring(0, pl.length - 2), 10);
> >> >>>>>> var npr:int =
> >> >>>>> parseInt(pr.substring(0, pr.length - 2), 10);
> >> >>>>>> maxWidth += npl + npr;
> >> >>>>>> contentView.width =
> >>maxWidth;
> >> >>>>>> }
> >> >>>>>>
> >> >>>>>> This seems totally wrong. Why is the padding being added when
> >>we¹re
> >> >>>>> using
> >> >>>>>> box-sizing: border-box?
> >> >>>>>>
> >> >>>>>> 3. Percentage size seems to be set based on the children rather
> >>than
> >> >>>>> the
> >> >>>>>> parents.
> >> >>>>>>
> >> >>>>>> 4. I¹m not sure I understand the layout lifecycle very well. We
> >>have
> >> >>>>> had
> >> >>>>>> cases where children did not seem to be layout, and forcing a
> >>layout
> >> >>>>>> seemed to be very difficult to do.
> >> >>>>>>
> >> >>>>>> Harbs
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>>
> >> >>>> Carlos Rovira
> >> >>>> Director General
> >> >>>> M: +34 607 22 60 05
> >> >>>> http://www.codeoscopic.com
> >> >>>> http://www.avant2.es
> >> >>>>
> >> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
> >> >>>>contener
> >> >>>> información privilegiada o confidencial. Si ha recibido este
> >>mensaje
> >> >>>>por
> >> >>>> error, le rogamos que nos lo comunique inmediatamente por esta
> >>misma
> >> >>>>vía
> >> >>>> y
> >> >>>> proceda a su destrucción.
> >> >>>>
> >> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >> >>>> comunicamos
> >> >>>> que sus datos forman parte de un fichero cuyo responsable es
> >> >>>>CODEOSCOPIC
> >> >>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación
> >>del
> >> >>>> servicio o información solicitados, teniendo usted derecho de
> >>acceso,
> >> >>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
> >> >>>> nuestras
> >> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
> >> >>>>documentación
> >> >>>> necesaria.
> >> >>>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >
> >Carlos Rovira
> >Director General
> >M: +34 607 22 60 05
> >http://www.codeoscopic.com
> >http://www.avant2.es
> >
> >Este mensaje se dirige exclusivamente a su destinatario y puede contener
> >información privilegiada o confidencial. Si ha recibido este mensaje por
> >error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
> >proceda a su destrucción.
> >
> >De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >comunicamos
> >que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
> >S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> >servicio o información solicitados, teniendo usted derecho de acceso,
> >rectificación, cancelación y oposición de sus datos dirigiéndose a
> >nuestras
> >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
> >necesaria.
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
That's a good strategy. My experiments this morning look like Flexbox is
the way to go. Its widely supported now and seems pretty easy to use.
I'm going to create VerticalFlexLayout and HorizontalFlexLayout and have
them extend the current versions just so the SWF side stays the same for
right now. The JS side will implement Flexbox. Then we can all try it out
and see how it behaves. If that's good, I can replace the current JS
version with the Flexbox version and then work on the SWF side to make it
compatible.
Will keep you all posted.
—peter
On 2/22/17, 10:16 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>That looks very promising Peter. Look forward to see some progress :)
>If flexbox is the future, I think we should always look to go with that
>specs, and in case that still is not in some browsers, search for a
>polyfill that could do the job for not supported browsers for now. At the
>end browsers will support it, and polyfill will end in no use (and we
>could
>eventually remove)
>
>2017-02-22 14:47 GMT+01:00 Peter Ent <pe...@adobe.com>:
>
>> I'm going to try some experiments in my own space. Basically, figuring
>>out
>> the best way to do simple layouts using CSS - vertical and horizontal
>>with
>> alignment options (center, left, right for vertical, top, middle, bottom
>> for horizontal). Because alignment will probably require more cycles
>>when
>> implemented in SWF, I will look to making these beads or
>> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
>> percentage sizes as well. A better understanding, on my part, of
>>HTML/CSS
>> capabilities will really help.
>>
>> Once I think the JS side is simple enough, I'll mimic then for the SWF
>> side. I really don't see why this should be complex. The big issue on
>>the
>> SWF side is not always knowing the size of the item that you want to
>> position and size.
>>
>> I have been reading about CSS Flexbox which seems like it is the future
>>of
>> layout for HTML/CSS. It seems to be widely supported at this point. The
>> next generation, Grid, is still in the W3C draft phase, but that will be
>> handy too once it gets adopted. I'll look into using various settings of
>> display and position first before resorting to Flexbox.
>>
>> —peter
>>
>> On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >
>> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
>> >>
>> >> It is probably time for our annual "revisiting of the layout code".
>>I
>> >> think if you look at source code history, Peter or I do this every so
>> >> often as we get more examples to work with.
>> >>
>> >> From memory, there are issues like whether we have to set
>> >> position:relative or not that came out of the MDL swc. And when/if
>>we
>> >> need to set the width on a parent for percentage width to work in the
>> >> children/grandchildren.
>> >>
>> >> It is great to finally have some people actually paying attention
>>that
>> >> know how this stuff is actually normally done in JS. Peter and I
>>were
>> >> mostly guessing since, if you think about it, we were basically doing
>> >>Flex
>> >> until we got into FlexJS and are not experienced in HTML/JS.
>> >>
>> >> So, fundamentally, if you have to stack things vertically, should you
>> >>use
>> >> display:block? If you have to line up a bunch of divs horizontally,
>> >> should you use display:inline-block?
>> >
>> >It depends. If everything is position:relative, then theoretically,
>>yes.
>> >The problem with position:relative in my experience is that it’s too
>> >unpredictable. I can’t give examples right now, but I know I spent
>> >countless hours struggling with getting HTML to correctly position
>> >elements using relative positioning. So while theoretically, using CSS
>> >and built-in browser positioning sounds good, I think there are enough
>> >edge cases to make it really difficult to be reliable in practice.
>> >
>> >> Is there a better way to do BasicLayout? We ended up using a
>>completely
>> >> handwritten set of code to essentially make everything use absolute
>> >> positioning.
>> >>
>> >> Is border-box working as expected? Do you set the height/width to
>> >>include
>> >> the padding or not?
>> >
>> >Yes. The size includes the padding, but padding only serves a function
>>if
>> >the children are positioned relative. Currently, that’s not the case
>> >AFAICT.
>> >
>> >
>> >> I think some layouts can use CSS but others have to be written in
>>code
>> >>to
>> >> override default browser behavior. But I'd love to be wrong about
>>that
>> >> (at least, without relying on latest browsers or polyfills).
>> >>
>> >> And finally, are there ways we can call the layout fewer times than
>>we
>> >> currently do?
>> >
>> >I don’t understand the current layout lifecycle well enough. I do know
>> >that we’ve observed layouts consistently happening twice, so I’d guess
>> >that the answer would be yes.
>> >
>> >Ultimately, it would be great to have a layout which relies exclusively
>> >on CSS, and if that can be achieved, it would be the most efficient way
>> >to lay things out in HTML.
>> >
>> >My belief is that it’s unattainable for anything but the simplest
>>layouts
>> >to rely on CSS. If we are not relying on CSS, then I believe the best
>>way
>> >to go is to calculate the layout almost exclusively in javascript and
>> >layout pretty much everything with position:absolute. The only
>>exception
>> >for that would be elements which should truly reflow based on the HTML
>> >layout (i.e. text and inline images, possibly image grids, etc.) The
>>more
>> >reliance we have on CSS, the more we’re opening the layout to bugs.
>> >Additionally, the more the code has to examine the results of browser
>> >rendering, the less efficient the JS code will be. Javascript alone is
>> >really fast in modern engines. It’s when there’s DOM interactions that
>> >Javascript hits a performance wall. The more we can keep the
>>calculations
>> >in pure JS and avoid DOM interaction, the better.
>> >
>> >So I would propose two sets of Layouts:
>> >CSSLayout which might or might not have sub-layouts to do bare-b ones
>> >layout optimized for as little JS code to run as possible and allow
>> >settings to be set using CSS. (cheap as possible PAYG layout)
>> >FlexLayout which would have vertical,horizontal,absolute,grid, etc.
>> >
>> >FlexLayout would use FlexJS properties to calculate layout, and support
>> >percentage, left,right,top,bottom properties to do proper constrained
>> >layout. I think that constrained layout (right,left,top,bottom) is
>>common
>> >enough that it doesn’t warrant a separate layout as long as we have the
>> >bare-bones CSSLayout for cases that need it.
>> >
>> >> For sure, we need to the the JS side right and then worry about the
>>SWF
>> >> side. I think there are way fewer behavior issues on the SWF side to
>> >>deal
>> >> with.
>> >
>> >Agreed.
>> >
>> >Harbs
>> >
>> >> My 2 cents,
>> >> -Alex
>> >>
>> >> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>> >>
>> >>> I think this is generally a good approach.
>> >>>
>> >>> I've been thinking that we have some refactoring to do which might
>> >>>help.
>> >>> For instance, Core should probably be edited to include interfaces,
>> >>> events, and whatever else works across all packages. HTML should
>> >>>probably
>> >>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that
>>wants
>> >>> HTML+ActionScript can use that and then use CSS to do all their
>> >>>layouts;
>> >>> HTML would not have a SWF version.
>> >>>
>> >>> Then Basic could be SWF & JS with layouts that are light on the JS
>>side
>> >>> using CSS and AS code to mimic them on the SWF side. Express would
>>do
>> >>>what
>> >>> it is doing now and compose components by extending the Basic set
>>and
>> >>> adding common beads.
>> >>>
>> >>> I've been hung up with the JS side having stuck on the display and
>> >>> position values and deferring them might be the best solution.
>> >>>
>> >>> —peter
>> >>>
>> >>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos
>> >>>Rovira"
>> >>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>> >>> wrote:
>> >>>
>> >>>> Hi Peter,
>> >>>>
>> >>>> it seems HTML rely for this task heavily on CSS to the point that
>> >>>>almost
>> >>>> nothing is done in html or js code.
>> >>>> So maybe we are not in the right way for HTML platform and we
>>should
>> >>>>make
>> >>>> our code be mainly CSS.
>> >>>> An example is here:
>> >>>>
>> >>>> https://css-tricks.com/snippets/sass/placing-items-circle/
>> >>>>
>> >>>> Another point is SWF. I'm not focusing in that output and even I
>> >>>>didn't
>> >>>> compile to SWF for long time, so don't know how
>> >>>> is looking, but for what I saw in other discussions seems that
>>Flash
>> >>>> needs
>> >>>> to implement the old Flex architecture of
>> >>>> updateDisplayList to manage refresh to avoid continuous redrawing
>>of
>> >>>>the
>> >>>> screen.
>> >>>>
>> >>>> So my bet is that our AS3 layout components should do:
>> >>>>
>> >>>> 1.- In JS -> add className to "some-class-layout" (for example for
>> >>>> circle,
>> >>>> if we have circle-layout, we should have a "circleLayout" css class
>> >>>> selector, that we could assign to out flexjs "list component"
>> >>>>
>> >>>> 2.- in SWF -> we should stick with the way this was done in Flex4
>>but
>> >>>> implementing as a bead and with the "updateDisplayList" performance
>> >>>>
>> >>>> What do you think?
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>> >>>>
>> >>>>> A lot of this work is mine and it seems to need to be thought
>>through
>> >>>>> once
>> >>>>> again. The dichotomy of SWF & JS has presented problems for me in
>>the
>> >>>>> past.
>> >>>>>
>> >>>>> Maybe the layouts, for JS platform, should do as little as
>>possible,
>> >>>>> replying on CSS as much as possible. Then make the SWF platform
>>mimic
>> >>>>> that.
>> >>>>>
>> >>>>> One issue that comes up for me is that we automatically set
>>display
>> >>>>>and
>> >>>>> position for every element soon after its created. If you were to
>> >>>>> hand-write the HTML you probably would not do that.
>> >>>>>
>> >>>>> So perhaps FlexJS should not set these styles at all and instead
>>let
>> >>>>> the
>> >>>>> layout set them if the layout even needs to do that.
>> >>>>>
>> >>>>> Thoughts?
>> >>>>> ‹peter
>> >>>>>
>> >>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>> >>>>>
>> >>>>>> We¹re really struggling with layout.
>> >>>>>>
>> >>>>>> Yishay just mentioned the fact that padding is not working, but
>>the
>> >>>>>> problems seem to go much deeper than that.
>> >>>>>>
>> >>>>>> 1. VerticalLayout has the following code:
>> >>>>>> for (i = 0; i < n; i++)
>> >>>>>> {
>> >>>>>> var
>>child:WrappedHTMLElement =
>> >>>>> children[i];
>> >>>>>> child.flexjs_wrapper.
>> >>>>> setDisplayStyleForLayout('block');
>> >>>>>> if (child.style.display ===
>> >>>>> 'none')
>> >>>>>> {
>> >>>>>>
>>child.flexjs_wrapper.
>> >>>>> setDisplayStyleForLayout('block');
>> >>>>>> }
>> >>>>>> else
>> >>>>>> {
>> >>>>>> // block elements
>>don't
>> >>>>> measure width correctly so set to inline
>> >>>>>> for a second
>> >>>>>> child.style.display
>>=
>> >>>>> 'inline-block';
>> >>>>>> maxWidth =
>> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >>>>>> child.style.display
>>=
>> >>>>> 'block';
>> >>>>>> }
>> >>>>>> child.flexjs_wrapper.
>> >>>>> dispatchEvent('sizeChanged');
>> >>>>>> }
>> >>>>>>
>> >>>>>> There is a number of problems that I can see with this. Firstly,
>> >>>>>>it¹s
>> >>>>>> horribly inefficient:
>> >>>>>> child.style.display
>>=
>> >>>>> 'inline-block';
>> >>>>>> maxWidth =
>> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >>>>>> The above will force a browser redraw at every step of the loop.
>>If
>> >>>>> you
>> >>>>>> have hundreds of children, there will be hundreds of redraws
>>just to
>> >>>>>> figure out the children width. If anything, there should
>>probably be
>> >>>>>> three loops: One to set the inline-blocks, The second to measure
>>all
>> >>>>> the
>> >>>>>> children (the first measure would trigger a redraw, but
>>subsequent
>> >>>>> ones
>> >>>>>> not) The third to set inline-block back.
>> >>>>>>
>> >>>>>> Secondly, there¹s only a need to measure the children if the
>> >>>>>>container
>> >>>>> is
>> >>>>>> sized to content. If the container has a fixed width or a
>>percentage
>> >>>>>> width, I don¹t see why the children should be measured at all.
>>The
>> >>>>> only
>> >>>>>> exception I can see is if there is overflow:auto.
>> >>>>>>
>> >>>>>> Thirdly, I don¹t understand how setting the child to inline-block
>> >>>>> helps.
>> >>>>>> What about the grandchildren? Don¹t those need to be measured
>>too?
>> >>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
>> >>>>> temporarily
>> >>>>>> sets inline-block. BasicLayout does not, and I don¹t understand
>>why
>> >>>>>> there¹s a difference. (BasicLayout has the same re-rendering
>>problem
>> >>>>>> though.)
>> >>>>>> 2.
>> >>>>>> if (!hasWidth && n > 0 &&
>> >>>>> !isNaN(maxWidth)) {
>> >>>>>> var pl:String =
>> >>>>> scv['padding-left'];
>> >>>>>> var pr:String =
>> >>>>> scv['padding-right'];
>> >>>>>> var npl:int =
>> >>>>> parseInt(pl.substring(0, pl.length - 2), 10);
>> >>>>>> var npr:int =
>> >>>>> parseInt(pr.substring(0, pr.length - 2), 10);
>> >>>>>> maxWidth += npl + npr;
>> >>>>>> contentView.width =
>>maxWidth;
>> >>>>>> }
>> >>>>>>
>> >>>>>> This seems totally wrong. Why is the padding being added when
>>we¹re
>> >>>>> using
>> >>>>>> box-sizing: border-box?
>> >>>>>>
>> >>>>>> 3. Percentage size seems to be set based on the children rather
>>than
>> >>>>> the
>> >>>>>> parents.
>> >>>>>>
>> >>>>>> 4. I¹m not sure I understand the layout lifecycle very well. We
>>have
>> >>>>> had
>> >>>>>> cases where children did not seem to be layout, and forcing a
>>layout
>> >>>>>> seemed to be very difficult to do.
>> >>>>>>
>> >>>>>> Harbs
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Carlos Rovira
>> >>>> Director General
>> >>>> M: +34 607 22 60 05
>> >>>> http://www.codeoscopic.com
>> >>>> http://www.avant2.es
>> >>>>
>> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
>> >>>>contener
>> >>>> información privilegiada o confidencial. Si ha recibido este
>>mensaje
>> >>>>por
>> >>>> error, le rogamos que nos lo comunique inmediatamente por esta
>>misma
>> >>>>vía
>> >>>> y
>> >>>> proceda a su destrucción.
>> >>>>
>> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> >>>> comunicamos
>> >>>> que sus datos forman parte de un fichero cuyo responsable es
>> >>>>CODEOSCOPIC
>> >>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación
>>del
>> >>>> servicio o información solicitados, teniendo usted derecho de
>>acceso,
>> >>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>> >>>> nuestras
>> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> >>>>documentación
>> >>>> necesaria.
>> >>>
>> >>
>> >
>>
>>
>
>
>--
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.
Re: [FlexJS]Layout redux
Posted by Carlos Rovira <ca...@codeoscopic.com>.
That looks very promising Peter. Look forward to see some progress :)
If flexbox is the future, I think we should always look to go with that
specs, and in case that still is not in some browsers, search for a
polyfill that could do the job for not supported browsers for now. At the
end browsers will support it, and polyfill will end in no use (and we could
eventually remove)
2017-02-22 14:47 GMT+01:00 Peter Ent <pe...@adobe.com>:
> I'm going to try some experiments in my own space. Basically, figuring out
> the best way to do simple layouts using CSS - vertical and horizontal with
> alignment options (center, left, right for vertical, top, middle, bottom
> for horizontal). Because alignment will probably require more cycles when
> implemented in SWF, I will look to making these beads or
> VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
> percentage sizes as well. A better understanding, on my part, of HTML/CSS
> capabilities will really help.
>
> Once I think the JS side is simple enough, I'll mimic then for the SWF
> side. I really don't see why this should be complex. The big issue on the
> SWF side is not always knowing the size of the item that you want to
> position and size.
>
> I have been reading about CSS Flexbox which seems like it is the future of
> layout for HTML/CSS. It seems to be widely supported at this point. The
> next generation, Grid, is still in the W3C draft phase, but that will be
> handy too once it gets adopted. I'll look into using various settings of
> display and position first before resorting to Flexbox.
>
> —peter
>
> On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >
> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
> >>
> >> It is probably time for our annual "revisiting of the layout code". I
> >> think if you look at source code history, Peter or I do this every so
> >> often as we get more examples to work with.
> >>
> >> From memory, there are issues like whether we have to set
> >> position:relative or not that came out of the MDL swc. And when/if we
> >> need to set the width on a parent for percentage width to work in the
> >> children/grandchildren.
> >>
> >> It is great to finally have some people actually paying attention that
> >> know how this stuff is actually normally done in JS. Peter and I were
> >> mostly guessing since, if you think about it, we were basically doing
> >>Flex
> >> until we got into FlexJS and are not experienced in HTML/JS.
> >>
> >> So, fundamentally, if you have to stack things vertically, should you
> >>use
> >> display:block? If you have to line up a bunch of divs horizontally,
> >> should you use display:inline-block?
> >
> >It depends. If everything is position:relative, then theoretically, yes.
> >The problem with position:relative in my experience is that it’s too
> >unpredictable. I can’t give examples right now, but I know I spent
> >countless hours struggling with getting HTML to correctly position
> >elements using relative positioning. So while theoretically, using CSS
> >and built-in browser positioning sounds good, I think there are enough
> >edge cases to make it really difficult to be reliable in practice.
> >
> >> Is there a better way to do BasicLayout? We ended up using a completely
> >> handwritten set of code to essentially make everything use absolute
> >> positioning.
> >>
> >> Is border-box working as expected? Do you set the height/width to
> >>include
> >> the padding or not?
> >
> >Yes. The size includes the padding, but padding only serves a function if
> >the children are positioned relative. Currently, that’s not the case
> >AFAICT.
> >
> >
> >> I think some layouts can use CSS but others have to be written in code
> >>to
> >> override default browser behavior. But I'd love to be wrong about that
> >> (at least, without relying on latest browsers or polyfills).
> >>
> >> And finally, are there ways we can call the layout fewer times than we
> >> currently do?
> >
> >I don’t understand the current layout lifecycle well enough. I do know
> >that we’ve observed layouts consistently happening twice, so I’d guess
> >that the answer would be yes.
> >
> >Ultimately, it would be great to have a layout which relies exclusively
> >on CSS, and if that can be achieved, it would be the most efficient way
> >to lay things out in HTML.
> >
> >My belief is that it’s unattainable for anything but the simplest layouts
> >to rely on CSS. If we are not relying on CSS, then I believe the best way
> >to go is to calculate the layout almost exclusively in javascript and
> >layout pretty much everything with position:absolute. The only exception
> >for that would be elements which should truly reflow based on the HTML
> >layout (i.e. text and inline images, possibly image grids, etc.) The more
> >reliance we have on CSS, the more we’re opening the layout to bugs.
> >Additionally, the more the code has to examine the results of browser
> >rendering, the less efficient the JS code will be. Javascript alone is
> >really fast in modern engines. It’s when there’s DOM interactions that
> >Javascript hits a performance wall. The more we can keep the calculations
> >in pure JS and avoid DOM interaction, the better.
> >
> >So I would propose two sets of Layouts:
> >CSSLayout which might or might not have sub-layouts to do bare-b ones
> >layout optimized for as little JS code to run as possible and allow
> >settings to be set using CSS. (cheap as possible PAYG layout)
> >FlexLayout which would have vertical,horizontal,absolute,grid, etc.
> >
> >FlexLayout would use FlexJS properties to calculate layout, and support
> >percentage, left,right,top,bottom properties to do proper constrained
> >layout. I think that constrained layout (right,left,top,bottom) is common
> >enough that it doesn’t warrant a separate layout as long as we have the
> >bare-bones CSSLayout for cases that need it.
> >
> >> For sure, we need to the the JS side right and then worry about the SWF
> >> side. I think there are way fewer behavior issues on the SWF side to
> >>deal
> >> with.
> >
> >Agreed.
> >
> >Harbs
> >
> >> My 2 cents,
> >> -Alex
> >>
> >> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
> >>
> >>> I think this is generally a good approach.
> >>>
> >>> I've been thinking that we have some refactoring to do which might
> >>>help.
> >>> For instance, Core should probably be edited to include interfaces,
> >>> events, and whatever else works across all packages. HTML should
> >>>probably
> >>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
> >>> HTML+ActionScript can use that and then use CSS to do all their
> >>>layouts;
> >>> HTML would not have a SWF version.
> >>>
> >>> Then Basic could be SWF & JS with layouts that are light on the JS side
> >>> using CSS and AS code to mimic them on the SWF side. Express would do
> >>>what
> >>> it is doing now and compose components by extending the Basic set and
> >>> adding common beads.
> >>>
> >>> I've been hung up with the JS side having stuck on the display and
> >>> position values and deferring them might be the best solution.
> >>>
> >>> —peter
> >>>
> >>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos
> >>>Rovira"
> >>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
> >>> wrote:
> >>>
> >>>> Hi Peter,
> >>>>
> >>>> it seems HTML rely for this task heavily on CSS to the point that
> >>>>almost
> >>>> nothing is done in html or js code.
> >>>> So maybe we are not in the right way for HTML platform and we should
> >>>>make
> >>>> our code be mainly CSS.
> >>>> An example is here:
> >>>>
> >>>> https://css-tricks.com/snippets/sass/placing-items-circle/
> >>>>
> >>>> Another point is SWF. I'm not focusing in that output and even I
> >>>>didn't
> >>>> compile to SWF for long time, so don't know how
> >>>> is looking, but for what I saw in other discussions seems that Flash
> >>>> needs
> >>>> to implement the old Flex architecture of
> >>>> updateDisplayList to manage refresh to avoid continuous redrawing of
> >>>>the
> >>>> screen.
> >>>>
> >>>> So my bet is that our AS3 layout components should do:
> >>>>
> >>>> 1.- In JS -> add className to "some-class-layout" (for example for
> >>>> circle,
> >>>> if we have circle-layout, we should have a "circleLayout" css class
> >>>> selector, that we could assign to out flexjs "list component"
> >>>>
> >>>> 2.- in SWF -> we should stick with the way this was done in Flex4 but
> >>>> implementing as a bead and with the "updateDisplayList" performance
> >>>>
> >>>> What do you think?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
> >>>>
> >>>>> A lot of this work is mine and it seems to need to be thought through
> >>>>> once
> >>>>> again. The dichotomy of SWF & JS has presented problems for me in the
> >>>>> past.
> >>>>>
> >>>>> Maybe the layouts, for JS platform, should do as little as possible,
> >>>>> replying on CSS as much as possible. Then make the SWF platform mimic
> >>>>> that.
> >>>>>
> >>>>> One issue that comes up for me is that we automatically set display
> >>>>>and
> >>>>> position for every element soon after its created. If you were to
> >>>>> hand-write the HTML you probably would not do that.
> >>>>>
> >>>>> So perhaps FlexJS should not set these styles at all and instead let
> >>>>> the
> >>>>> layout set them if the layout even needs to do that.
> >>>>>
> >>>>> Thoughts?
> >>>>> ‹peter
> >>>>>
> >>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
> >>>>>
> >>>>>> We¹re really struggling with layout.
> >>>>>>
> >>>>>> Yishay just mentioned the fact that padding is not working, but the
> >>>>>> problems seem to go much deeper than that.
> >>>>>>
> >>>>>> 1. VerticalLayout has the following code:
> >>>>>> for (i = 0; i < n; i++)
> >>>>>> {
> >>>>>> var child:WrappedHTMLElement =
> >>>>> children[i];
> >>>>>> child.flexjs_wrapper.
> >>>>> setDisplayStyleForLayout('block');
> >>>>>> if (child.style.display ===
> >>>>> 'none')
> >>>>>> {
> >>>>>> child.flexjs_wrapper.
> >>>>> setDisplayStyleForLayout('block');
> >>>>>> }
> >>>>>> else
> >>>>>> {
> >>>>>> // block elements don't
> >>>>> measure width correctly so set to inline
> >>>>>> for a second
> >>>>>> child.style.display =
> >>>>> 'inline-block';
> >>>>>> maxWidth =
> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >>>>>> child.style.display =
> >>>>> 'block';
> >>>>>> }
> >>>>>> child.flexjs_wrapper.
> >>>>> dispatchEvent('sizeChanged');
> >>>>>> }
> >>>>>>
> >>>>>> There is a number of problems that I can see with this. Firstly,
> >>>>>>it¹s
> >>>>>> horribly inefficient:
> >>>>>> child.style.display =
> >>>>> 'inline-block';
> >>>>>> maxWidth =
> >>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >>>>>> The above will force a browser redraw at every step of the loop. If
> >>>>> you
> >>>>>> have hundreds of children, there will be hundreds of redraws just to
> >>>>>> figure out the children width. If anything, there should probably be
> >>>>>> three loops: One to set the inline-blocks, The second to measure all
> >>>>> the
> >>>>>> children (the first measure would trigger a redraw, but subsequent
> >>>>> ones
> >>>>>> not) The third to set inline-block back.
> >>>>>>
> >>>>>> Secondly, there¹s only a need to measure the children if the
> >>>>>>container
> >>>>> is
> >>>>>> sized to content. If the container has a fixed width or a percentage
> >>>>>> width, I don¹t see why the children should be measured at all. The
> >>>>> only
> >>>>>> exception I can see is if there is overflow:auto.
> >>>>>>
> >>>>>> Thirdly, I don¹t understand how setting the child to inline-block
> >>>>> helps.
> >>>>>> What about the grandchildren? Don¹t those need to be measured too?
> >>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
> >>>>> temporarily
> >>>>>> sets inline-block. BasicLayout does not, and I don¹t understand why
> >>>>>> there¹s a difference. (BasicLayout has the same re-rendering problem
> >>>>>> though.)
> >>>>>> 2.
> >>>>>> if (!hasWidth && n > 0 &&
> >>>>> !isNaN(maxWidth)) {
> >>>>>> var pl:String =
> >>>>> scv['padding-left'];
> >>>>>> var pr:String =
> >>>>> scv['padding-right'];
> >>>>>> var npl:int =
> >>>>> parseInt(pl.substring(0, pl.length - 2), 10);
> >>>>>> var npr:int =
> >>>>> parseInt(pr.substring(0, pr.length - 2), 10);
> >>>>>> maxWidth += npl + npr;
> >>>>>> contentView.width = maxWidth;
> >>>>>> }
> >>>>>>
> >>>>>> This seems totally wrong. Why is the padding being added when we¹re
> >>>>> using
> >>>>>> box-sizing: border-box?
> >>>>>>
> >>>>>> 3. Percentage size seems to be set based on the children rather than
> >>>>> the
> >>>>>> parents.
> >>>>>>
> >>>>>> 4. I¹m not sure I understand the layout lifecycle very well. We have
> >>>>> had
> >>>>>> cases where children did not seem to be layout, and forcing a layout
> >>>>>> seemed to be very difficult to do.
> >>>>>>
> >>>>>> Harbs
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Carlos Rovira
> >>>> Director General
> >>>> M: +34 607 22 60 05
> >>>> http://www.codeoscopic.com
> >>>> http://www.avant2.es
> >>>>
> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
> >>>>contener
> >>>> información privilegiada o confidencial. Si ha recibido este mensaje
> >>>>por
> >>>> error, le rogamos que nos lo comunique inmediatamente por esta misma
> >>>>vía
> >>>> y
> >>>> proceda a su destrucción.
> >>>>
> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
> >>>> comunicamos
> >>>> que sus datos forman parte de un fichero cuyo responsable es
> >>>>CODEOSCOPIC
> >>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
> >>>> servicio o información solicitados, teniendo usted derecho de acceso,
> >>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
> >>>> nuestras
> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
> >>>>documentación
> >>>> necesaria.
> >>>
> >>
> >
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
I'm going to try some experiments in my own space. Basically, figuring out
the best way to do simple layouts using CSS - vertical and horizontal with
alignment options (center, left, right for vertical, top, middle, bottom
for horizontal). Because alignment will probably require more cycles when
implemented in SWF, I will look to making these beads or
VerticalLayoutWithAlignment to keep in PAYG. I'll pay attention to
percentage sizes as well. A better understanding, on my part, of HTML/CSS
capabilities will really help.
Once I think the JS side is simple enough, I'll mimic then for the SWF
side. I really don't see why this should be complex. The big issue on the
SWF side is not always knowing the size of the item that you want to
position and size.
I have been reading about CSS Flexbox which seems like it is the future of
layout for HTML/CSS. It seems to be widely supported at this point. The
next generation, Grid, is still in the W3C draft phase, but that will be
handy too once it gets adopted. I'll look into using various settings of
display and position first before resorting to Flexbox.
—peter
On 2/22/17, 3:29 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
>>
>> It is probably time for our annual "revisiting of the layout code". I
>> think if you look at source code history, Peter or I do this every so
>> often as we get more examples to work with.
>>
>> From memory, there are issues like whether we have to set
>> position:relative or not that came out of the MDL swc. And when/if we
>> need to set the width on a parent for percentage width to work in the
>> children/grandchildren.
>>
>> It is great to finally have some people actually paying attention that
>> know how this stuff is actually normally done in JS. Peter and I were
>> mostly guessing since, if you think about it, we were basically doing
>>Flex
>> until we got into FlexJS and are not experienced in HTML/JS.
>>
>> So, fundamentally, if you have to stack things vertically, should you
>>use
>> display:block? If you have to line up a bunch of divs horizontally,
>> should you use display:inline-block?
>
>It depends. If everything is position:relative, then theoretically, yes.
>The problem with position:relative in my experience is that it’s too
>unpredictable. I can’t give examples right now, but I know I spent
>countless hours struggling with getting HTML to correctly position
>elements using relative positioning. So while theoretically, using CSS
>and built-in browser positioning sounds good, I think there are enough
>edge cases to make it really difficult to be reliable in practice.
>
>> Is there a better way to do BasicLayout? We ended up using a completely
>> handwritten set of code to essentially make everything use absolute
>> positioning.
>>
>> Is border-box working as expected? Do you set the height/width to
>>include
>> the padding or not?
>
>Yes. The size includes the padding, but padding only serves a function if
>the children are positioned relative. Currently, that’s not the case
>AFAICT.
>
>
>> I think some layouts can use CSS but others have to be written in code
>>to
>> override default browser behavior. But I'd love to be wrong about that
>> (at least, without relying on latest browsers or polyfills).
>>
>> And finally, are there ways we can call the layout fewer times than we
>> currently do?
>
>I don’t understand the current layout lifecycle well enough. I do know
>that we’ve observed layouts consistently happening twice, so I’d guess
>that the answer would be yes.
>
>Ultimately, it would be great to have a layout which relies exclusively
>on CSS, and if that can be achieved, it would be the most efficient way
>to lay things out in HTML.
>
>My belief is that it’s unattainable for anything but the simplest layouts
>to rely on CSS. If we are not relying on CSS, then I believe the best way
>to go is to calculate the layout almost exclusively in javascript and
>layout pretty much everything with position:absolute. The only exception
>for that would be elements which should truly reflow based on the HTML
>layout (i.e. text and inline images, possibly image grids, etc.) The more
>reliance we have on CSS, the more we’re opening the layout to bugs.
>Additionally, the more the code has to examine the results of browser
>rendering, the less efficient the JS code will be. Javascript alone is
>really fast in modern engines. It’s when there’s DOM interactions that
>Javascript hits a performance wall. The more we can keep the calculations
>in pure JS and avoid DOM interaction, the better.
>
>So I would propose two sets of Layouts:
>CSSLayout which might or might not have sub-layouts to do bare-b ones
>layout optimized for as little JS code to run as possible and allow
>settings to be set using CSS. (cheap as possible PAYG layout)
>FlexLayout which would have vertical,horizontal,absolute,grid, etc.
>
>FlexLayout would use FlexJS properties to calculate layout, and support
>percentage, left,right,top,bottom properties to do proper constrained
>layout. I think that constrained layout (right,left,top,bottom) is common
>enough that it doesn’t warrant a separate layout as long as we have the
>bare-bones CSSLayout for cases that need it.
>
>> For sure, we need to the the JS side right and then worry about the SWF
>> side. I think there are way fewer behavior issues on the SWF side to
>>deal
>> with.
>
>Agreed.
>
>Harbs
>
>> My 2 cents,
>> -Alex
>>
>> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>>
>>> I think this is generally a good approach.
>>>
>>> I've been thinking that we have some refactoring to do which might
>>>help.
>>> For instance, Core should probably be edited to include interfaces,
>>> events, and whatever else works across all packages. HTML should
>>>probably
>>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
>>> HTML+ActionScript can use that and then use CSS to do all their
>>>layouts;
>>> HTML would not have a SWF version.
>>>
>>> Then Basic could be SWF & JS with layouts that are light on the JS side
>>> using CSS and AS code to mimic them on the SWF side. Express would do
>>>what
>>> it is doing now and compose components by extending the Basic set and
>>> adding common beads.
>>>
>>> I've been hung up with the JS side having stuck on the display and
>>> position values and deferring them might be the best solution.
>>>
>>> —peter
>>>
>>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos
>>>Rovira"
>>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>>> wrote:
>>>
>>>> Hi Peter,
>>>>
>>>> it seems HTML rely for this task heavily on CSS to the point that
>>>>almost
>>>> nothing is done in html or js code.
>>>> So maybe we are not in the right way for HTML platform and we should
>>>>make
>>>> our code be mainly CSS.
>>>> An example is here:
>>>>
>>>> https://css-tricks.com/snippets/sass/placing-items-circle/
>>>>
>>>> Another point is SWF. I'm not focusing in that output and even I
>>>>didn't
>>>> compile to SWF for long time, so don't know how
>>>> is looking, but for what I saw in other discussions seems that Flash
>>>> needs
>>>> to implement the old Flex architecture of
>>>> updateDisplayList to manage refresh to avoid continuous redrawing of
>>>>the
>>>> screen.
>>>>
>>>> So my bet is that our AS3 layout components should do:
>>>>
>>>> 1.- In JS -> add className to "some-class-layout" (for example for
>>>> circle,
>>>> if we have circle-layout, we should have a "circleLayout" css class
>>>> selector, that we could assign to out flexjs "list component"
>>>>
>>>> 2.- in SWF -> we should stick with the way this was done in Flex4 but
>>>> implementing as a bead and with the "updateDisplayList" performance
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>>
>>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>>>>
>>>>> A lot of this work is mine and it seems to need to be thought through
>>>>> once
>>>>> again. The dichotomy of SWF & JS has presented problems for me in the
>>>>> past.
>>>>>
>>>>> Maybe the layouts, for JS platform, should do as little as possible,
>>>>> replying on CSS as much as possible. Then make the SWF platform mimic
>>>>> that.
>>>>>
>>>>> One issue that comes up for me is that we automatically set display
>>>>>and
>>>>> position for every element soon after its created. If you were to
>>>>> hand-write the HTML you probably would not do that.
>>>>>
>>>>> So perhaps FlexJS should not set these styles at all and instead let
>>>>> the
>>>>> layout set them if the layout even needs to do that.
>>>>>
>>>>> Thoughts?
>>>>> ‹peter
>>>>>
>>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> We¹re really struggling with layout.
>>>>>>
>>>>>> Yishay just mentioned the fact that padding is not working, but the
>>>>>> problems seem to go much deeper than that.
>>>>>>
>>>>>> 1. VerticalLayout has the following code:
>>>>>> for (i = 0; i < n; i++)
>>>>>> {
>>>>>> var child:WrappedHTMLElement =
>>>>> children[i];
>>>>>> child.flexjs_wrapper.
>>>>> setDisplayStyleForLayout('block');
>>>>>> if (child.style.display ===
>>>>> 'none')
>>>>>> {
>>>>>> child.flexjs_wrapper.
>>>>> setDisplayStyleForLayout('block');
>>>>>> }
>>>>>> else
>>>>>> {
>>>>>> // block elements don't
>>>>> measure width correctly so set to inline
>>>>>> for a second
>>>>>> child.style.display =
>>>>> 'inline-block';
>>>>>> maxWidth =
>>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>>>>> child.style.display =
>>>>> 'block';
>>>>>> }
>>>>>> child.flexjs_wrapper.
>>>>> dispatchEvent('sizeChanged');
>>>>>> }
>>>>>>
>>>>>> There is a number of problems that I can see with this. Firstly,
>>>>>>it¹s
>>>>>> horribly inefficient:
>>>>>> child.style.display =
>>>>> 'inline-block';
>>>>>> maxWidth =
>>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>>>>> The above will force a browser redraw at every step of the loop. If
>>>>> you
>>>>>> have hundreds of children, there will be hundreds of redraws just to
>>>>>> figure out the children width. If anything, there should probably be
>>>>>> three loops: One to set the inline-blocks, The second to measure all
>>>>> the
>>>>>> children (the first measure would trigger a redraw, but subsequent
>>>>> ones
>>>>>> not) The third to set inline-block back.
>>>>>>
>>>>>> Secondly, there¹s only a need to measure the children if the
>>>>>>container
>>>>> is
>>>>>> sized to content. If the container has a fixed width or a percentage
>>>>>> width, I don¹t see why the children should be measured at all. The
>>>>> only
>>>>>> exception I can see is if there is overflow:auto.
>>>>>>
>>>>>> Thirdly, I don¹t understand how setting the child to inline-block
>>>>> helps.
>>>>>> What about the grandchildren? Don¹t those need to be measured too?
>>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
>>>>> temporarily
>>>>>> sets inline-block. BasicLayout does not, and I don¹t understand why
>>>>>> there¹s a difference. (BasicLayout has the same re-rendering problem
>>>>>> though.)
>>>>>> 2.
>>>>>> if (!hasWidth && n > 0 &&
>>>>> !isNaN(maxWidth)) {
>>>>>> var pl:String =
>>>>> scv['padding-left'];
>>>>>> var pr:String =
>>>>> scv['padding-right'];
>>>>>> var npl:int =
>>>>> parseInt(pl.substring(0, pl.length - 2), 10);
>>>>>> var npr:int =
>>>>> parseInt(pr.substring(0, pr.length - 2), 10);
>>>>>> maxWidth += npl + npr;
>>>>>> contentView.width = maxWidth;
>>>>>> }
>>>>>>
>>>>>> This seems totally wrong. Why is the padding being added when we¹re
>>>>> using
>>>>>> box-sizing: border-box?
>>>>>>
>>>>>> 3. Percentage size seems to be set based on the children rather than
>>>>> the
>>>>>> parents.
>>>>>>
>>>>>> 4. I¹m not sure I understand the layout lifecycle very well. We have
>>>>> had
>>>>>> cases where children did not seem to be layout, and forcing a layout
>>>>>> seemed to be very difficult to do.
>>>>>>
>>>>>> Harbs
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Carlos Rovira
>>>> Director General
>>>> M: +34 607 22 60 05
>>>> http://www.codeoscopic.com
>>>> http://www.avant2.es
>>>>
>>>> Este mensaje se dirige exclusivamente a su destinatario y puede
>>>>contener
>>>> información privilegiada o confidencial. Si ha recibido este mensaje
>>>>por
>>>> error, le rogamos que nos lo comunique inmediatamente por esta misma
>>>>vía
>>>> y
>>>> proceda a su destrucción.
>>>>
>>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>>> comunicamos
>>>> que sus datos forman parte de un fichero cuyo responsable es
>>>>CODEOSCOPIC
>>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>>> servicio o información solicitados, teniendo usted derecho de acceso,
>>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>>>> nuestras
>>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>>>>documentación
>>>> necesaria.
>>>
>>
>
Re: [FlexJS]Layout redux
Posted by Harbs <ha...@gmail.com>.
> On Feb 22, 2017, at 9:46 AM, Alex Harui <ah...@adobe.com> wrote:
>
> It is probably time for our annual "revisiting of the layout code". I
> think if you look at source code history, Peter or I do this every so
> often as we get more examples to work with.
>
> From memory, there are issues like whether we have to set
> position:relative or not that came out of the MDL swc. And when/if we
> need to set the width on a parent for percentage width to work in the
> children/grandchildren.
>
> It is great to finally have some people actually paying attention that
> know how this stuff is actually normally done in JS. Peter and I were
> mostly guessing since, if you think about it, we were basically doing Flex
> until we got into FlexJS and are not experienced in HTML/JS.
>
> So, fundamentally, if you have to stack things vertically, should you use
> display:block? If you have to line up a bunch of divs horizontally,
> should you use display:inline-block?
It depends. If everything is position:relative, then theoretically, yes. The problem with position:relative in my experience is that it’s too unpredictable. I can’t give examples right now, but I know I spent countless hours struggling with getting HTML to correctly position elements using relative positioning. So while theoretically, using CSS and built-in browser positioning sounds good, I think there are enough edge cases to make it really difficult to be reliable in practice.
> Is there a better way to do BasicLayout? We ended up using a completely
> handwritten set of code to essentially make everything use absolute
> positioning.
>
> Is border-box working as expected? Do you set the height/width to include
> the padding or not?
Yes. The size includes the padding, but padding only serves a function if the children are positioned relative. Currently, that’s not the case AFAICT.
> I think some layouts can use CSS but others have to be written in code to
> override default browser behavior. But I'd love to be wrong about that
> (at least, without relying on latest browsers or polyfills).
>
> And finally, are there ways we can call the layout fewer times than we
> currently do?
I don’t understand the current layout lifecycle well enough. I do know that we’ve observed layouts consistently happening twice, so I’d guess that the answer would be yes.
Ultimately, it would be great to have a layout which relies exclusively on CSS, and if that can be achieved, it would be the most efficient way to lay things out in HTML.
My belief is that it’s unattainable for anything but the simplest layouts to rely on CSS. If we are not relying on CSS, then I believe the best way to go is to calculate the layout almost exclusively in javascript and layout pretty much everything with position:absolute. The only exception for that would be elements which should truly reflow based on the HTML layout (i.e. text and inline images, possibly image grids, etc.) The more reliance we have on CSS, the more we’re opening the layout to bugs. Additionally, the more the code has to examine the results of browser rendering, the less efficient the JS code will be. Javascript alone is really fast in modern engines. It’s when there’s DOM interactions that Javascript hits a performance wall. The more we can keep the calculations in pure JS and avoid DOM interaction, the better.
So I would propose two sets of Layouts:
CSSLayout which might or might not have sub-layouts to do bare-b ones layout optimized for as little JS code to run as possible and allow settings to be set using CSS. (cheap as possible PAYG layout)
FlexLayout which would have vertical,horizontal,absolute,grid, etc.
FlexLayout would use FlexJS properties to calculate layout, and support percentage, left,right,top,bottom properties to do proper constrained layout. I think that constrained layout (right,left,top,bottom) is common enough that it doesn’t warrant a separate layout as long as we have the bare-bones CSSLayout for cases that need it.
> For sure, we need to the the JS side right and then worry about the SWF
> side. I think there are way fewer behavior issues on the SWF side to deal
> with.
Agreed.
Harbs
> My 2 cents,
> -Alex
>
> On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>
>> I think this is generally a good approach.
>>
>> I've been thinking that we have some refactoring to do which might help.
>> For instance, Core should probably be edited to include interfaces,
>> events, and whatever else works across all packages. HTML should probably
>> be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
>> HTML+ActionScript can use that and then use CSS to do all their layouts;
>> HTML would not have a SWF version.
>>
>> Then Basic could be SWF & JS with layouts that are light on the JS side
>> using CSS and AS code to mimic them on the SWF side. Express would do what
>> it is doing now and compose components by extending the Basic set and
>> adding common beads.
>>
>> I've been hung up with the JS side having stuck on the display and
>> position values and deferring them might be the best solution.
>>
>> —peter
>>
>> On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
>> <carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>> wrote:
>>
>>> Hi Peter,
>>>
>>> it seems HTML rely for this task heavily on CSS to the point that almost
>>> nothing is done in html or js code.
>>> So maybe we are not in the right way for HTML platform and we should make
>>> our code be mainly CSS.
>>> An example is here:
>>>
>>> https://css-tricks.com/snippets/sass/placing-items-circle/
>>>
>>> Another point is SWF. I'm not focusing in that output and even I didn't
>>> compile to SWF for long time, so don't know how
>>> is looking, but for what I saw in other discussions seems that Flash
>>> needs
>>> to implement the old Flex architecture of
>>> updateDisplayList to manage refresh to avoid continuous redrawing of the
>>> screen.
>>>
>>> So my bet is that our AS3 layout components should do:
>>>
>>> 1.- In JS -> add className to "some-class-layout" (for example for
>>> circle,
>>> if we have circle-layout, we should have a "circleLayout" css class
>>> selector, that we could assign to out flexjs "list component"
>>>
>>> 2.- in SWF -> we should stick with the way this was done in Flex4 but
>>> implementing as a bead and with the "updateDisplayList" performance
>>>
>>> What do you think?
>>>
>>>
>>>
>>>
>>> 2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>>>
>>>> A lot of this work is mine and it seems to need to be thought through
>>>> once
>>>> again. The dichotomy of SWF & JS has presented problems for me in the
>>>> past.
>>>>
>>>> Maybe the layouts, for JS platform, should do as little as possible,
>>>> replying on CSS as much as possible. Then make the SWF platform mimic
>>>> that.
>>>>
>>>> One issue that comes up for me is that we automatically set display and
>>>> position for every element soon after its created. If you were to
>>>> hand-write the HTML you probably would not do that.
>>>>
>>>> So perhaps FlexJS should not set these styles at all and instead let
>>>> the
>>>> layout set them if the layout even needs to do that.
>>>>
>>>> Thoughts?
>>>> ‹peter
>>>>
>>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> We¹re really struggling with layout.
>>>>>
>>>>> Yishay just mentioned the fact that padding is not working, but the
>>>>> problems seem to go much deeper than that.
>>>>>
>>>>> 1. VerticalLayout has the following code:
>>>>> for (i = 0; i < n; i++)
>>>>> {
>>>>> var child:WrappedHTMLElement =
>>>> children[i];
>>>>> child.flexjs_wrapper.
>>>> setDisplayStyleForLayout('block');
>>>>> if (child.style.display ===
>>>> 'none')
>>>>> {
>>>>> child.flexjs_wrapper.
>>>> setDisplayStyleForLayout('block');
>>>>> }
>>>>> else
>>>>> {
>>>>> // block elements don't
>>>> measure width correctly so set to inline
>>>>> for a second
>>>>> child.style.display =
>>>> 'inline-block';
>>>>> maxWidth =
>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>>>> child.style.display =
>>>> 'block';
>>>>> }
>>>>> child.flexjs_wrapper.
>>>> dispatchEvent('sizeChanged');
>>>>> }
>>>>>
>>>>> There is a number of problems that I can see with this. Firstly, it¹s
>>>>> horribly inefficient:
>>>>> child.style.display =
>>>> 'inline-block';
>>>>> maxWidth =
>>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>>>> The above will force a browser redraw at every step of the loop. If
>>>> you
>>>>> have hundreds of children, there will be hundreds of redraws just to
>>>>> figure out the children width. If anything, there should probably be
>>>>> three loops: One to set the inline-blocks, The second to measure all
>>>> the
>>>>> children (the first measure would trigger a redraw, but subsequent
>>>> ones
>>>>> not) The third to set inline-block back.
>>>>>
>>>>> Secondly, there¹s only a need to measure the children if the container
>>>> is
>>>>> sized to content. If the container has a fixed width or a percentage
>>>>> width, I don¹t see why the children should be measured at all. The
>>>> only
>>>>> exception I can see is if there is overflow:auto.
>>>>>
>>>>> Thirdly, I don¹t understand how setting the child to inline-block
>>>> helps.
>>>>> What about the grandchildren? Don¹t those need to be measured too?
>>>>> Fourthly, Both Horizontal and VerticalLayout have code which
>>>> temporarily
>>>>> sets inline-block. BasicLayout does not, and I don¹t understand why
>>>>> there¹s a difference. (BasicLayout has the same re-rendering problem
>>>>> though.)
>>>>> 2.
>>>>> if (!hasWidth && n > 0 &&
>>>> !isNaN(maxWidth)) {
>>>>> var pl:String =
>>>> scv['padding-left'];
>>>>> var pr:String =
>>>> scv['padding-right'];
>>>>> var npl:int =
>>>> parseInt(pl.substring(0, pl.length - 2), 10);
>>>>> var npr:int =
>>>> parseInt(pr.substring(0, pr.length - 2), 10);
>>>>> maxWidth += npl + npr;
>>>>> contentView.width = maxWidth;
>>>>> }
>>>>>
>>>>> This seems totally wrong. Why is the padding being added when we¹re
>>>> using
>>>>> box-sizing: border-box?
>>>>>
>>>>> 3. Percentage size seems to be set based on the children rather than
>>>> the
>>>>> parents.
>>>>>
>>>>> 4. I¹m not sure I understand the layout lifecycle very well. We have
>>>> had
>>>>> cases where children did not seem to be layout, and forcing a layout
>>>>> seemed to be very difficult to do.
>>>>>
>>>>> Harbs
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Carlos Rovira
>>> Director General
>>> M: +34 607 22 60 05
>>> http://www.codeoscopic.com
>>> http://www.avant2.es
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>> información privilegiada o confidencial. Si ha recibido este mensaje por
>>> error, le rogamos que nos lo comunique inmediatamente por esta misma vía
>>> y
>>> proceda a su destrucción.
>>>
>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>> comunicamos
>>> que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>> servicio o información solicitados, teniendo usted derecho de acceso,
>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>>> nuestras
>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>> necesaria.
>>
>
Re: [FlexJS]Layout redux
Posted by Alex Harui <ah...@adobe.com>.
It is probably time for our annual "revisiting of the layout code". I
think if you look at source code history, Peter or I do this every so
often as we get more examples to work with.
From memory, there are issues like whether we have to set
position:relative or not that came out of the MDL swc. And when/if we
need to set the width on a parent for percentage width to work in the
children/grandchildren.
It is great to finally have some people actually paying attention that
know how this stuff is actually normally done in JS. Peter and I were
mostly guessing since, if you think about it, we were basically doing Flex
until we got into FlexJS and are not experienced in HTML/JS.
So, fundamentally, if you have to stack things vertically, should you use
display:block? If you have to line up a bunch of divs horizontally,
should you use display:inline-block?
Is there a better way to do BasicLayout? We ended up using a completely
handwritten set of code to essentially make everything use absolute
positioning.
Is border-box working as expected? Do you set the height/width to include
the padding or not?
I think some layouts can use CSS but others have to be written in code to
override default browser behavior. But I'd love to be wrong about that
(at least, without relying on latest browsers or polyfills).
And finally, are there ways we can call the layout fewer times than we
currently do?
For sure, we need to the the JS side right and then worry about the SWF
side. I think there are way fewer behavior issues on the SWF side to deal
with.
My 2 cents,
-Alex
On 2/21/17, 12:35 PM, "Peter Ent" <pe...@adobe.com> wrote:
>I think this is generally a good approach.
>
>I've been thinking that we have some refactoring to do which might help.
>For instance, Core should probably be edited to include interfaces,
>events, and whatever else works across all packages. HTML should probably
>be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
>HTML+ActionScript can use that and then use CSS to do all their layouts;
>HTML would not have a SWF version.
>
>Then Basic could be SWF & JS with layouts that are light on the JS side
>using CSS and AS code to mimic them on the SWF side. Express would do what
>it is doing now and compose components by extending the Basic set and
>adding common beads.
>
>I've been hung up with the JS side having stuck on the display and
>position values and deferring them might be the best solution.
>
>—peter
>
>On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
><carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com>
>wrote:
>
>>Hi Peter,
>>
>>it seems HTML rely for this task heavily on CSS to the point that almost
>>nothing is done in html or js code.
>>So maybe we are not in the right way for HTML platform and we should make
>>our code be mainly CSS.
>>An example is here:
>>
>>https://css-tricks.com/snippets/sass/placing-items-circle/
>>
>>Another point is SWF. I'm not focusing in that output and even I didn't
>>compile to SWF for long time, so don't know how
>>is looking, but for what I saw in other discussions seems that Flash
>>needs
>>to implement the old Flex architecture of
>>updateDisplayList to manage refresh to avoid continuous redrawing of the
>>screen.
>>
>>So my bet is that our AS3 layout components should do:
>>
>>1.- In JS -> add className to "some-class-layout" (for example for
>>circle,
>>if we have circle-layout, we should have a "circleLayout" css class
>>selector, that we could assign to out flexjs "list component"
>>
>>2.- in SWF -> we should stick with the way this was done in Flex4 but
>>implementing as a bead and with the "updateDisplayList" performance
>>
>>What do you think?
>>
>>
>>
>>
>>2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>>
>>> A lot of this work is mine and it seems to need to be thought through
>>>once
>>> again. The dichotomy of SWF & JS has presented problems for me in the
>>>past.
>>>
>>> Maybe the layouts, for JS platform, should do as little as possible,
>>> replying on CSS as much as possible. Then make the SWF platform mimic
>>>that.
>>>
>>> One issue that comes up for me is that we automatically set display and
>>> position for every element soon after its created. If you were to
>>> hand-write the HTML you probably would not do that.
>>>
>>> So perhaps FlexJS should not set these styles at all and instead let
>>>the
>>> layout set them if the layout even needs to do that.
>>>
>>> Thoughts?
>>> ‹peter
>>>
>>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> >We¹re really struggling with layout.
>>> >
>>> >Yishay just mentioned the fact that padding is not working, but the
>>> >problems seem to go much deeper than that.
>>> >
>>> >1. VerticalLayout has the following code:
>>> > for (i = 0; i < n; i++)
>>> > {
>>> > var child:WrappedHTMLElement =
>>> children[i];
>>> > child.flexjs_wrapper.
>>> setDisplayStyleForLayout('block');
>>> > if (child.style.display ===
>>>'none')
>>> > {
>>> > child.flexjs_wrapper.
>>> setDisplayStyleForLayout('block');
>>> > }
>>> > else
>>> > {
>>> > // block elements don't
>>> measure width correctly so set to inline
>>> >for a second
>>> > child.style.display =
>>> 'inline-block';
>>> > maxWidth =
>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>> > child.style.display =
>>> 'block';
>>> > }
>>> > child.flexjs_wrapper.
>>> dispatchEvent('sizeChanged');
>>> > }
>>> >
>>> >There is a number of problems that I can see with this. Firstly, it¹s
>>> >horribly inefficient:
>>> > child.style.display =
>>> 'inline-block';
>>> > maxWidth =
>>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>>> >The above will force a browser redraw at every step of the loop. If
>>>you
>>> >have hundreds of children, there will be hundreds of redraws just to
>>> >figure out the children width. If anything, there should probably be
>>> >three loops: One to set the inline-blocks, The second to measure all
>>>the
>>> >children (the first measure would trigger a redraw, but subsequent
>>>ones
>>> >not) The third to set inline-block back.
>>> >
>>> >Secondly, there¹s only a need to measure the children if the container
>>>is
>>> >sized to content. If the container has a fixed width or a percentage
>>> >width, I don¹t see why the children should be measured at all. The
>>>only
>>> >exception I can see is if there is overflow:auto.
>>> >
>>> >Thirdly, I don¹t understand how setting the child to inline-block
>>>helps.
>>> >What about the grandchildren? Don¹t those need to be measured too?
>>> >Fourthly, Both Horizontal and VerticalLayout have code which
>>>temporarily
>>> >sets inline-block. BasicLayout does not, and I don¹t understand why
>>> >there¹s a difference. (BasicLayout has the same re-rendering problem
>>> >though.)
>>> >2.
>>> > if (!hasWidth && n > 0 &&
>>> !isNaN(maxWidth)) {
>>> > var pl:String =
>>> scv['padding-left'];
>>> > var pr:String =
>>> scv['padding-right'];
>>> > var npl:int =
>>> parseInt(pl.substring(0, pl.length - 2), 10);
>>> > var npr:int =
>>> parseInt(pr.substring(0, pr.length - 2), 10);
>>> > maxWidth += npl + npr;
>>> > contentView.width = maxWidth;
>>> > }
>>> >
>>> >This seems totally wrong. Why is the padding being added when we¹re
>>>using
>>> >box-sizing: border-box?
>>> >
>>> >3. Percentage size seems to be set based on the children rather than
>>>the
>>> >parents.
>>> >
>>> >4. I¹m not sure I understand the layout lifecycle very well. We have
>>>had
>>> >cases where children did not seem to be layout, and forcing a layout
>>> >seemed to be very difficult to do.
>>> >
>>> >Harbs
>>>
>>>
>>
>>
>>--
>>
>>Carlos Rovira
>>Director General
>>M: +34 607 22 60 05
>>http://www.codeoscopic.com
>>http://www.avant2.es
>>
>>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>>información privilegiada o confidencial. Si ha recibido este mensaje por
>>error, le rogamos que nos lo comunique inmediatamente por esta misma vía
>>y
>>proceda a su destrucción.
>>
>>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>>comunicamos
>>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>>servicio o información solicitados, teniendo usted derecho de acceso,
>>rectificación, cancelación y oposición de sus datos dirigiéndose a
>>nuestras
>>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>>necesaria.
>
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
I think this is generally a good approach.
I've been thinking that we have some refactoring to do which might help.
For instance, Core should probably be edited to include interfaces,
events, and whatever else works across all packages. HTML should probably
be just the HTML classes (Div, H1, TextNode, etc) so anyone that wants
HTML+ActionScript can use that and then use CSS to do all their layouts;
HTML would not have a SWF version.
Then Basic could be SWF & JS with layouts that are light on the JS side
using CSS and AS code to mimic them on the SWF side. Express would do what
it is doing now and compose components by extending the Basic set and
adding common beads.
I've been hung up with the JS side having stuck on the display and
position values and deferring them might be the best solution.
—peter
On 2/21/17, 2:25 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:
>Hi Peter,
>
>it seems HTML rely for this task heavily on CSS to the point that almost
>nothing is done in html or js code.
>So maybe we are not in the right way for HTML platform and we should make
>our code be mainly CSS.
>An example is here:
>
>https://css-tricks.com/snippets/sass/placing-items-circle/
>
>Another point is SWF. I'm not focusing in that output and even I didn't
>compile to SWF for long time, so don't know how
>is looking, but for what I saw in other discussions seems that Flash needs
>to implement the old Flex architecture of
>updateDisplayList to manage refresh to avoid continuous redrawing of the
>screen.
>
>So my bet is that our AS3 layout components should do:
>
>1.- In JS -> add className to "some-class-layout" (for example for circle,
>if we have circle-layout, we should have a "circleLayout" css class
>selector, that we could assign to out flexjs "list component"
>
>2.- in SWF -> we should stick with the way this was done in Flex4 but
>implementing as a bead and with the "updateDisplayList" performance
>
>What do you think?
>
>
>
>
>2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
>
>> A lot of this work is mine and it seems to need to be thought through
>>once
>> again. The dichotomy of SWF & JS has presented problems for me in the
>>past.
>>
>> Maybe the layouts, for JS platform, should do as little as possible,
>> replying on CSS as much as possible. Then make the SWF platform mimic
>>that.
>>
>> One issue that comes up for me is that we automatically set display and
>> position for every element soon after its created. If you were to
>> hand-write the HTML you probably would not do that.
>>
>> So perhaps FlexJS should not set these styles at all and instead let the
>> layout set them if the layout even needs to do that.
>>
>> Thoughts?
>> ‹peter
>>
>> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> >We¹re really struggling with layout.
>> >
>> >Yishay just mentioned the fact that padding is not working, but the
>> >problems seem to go much deeper than that.
>> >
>> >1. VerticalLayout has the following code:
>> > for (i = 0; i < n; i++)
>> > {
>> > var child:WrappedHTMLElement =
>> children[i];
>> > child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> > if (child.style.display ===
>>'none')
>> > {
>> > child.flexjs_wrapper.
>> setDisplayStyleForLayout('block');
>> > }
>> > else
>> > {
>> > // block elements don't
>> measure width correctly so set to inline
>> >for a second
>> > child.style.display =
>> 'inline-block';
>> > maxWidth =
>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> > child.style.display =
>> 'block';
>> > }
>> > child.flexjs_wrapper.
>> dispatchEvent('sizeChanged');
>> > }
>> >
>> >There is a number of problems that I can see with this. Firstly, it¹s
>> >horribly inefficient:
>> > child.style.display =
>> 'inline-block';
>> > maxWidth =
>> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>> >The above will force a browser redraw at every step of the loop. If you
>> >have hundreds of children, there will be hundreds of redraws just to
>> >figure out the children width. If anything, there should probably be
>> >three loops: One to set the inline-blocks, The second to measure all
>>the
>> >children (the first measure would trigger a redraw, but subsequent ones
>> >not) The third to set inline-block back.
>> >
>> >Secondly, there¹s only a need to measure the children if the container
>>is
>> >sized to content. If the container has a fixed width or a percentage
>> >width, I don¹t see why the children should be measured at all. The only
>> >exception I can see is if there is overflow:auto.
>> >
>> >Thirdly, I don¹t understand how setting the child to inline-block
>>helps.
>> >What about the grandchildren? Don¹t those need to be measured too?
>> >Fourthly, Both Horizontal and VerticalLayout have code which
>>temporarily
>> >sets inline-block. BasicLayout does not, and I don¹t understand why
>> >there¹s a difference. (BasicLayout has the same re-rendering problem
>> >though.)
>> >2.
>> > if (!hasWidth && n > 0 &&
>> !isNaN(maxWidth)) {
>> > var pl:String =
>> scv['padding-left'];
>> > var pr:String =
>> scv['padding-right'];
>> > var npl:int =
>> parseInt(pl.substring(0, pl.length - 2), 10);
>> > var npr:int =
>> parseInt(pr.substring(0, pr.length - 2), 10);
>> > maxWidth += npl + npr;
>> > contentView.width = maxWidth;
>> > }
>> >
>> >This seems totally wrong. Why is the padding being added when we¹re
>>using
>> >box-sizing: border-box?
>> >
>> >3. Percentage size seems to be set based on the children rather than
>>the
>> >parents.
>> >
>> >4. I¹m not sure I understand the layout lifecycle very well. We have
>>had
>> >cases where children did not seem to be layout, and forcing a layout
>> >seemed to be very difficult to do.
>> >
>> >Harbs
>>
>>
>
>
>--
>
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>http://www.codeoscopic.com
>http://www.avant2.es
>
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>comunicamos
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>nuestras
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
>necesaria.
Re: [FlexJS]Layout redux
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Peter,
it seems HTML rely for this task heavily on CSS to the point that almost
nothing is done in html or js code.
So maybe we are not in the right way for HTML platform and we should make
our code be mainly CSS.
An example is here:
https://css-tricks.com/snippets/sass/placing-items-circle/
Another point is SWF. I'm not focusing in that output and even I didn't
compile to SWF for long time, so don't know how
is looking, but for what I saw in other discussions seems that Flash needs
to implement the old Flex architecture of
updateDisplayList to manage refresh to avoid continuous redrawing of the
screen.
So my bet is that our AS3 layout components should do:
1.- In JS -> add className to "some-class-layout" (for example for circle,
if we have circle-layout, we should have a "circleLayout" css class
selector, that we could assign to out flexjs "list component"
2.- in SWF -> we should stick with the way this was done in Flex4 but
implementing as a bead and with the "updateDisplayList" performance
What do you think?
2017-02-21 20:10 GMT+01:00 Peter Ent <pe...@adobe.com>:
> A lot of this work is mine and it seems to need to be thought through once
> again. The dichotomy of SWF & JS has presented problems for me in the past.
>
> Maybe the layouts, for JS platform, should do as little as possible,
> replying on CSS as much as possible. Then make the SWF platform mimic that.
>
> One issue that comes up for me is that we automatically set display and
> position for every element soon after its created. If you were to
> hand-write the HTML you probably would not do that.
>
> So perhaps FlexJS should not set these styles at all and instead let the
> layout set them if the layout even needs to do that.
>
> Thoughts?
> ‹peter
>
> On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>
> >We¹re really struggling with layout.
> >
> >Yishay just mentioned the fact that padding is not working, but the
> >problems seem to go much deeper than that.
> >
> >1. VerticalLayout has the following code:
> > for (i = 0; i < n; i++)
> > {
> > var child:WrappedHTMLElement =
> children[i];
> > child.flexjs_wrapper.
> setDisplayStyleForLayout('block');
> > if (child.style.display === 'none')
> > {
> > child.flexjs_wrapper.
> setDisplayStyleForLayout('block');
> > }
> > else
> > {
> > // block elements don't
> measure width correctly so set to inline
> >for a second
> > child.style.display =
> 'inline-block';
> > maxWidth =
> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> > child.style.display =
> 'block';
> > }
> > child.flexjs_wrapper.
> dispatchEvent('sizeChanged');
> > }
> >
> >There is a number of problems that I can see with this. Firstly, it¹s
> >horribly inefficient:
> > child.style.display =
> 'inline-block';
> > maxWidth =
> Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> >The above will force a browser redraw at every step of the loop. If you
> >have hundreds of children, there will be hundreds of redraws just to
> >figure out the children width. If anything, there should probably be
> >three loops: One to set the inline-blocks, The second to measure all the
> >children (the first measure would trigger a redraw, but subsequent ones
> >not) The third to set inline-block back.
> >
> >Secondly, there¹s only a need to measure the children if the container is
> >sized to content. If the container has a fixed width or a percentage
> >width, I don¹t see why the children should be measured at all. The only
> >exception I can see is if there is overflow:auto.
> >
> >Thirdly, I don¹t understand how setting the child to inline-block helps.
> >What about the grandchildren? Don¹t those need to be measured too?
> >Fourthly, Both Horizontal and VerticalLayout have code which temporarily
> >sets inline-block. BasicLayout does not, and I don¹t understand why
> >there¹s a difference. (BasicLayout has the same re-rendering problem
> >though.)
> >2.
> > if (!hasWidth && n > 0 &&
> !isNaN(maxWidth)) {
> > var pl:String =
> scv['padding-left'];
> > var pr:String =
> scv['padding-right'];
> > var npl:int =
> parseInt(pl.substring(0, pl.length - 2), 10);
> > var npr:int =
> parseInt(pr.substring(0, pr.length - 2), 10);
> > maxWidth += npl + npr;
> > contentView.width = maxWidth;
> > }
> >
> >This seems totally wrong. Why is the padding being added when we¹re using
> >box-sizing: border-box?
> >
> >3. Percentage size seems to be set based on the children rather than the
> >parents.
> >
> >4. I¹m not sure I understand the layout lifecycle very well. We have had
> >cases where children did not seem to be layout, and forcing a layout
> >seemed to be very difficult to do.
> >
> >Harbs
>
>
--
Carlos Rovira
Director General
M: +34 607 22 60 05
http://www.codeoscopic.com
http://www.avant2.es
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.
De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.
Re: [FlexJS]Layout redux
Posted by Peter Ent <pe...@adobe.com>.
A lot of this work is mine and it seems to need to be thought through once
again. The dichotomy of SWF & JS has presented problems for me in the past.
Maybe the layouts, for JS platform, should do as little as possible,
replying on CSS as much as possible. Then make the SWF platform mimic that.
One issue that comes up for me is that we automatically set display and
position for every element soon after its created. If you were to
hand-write the HTML you probably would not do that.
So perhaps FlexJS should not set these styles at all and instead let the
layout set them if the layout even needs to do that.
Thoughts?
‹peter
On 2/21/17, 1:42 PM, "Harbs" <ha...@gmail.com> wrote:
>We¹re really struggling with layout.
>
>Yishay just mentioned the fact that padding is not working, but the
>problems seem to go much deeper than that.
>
>1. VerticalLayout has the following code:
> for (i = 0; i < n; i++)
> {
> var child:WrappedHTMLElement = children[i];
> child.flexjs_wrapper.setDisplayStyleForLayout('block');
> if (child.style.display === 'none')
> {
> child.flexjs_wrapper.setDisplayStyleForLayout('block');
> }
> else
> {
> // block elements don't measure width correctly so set to inline
>for a second
> child.style.display = 'inline-block';
> maxWidth = Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
> child.style.display = 'block';
> }
> child.flexjs_wrapper.dispatchEvent('sizeChanged');
> }
>
>There is a number of problems that I can see with this. Firstly, it¹s
>horribly inefficient:
> child.style.display = 'inline-block';
> maxWidth = Math.max(maxWidth, child.offsetLeft + child.offsetWidth);
>The above will force a browser redraw at every step of the loop. If you
>have hundreds of children, there will be hundreds of redraws just to
>figure out the children width. If anything, there should probably be
>three loops: One to set the inline-blocks, The second to measure all the
>children (the first measure would trigger a redraw, but subsequent ones
>not) The third to set inline-block back.
>
>Secondly, there¹s only a need to measure the children if the container is
>sized to content. If the container has a fixed width or a percentage
>width, I don¹t see why the children should be measured at all. The only
>exception I can see is if there is overflow:auto.
>
>Thirdly, I don¹t understand how setting the child to inline-block helps.
>What about the grandchildren? Don¹t those need to be measured too?
>Fourthly, Both Horizontal and VerticalLayout have code which temporarily
>sets inline-block. BasicLayout does not, and I don¹t understand why
>there¹s a difference. (BasicLayout has the same re-rendering problem
>though.)
>2.
> if (!hasWidth && n > 0 && !isNaN(maxWidth)) {
> var pl:String = scv['padding-left'];
> var pr:String = scv['padding-right'];
> var npl:int = parseInt(pl.substring(0, pl.length - 2), 10);
> var npr:int = parseInt(pr.substring(0, pr.length - 2), 10);
> maxWidth += npl + npr;
> contentView.width = maxWidth;
> }
>
>This seems totally wrong. Why is the padding being added when we¹re using
>box-sizing: border-box?
>
>3. Percentage size seems to be set based on the children rather than the
>parents.
>
>4. I¹m not sure I understand the layout lifecycle very well. We have had
>cases where children did not seem to be layout, and forcing a layout
>seemed to be very difficult to do.
>
>Harbs
Re: [FlexJS]Layout redux
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Yishay just mentioned the fact that padding is not working
It not working for me either - see https://issues.apache.org/jira/browse/FLEX-35274
> This seems totally wrong. Why is the padding being added when we’re using box-sizing: border-box?
Also seems wrong to me.
> 3. Percentage size seems to be set based on the children rather than the parents.
It's also basically impossible to include percent and fixes sizes in a layout.
Thanks,
Justin