Hi, just to add something more here. I already mentioned the problems of div relative positioning in other threads. I as well think that having the basic set with predefined styles is not PAYG, and we get a bloated html full of tags with style attributes (div, span...).
The problem Alex comment in the other thread was that percentages was not playing well. That's a problem, but maybe one option would be to remove all styles tags in createElement (or other AS code) and move to CSS. In this way you can exclude in your project and remove the rules from the basic set. That's what I do with MDL. In MDL we don't need any style tag and percents works ok. But if I use some HTML.swc comps I get the styles bloating my html and I don't want that. So for that reason I think we should refactor styles to CSS. As well this is a basic separation of concerns and we should avoid that always as a golden rule. In resume, we should get rid of all "styles" set in code that translates to output html tags in order to be able to be easy to exclude if you don't want, or don't like and want another. Another problem is that sometimes we get div inside div (or other tags) that we don't need. I already don't know how to get rid of this. I think is VIEW comps what make that magic, but I'd need some example to see how it works (for example my problems with List that I need to solve). 2016-11-27 16:12 GMT+01:00 Harbs <harbs.li...@gmail.com>: > I’m not blaming the concepts. I’m just stating that as it stands, layout > is really hard. > > Part of the problem I was able to see was due to the fact that there were > nested divs with alternating absolute and relative positioning. This killed > all padding settings to the sub-objects. Basically the default layout was > preventing natural browser positioning. (anti-PAYG) ;-) > > Maybe the solution is to write another layout, but I have a feeling that > simplifying the layout might help even more. > > Yishay and I will try to put together some test cases to help show the > problems and possibly help find the correct solution... > > On Nov 27, 2016, at 5:06 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > On 11/27/16, 3:31 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > >> FlexJS makes it way too hard to solve simple layout challenges. > > > > I don't know if it is fair to blame the patterns and principles of FlexJS > > for that, but it certainly is possible that the Layout you need hasn't > > been written yet. > > > > Keep in mind that regular Flex VerticalLayout visited every child twice > > and used %width in a non-CSS-compliant way. So under PAYG, the default > > FlexJS VerticalLayout is going to leverage what the browser will do and > > work differently. > > > > But that means these lighter weight layouts will leverage CSS and > > StackOverflow is full of folks wrestling with CSS to get what they want. > > If FlexJS has other, slower layouts that solve these common problems, > that > > will be an advantage for us. > > > > The way I suggest folks deal with layout right now (given that the layout > > you want may not exist yet), is to just use an HTML editor to layout some > > widgets in the way you want. All FlexJS is trying to do is identify and > > encapsulate existing HTML and JS patterns and present them as components. > > So figure out what the HTML needs to look like and that will determine if > > an existing layout can do it, or if you need to write a new one. Don't > > forget that in FlexJS, there is both CSS margin and padding: regular > Flex > > only supported padding and a non-CSS compliant "gap". > > > > Thanks, > > -Alex > > > > -- 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.
