Hi Alex,
2018-05-17 19:36 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> Some comments inline.
>
> On 5/17/18, 4:53 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> OK. Let’s take a step back.
>
> Here’s what I think is the takeaway of the first part of the
> “refactor” discussion. It seems like there are real issues — some of which
> have been partially resolved by Carlos, and none really have to do
> specifically with a project refactor.
>
> There are multiple issues with CSS and component sets:
> 1. As it stands all CSS for all used component sets are imported into
> the final compiled CSS.
> 2. all classes mentioned in said CSS are imported as well.
> 3. The typenames of different component sets collide because they are
> not qualified.
> 4. typenames which match HTML element names are compiled as element
> selectors instead of class selectors.
>
> I think we all agree that #1 and #2 are bugs which need to be fixed in
> the compiler. The exact changes that are needed should be ironed out.
>
> 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.
Harbs, discover like me that this is not completely true. He saw how some
not used compoenents where in his CSS (maybe one was ButtonBar and the
other don't remember. This is in one of this thread.
> 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.
>
When we discussed this I thought and wrote some code like
.org_apache_royale_jewel_Button {}, but finaly this seems to me very
verbose and we will end with things like ".org_apache_royale_jewel_Alert
.org_apache_royale_jewel_Group .org_apache_royale_jewel_TitleBar {}" , that
doesn't seem to me the best way.
Regarding subclassing, I as well considered when we commented, but this
seems to me a very heavy solution to create a class definition (with all
that means) to solve a problem that should not requiere to do a subclass,
so I as well prefer not follow that path.
>
> 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.
>
>
definitely it will help me figure your previous email.
>
> #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.
>
>
>
> On the other hand, I do agree that folks should have a way of
> declaring styling for HTML element types as in normal css. This takes two
> forms.
>
> The first is css with a namespace of "https://na01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%
> 2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com%
> 7Cd269492fc0b8447b643f08d5bbecdb28%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621548320427521&sdata=DR6FgV9nHlc%
> 2B81Ougp52gH6t7t0IxGcI6QoBS7idDdM%3D&reserved=0 <https://na01.safelinks.
> protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%
> 2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com%
> 7Cd269492fc0b8447b643f08d5bbecdb28%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636621548320427521&sdata=DR6FgV9nHlc%
> 2B81Ougp52gH6t7t0IxGcI6QoBS7idDdM%3D&reserved=0>”. This is treated like
> normal css as I think it should. This allows folks to copy csss into their
> Royale apps and just have it “work”.
> The second is the components in the HTML package. All these elements
> have types (i.e. button, input, h1, etc.) but not typenames. As it stands,
> they will be styled correctly using type selectors as they have no default
> class names.
>
> So, type selectors should work for HTML components as well as an
> “dynamic” HTML created by “whatever”. The type selectors will probably
> usually be overridden by “regular” Royale components because these will
> usually have styling applied by either class names or inline 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.
>
> 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.
>
> Harbs
>
> > On May 17, 2018, at 12:26 AM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >
> > Changing the subject line...
> >
> > What is the failure case? I think I've gotten lost somewhere.
> >
> > IMO, the goal is to approximate Type Selectors (effectively extend
> Type Selectors to other types not specified by W3C), and AIUI, order of
> class selectors is about specificity and order of appearance in the CSS
> file. So one possible improvement to the current situation is to make the
> compiler output the class selectors that are supposed to approximate class
> selectors first in the final css file so all later class selectors override
> it. IOW, do a better job at making our class selectors that are supposed
> to act like type selectors be overridden just like a type selector would.
> >
> > Thoughts?
> > -Alex
> >
> > On 5/16/18, 12:52 PM, "Harbs" <harbs.li...@gmail.com> wrote:
> >
> > I guess it depends.
> >
> > As long as the styling is set by class selectors, it will work
> because class selectors trump type selectors.
> >
> > I think it would at least be better than what we have now.
> >
> >> On May 16, 2018, at 10:42 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >>
> >> Would that work? I think any TLC with an HTMLButtonElement as its
> element (or sub-element) will still be affected by any Button type selector
> in some CSS file. Or maybe I don't fully understand what you are proposing.
> >>
> >> -Alex
> >>
> >> On 5/16/18, 9:41 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>
> >> Sure. I wonder if we should handle different namespaces
> differently.
> >>
> >> Maybe the following two namespaces should get proper type
> selectors, while any others would get class selectors?
> >>
> >> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.w3.org%2F1999%2Fxhtml&data=02%7C01%7Caharui%40adobe.com%
> 7C9b1582ba79124743cf6f08d5bb4be38b%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636620856972038920&sdata=l94LsFAHe4i1NHoCalhlCKlF5L8yvp
> brlh5qgmVhyGE%3D&reserved=0
> >> library://ns.apache.org/royale/html <library://ns.apache.org/
> royale/html>
> >>
> >> Harbs
> >>
> >>> On May 15, 2018, at 6:52 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >>>
> >>> The goal of typenames is to do the best job we can of emulating
> Type Selectors. I understand it isn't perfect, but the browser does have
> Type Selectors and we can't really stop people from expecting Type
> Selectors to work, and wishing it would work on the rest of Royale.
> >>>
> >>> On 5/15/18, 8:37 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>
> >>> Makes sense, but there’s two problems with that:
> >>>
> >>> 1. That makes the assumption that components of a specific name
> implement the HTML component of the same name.
> >>> 2. Classes take precedence over element selectors, so that
> styling is too easily overridden.
> >>>
> >>>
> >>>> On May 15, 2018, at 6:11 PM, Alex Harui <aha...@adobe.com.INVALID>
> wrote:
> >>>>
> >>>> Certain typenames match up against HTMLElement names and are thus
> valid Type selectors so are not transformed into Class Selectors.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 5/15/18, 2:09 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >>>>
> >>>> Interesting. It looks to me like a bug.
> >>>>
> >>>> The theme CSS compiles into this:
> >>>> Button {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #f8f8f8;
> >>>> margin: 0px;
> >>>> border-radius: 2px;
> >>>> }
> >>>> Button:hover {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #e8e8e8;
> >>>> }
> >>>> Button:active {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #d8d8d8;
> >>>> }
> >>>>
> >>>> Instead of this:
> >>>>
> >>>> .Button {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #f8f8f8;
> >>>> margin: 0px;
> >>>> border-radius: 2px;
> >>>> }
> >>>> .Button:hover {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #e8e8e8;
> >>>> }
> >>>> .Button:active {
> >>>> border: 1px solid #808080;
> >>>> padding: 4px;
> >>>> background-color: #d8d8d8;
> >>>> }
> >>>>
> >>>> Button is an element name (case insensitive) instead of a class
> name…
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On May 15, 2018, at 11:52 AM, Harbs <harbs.li...@gmail.com>
> wrote:
> >>>>>
> >>>>> I just tried an experiment of giving an MDL Button a classname
> of “Button” in addition to all the MDL classes. Interestingly, the mdl
> class names overrode the Button one. I’m really not sure why because the
> Button css should have been loaded later than MDL. I’d appreciate your
> thoughts if you have any on that.
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
