Excellent! I think we’re finally on the same page. :-) We agree that j|Button would theoretically be better, but we are unsure whether we can practically achieve that goal in a manner that would be acceptable. It might be that the current solution is the best we can do with all things considered, but two heads (or more) are always better than one. Let’s try to discuss this and see if we can come up with another solution.
You bring up two good points: 1. This does not seem to work for integrated JS frameworks. (i.e. MDL) 2. It could be verbose. (And I definitely agree that only CSS actually used should be compiled.) Point #1 seems to have a couple of considerations: a) Can MDL components have visual CSS applied to them? b) Assuming it can’t, should that dictate how other component sets work? I *think* the answer to a is “sort of”. The container element of MDL can certainly have CSS. If an MDL Button has a “proper” typename, CSS can be applied. How effective it will be depends on the specific style and whether it’s overridden by the MDL CSS. More complex components which have nested elements make that answer more convoluted. However, assuming that the CSS makes sense. I don’t see why it would not work in theory. 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. Regarding b, I think “native” components should support as many native features as possible, so I don’t think an MDL component set should dictate how other component sets work. 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 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. Thoughts? Are there reasons I’m missing why these solutions will not work? Thanks, Harbs > On May 15, 2018, at 8:34 AM, Carlos Rovira <[email protected]> wrote: > > Hi Harbs, > > 2018-05-14 23:37 GMT+02:00 Harbs <[email protected] > <mailto:[email protected]>>: > >> So, we are saying the same thing. >> >> This will not work: >> j|Button >> { >> border: 5px solid black; >> } >> >> But this will: >> .jewel.button >> { >> border: 5px solid black; >> } >> >> That’s what I meant when I said the user must know the default classnames >> that Jewel uses. >> >> I consider this to be a problem. (Not a catastrophic one, but one I’d like >> to avoid if possible.) >> >> One of the features of Royale is that qualified CSS can be used to >> describe application defaults for types. This applies to beads as well as >> styling. With the Jewel (and MDL) architecture, beads are described using >> namespaced classes, while HTML css is described using whatever (different) >> classnames are defined. One of the features of namespaced classes in CSS is >> that it’s checked by the compiler and tooling can take advantage of that. >> By using custom class names, we lose that. >> >> I understand why this compromise was reached, but can we agree that it’s a >> compromise and not the ideal way to solve the problem? If we could make >> j|Button{} work, wouldn’t that be better? >> >> > Right, but take two considerations: > > a) UI sets like MDL (BootStrap, Semantic,...) will never could be done in > that way, since you must to follow the way that external library works. Or > in other words you must to adapt to the given css unless you want to rework > the external CSS (s). > > b) Depending on solution, that could be very verbose, so that should be > considered. > > on the other hand that would be good solution to avoid styles reach final > App if the user doesn't use a concrete component, then the compiler should > not bring it to the final CSS from the theme CSS > > Carlos > > > > >> Thanks, >> Harbs >> >>> On May 14, 2018, at 7:25 PM, Carlos Rovira <[email protected] >>> <mailto:[email protected]>> >> wrote: >>> >>> I'll give you working examples that I tried for this so you can test >>> yourself if you want: >>> >>> To affect all buttons with *html css*, you do this (for example in main >>> App.mxml file (you can try this in JewelExample): >>> >>> <fx:Style> >>> @namespace j "library://ns.apache.org/royale/jewel >>> <library://ns.apache.org/royale/jewel> <library:// >> ns.apache.org/royale/jewel <http://ns.apache.org/royale/jewel>>"; >>> >>> .jewel.button >>> { >>> border: 5px solid black; >>> } >>> </fx:Style> >>> >>> >>> <j:Button text="hi!"/> >>> >>> you'll see all buttons with a black border of 5 pixels. overriding the >>> normal Jewel Button border. >>> >>> Instead if you want to change something at "bead level" you must use the >>> component name. For example: >>> >>> j|TitleBar { >>> IBeadLayout: ClassReference( >>> "org.apache.royale.jewel.beads.layouts.VerticalLayout"); >>> } >>> >>> will make *Alert* display things in tittle vertical instead of >> horizontal. >>> (notice that to see the effect you need to add something more to >>> AlertTitleBarBiew like this: >>> >>> <j:Label text="hi"/> >>> >>> Since by default there's only a label so you will not see the real >> effect. >>> >>> and must comment in AlertView this line (130) >>> titleBar.addBead(new HorizontalLayoutSpaceBetween()); >>> that override the concrete behavior of the standard TitleBar for Alert >> and >>> expose the one in css for general TitleBar. >>> >>> Why this happens? Is simply how compiler works. I see it a lot natural >> and >>> for that reason styles in Jewel are organized in the actual way: beads >> are >>> in the Jewel library since it wire the default behavior and html css >> styles >>> are in themes since the things we want to change mostly. >>> >>> Other themes could mix both, and as I tried and exposed, override beads >> in >>> themes is supported that seems a very powerful feature to explore in the >>> future. >>> >>> I worked a lot on organization, I think where you put things (library), >>> packaging and naming is all important, even method signatures are vey >>> important since is what users will be using finaly, so making this as >>> simple as possible but flexible is our main focus. >>> >>> Hope this clears all better :) >>> >>> >>> 2018-05-14 17:43 GMT+02:00 Harbs <[email protected] >>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>>: >>> >>>> I think we have zeroed in on the point of 1a. Great! :-) >>>> >>>> I don’t understand what you mean here. I don’t understand how component >>>> styles could be assigned. >>>> >>>> To be clear I mean something like this: >>>> >>>> <js:Application xmlns:fx="http://ns.adobe.com/mxml/2009 >>>> <http://ns.adobe.com/mxml/2009> < >> http://ns.adobe.com/mxml/2009 <http://ns.adobe.com/mxml/2009>> < >>>> http://ns.adobe.com/mxml/2009 <http://ns.adobe.com/mxml/2009> >>>> <http://ns.adobe.com/mxml/2009 <http://ns.adobe.com/mxml/2009>>>" >> xmlns:js="library://ns.apache <library://ns.apache> <library://ns.apache >> <library://ns.apache>>. >>>> org/royale/basic <library://ns.apache.org/royale/basic >>>> <library://ns.apache.org/royale/basic> <library:// >> ns.apache.org/royale/basic <http://ns.apache.org/royale/basic>>>" >>>> xmlns:j="library://ns.apache >>>> <library://ns.apache> >> <library://ns.apache <library://ns.apache>>. >>>> org/royale/jewel <library://ns.apache.org/royale/jewel >>>> <library://ns.apache.org/royale/jewel> <library:// >> ns.apache.org/royale/jewel <http://ns.apache.org/royale/jewel>>>"> >>>> <fx:Style> >>>> @namespace "http://www.w3.org/1999/xhtml >>>> <http://www.w3.org/1999/xhtml> < >> http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml>> < >>>> http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml> >>>> <http://www.w3.org/1999/xhtml <http://www.w3.org/1999/xhtml>>>"; >>>> @namespace svg "library://ns.apache.org/royale/svg >>>> <library://ns.apache.org/royale/svg> >> <library://ns.apache.org/royale/svg <library://ns.apache.org/royale/svg>> >>>> <library://ns.apache.org/royale/svg <library://ns.apache.org/royale/svg> >>>> <library://ns.apache.org/royale/svg <library://ns.apache.org/royale/svg> >>>> "; >>>> @namespace j "library://ns.apache.org/royale/jewel >>>> <library://ns.apache.org/royale/jewel> >> <library://ns.apache.org/royale/jewel <library://ns.apache.org/royale/jewel>> >>>> <library://ns.apache.org/royale/jewel >>>> <library://ns.apache.org/royale/jewel> <library://ns.apache.org/ >>>> <library://ns.apache.org/> >> royale/jewel>>"; >>>> >>>> j|TextButton >>>> { >>>> padding-top:10px; >>>> } >>>> </fx:Style> >>>> </js:Application> >>>> >>>> Are you saying that this will work? If yes, please explain how. >>>> >>>> Thanks, >>>> Harbs >>>> >>>>> On May 14, 2018, at 5:26 PM, Carlos Rovira <[email protected] >>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> >> wrote: >>>>> >>>>>> >>>>>> 2. Client code cannot declare default CSS in their app for all Jewel >>>>>> components of a specific type. In other words >> j:Button{background-color: >>>> blue} >>>>>> will not work because a Jewel Button does not have a “Button” class >>>> name. >>>>>> >>>>> >>>>> No. That would work. You can check in Jewel "sass" folder where all >>>>> components define the css that links beads and classes. >>>>> In that case we don't have anything for Button at this time, but most >> of >>>>> the rest have declarations like j|{Component} and beans assigned. >>>>> Then mostly all html styles are in themes in the styles that are as you >>>>> already notice "jewel {component}" >>>> >>>> >>> >>> >>> -- >>> Carlos Rovira >>> http://about.me/carlosrovira <http://about.me/carlosrovira> >>> <http://about.me/carlosrovira <http://about.me/carlosrovira>> >> > > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira>
