royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: [DISCUSS] Explanation of the changes
Date Tue, 15 May 2018 11:26:00 GMT
This makes sense. I liked the way you used style composition in Jewel to piece together functionality.
It’s very elegant.

The only thing I would comment is that we can still use prefixing to prevent conflicts: "jewel
jewel-Button primary" or “jewel jewel-Button emphasized”.

It seems to me like your comments bring to light a third option along the lines of what I
was saying:

Instead of:
/*some styling*/
We could have:
/*some styling*/
/*some styling*/

And the basic typenames could be: “basic FooComponent”. Jewel typename would be “jewel
FooComponent”, etc.  I think this would work as long as all compiled css always uses combined
class selectors using prefixes.

I don’t see a downside to this idea. It seems like it should allow for separation of component
sets while offering even more flexibility. There’s no reason why someone (on the application
level) could not decide to set styling across *all* component sets by then using
*/some more styling*/



> On May 15, 2018, at 1:38 PM, Carlos Rovira <> wrote:
>> Point #2 starts down the path of possible solutions.
>> The two relatively simple (I think) solutions I see (which have been
>> touched on already) are:
>> 1. Fully qualifying the typenames (i.e. "org-apache-royale-html-Button"
>> instead of “Button”.) It seems like org.apache.royale.html.Button can work
>> too, but the period needs to be escaped in the css file (i.e.
>> org\.apache\.royale\.html\.Button)
>> 2. Prefixing the typenames (i.e. basic-Button instead of Button).
> I choose "jewel button" since is the same "Semantic" do instead
> "jewel-button". The reason is that seems more flexible when you are nesting
> things. So making things like "jewel" we can change all jewel things and
> the by component we do (ie. for Button) : "jewel button primary" or "jewel
> button emphasized"...and so on...
>> I like solution 2 better because having such long classnames is “ugly”,
>> but solution 2 would require some kind of lookup for the compiler to know
>> the correct prefix to use.
> Right, is the one I choose (just with the difference of the "-" to be more
> flexible)
>> Thoughts? Are there reasons I’m missing why these solutions will not work?
> Perfectly, I think for example you want to join j|Button with "jewel
> button" to get all in "jewel button" right?
> I think the benefit from this will be the possibility to remove css if the
> concrete component is not present.
> So good.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message