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.
#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).
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 "http://www.w3.org/1999/xhtml
<http://www.w3.org/1999/xhtml>”. 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.
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
* We will need a lookup of “standard” prefixes for the compiler to use so it
knows what typenames to use for different packages.
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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
