Re: typeNames vs className

Thanks. Harbs escreveu no dia sábado, 12/02/2022 à(s) 23:54: > typeNames are class names set by the class which should not be changed by > client code. > > className is what you set in an application for styling. > > > On Feb 12, 2022, at 10:14 PM, Hugo Ferreira > wrote: > > > > Hi, > > > > For

Re: typeNames vs className

typeNames are class names set by the class which should not be changed by client code. className is what you set in an application for styling. > On Feb 12, 2022, at 10:14 PM, Hugo Ferreira wrote: > > Hi, > > For me seems that same, typeNames is converted at runtime to className but > is so,

typeNames vs className

Hi, For me seems that same, typeNames is converted at runtime to className but is so, what the reason to have a second property ?

Re: TypeNames vs ClassName

Carlos Rovira > Sent: Thursday, February 14, 2019 7:28:19 PM > To: dev@royale.apache.org > Subject: Re: TypeNames vs ClassName > > HI Yishay, > > A working example is in TDJ ( https://royale.apache.org/tourdejewel ) > go to layouts. First one is a group with a

RE: TypeNames vs ClassName

Hi Carlos, After updating from dev it looks like it’s working now. Thanks. From: Carlos Rovira Sent: Thursday, February 14, 2019 7:28:19 PM To: dev@royale.apache.org Subject: Re: TypeNames vs ClassName HI Yishay, A working example is in TDJ ( https

Re: TypeNames vs ClassName

; Thank you > > yannick > > > > -Message d'origine- > > De : Carlos Rovira [mailto:carlosrov...@apache.org] > > Envoyé : jeudi 14 février 2019 18:28 > > À : dev@royale.apache.org > > Objet : Re: TypeNames vs ClassName >

Re: TypeNames vs ClassName

s Rovira [mailto:carlosrov...@apache.org] > Envoyé : jeudi 14 février 2019 18:28 > À : dev@royale.apache.org > Objet : Re: TypeNames vs ClassName > > HI Yishay, > > A working example is in TDJ ( https://royale.apache.org/tourdejewel )

RE: TypeNames vs ClassName

ssage d'origine- De : Carlos Rovira [mailto:carlosrov...@apache.org] Envoyé : jeudi 14 février 2019 18:28 À : dev@royale.apache.org Objet : Re: TypeNames vs ClassName HI Yishay, A working example is in TDJ ( https://royale.apache.org/tourdejewel ) go to layouts. First one is a group with a

Re: TypeNames vs ClassName

HI Yishay, A working example is in TDJ ( https://royale.apache.org/tourdejewel ) go to layouts. First one is a group with a className: Jewel BasicLayout (width200, height:200px) code: If is no

Re: TypeNames vs ClassName

Confused about this, now that I'm using Jewel. I want to add shadow to a Jewel group. So I do this: But then I see raisedShadow removed in in run-time in favor of classes such as "itemsExpand itemsCenter itemsCentered layout vertical" Where should I be specifying my application classNa

Re: TypeNames vs ClassName

HI Alex, ok, I think I'll be subclassing in my branch and see where I get, in this way the Piotr and Harbs can continue with things as they expect to. In the other way, maybe it could seem that I'm worried to much about how html looks, and maybe things like the layouts can wait, but I think is imp

Re: TypeNames vs ClassName

Hi Carlos, I think people are more uncomfortable with the proposal to use element.classList than any issue about order. It is hard for me to truly understand without seeing code so I think you should push it to your branch. I agree with Piotr that we can't make the users (app dev) use classList.

Re: TypeNames vs ClassName

Hi Alex, since Piotr and Harbs seems not to be very comfortable with the change, I can subclass UIBase for Jewel and make that changes there. I don't want to conflict in such central point of the framework, Will it be ok for all of us? 2018-03-12 18:56 GMT+01:00 Alex Harui : > IMO, the order isn

Re: TypeNames vs ClassName

IMO, the order isn't going to make or break Royale. Leave it as you have it and we'll see what our users think. -Alex On 3/12/18, 10:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: >Hi > >sorry guys, I changed it since I thought I would not matter anyone. For me >is just the

Re: TypeNames vs ClassName

Hi Piotr. I think is what I just pointed in the response to a Harbs emails. I think once people set typenames and classnames, if we operate all through element.classList, that solves all conflicts, since all classes are in a managed list, if people wants to add or remove they can through the list.

Re: TypeNames vs ClassName

Hi sorry guys, I changed it since I thought I would not matter anyone. For me is just the opposite. Feels very strange to me see things right to left, is like description of folders, bread crumbs and something like this that use to be from parent to child, and left to right I do that as well sinc

Re: TypeNames vs ClassName

Carlos, But people are changing className all the time and that's the way how you are changing your component. That was the problem. How do you handle that one ? Change UIBase, your component to your approach. Than in your examples set - What are you get ? 2018-03-12 18:44 GMT+01:00 Carlos Ro

Re: TypeNames vs ClassName

Hi Harbs, if once typenames and classnames are set, if UIBase changes the way it manages className to use element.classList, things will be more easy and a matter of use add/remove/toggle methods in element.classList. right? if people changes className directly will be bad, unless he/she wants to

Re: TypeNames vs ClassName

Hi Piotr, I was reding from the begging and saw when the CSSClassList came. I think Harbs solution is ok, the only problem I see is that in MDL, and Jewel, we need to have functions per class that manages add/remove of classes and override of compute function. That's what I don't like of current

Re: TypeNames vs ClassName

2018-03-12 17:14 GMT+01:00 Alex Harui : > If HTMLElement.classList is exposed to the user (the app developer) then > they can remove any of the items that were added from the typenames. > There is no way to enforce immutability of the typenames. We can choose > to give up on that and require that

Re: TypeNames vs ClassName

Sure, the way the code is written in UIBase today. I think he can modify what UIBase className does, but then I think it starts becoming "more work" and not "simple" and PAYG. Of course, I could be wrong... -Alex On 3/12/18, 9:51 AM, "Harbs" wrote: >Right, but Carlos is using: element.classLis

Re: TypeNames vs ClassName

Hi Carlos, That's why we are using Harb's solution with his own class list. If you went through this long thread carefully I have an issue which end up with that solution. The problem was exactly as Harb's mention. Try it yourself. Another great things which Harb's bring up here is why I also lik

Re: TypeNames vs ClassName

Right, but Carlos is using: element.classList.toggle("primary", value); (and similar) That will be overwritten if someone sets myButton.className = “foo_class”; (where myButton is some kind of UIBase) You cannot even do something like this: myButton.className = myButton.className + “ foo_clas

Re: TypeNames vs ClassName

Well, it isn't fair if someone writes to element.className, but we control what happens when someone writes to UIBase.className. I just want it to be as simple as possible and PAYG. -Alex On 3/12/18, 9:21 AM, "Harbs" wrote: >I’m pretty sure your solution will only work if the user doesn’t set

Re: TypeNames vs ClassName

I’m pretty sure your solution will only work if the user doesn’t set a className of their own. Setting className overwrites the entire classList. > On Mar 12, 2018, at 5:45 PM, Carlos Rovira wrote: > > Hi > > I made some simplification that works ok in Jewel: > > 1.- remove CSSClassList and u

Re: TypeNames vs ClassName

If HTMLElement.classList is exposed to the user (the app developer) then they can remove any of the items that were added from the typenames. There is no way to enforce immutability of the typenames. We can choose to give up on that and require that app developers be careful, but I'd rather not.

Re: TypeNames vs ClassName

Hi I made some simplification that works ok in Jewel: 1.- remove CSSClassList and use element.classList since is native and supported in all browsers we target, this simplifies code, and removes classes from core. 2.- I still need to use some additional code that can be simplified. I'm doing: el

Re: TypeNames vs ClassName

Hi, long thread and very useful read here. Since Jewel is very similar to MDL in adding/removing classes I want to comment here some things: 1.- I just changed jewel typenames to the constructor and things works ok, I could remove the createElement override 2.- I have into account the use of type

Re: TypeNames vs ClassName

Harbs please post code snippets so we can understand what you are referring to. I'm not too concerned about how much code is baked into MDL, but I'm more interested in the notion that there are just-in-case patterns that are somehow more optimal than on-demand patterns. I'm thinking there are way

Re: TypeNames vs ClassName

> On Mar 5, 2018, at 2:18 AM, Alex Harui wrote: > > Why are there so many empty strings and why do the cost so much? Should > we reference a single global empty string? If you mean in XML, I eliminated initializing *everything* in XML unless needed and I saw a drastic reduction in use of memo

Re: TypeNames vs ClassName

Why are there so many empty strings and why do the cost so much? Should we reference a single global empty string? I don't think I follow why just-in-case code is less than not-just-in-case code. I don't think I've ever really seen that. Can you provide more detail? -Alex On 3/4/18, 5:24 AM,

Re: TypeNames vs ClassName

> On Mar 2, 2018, at 6:46 PM, Alex Harui wrote: > > Again, the principles of PAYG are that there is as little Just-in-case > code as possible. AIUI, every MDL user will be downloading and > initializing the ClassList prototype just-in-case. This is not true of > Strings. It isn't just the cos

Re: TypeNames vs ClassName

Again, the principles of PAYG are that there is as little Just-in-case code as possible. AIUI, every MDL user will be downloading and initializing the ClassList prototype just-in-case. This is not true of Strings. It isn't just the cost of instantiation. There are download and class initializat

Re: TypeNames vs ClassName

Harbs, Thanks for such a good explanation. I think I will go with your class. 2018-03-02 10:36 GMT+01:00 Harbs : > I do agree that this is pretty low on the list of priorities. I did not > have a head to work on anything “serious” and the class lists was a nice > distraction for me. I’m certai

Re: TypeNames vs ClassName

I do agree that this is pretty low on the list of priorities. I did not have a head to work on anything “serious” and the class lists was a nice distraction for me. I’m certainly fine with however Piotr handles this. I would like to point out a few things: 1. Object instantiation is pretty chea

Re: TypeNames vs ClassName

Maybe let's do this in that way. I could stay with your solution where I'm using that array class, but we could move it to the MDL module. Since this problem is specific right now to that. Maybe the computation won't be so large like it is in case of MDL, where you have 5-6 properties and you need

Re: TypeNames vs ClassName

Hi Harbs, As much as I like Array approach I took Alex's words more serious that having an Array in the game here could be more heavier than String concatenation. It's earlier in the discussion. Piotr 2018-03-02 3:26 GMT+01:00 Alex Harui : > Very nice, but IMO, this is over-engineering. We ar

Re: TypeNames vs ClassName

Very nice, but IMO, this is over-engineering. We are talking about a space-delimited list where some portion of it is considered "fixed" another portion is user-settable and another portion comes from other attributes. Some generic StringUtils or ListUtils might be more PAYG, especially if they a

Re: TypeNames vs ClassName

What do you think of the CSSClassList class I just committed? I *think* that makes the pattern more recognizable and probably is less heavy if more than one class can be used. Harbs > On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki wrote: > > Harbs, Alex, > > I just pushed implementation of comp

Re: TypeNames vs ClassName

Harbs, Alex, I just pushed implementation of computeFinalClassNames to branch feature/type_names_class_name_issue124. You can review implementation in this commit [1] and example of usage in Card and Button. I have tested with Harbs example [3] and with Card by changing orders. It's working. [1]

Re: TypeNames vs ClassName

Let me play with implementation of that function. It seems to me that will be much cleaner than current solution. If user actually wanted to do anythin with className - let the overriding speaks. On Wed, Feb 28, 2018, 21:51 Alex Harui wrote: > On 2/28/18, 12:27 PM, "Harbs" wrote: > > >OK. I

Re: TypeNames vs ClassName

On 2/28/18, 12:27 PM, "Harbs" wrote: >OK. I think that will work for DML components, but what if there’s a bead >which needs to add class names? What would be the “right” way to do that? >A bead cannot override the function on the strand. Do we have beads that manipulate className? IMO, the pri

Re: TypeNames vs ClassName

OK. I think that will work for DML components, but what if there’s a bead which needs to add class names? What would be the “right” way to do that? A bead cannot override the function on the strand. > On Feb 28, 2018, at 10:17 PM, Alex Harui wrote: > > I think you are missing that the element.

Re: TypeNames vs ClassName

I think you are missing that the element.className is set to computeFinalClassNames. So the user is welcome to manipulate the UIBase.className however they see fit. They can assign it a whole new space-delimited list if they want. But what gets set on element.className is computed from typeNames

Re: TypeNames vs ClassName

The problem which sparked this whole issue is like this: 1. We have some components (i.e. in MDL) which add “pieces” to the class names (such as “fab”, “raised”, “colored”, etc. 2. The client might subsequently set the className to something else. 3. When the component sets the “pieces” first and

Re: TypeNames vs ClassName

On 2/28/18, 10:44 AM, "Harbs" wrote: >If it’s not public, I don’t see how a utility method could call it though. I didn't think the utility methods like addClassName/removeClassName would need to alter computeFinalClassNames(). AIUI, for most UIBase subclasses, the final element.className is a

Re: TypeNames vs ClassName

If it’s not public, I don’t see how a utility method could call it though. > On Feb 28, 2018, at 8:21 PM, Alex Harui wrote: > > > > On 2/28/18, 9:50 AM, "Piotr Zarzycki" > wrote: > >> Ok Understand, but do you agree that computeFinalClassNames - is >> somet

Re: TypeNames vs ClassName

On 2/28/18, 9:50 AM, "Piotr Zarzycki" wrote: >Ok Understand, but do you agree that computeFinalClassNames - is >something >which is in the UIBase ? Yes, and probably protected instead of public. The one in UIBase just appends typenames to className. It gets overridden in MDL where needed fo

Re: TypeNames vs ClassName

Ok Understand, but do you agree that computeFinalClassNames - is something which is in the UIBase ? 2018-02-28 18:47 GMT+01:00 Alex Harui : > I think that in the shadow setter, it would change _shadow and call > setClassName(computeFinalClassNames()); > > On 2/28/18, 9:33 AM, "Piotr Zarzycki" w

Re: TypeNames vs ClassName

I think that in the shadow setter, it would change _shadow and call setClassName(computeFinalClassNames()); On 2/28/18, 9:33 AM, "Piotr Zarzycki" wrote: >Alex, > >So we are getting back to the idea where you proposed to have function >which computes everything. > >override public function comput

Re: TypeNames vs ClassName

Alex, So we are getting back to the idea where you proposed to have function which computes everything. override public function computeFinalClassNames():String { return super.computeFinalClassNames() + " " + _shadow; } Where does that function should be placed ? Does that function should be c

Re: TypeNames vs ClassName

Hi Piotr, I think am I not communicating the principles effectively. First, IMO, addClassName and removeClassName should not be in UIBase. Lots of apps can be written without needing these methods. I think they can be written as utility functions. Second, the computation of the final element.cl

Re: TypeNames vs ClassName

Hi Alex, Sorry about that. Let me show you code and I recorded GIF with problem debugging. *Code in UIBase which I have implemented:* addClassName and removeClassName [1]. addedToParent what is happen with internal field which I have added [2] *Code for Testing* [3] - I'm adding first className,

Re: TypeNames vs ClassName

Hi Piotr, I could not understand this explanation. Might be better to show actual code. For example in #3, there is a cssClass variable that I don't know about. Also you mention at the bottom setting something as empty, but I'm not sure what that is. However, IMO, this code should be in utility

Re: TypeNames vs ClassName

Here is how I'm thinking to resolve that issue. I would take Harb's proposition and add to UIBase addClassName() and removeClassName(). Next I would add internal field _internalClassName:String. addClassName(value): 1) Will check if provided class name exits in _className and in _internalClassNam

Re: TypeNames vs ClassName

I think I have analyzed everything and have some implementation proposition. I will try to provide it later today. Thanks, Piotr 2018-02-27 13:35 GMT+01:00 Harbs : > ExpandableSearch broke too. > > > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki > wrote: > > > > Harbs, > > > > If you are using so

Re: TypeNames vs ClassName

ExpandableSearch broke too. > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki wrote: > > Harbs, > > If you are using something more than MDL Dialog in your application it > would be great to get feedback whether I didn't break for you anything. :)

Re: TypeNames vs ClassName

I know what you mean Harbs, but it may not be so easy to achieve. classList and className at some point are wiped out. When I was working on changes in MDL it happened in addedToParent. The end of all process to save things was always concatenating. I think having couple of functions is a good t

Re: TypeNames vs ClassName

My thinking is that there are a set of defaults in typeNames that match fake type selectors and should almost never be changed at runtime. What scenario made you want to change typeNames outside the component? Then there is another set of class names that you specify outside the component. There

Re: TypeNames vs ClassName

I think my main point was that we wouldn’t need computeFinalClassNames() which would be overridden in subclasses. If there’s simple a _classList:Array which would have something like: protected function applyClassNames():void { element.className = className ? className : “” + “ “ + _clas

Re: TypeNames vs ClassName

Harbs, You simply suggesting to have several functions instead of one which computes things? On Mon, Feb 26, 2018, 20:21 Harbs wrote: > Yes. Very thorough explanation. Thanks. > > It seems to me like there should be functions for addClassName() and > removeClassName() which would add and remo

Re: TypeNames vs ClassName

Yes. Very thorough explanation. Thanks. It seems to me like there should be functions for addClassName() and removeClassName() which would add and remove the classNames from a list. When the className is computed, the list should be concatenated to classNames (and possibly typeNames — although

Re: TypeNames vs ClassName

Hi Alex, Great reading and explanation. My first thought was to have something which computes className together, but currently it is needed for MDL only almost. I went with this additional function Utility. I think there won't be too much time when we will need such ability like switching and add

Re: TypeNames vs ClassName

Here's my view of this problem space. This is my opinion, not marching orders. Everything is up for discussion. This is what the current code is trying to do, though. Also, important note: The order of names in the HTMLElement.className does not matter. CSS style precedence is determined by t

Re: TypeNames vs ClassName

Yes. The changes did break things. I committed an alternate way of fixing things. There is a discussion on Github on how strictly we avoid changing typeNames: https://github.com/apache/royale-asjs/commit/c01ebc2cc946570006d8f5cea607182e16eaf0fe#r27788371

Re: TypeNames vs ClassName

I just pushed changes to MDL. With couple of exceptions all typeNames landed to constructor. Thanks to that changes some components started to work better. I'm wondering whether I do not break anything. Harbs, If you are using something more than MDL Dialog in your application it would be great t

Re: TypeNames vs ClassName

Sorry, I wasn't clear. The function itself can go in Basic or better yet, Core, since I don't think it has any dependencies and can be use anywhere. I was just saying that I would prefer if none of the Basic components or UIBase used your new function. You should be able to write a Royale app wi

Re: TypeNames vs ClassName

I was going to put it somewhere in the Basic, but I can leave it in the MDL. The className can be undefined in the case where you wanted to add something to such "undefinded" string you will got: "undefined myClass". - I probably cannot escape from that... Maybe I'm missing some way. 2018-02-24

Re: TypeNames vs ClassName

Looks ok to me. Seems like you don't need COMPILE::JS. It should work on all platforms. We can have lots of utility functions in org.apache.royale.utils. In terms of optimization (size/performance) a function like this is potentially overkill for the Basic set. It is fine for MDL since MDL has

Re: TypeNames vs ClassName

Alex, I used your suggestion, added some additional things and I end up with following utility [1]. Usage will looks like that: [2]. Do you think it could be part of the framework ? It's working nicely with MDL. [1] https://paste.apache.org/tsaF [2] https://paste.apache.org/xbfb Thanks, Piotr

Re: TypeNames vs ClassName

Well, whether you like it or not, the wrapper is mapping a space-delimited list to the array so if you manipulate the array you have to back-calculate the string. IMO, in HTML, the "class" property is a string and people are used to entering a space-delimited list. That's why we have a className

Re: TypeNames vs ClassName

It's just swapping. If I have following code [1] - it is easier to manipulate classList than className which is simple string. What utility could look like ? It would be manipulating strings, which is less convenient. [1] https://paste.apache.org/at0H 2018-02-23 21:11 GMT+01:00 Alex Harui : > Ju

Re: TypeNames vs ClassName

Just compiler. No need for asjs changes at this time I think. I'm still unclear on why you need to manipulate classList directly. Is there some code that is in the JS from Material that manipulates classList? Or are you just trying to swap out a name on the classList? If the latter, why not jus

Re: TypeNames vs ClassName

You did merge vivid compiler changes or also changes from asjs repository. As for my work on MDL. I ended up with something like that [1]. The question now how to propagate that code ? This is code for the component which manipulates classList. Should I create some parent class ? General/ for MDL

Re: TypeNames vs ClassName

I think I have Maven using the basic.css appropriately. There is no way to default to including a SWC in Maven and then not use it in a child project, so all example poms that aren't MDL need to bring in the BasicTheme. Also, I had to merge the compiler change from vivid-ui-set branch to get the

Re: TypeNames vs ClassName

Ok, maybe I had problems in the past due to what you say. Hope this changes remove that problems too thanks 2018-02-23 19:29 GMT+01:00 Alex Harui : > Hi Carlos, > > I think we've separated out basic.css and stopped misusing "className" in > the Basic components so typeNames should work as expect

Re: TypeNames vs ClassName

Hi Carlos, I think we've separated out basic.css and stopped misusing "className" in the Basic components so typeNames should work as expected in subclasses like MDL and possibly even Vivid. Piotr might as well finish up MDL so we can see if there might be issues that affect Vivid. My 2 cents, -

Re: TypeNames vs ClassName

Hi!, can't read all the thread right now, but I want to share a word of caution with MDL When I started that library, I had to fight a lot with typenames and classnames. Alex hopefully remember several emails about this topic. I ended with the current solution. As I excluded basic css, I think I w

Re: TypeNames vs ClassName

Understand! :) Now I can agree with you that typeNames could be protected. Definitely. Let me play farther with MDL and see where I end up. On Fri, Feb 23, 2018, 18:28 Alex Harui wrote: > > > On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote: > > >Just the opposite. The typeNames get rid of everythi

Re: TypeNames vs ClassName

On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote: >Just the opposite. The typeNames get rid of everything what is setup in >the >classList. > >But className is being add typeNames. This is what is happen: > >typeNames=mdl-card >classList.add("someclass") > >In addedToParent: >className += typeNames

Re: TypeNames vs ClassName

Just the opposite. The typeNames get rid of everything what is setup in the classList. But className is being add typeNames. This is what is happen: typeNames=mdl-card classList.add("someclass") In addedToParent: className += typeNames classList is being wipped out and filled by className. That

Re: TypeNames vs ClassName

TypeNames is supposed to override what is in classList. ClassList should contain two sets of names. Immutable ones that come from typeNames like TextInput or Card that map to the component that is pointed to by element.royale_wrapper. That allows us to "extend" the set of TypeSelectors as folks i

Re: TypeNames vs ClassName

I'm not sure what you put in the theme for MDL. But it shouldn't matter whether it is in a theme or in MDL's defaults.css since nobody in MDLTabsExample is trying to override it. MDL only needs its own theme if someone will want to use the structural aspects of the MDL components (the layouts and

Re: TypeNames vs ClassName

Reading what you are saying here regarding classList and className w have a bug. typeNames shouldn't override what is inside classList, but this is what has happened in addedToParent. Am I understand you correctly? On Fri, Feb 23, 2018, 17:11 Alex Harui wrote: > > > On 2/23/18, 7:32 AM, "Piotr

Re: TypeNames vs ClassName

On 2/23/18, 7:32 AM, "Piotr Zarzycki" wrote: >Alex, > >I have started to work on MDL and move all typeNames from createElement to >constructor. Unfortunately something is not right here. > >1) I still need to exclude BasicJS.swc:default.css - I did add theme to >MaterialDesignLite module maven

Re: TypeNames vs ClassName

I have added separate theme for MDL - didn't touch basic.css at all. I did add it as an -theme=path - this doesn't change anything in Basic module. On Fri, Feb 23, 2018, 17:05 Piotr Zarzycki wrote: > I think I see where the issue may be, but not sure if it is an issue. I > have created separate

Re: TypeNames vs ClassName

I think I see where the issue may be, but not sure if it is an issue. I have created separate project where I have only MDL Card component. I'm setting property shardow = "2" [1]. This property is being called, but I don't have line with typeNames - it's deleted. What is happen: 1) Constructor is

Re: TypeNames vs ClassName

MDL does not want the basic.css theme. That is why we are moving styles from Basic:swc's defaults.css to themes/basic.css. I see that the Maven plugin doesn't allow specification of a theme, so that's another task. I can do it if nobody wants to take that on. So, yes, move the Button selectors

Re: TypeNames vs ClassName

A bit more on point 1. and let's take for the example simple Button. We have some styles for Button in Basic.css. MDL Button extends TextButton - some styles naturally has been added from default.css. If I create theme I should achieve that my theme classes will override default.css Button styles

Re: TypeNames vs ClassName

Alex, I have started to work on MDL and move all typeNames from createElement to constructor. Unfortunately something is not right here. 1) I still need to exclude BasicJS.swc:default.css - I did add theme to MaterialDesignLite module maven build - it didn't help. 2) If I cannot setup typeNames a

Re: TypeNames vs ClassName

Peter, That is interesting what you are saying. What will happen then if you have class which extends other one. The parent class is setting typeNames and derived one also before super? The parent one will override it? I cannot check now how typeNames is implemented. Piotr On Fri, Feb 23, 2018,

Re: TypeNames vs ClassName

I have been guilty of this and have been using typeNames now. I've found that I need to set typeNames before calling super() in the constructor. I thought it was done afterwards, but if I set typeNames after calling super(), the typeName I set does not show up in the HTML produced. Also, suppose I

Re: TypeNames vs ClassName

There’s some edge cases which seem problematic. One example: ComboBoxBiew has the following: input = new TextInput(); input.className = "ComboBoxTextInput"; button = new TextButton(); button.className = "opt_org-apache.royale-ht

Re: TypeNames vs ClassName

I’ll help. > On Feb 23, 2018, at 10:50 AM, Alex Harui wrote: > > Quick note before I shut down for the night. > > UIBase has both a typeNames and className property. TypeNames is used to > emulate Flex-like type selectors in the CSS lookup. It should be set in > the constructor and never set

Re: TypeNames vs ClassName

Alex, I will look into the MDL. Thanks, Piotr 2018-02-23 9:50 GMT+01:00 Alex Harui : > Quick note before I shut down for the night. > > UIBase has both a typeNames and className property. TypeNames is used to > emulate Flex-like type selectors in the CSS lookup. It should be set in > the cons

TypeNames vs ClassName

Quick note before I shut down for the night. UIBase has both a typeNames and className property. TypeNames is used to emulate Flex-like type selectors in the CSS lookup. It should be set in the constructor and never set from outside the class. There are a few classes in Basic and lots of classe