2018-05-15 10:52 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> 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?
>
In MDL you "import" the real CSS and JS. Take into account we are
"wrapping" a real library. But you still can add new css, but I must say I
didn't experiment with that, since the motivation to bring MDL was to have
a set that looks good out-of-the-box.
> b) Assuming it can’t, should that dictate how other component sets work?
>
No. MDL has the problem that it comes from other source, so the problem is
that it has some components (Badge, Card,..), and does not have others
(Panel, Accordion,..). So wrapping this ui sets, is good to make Royale
more powerful, but I think it should not be our real target, as I said many
times. For example, with Jewel we can make many different themes, and make
our applications change theme and change the look completely. With MDL your
tied to how MDL looks (or MDL themes)
>
> 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.
>
I don't think I follow you here. But If you are saying to make MDL have
generic CSS styles, I think that will make a "Frankenstein" ;). For
external sets, I think is better left as is, and only think of use it as it
was designed. What I think we could do at some time, but would require lots
of time, is to implement our own MDL Jewel theme, that could match the MDL
style, but I think that have visible differences and will not match MDL
100%. Or we can make a theme overriding Views and applying real MDL css and
js, but we'll have more components than the ones supported by MDL.
>
> 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.
>
I see you sent another email, I see 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.
>
>
Right, I talked about this many times in the past, and was the reason to
make Jewel. I always said we need our own theme-able UI set that could
switch faces and is the reason Jewel was born. MDL, and the rest of
external UI sets will be always isolated sets with its own rules since we
can do anything more about that.
> 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.
Thanks
>
> Thanks,
> Harbs
>
> > On May 15, 2018, at 8:34 AM, Carlos Rovira <carlosrov...@apache.org>
> wrote:
> >
> > Hi Harbs,
> >
> > 2018-05-14 23:37 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>:
> >
> >> 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 <carlosrov...@apache.org
> <mailto:carlosrov...@apache.org>>
> >> 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 <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com> <mailto:
> >> harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>>:
> >>>
> >>>> 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 <carlosrov...@apache.org
> <mailto:carlosrov...@apache.org>
> >> <mailto:carlosrov...@apache.org <mailto:carlosrov...@apache.org>>
> >>>> <mailto:carlosrov...@apache.org <mailto:carlosrov...@apache.org>
> <mailto:carlosrov...@apache.org <mailto:carlosrov...@apache.org>>>>
> >> 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>
>
--
Carlos Rovira
http://about.me/carlosrovira
