flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [FlexJS]Layout redux
Date Wed, 22 Feb 2017 17:03:23 GMT
Hi Peter, that sound very good :)
thanks!

2017-02-22 16:53 GMT+01:00 Peter Ent <pent@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.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlos.rovira@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 <pent@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.lists@gmail.com> wrote:
> >>
> >> >
> >> >> On Feb 22, 2017, at 9:46 AM, Alex Harui <aharui@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" <pent@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.rovira@gmail.com on behalf of Carlos
> >> >>>Rovira"
> >> >>> <carlos.rovira@gmail.com on behalf of carlos.rovira@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 <pent@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.lists@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message