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. 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.
#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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636620856972038920&sdata=l94LsFAHe4i1NHoCalhlCKlF5L8yvpbrlh5qgmVhyGE%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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
