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 <p...@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.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> > wrote: > > >Hi Peter, that sound very good :) > >thanks! > > > >2017-02-22 16:53 GMT+01:00 Peter Ent <p...@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.rov...@gmail.com on behalf of Carlos > >>Rovira" > >> <carlos.rov...@gmail.com on behalf of carlos.rov...@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 <p...@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" <harbs.li...@gmail.com> wrote: > >> >> > >> >> > > >> >> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <aha...@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" <p...@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.rov...@gmail.com on behalf of > Carlos > >> >> >>>Rovira" > >> >> >>> <carlos.rov...@gmail.com on behalf of > >>carlos.rov...@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 <p...@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" <harbs.li...@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.
