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.

Reply via email to