Here's an idea: Let's say MXML and the Royale Framework in general, generated a simple DOM based on the component types. In other words, an MXML file translates into the DOM structure: div, span, button, input, etc.
Royale also provides the event glue so that you can connect events sent from components to handlers. Further, attributes on MXML elements are either data properties (eg, minimum="15") or styles (eg, width="40%"). The styles are present for convenience only and are translated into style="width:50%" on the HTML elements. Or perhaps better, Royale application writers who want to include in-line styles use js:Style tags that build up the HTML style attribute. There are no layouts. Instead, you have specialized containers: VerticalContainer, HorizontalContainer, AbsoluteContainer, and so forth. These containers know how to augment their children to achieve the look they want. For example, VerticalContainer loops through the children and adds to their className, "verticalContainerChild" style. The code does not actually assign display:block nor query size nor set position or anything like that. The container could even append "top", "middle", and "bottom" styles to further refine how the application could look. Royale comes with a set of pre-defined styles to make these containers work. To address Harbs concerns about performance, the Royale framework makes minimal DOM structures, adding in-line styles where the user really wants to do that. In addition, for those times where performance is key, Harbs mentioned that position:absolute can be used to programmatically place the children. In this case, a container like AbsoluteVerticalContainer would do just that. This way we get to have clean HTML DOM (shadowed, as Harbs says, with our own internal structure and .royale-wrapper links (per element), We leave layout to CSS (eg, VerticalContainer + verticalContainerChild) or JavaScript via absolute positioning containers. Now one more refinement: just have Container and move the layout algorithms in those specialized Containers into beads. If we do this, then I think what I've described is pretty much what Royale is today. I feel that some of what is in the layout code is an artifact of making the code work on the Flash Player. And if not directly via shared ActionScript code, then in philosophy. When writing a layout, its easy to get your head in the space of writing for the Player and then you look at all the code and try to envision it working in the browser. In reality, sometimes the browser code should either be nothing or just assignment of styles. Royale should allow person A to make as much use of the browser/CSS as they want while still allowing person B to have as much programmatic control of element position and size as they want. I think beads allow for this and if not, we should work on making that possible. My two cents ‹peter On 3/27/18, 5:24 AM, "Harbs" <harbs.li...@gmail.com> wrote: >Interesting to further note: > >The first time the content is fit, the parent object gets its size >hard-coded. That knocks subsequent down to about a third of the time. > >> On Mar 27, 2018, at 1:22 AM, Harbs <harbs.li...@gmail.com> wrote: >> >> Case in point: >> >> In my app, I¹m using OneFlexibleChildHorizontalLayout which uses >>flexbox. Great. No need for writing values. Right? >> >> Not so fast. >> >> I have fit to view functionality in my app which needs to get the size >>of the flexibleChild which is the container to figure out how much to >>scale the content. The entire fit function takes 36 ms to run. The >>height getter on the flexibleChild *alone* takes 14 ms. If the size of >>the flexibleChild was hard-coded, the getter would not take measurable >>time. >> >> I have tons of hard coded size and positioning of SVG in my app >>(literally hundreds of DOM objects) and it runs ridiculously fast >>compared to all the Recalculate Styles which are caused by default >>browser layout. >> >> I¹d really love to get some hard numbers from comparing the approaches. >> >> Harbs >> >>> On Mar 26, 2018, at 11:28 PM, Harbs <harbs.li...@gmail.com >>><mailto:harbs.li...@gmail.com>> wrote: >>> >>> With hard-coded values DOM interaction could be kept to a minimum. It >>>would be an interesting experiment to see what would happen if we >>>*don¹t* rely on browser layout and hard code everything. >> >
