On 4/11/18, 2:37 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>1) I agree with most of your mail. My main need is to use an API that let
>me add/remove/toggle styles easily (mine and whoever wants to deal with
>So if you think my changes to UIBase are not ok and you want to ensure
>things are more as you have in mind, that's ok with me. But to avoid more
>investing time in discussion I prefer wait for you to make the changes in
>the UIBase classname branch. I assume that the way I use it though new
>methods like "addStyles" will not change, and so I can continue my work
>with the rest of components. So in this point I'll wait for you changes if
>is ok for you.
OK, I will make the changes after I finish up a few other things.
>2) About Jewel UIBase extension: I think is better to always extend UIBase
>than the Basic component as a rule. So I'll normalize the current Jewel
>components so Basic and Jewel will be siblings and extend from UIBase
>instead jewel extend basic and basic UIBase. Let me know if you agree with
>me that this is a better decision.
I'm not quite sure what you mean here. I don't think Jewel needs its own
UIBase. It should be able to use the one in Basic.
>3) about separation of styles in CSS, in this part I not agree. I don't
>think is just stylistic code decision, or for me that's not the main
>motivation behind. I think that setting things like, "display", width or
>height or padding in the component class is a bad design choice, since
>you're making that component coupled to that decisions, while here for me
>applys the "separation of concerns" concept.
>Why basic label sets word-wrap in the class instead of in the CSS Label
>rule as with the rest of its beads? For me that's the right place to do
>For me the class setups the HTML structure (i.e, span, div,...) and wire
>the needed JS, then the CSS should set up all styles and transition
>effects, since is how things works in HTML. I think things like
>"display:none" should be managed, not setting that as is, but to adding a
>class "visible" to the component class list. Is this more/less efficient.
>don't thing it makes any difference in performance, nobody here can said
>that is better through the myriad of browser implementations and its
>different performances, but most important in this case is separation of
>concerns and how we organize the code. since a CSS rule like ".visible"
>used for all components to set display to none or not, makes more reusable
>that code and more easy to deal with that, and then in JS you can make
>and in SWF use a different code.
If it isn't stylistic, then you should be able to provide technical
reasoning including articles on the internet explaining why using styles
object is wrong or inefficient. Every website I look at is using both
classes and the style object directly, even the WordPress generated
royale.a.o. The APIs allow us to use the style object. They allow us to
use classList and/or className. What you want to do appears to be a
preference without any technical justification. There is nothing in
Royale that prevents you from contributing layouts that use classes
instead of the style object.
If you want to discuss about why UIBase.visible=false sets display:none on
the style object, I guess we can have that discussion. To me, using the
style object makes sense so you don't have to worry about other class
selectors with display styles taking precedence.
If you want to discuss about why Label sets wordWrap:none on the style
object, we can have that discussion as well. To me, the reasoning is
similar. You can't control the order of precedence in class selectors,
and the Basic Label should be single line and not have that messed with by
folks editing CSS. You are welcome to create a different Label in Jewel
if you want.
>2018-04-11 7:13 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
>> Hi Carlos,
>> My proposal uses classList, but only where it will be optimal to use it
>> given the scenarios. I think you misunderstood scenario 4. The
>> application developer can certainly cause classes to be added and
>> at runtime by manipulating properties on the component like "secondary"
>> "emphasized", but the actual applying of those styles are done by
>> framework code we write. IMO, other than the components that have the
>> same names as HTMLElements, we want the other Basic components and other
>> Royale components to abstract the underlying browser implementations so
>> we ever target another platform or output language, we aren't as tied to
>> browser APIs.
>> IMO, the reason there is both a classList and className API on
>> is that it can be more efficient to use one or the other in certain
>> scenarios. Instead of trying to always use classList or always use
>> className, my proposal uses both depending on which will be most
>> efficient, and also presents an abstraction that is backward compatible
>> with Flex and does not tie us to a browser implementation. One key
>> to remember is that lots of articles you find on the internet are about
>> working with hand-written JS and CSS. In Royale, we have a component
>> lifecycle and can control when code runs and thus some internet advice
>> does not apply.
>> If you are asking me to code up my proposal so you can see it, I guess I
>> will take the time to do so, or maybe Harbs can do it.
>> Regarding whether Jewel Slider extends Basic Slider, now that I
>> what you are saying, that isn't a problem for me. But whether you
>> Basic Slider or not, the hope is that both Slider components implement
>> same pattern: the outer component proxies properties to/from a model or
>> directly to an HTMLElement. And if there is a View, it pulls data from
>> the model.
>> Changes to UIBase probably should result in lengthy discussion to make
>> sure it is truly necessary. UIBase changes will have impact everywhere.
>> We need to consider PAYG, size, performance, usability and more. This
>> the most important thing to me. I do not want to see us repeat the
>> mistakes of Flex where we just packed the latest idea onto UIComponent
>> until it became 13,000 lines that dragged in all kinds of dependencies.
>> But, IMO, we have to separate technical decisions from stylistic
>> decisions. IMO, your desire to not have any Royale component set a
>> directly and only add classes is a stylistic decision. I think Harbs
>> shown that it is less efficient. But if that's how you want to write
>> code, that's fine. Royale is designed to provide choices. Often there
>> no one right way.
>> Anyway, let's see if we can get consensus on the changes to UIBase.
>> that's the only thing we need to agree on. If you still need to see it
>> code, let us know.
>> On 4/10/18, 2:49 PM, "carlos.rov...@gmail.com on behalf of Carlos
>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>> >Hi Alex,
>> >2018-04-10 21:17 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
>> >> Hi Carlos,
>> >> I think I'm still confused. Earlier you said that half of Jewel
>> >> components do not extend Basic components. What do they extend and
>> >When I said does not extend Basic components, I mean that doesn't
>> >counterpart (i.e. Jewel Slider does not extend Basic Slider, since are
>> >different), if not extend its counterpart at least extends UIBase
>> >> I think I have proposed a solution to how we handle classNames that
>> >> work for Jewel, MDL and all other components.
>> >I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3
>> >not with 4.
>> >For example Button.primary will need to set "primary" class" but as
>> >remove others
>> >like "secondary" or "emphasized" since only one of them should exists
>> >This is the same in MDL. Nowadays all set like MDL uses this a lot,
>> >all visuals
>> >depends on this things.
>> >> I think it would be better
>> >> for Royale to be able to use Jewel theme without a JewelUIBase unless
>> >> there is a really good technical reason.
>> >We should get to a consensus to reach this. I really prefer to stick
>> >UIBase if possible.
>> >> I was hoping Jewel really would
>> >> be the replacement of views and HTMLElements in the existing Basic
>> >> components.
>> >the problem with that is that it's making a change in basic is very
>> >consuming since we all disagree on how to make things. and we have the
>> >following problems:
>> >1) Basic is now used by people and changes on it can break code. For me
>> >that's ok, since I think we are in 0.9 and change things should be
>> >but then
>> >many of you will oppose to changes, so...
>> >2) ..this makes each change a discussion that makes us to spend several
>> >3) in the other hand we want basic to remain basic. that could be ok
>> >use views, but in the other hand we need some property methods in the
>> >(think in
>> >"primary", "secondary" and "emphasized" in Jewel Button....we can't
>> >them in basic button, since no body will allow that, so, this makes
>> >themes partially unusable.
>> >4) the other huge point for me is that I don't understand style code
>> >component. For me this is not optional and that is in many Basic code
>> >components and layouts.
>> >So I see basic mostly difficult to skin and will be use as you said for
>> >people that doesnt't want any overhead, but that's not my target in
>> >project, for this reason I doing Jewel.
>> >Alex, I think classList is a must nowadays in browser space, I already
>> >in lots of emails. All great projects use it.
>> >I post a link from MDL that states that one of the things they require
>> >browser (between others) is that support classList.
>> >But, if you really thing classList is not ok, and you have a better
>> >proposal of an API that allows me to add/remove easily classes at
>> >I think is better that you implement it in the branch we have,
>> >changes so I can really understand and test it. I think that would be
>> >better for all of us. I posted my proposal. I think you should post
>> >If I try it and works, I'm sure yours will be very efficient, so I
>> >can go with that. But we should not continue discussing without that
>> >to test, since I see we are doesn't understanding ok one to each other
>> >since maybe you and I are interpreting in our way what the other want
>> >For that reason and to avoid another long discussion, my position was
>> >extend UIBase with classList methods, that we already discussed for
>> >time in other thread
>> >in this way Basic components will not need classList, but Jewel will
>> >since is needed.
>> >I think we should take a path or another, and to do this and avoid lost
>> >more time in emails, is that you put the few lines of code you thing
>> >right in a commit in the uibase changes branch, so I can test it
>> >Let me know what do you think about it
>> >> Thanks,
>> >> -Alex
>> >> On 4/10/18, 9:55 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>> >> >Hi Alex,
>> >> >
>> >> >Jewel components extends UIBase or the basic version
>> >> >For example
>> >> >Jewel Button extends Basic Button,
>> >> >Jewel TextField extends Basic TextField
>> >> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an
>> >> >range and not 2 buttons)
>> >> >
>> >> >the main reason is that majority of basic controls can be what Jewel
>> >> >except for html needed (we needed structures most like MDL does) and
>> >> >to add some property methods to add / remove CSS rules.
>> >> >
>> >> >That's the main reason behind, in the end is to replicate what I
>> >> >MDL
>> >> >but using royale components and our own structure since we define
>> >> >theme
>> >> >css rule selectors.
>> >> >
>> >> >Hope it make more sense now.
>> >> >
>> >> >thanks
>> >> >
>> >> >Carlos
>> >> >
>> >Carlos Rovira