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>
> 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