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, > > > >

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

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

nick > > > > -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 > > > > HI Yishay, &g

Re: TypeNames vs ClassName

v...@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

RE: TypeNames vs ClassName

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 className

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

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

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

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

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

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

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

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.-

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:

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

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

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

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 >

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

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 >

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

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

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

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

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.

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,

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

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

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

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

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,

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. >

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

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

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

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

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

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

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

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.

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 : “” + “ “ +

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()

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

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

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

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

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

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

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

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

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

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: > >

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

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.

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

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

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

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

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,

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

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 =

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

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