> 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. >> >
