Hi Alex,

I think I need some example code to understand what you try to explain
here. I don't get to follow your explanation. Can you post some sample code
to explain it better?
thanks!

2018-05-16 23:43 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:

> Typo in there:
>
> "...make the compiler output the class selectors that are supposed to
> approximate type selectors..."
>
> Sorry,
> -Alex
>
> On 5/16/18, 2:26 PM, "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

Reply via email to