Your point of view is valid, but it might depend on the kind of
application.  Some might have 100's of views to port, others might only
have 2 or 3 views and a million lines of business logic.

In another thread I mentioned the -api-report option I added.  It would be
interesting for folks to try getting API reports on their Flex apps so we
can see what folks are using so we can use that in making decisions.

My 2 cents,
-Alex

On 2/22/18, 8:39 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:

>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
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C16c51d3899b54f56d1fb08d5
>7a12f462%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549144184428545&s
>data=9atjDHHuhnuufVBQPZuUzM8vf30vf9Q0CP81XX8bXkg%3D&reserved=0

Reply via email to