I love that idea of Metadata in class. +1 to that one :)

2018-05-17 22:39 GMT+02:00 Harbs <harbs.li...@gmail.com>:

> Snipping relevant pieces to make it more legible…
> >
> > I agree #1 and #2 are creating problems, but they are not bugs in the
> compiler.  I believe the compiler correctly prunes out any Type Selectors
> that are not used.  The compiler must carry over any class and id selectors
> since there is no way to determine if they are used or not (and it must
> bring in any ClassReferences in selectors).  If you have a strategy for a
> feature enhancement by which the compiler can know to prune more stuff, we
> should discuss that.  Just remember that any strategy must apply to
> user-supplied CSS in fx:Style blocks.  I implemented one such strategy
> already.  If you give a class selector a name that uses a fully qualified
> classname (with hyphens instead of dots, so 
> org_apache_royale_html_TextInput_SomeClass)
> then the compiler will prune that class selector if TextInput is not in the
> output.  IMO, the changes required here are in the framework to use that
> naming scheme on any class selectors used in the framework, and/or stop
> using class selectors in the framework.  We could create subclasses for
> just about every class selector currently in the defaults.css for our SWCs.
> >
> > Also note what I wrote in the wiki about "kinds" of CSS.  I believe that
> the framework code is not fully conforming to the recommended practices in
> that wiki article.  If it did, I think there would be far less extra CSS
> being added to the output. As Carlos mentioned, maybe we should work on a
> test case so we have specific code to talk about.
> Let me use a concrete example to illustrate what I mean: Try compiling the
> DateControlsExample. The example does not use ButtonBar in any manner,
> shape or form. Being so, ButtonBar and all related classes should not be
> included in the output. However, both the ButtonBar CSS and ButtonBar and
> associated classes are included in both debug and release code. I think
> this can only be classified as a bug and this is what we need to fix.
> I don’t understand why the compiler cannot build a list of used classes
> and drop any CSS references not used.
> >
> >    #3 has a few different ways it can be resolved. The way that Carlos
> and I both like is by using composite class names such as “basic Button”
> and using a selector .basic.Button{} which requires the element to have
> *both* class names applied.
> >
> >    The solution above requires that class selectors are used and not
> type selectors. (The same for other solutions which use fully qualified
> names).
> >
> > That is an appealing solution.  In fact, it might be worth adding a name
> like "basic" or "jewel" to the className list of TLCs so users can control
> styles for individual component sets, but that isn't quite PAYG.  It is
> making everyone pay the price for multiple component sets even if they only
> use one.  Also I'm trying to figure out how the compiler will know to prune
> out selectors that are not used.
> >
> > The Type Selectors in defaults.css for SWCs are using fully qualified
> names already.  When you specify the namespace in the defaults.css then
> just having:
> >
> >   @namespace foo
> >   Application {}
> >
> > really means that selector is foo.Application.  But if you have multiple
> namespaces open, then what would you write?  I'm not sure .basic.s|Button
> is allowed.  Needs more investigation.
> I’m not sure we’re talking the same language. The class selector for
> ImageButton will always be (in HTML css) .ImageButton. So if you have a
> basic ImageButton and a Jewel ImageButton, there will be CSS conflicts in
> the compiled HTML CSS.
> >
> > Sounds like you are saying we shouldn't support extending Type Selectors
> in Royale for non-HTML components.  I think we can approximate it well
> enough to do it.  I think customers will want it and expect it and it will
> be an attractive feature for Royale.  Royale is all about Types, and we
> should leverage it to help optimize the users output.  It is much easier to
> prune based on type selectors than class selectors.
> I’m not sure what you mean here. I definitely think we should support
> things like js|ImageButton{background:none}. The question is what that
> will ultimately output in the final css file.
> >    Some additional points:
> >    * Unless we can figure out a way for the compiler to know which
> typenames are *actually* used, to prevent css of superclasses from being
> imported (i.e. basic Button), other components cannot subclass it. (i.e.
> Jewel should not subclass basic Button to prevent basic Button CSS from
> being unnecessarily included.0
> >
> > Interesting question.  However, a "workaround" might be to make sure the
> Application developer can manually prune out unused ClassReferences.
> Often, optimization has to be left to the app dev.  There is no easy way
> for the framework and tool chain to really know.  And I think an app dev
> can prune class references by declaring the Type Selector in custom CSS and
> setting properties to null:
> >
> > Button { iBeadModel: null }
> >
> >    * We will need a lookup of “standard” prefixes for the compiler to
> use so it knows what typenames to use for different packages.
> >
> > I'm not understanding what you mean here.
> If the typenames are always fully qualified, then the compiler knows what
> CSS to output. If we want to go the prefix route (i.e. j|ImageButton would
> output .jewel.ImageButton), the compiler needs some way to know that the
> prefix for the Jewel namespace is “jewel”.
> While discussing this I actually came up with a new idea which I think
> would be better all-around:
> We could support metadata in classes for Typename and TypenamePrefix. That
> would allow each class to specify exactly what css classes the compiler
> should use when compiling the CSS for that class.
> For example:
>     [Typename(name="Button", prefix="basic")]
>     public class Button extends ButtonBase
> would tell the compiler that the selector for this class should look like:
> .basic.Button{
> }
>     [Typename(name="org_apache_royale_html_Button")]
>     public class Button extends ButtonBase
> would tell the compiler that the selector for this class should look like:
> .org_apache_royale_html_Button{
> }
> If there’s no meta-tag at all, the behavior would stay as it is today and
> you’d get:
> .ImageButton{
> }
> and
> Button{
> }
> This feels like the smallest change to the compiler and leaves the
> component sets to decide for themselves how to best handle possible
> conflicts.
> Thoughts?
> Harbs

Carlos Rovira

Reply via email to