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.
