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.

>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
>> manage.
>> This should eliminate the need for other component sets to try to
>> 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
>> 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
>> 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
>> 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

Reply via email to