Without know nothing about the solution I want to share a though: I think
the implementation of all the things related to visuals (and css is one of
them) is completely different in Royale to what it was in flex, so maybe we
should not be worried that CSS is not following main flex rules.
For me UX in royale must be done from scratch, if someone is migrating, we
can only provide some basic *structure* similar to what Flex was. But
that's only some kind of guide and could mean around 5-10% of what they
must to migrate. So this is the opposite to things more related to
"business" (like the ArrayCollection disscussion we made some days ago), in
this case, there's very few to save from a flex codebase point of view, and
CSS is one of the things I don't expect to reuse if I come from flex
codebase.



2018-02-22 17:27 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:

> Well, it might be a migration issue in the sense that you could use a
> selector called "global" in Flex and it would become the default value for
> styles.
>
> Flex and Royale CSS has non-compliant CSS in it like "cffHinting" or
> "focusSkin" in Flex or "IStatesImpl" in Royale.  Non-compliant styles are
> not emitted to the final .css file since the browser has no use for them,
> but are kept in a data structure used by ValuesManager.  If you use
> "global" for non-compliant style properties, it will work in Royale like
> it did in Flex, but if you use "global" to try to set the fontFamily to
> Gothic everywhere in your app it will not work in Royale as it did in Flex.
>
> Until this change we renamed "global" in the final CSS to "*" so it would
> have a more global effect, but I took that out because I'm not sure that
> "*" is the equivalent since "*" actually has precedence over Type
> Selectors.  I'm not quite sure how to create the true equivalent of Flex
> global styles.
>
> We could rename what I'm currently calling "global" in Royale to something
> else like "royale" and go back to renaming "global" to "*", but I think
> that will end up with complaints.  I think it might be right for the
> migration docs to mention this and offer alternatives like moving some
> styles from global to "*" if they understand the impact of doing so.
> Also, everything is currently a child of the Application so setting
> Application styles should have a global effect, but I think both will
> still override type selectors.
>
> My 2 cents,
> -Alex
>
> On 2/22/18, 7:44 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
> >Hi Andrew, this is new for Apache Royale since is how to deal with CSS and
> >how browsers manage it.
> >So maybe not much relation with Flex in this case
> >
> >Best
> >
> >Carlos
> >
> >
> >
> >2018-02-22 13:27 GMT+01:00 Andrew Wetmore <cottag...@gmail.com>:
> >
> >> Is this a migration issue for Flex apps, or is this specific to Royale?
> >>
> >> On Thu, Feb 22, 2018 at 5:29 AM, Alex Harui <aha...@adobe.com.invalid>
> >> wrote:
> >>
> >> >
> >> >
> >> > On 2/22/18, 1:12 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> Rovira"
> >> > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
> >> >
> >> > >Hi Alex,
> >> > >
> >> > >I think this is a very good change since I had many problems with MDL
> >> and
> >> > >have to use the exclusion on CSS to make it work properly.
> >> > >
> >> > >If I understand ok, I should see fonts at 16px, that I think is
> >>nowadays
> >> > >the standard for "normal" text, so good.
> >> > >
> >> > >What I don't understand is what basic should making any change. From
> >>my
> >> > >point of view basic is as the name says...basic, and I don't like to
> >> make
> >> > >fonts 12px.
> >> > >I only expect in basic to see the wiring of beads like views, models
> >>and
> >> > >controllers. But I think almost no CSS rules should be there, hence
> >>the
> >> > >basic point at the lowest level, where users only have the basics of
> >> what
> >> > >royale provides without any customization.
> >> > >
> >> > >That's how I see it
> >> >
> >> > I think I agree.  That's sort of where I was heading by creating a
> >> > separate theme in basic.css.  Basic.css is separate from the
> >>defaults.css
> >> > in Basic.swc.  Maybe we should give basic.css a different name.  The
> >>goal
> >> > of basic.css was to give our examples and anybody else building the
> >> > smallest app on Basic a more Flex-like look.  I just don't think Serif
> >> > 16px looks good.  It is true that more traditional CSS visual styles
> >>can
> >> > be moved from the Basic defaults.css to whatever we call basic.css.
> >> > Someone else can do that work once we see how this change affects
> >>Vivid
> >> > and other themes like MDL.  I'm not sure if every component set should
> >> > have a separate theme file or SWC as well.  Or if there are a few
> >>visual
> >> > styles in that should remain in Basic's defaults.css so that other
> >> > component sets don't have to repeat that information.
> >> >
> >> > -Alex
> >> > >
> >> > >
> >> > >2018-02-22 2:43 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> Royale has been using the universal selector for a while now to set
> >> > >> defaults for Royale apps.  However, that caused problems with other
> >> > >> third-party CSS.
> >> > >>
> >> > >> I just pushed changes to the compiler and framework so that we
> >>don't
> >> use
> >> > >> the * selector.  Instead we will be using the * selector properly
> >>if
> >> > >> provided by the users CSS and we are using a special selector
> >>called
> >> > >> "global" as the "browser defaults" and the final selector in the
> >> lookup
> >> > >>we
> >> > >> manage.
> >> > >>
> >> > >> This should eliminate the need for other component sets to try to
> >> > >>exclude
> >> > >> the defaults.css from Basic.
> >> > >>
> >> > >> You may find that text that once looked nice now is 16px Serif.
> >> That's
> >> > >> because we are no longer using inheritance to set the font-family
> >>on
> >> all
> >> > >> components.  The browsers do not seem to deploy a default
> >>font-family
> >> so
> >> > >> the SWF side shouldn't either.  IOW, if you just put some plain
> >>text
> >> in
> >> > >>an
> >> > >> HTML file it shows up as 16px Serif.  If you see 16px Serif, let us
> >> know
> >> > >> which component is showing that by default.
> >> > >>
> >> > >> However, we don't really want to make 16px Serif the default font
> >>in
> >> our
> >> > >> examples, so I created a CSS-based theme in themes/Basic/basic.css
> >>and
> >> > >>put
> >> > >> 12px Sans-Serif as the default for a bunch of type selectors since
> >> that
> >> > >> was what our examples were using.  I did not create a default font
> >>for
> >> > >> Application as that would become the default for other component
> >>sets
> >> > >> mixed into a Royale app unless otherwise specified.  Component sets
> >> with
> >> > >> different looks can use a different theme and get different
> >>defaults.
> >> > >>
> >> > >> So, in sum, without any theme, we want the SWF side to look like
> >>the
> >> > >> browser and have 16px Serif.  But the royale-config.xml will
> >>specify
> >> > >> themes/Basic/basic.css as the default theme giving the examples and
> >> most
> >> > >> people's unstyled apps a more Flex-like look by using sans-serif.
> >> More
> >> > >> type selectors may need to be added to themes/Basic/basic.css in
> >>order
> >> > >>to
> >> > >> get sans serif everywhere by default without putting font-family on
> >> > >> Application.  That way, when you switch to another theme, like the
> >> Vivid
> >> > >> that Carlos is working on, there should be fewer, if any, default
> >> values
> >> > >> that screw up the other theme.
> >> > >>
> >> > >> Thanks,
> >> > >> -Alex
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > >--
> >> > >Carlos Rovira
> >> > >https://na01.safelinks.protection.outlook.com/?url=
> >> > http%3A%2F%2Fabout.me%2
> >> > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> > 7C5807444789504e2f3d8c08d5
> >> > >79d46f81%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> > 7C636548875665083262&s
> >> > >data=MjSAbOXuFPTLeafKWOYuDDbc8oMn4YbsZ6pzwxYA6pg%3D&reserved=0
> >> >
> >> >
> >>
> >>
> >> --
> >> Andrew Wetmore
> >>
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fcottage14
> >>.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7Cc2d5d47c21084996345c
> >>08d57a0b4647%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636549111204032
> >>767&sdata=5DOBst1ytHpKOuKlMicXtNr8AfJuWiEbXpk%2BmvUspLw%3D&reserved=0
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Cc2d5d47c21084996345c08d5
> >7a0b4647%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636549111204032767&s
> >data=y64W72CO7WgyBNYCVAKpczGJaisl3vwuCu00%2FWx1sVA%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to