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.
