I think is important that we reach the most simple and cross browser way to
get things work. At least Royale should be able to make all most used
layouts
only declaring containers and layouts in its simplest forms. Then people
that want to make some not conventional things could need to make some
calculations, bindings and settings. Back in flex days, I remember to watch
code with calculations and bindings, I always think that 95% of times that
was not needed and only makes your code complex, less performant and
difficult to debug.
This is an important target for us
Let's see if we can get something cool here
2018-06-11 10:29 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> FWIW, I’ve found that the single-most painful part of developing using
> Royale has been layouts.
>
> I *think* defaulting to relative might help some issues, but things like
> percentages simply don’t work as you’d expect in HTML. I have been forced
> to stick calc() css in at least 12 places in my app.
>
> > On Jun 11, 2018, at 11:00 AM, Carlos Rovira <carlosrov...@apache.org>
> wrote:
> >
> > Hi,
> >
> > I'm finding some problems with all this in Jewel as I go deeper with
> > layouts. I'll write about it soon, I hope to solve some issue and left
> most
> > important to discuss.
> > As I get something working, I see a collateral effect that makes other
> > thing that was working fail on some way...it's like a puzzle where
> > positioning, layout, states must adjust to work ok. And still I'm getting
> > hard time with ClassSelectorList. I think we have an huge issue with
> class
> > name handling through Royale, since is not consistent, and class names
> are
> > essential in html. For example since layouts class names are some kind of
> > "typenames", those are removed when a user adds some class...
> >
> > This is a sneak peak of what I'm finding, and hope to work more over it
> and
> > try to raise only essential issues
> >
> >
> >
> > 2018-06-11 9:36 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> >
> >> We could always have a bead which sets:
> >>
> >> .foo *{
> >> position: static;
> >> }
> >> To reset the defaults of all elements below “foo” to static.
> >>
> >> Of course to change it to something else, you’d need:
> >> .foo .baz{
> >> position: absolute;
> >> }
> >>
> >> I’m not sure how well this would work with the Jewel layout beads. I’m
> not
> >> sure what the specificity is on that.
> >>
> >> Harbs
> >>
> >>> On Jun 11, 2018, at 10:11 AM, Alex Harui <aha...@adobe.com.INVALID>
> >> wrote:
> >>>
> >>> The emulation Application is based on Container and thus creates a Div.
> >> It may not stay that way, but we did it so that the SystemManager can
> >> parent the app like it does in Flex.
> >>>
> >>> Feel free to commit the bead. It won't hurt anything and some folks
> >> will be able to use it. I'm still wondering what the right answer is
> going
> >> to be for the emulation component sets. Or what to do if someone does
> have
> >> some part of the DOM that they do not want style.position set. There
> is no
> >> CSS way to specify "set style on all parents", AFAIK, which is would
> help
> >> reduce side-effects.
> >>>
> >>> Later,
> >>> -Alex
> >>>
> >>> On 6/8/18, 9:02 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>
> >>>> Interesting idea, but I thought there was concern about the global
> >> selector affecting HTML around the app?
> >>>
> >>> Currently, we don’t have an Application class that attaches to
> >> regular divs It always controls the body element. Since we control the
> >> whole page, it’s not a problem. If we do get to the point where a Royale
> >> app can be injected into a random div, then setting a global selector
> might
> >> be a problem if there’s other HTML which relies on static. We can have
> >> heavier-duty beads to deal with setting relative positioning in those
> cases.
> >>>
> >>> Harbs
> >>>
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
