If I could decide - that class should be used as an util outside UIBase. UIBase should be as much technology agnostic as we can. However how to use that class outside ?
Thanks, Piotr 2018-04-16 10:08 GMT+02:00 Alex Harui <[email protected]>: > Hi Carlos, > > I'm running out of ways to try to explain this one concept. Here's my > next attempt: I think you are too focused on the underlying browser > implementation. Conceptually, the application developer is "setting > properties to affect visuals" or "choosing sets of groups of styles at > runtime". That is the abstraction/APIs Royale needs to present. It has > nothing to do with className/classList. If we ever target some other > runtime, for example, native C code, or even in the SWF implementations, > there may not be any className/classList in the runtime and the runtime > implementation should only have to implement the APIs we present, and not > emulate the browser's className/classList. > > Thus, the APIs we present should be things like "primary", "secondary", > "emphasized" as "properties that affect visuals", and addStyles, > removeStyles, toggleStyles for "choosing sets of groups of styles". But > addStyles, removeStyles, and toggleStyles should not take an HTMLElement > as a parameter, but rather, an IUIBase. The key question here is whether > the JS implementation can always assume that the styles get applied to the > positioner which may not be the same as the element. I think the answer > is yes. > > Then we have another option, which is to say that there is "an initial set > of styles". That's our MXML className property. We are not obligated to > allow it to be changed at runtime since we have the other APIs nor are we > obligated to keep it in sync with the properties we use in the JS > implementation. Note that Royale className and HTMLElement className has > never been kept in sync even in Basic because we add typeNames. > > I think with that set of 3 categories, there isn't really a need for folks > to have to "totally reset the initial set of styles", which implies > setting MXML className at runtime, or if there is a small amount of code > to do it but it is computationally expensive, that may be acceptable. I > think "totally resetting" is a rare occurrence and the "choosing sets" is > a sufficient API. > > I spent this evening trying a different implementation, but found out that > classList isn't backed by the kind of data structure I thought it had. I > was hoping that toggle disabled entries instead of removing them. I've > pushed a first cut at another way of managing the list of classes by > trying to track the indexes in the classList set by the classname. See > ClassSelectorList.as. I haven't wired it up yet to Jewel. I'm pondering > whether it could go in UIBase. > > Thoughts? > -Alex > > > > > On 4/15/18, 4:01 AM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > > >Hi Alex, > > > >app devs will create logic that will use our encapsulated code (i.e: > >setting primary to true or false). Jewel as MDL has properties that uses > >to > >deal with true/false values to make it easy for the user to change a > >style. > >Under the hood, that is changing the "element.class" or > >"positioner.class". > >I think component's royale className property should be updated and not > >remain dirty since that would create lots of confusion for our users. If > >we > >do that folks should never operate again with "className", maybe it could > >not be a problem, although left className in a non valid state sound > >strange to me. If you think it can work, we can try it and see what > >happen... but seems to me that maybe we're making thing very complex when > >all could be more straight lined. Anyway, I'll wait for your changes. > >Thanks! > > > >Carlos > > > > > > > >2018-04-15 8:49 GMT+02:00 Alex Harui <[email protected]>: > > > >> IMO, Carlos still isn't understanding my point. My point is that the > >>app > >> devs will not need to be setting className. They will be setting > >> properties like "emphasized", "secondary" and "primary" that can do > >> whatever it wants under the covers, and if we assume that folks will not > >> set (or are not supposed to set) className after init time, there are > >>much > >> simpler ways to handle this situation. > >> > >> That said, I have another idea about how to allow "emphasized", > >> "secondary" and "primary" to use classList that might be simpler that > >>what > >> I have committed so far. I will try to code it up tomorrow for others > >>to > >> look at. > >> > >> Thanks, > >> -Alex > >> > >> On 4/14/18, 9:24 AM, "Piotr Zarzycki" <[email protected]> > wrote: > >> > >> >Are you saying that it will work with your implementation and not with > >> >Alex's? > >> > > >> >Actually as a app developer above situation is very rare. > >> > > >> >Thanks, > >> >Piotr > >> > > >> >On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira <[email protected]> > >> >wrote: > >> > > >> >> That's what Alex want. To make className only used at init time then > >>we > >> >> should use classList methods. > >> >> I think that the premises are not right, since Alex thinks devs will > >>not > >> >> make heavy use of switching class selectors at runtime (at init time > >>and > >> >> later while using the app). MDL and Jewel are constantly setting and > >> >> removing class selectors from elements and positioners, so className > >> >>(set > >> >> only once at init time) is not right for use, but for people using > >> >>Basic. > >> >> Hence, Basic should remain with className, and MDL/Jewel should go > >> >> classList *always* (shadowing it so will have a royale API to work > >>with > >> >>SWF > >> >> and JS and in JS compilation use classList > >> >> > >> >> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki > >><[email protected]>: > >> >> > >> >> > Carlos, > >> >> > > >> >> > Are you saying here having your idea: > >> >> > > >> >> > " > >> >> > 1) I think people have the APIs (className and classList) and > >> >>can/will do > >> >> > what they want, although we say "use className only at init time". > >> >> > " > >> >> > > >> >> > If I do following things: > >> >> > > >> >> > <Component id="comp" className="myClass"/> > >> >> > > >> >> > And later in the code I do: > >> >> > > >> >> > comp.className = "myOtherClass"; > >> >> > > >> >> > It won't work? > >> >> > > >> >> > Piotr > >> >> > > >> >> > > >> >> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira > >><[email protected] > >> > > >> >> > wrote: > >> >> > > >> >> > > Alex > >> >> > > > >> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui <[email protected]>: > >> >> > > > >> >> > > > Carlos, > >> >> > > > > >> >> > > > It seems like either you have missed some of the discussion or > >> >>maybe > >> >> we > >> >> > > > weren't clear enough. > >> >> > > > > >> >> > > > >> >> > > I think most of what you say was considered but let's go for > >>parts: > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > Simply put: > >> >> > > > -The Basic components do not need to handle classList APIs. > >> >>There is > >> >> > no > >> >> > > > expectation that classes will be frequently added and removed. > >> >> > > > > >> >> > > > >> >> > > That's ok. Basic no, Jewel yes. That's huge diference, so I > >>think as > >> >> you > >> >> > > UIBase should go to Core and be as is now (or make the changes > >>you > >> >> > > estimate) > >> >> > > > >> >> > > > >> >> > > > -The goal of most component sets in Royale is to abstract away > >>the > >> >> > > > underlying platform APIs. That's why I'm not in favor of > >>having a > >> >> > > > classList API on UIBase. > >> >> > > > > >> >> > > > >> >> > > Right, classList is JS only so maybe an API in JewelUIBase > >>should be > >> >> > > general and use the JS code with COMPILE::JS > >> >> > > then implement others. > >> >> > > > >> >> > > -MXML is better with space delimited string lists instead of > >>arrays. > >> >> > > > > >> >> > > > >> >> > > I think in you version and my version is a string, but in mine > >>then > >> >>is > >> >> > > converted to feed classList > >> >> > > > >> >> > > > >> >> > > > -It doesn't make sense to split strings into an array in JS > >>when > >> >>the > >> >> > > > browser clearly can do it. > >> >> > > > -This perf test shows className is faster [1] > >> >> > > > -So does this one [2] > >> >> > > > > >> >> > > > > >> >> > > > We are starting from a list of strings. MDL is not. And that > >> >>makes > >> >> a > >> >> > > > difference, IMO. > >> >> > > > > >> >> > > > > >> >> > > ok in Jewel we could do in that way, the main difference with > >>Basic > >> >>is > >> >> > that > >> >> > > the main task of this kind of set is > >> >> > > heavily deal with class selectors so for Jewel (not for Basic) we > >> >> should > >> >> > > focus on it what means to me be fundamental part of JewelUIBase > >>to > >> >>have > >> >> > an > >> >> > > API to deal with styles in all platforms and that all components > >> >> > extending > >> >> > > it can use. > >> >> > > > >> >> > > > >> >> > > > I forgot to mention earlier that I was not happy that addStyles > >> >>and > >> >> > > > friends were JS-only. It would have been better if it did not > >> >>take > >> >> an > >> >> > > > element since that is a JS platform implementation. That way > >> >> > application > >> >> > > > developers could use addStyles and friends to manipulate the > >>set > >> >>of > >> >> > class > >> >> > > > selectors at runtime. > >> >> > > > > >> >> > > > >> >> > > ok, that's a fail on my implementation that should be fixed > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > More comments in-line.. > >> >> > > > > >> >> > > > [1] > >> >> > > > > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fmeasuret > >> >>hat.net%2FBenchmarks%2FShow%2F54%2F0%2F&data=02%7C01%7Caharui% > >> 40adobe.com > >> >>%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C > >> >>0%7C0%7C636593199085882368&sdata=ya1hbY9%2FHxLCMbEh% > >> 2BVqXP0OdWrV03zEPRAtu > >> >>ybj223w%3D&reserved=0 > >> >> > > > classname-vs-setattribute-vs-c > >> >> > > > lasslist > >> >> > > > [2] > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fjsperf.c > >> >>om%2Fclassname-vs-classlist-showdown%2F5&data=02%7C01%7Caharui% > >> 40adobe.co > >> >>m%7C18aef785013e484cfcf108d5a22445a7%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7 > >> >>C0%7C0%7C636593199085882368&sdata=ygYm8sTMDTniu1NFzxds3fEaa0e% > >> 2FxnNaYxHeO > >> >>6G3F0g%3D&reserved=0 > >> >> > > > > >> >> > > > On 4/13/18, 7:18 PM, "[email protected] on behalf of > >>Carlos > >> >> > > Rovira" > >> >> > > > <[email protected] on behalf of [email protected]> > >> >> wrote: > >> >> > > > > >> >> > > > >Hi, > >> >> > > > > > >> >> > > > >I think the discussion now should center in numbers. > >> >> > > > > > >> >> > > > >I added "performance.now()" to typedefs (how could we live > >> >>without > >> >> > this > >> >> > > > >until now? :)) > >> >> > > > > >> >> > > > Snip... > >> >> > > > > > >> >> > > > > > >> >> > > > >I think numbers are near identical right? > >> >> > > > > > >> >> > > > > > >> >> > > > >So given very close numbers should make us choose the more > >> >>simplest > >> >> > code > >> >> > > > > > >> >> > > > > > >> >> > > > >right? > >> >> > > > > > >> >> > > > No. Small samples are often not useful. These kinds of > >>arguments > >> >> are > >> >> > > the > >> >> > > > ones that led to UIComponent being 13,000 lines in Flex. > >> >> > > > > >> >> > > > >> >> > > I think here we are talking about performance, not about to > >>increase > >> >> > number > >> >> > > of lines of code > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > > >> >> > > > > > >> >> > > > > > >> >> > > > >2018-04-14 2:58 GMT+02:00 Carlos Rovira > >> >><[email protected]>: > >> >> > > > > > >> >> > > > >> Hi Alex, > >> >> > > > >> > >> >> > > > >> just studied you changes and want to ask you a few things: > >> >> > > > >> > >> >> > > > >> 1) Why className and classLists methods must remain > >>unsynced? I > >> >> > think > >> >> > > > >>this > >> >> > > > >> is not necessary and seems to me a bit unnatural since when > >>I > >> >>add > >> >> > > styles > >> >> > > > >> though classList in a element this makes the internal list > >> >> changed, > >> >> > > and > >> >> > > > >>if > >> >> > > > >> I then do "trace(element.className)" it will report the > >>updated > >> >> > > > >>list...so I > >> >> > > > >> think both are synced by default > >> >> > > > > >> >> > > > I proposed a way to have components that want to use classList > >>pay > >> >> for > >> >> > > it. > >> >> > > > If you want to further penalize those components in order to > >> >> maintain > >> >> > > > synchronization of classList and className go ahead as long as > >>it > >> >> > doesn't > >> >> > > > impact org.apache.flex.core.UIBase. Yes, the browser keeps > >> >>className > >> >> > and > >> >> > > > classList in sync, but you are missing that the emphasized, > >> >>primary > >> >> and > >> >> > > > secondary selectors are not in the className list maintained by > >> >> UIBase > >> >> > > and > >> >> > > > there is additional cost to doing so. > >> >> > > > > >> >> > > > > >> >> > > That's because when I refactored the code when you ask me to do > >>so I > >> >> > tried > >> >> > > to make it > >> >> > > className dependent. I think the solution is in JewelUIBase wire > >>all > >> >> > > through classList. > >> >> > > we'll have a tiny performance hit, that's right, but I think a > >>uiset > >> >> with > >> >> > > the purpose of Jewel > >> >> > > (theming - styling - goof looking) is the price that have to > >>pay. a > >> >> > little > >> >> > > less performance than Basic > >> >> > > > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > >> > >> >> > > > >> 2) Now Button has two new methods that must make various > >> >> operations > >> >> > > with > >> >> > > > >> arrays (join, push, splice...), this means in almost all > >>jewel > >> >> > > > >>components > >> >> > > > >> override at least computeFinalClassNames and insert new > >>custom > >> >> > methods > >> >> > > > >>for > >> >> > > > >> add/toggle/remove and each one will make various > >>operations: in > >> >> the > >> >> > > > >>case of > >> >> > > > >> toggle will do a push or splice and then the normal > >>classList > >> >> toggle > >> >> > > > >> operation. > >> >> > > > >> > >> >> > > > It is probably possible to package up the code I added to Jewel > >> >> Button > >> >> > > and > >> >> > > > make it re-usable without inserting a base class for all of > >>Jewel. > >> >> Or > >> >> > is > >> >> > > > absolutely every Jewel component going to need that code? If > >>so, > >> >> then > >> >> > > > maybe a common base class for all of Jewel makes sense. > >> >> > > > > >> >> > > > >> >> > > Yes, all components in Jewel is doing/will do heavy use of style > >> >>API, > >> >> so > >> >> > is > >> >> > > a must > >> >> > > in this set to have that api (while it's not in UIBase and Basic) > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > Also, the code I added to Jewel Button is can be greatly > >> >>simplified > >> >> if > >> >> > > you > >> >> > > > assume folks will not directly set className after adding to > >> >>parent. > >> >> > > > > >> >> > > > >> >> > > No, as MDL, this kind of components are based on heavily add and > >> >> removal > >> >> > of > >> >> > > class selectors > >> >> > > users will pushing buttons, clicking checkboxes, and more, and > >>part > >> >>of > >> >> > that > >> >> > > actions will be to add/remove/toggle > >> >> > > class selectors in one or more components. > >> >> > > > >> >> > > That's what MDL does, that what Jewel does, and that's what any > >> >>actual > >> >> UI > >> >> > > set with focus on visuals will do > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > > >> >> > > > >> 3) we are introducing a new array property per component to > >> >>store > >> >> > what > >> >> > > > >> classList already do > >> >> > > > > >> >> > > > No, the array does not have to have as many elements as the > >> >> classList. > >> >> > > > >> > >> >> > > > >> So for me we are introducing lots of complexity, with more > >>code > >> >> > > splitter > >> >> > > > >> in every class, each one with more operations of array > >> >>operations > >> >> > that > >> >> > > > >> finaly makes the same call I did. And generating complexity > >> >>since > >> >> > > > >>className > >> >> > > > >> should be used by users only at init time and then use the > >> >>rest of > >> >> > > > >> classList apis... > >> >> > > > > >> >> > > > That's PAYG. The classes that need it get the additional > >> >>complexity. > >> >> > > And > >> >> > > > again, if we want to restrict setting classname after init in > >> >>Jewel, > >> >> > > > that's totally fine with me and will simplify the code. > >> >> > > > > >> >> > > > >> >> > > The classes that need get the additional complexity, but at > >>least we > >> >> need > >> >> > > to > >> >> > > proxy all that in JewelUIBase since *all* Jewel components will > >>use > >> >>the > >> >> > > same code > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> > >> >> > > > >> The only difference for me is that you want to avoid the > >> >>classList > >> >> > > > >>initial > >> >> > > > >> add method that in most of the cases will add from 1 or 2 > >> >>classes > >> >> > and > >> >> > > > >>up to > >> >> > > > >> 3-4-5. I think normal components would have 3 on average... > >> >> > > > >> > >> >> > > > >> This related to lots of sites saying "use classList instead > >>of > >> >> > > > >>className" > >> >> > > > >> and frameworks like MDL that are based only on classList , > >>and > >> >>all > >> >> > > > >>jsperfs > >> >> > > > >> (that although are not reflecting our concrete use case and > >> >>use of > >> >> > > > >> classList, I think are completely valid on essence) makes me > >> >>think > >> >> > > about > >> >> > > > >> how we have such different visions. > >> >> > > > >> > >> >> > > > >> So I must to say that as much as I want to see the > >>advantages > >> >>the > >> >> > > > >> approaches do not convince me... > >> >> > > > >> > >> >> > > > >> for me is more simple that all of that. > >> >> > > > >> > >> >> > > > >> 1) I think people have the APIs (className and classList) > >>and > >> >> > can/will > >> >> > > > >>do > >> >> > > > >> what they want, although we say "use className only at init > >> >>time". > >> >> > > > > >> >> > > > Again, we are abstracting the underlying implementation of how > >>to > >> >>set > >> >> > > > class selectors in most Royale component sets. That way, if we > >> >>want > >> >> to > >> >> > > > target other output we have fewer APIs to reproduce. We only > >> >>need to > >> >> > > > reproduce the conceptual APIs. > >> >> > > > >> > >> >> > > > >> 2) I think we should have the most easy way to modify since > >> >> browsers > >> >> > > are > >> >> > > > >> takin care of internal apis performance (or at least I'm > >> >>confident > >> >> > > with > >> >> > > > >> that, like I was confident on flash player performance) > >> >> > > > >> > >> >> > > > >> 3) I don't like to introduce lots of code when maybe the > >>basic > >> >> usage > >> >> > > of > >> >> > > > >> classList can be even more efficient. I give various jsperf > >> >> studies > >> >> > > out > >> >> > > > >> there but both Harbs and you didn't show me anyone that > >>shows > >> >> > > className > >> >> > > > >>as > >> >> > > > >> a better option. > >> >> > > > >> > >> >> > > > >> 4) If we are introducing such complexity, wouldn't be > >>better to > >> >> > remove > >> >> > > > >> completely classList and end that code with the new array > >> >>property > >> >> > and > >> >> > > > >> array operations? I think it will be more performant and > >>will > >> >> remove > >> >> > > > >> complexity. > >> >> > > > >> > >> >> > > > >> 5) If I use that solution for jewel, I should introduce some > >> >> > > > >>intermediate > >> >> > > > >> class between UIBase and a Jewel Component where I can proxy > >> >>all > >> >> > that > >> >> > > > >> methods that are now in button to avoid replicate in all > >>jewel > >> >> > > > >>components. > >> >> > > > >> And by doing that, as I said before, I'll prefer to remove > >>that > >> >> > > > >>complexity > >> >> > > > >> and go for simple classList manipulation since is the same > >>that > >> >> MDL > >> >> > > (to > >> >> > > > >> name a concrete and successful project that renders and > >> >>performs > >> >> > > > >> magnificent) does [1] (I put button example just as an > >>example > >> >> since > >> >> > > > >> there's lots more) > >> >> > > > >> > >> >> > > > >> Sincerily, I'm not convinced with the results exposed here, > >> >>and I > >> >> > was > >> >> > > > >> always thinking that I was not seeing something evident, but > >> >>now > >> >> I'm > >> >> > > > >>even > >> >> > > > >> more convinced that we should use classList without any > >> >>rejection. > >> >> > > Even > >> >> > > > >>for > >> >> > > > >> the use of className in MXML, is ok since I proved you can > >> >> transform > >> >> > > it > >> >> > > > >> without problem getting the string, splitting and > >>introducing > >> >>in > >> >> the > >> >> > > > >> classList, and then opertating with is when needed without > >>any > >> >> > > > >>performance > >> >> > > > >> significant problem. For me is more problematic all the > >>code we > >> >> want > >> >> > > to > >> >> > > > >> introduce to avoid possible performance problems that I and > >> >>many > >> >> > > others > >> >> > > > >> don't see and that main web projects actually don't see and > >>are > >> >> used > >> >> > > all > >> >> > > > >> over the web. We should not be different in something that > >> >>other > >> >> has > >> >> > > > >> already adopted, and if people is using it, is because the > >> >> browsers, > >> >> > > the > >> >> > > > >> standards and all the web wants all people using it, and for > >> >>me is > >> >> > > what > >> >> > > > >> happen with classList. > >> >> > > > >> > >> >> > > > >> in resume. I still don't want to make this discussion > >>longer. I > >> >> > think > >> >> > > we > >> >> > > > >> have different opinions on this particular subject and the > >> >> greatness > >> >> > > of > >> >> > > > >> royale is that it doesn't mind since if you and Harbs are > >> >>betting > >> >> > for > >> >> > > > >> className, we can remain Basic with the initial use (or the > >> >> current > >> >> > > > >>one). > >> >> > > > >> For Jewel, I can bet for the same method MDL uses with > >> >>classList > >> >> and > >> >> > > as > >> >> > > > >>I > >> >> > > > >> must to refactor half of the Jewel components to extend from > >> >> UIBase > >> >> > > > >> directly instead of Basic components counterparts, I can > >>put a > >> >> > > > >>JewelUIBase > >> >> > > > >> piece between that uses classList in the way Jewel need. In > >> >>fact > >> >> > > Jewel, > >> >> > > > >>and > >> >> > > > >> any of the modern UI sets (Semantic, MDL, Bootstrap, ...) > >> >>depends > >> >> > > > >>heavily > >> >> > > > >> in class selector assignation, hence the use of classList > >>as a > >> >> > general > >> >> > > > >> rule. So I think is natural to have this marked > >> >>differentiation, > >> >> > while > >> >> > > > >>in > >> >> > > > >> Basic we should not expect people wants to deal with class > >> >> selectors > >> >> > > in > >> >> > > > >>a > >> >> > > > >> heavy use. > >> >> > > > >> > >> >> > > > >> Maybe I can wrong, but sincerely, if so I can't see where, > >>but > >> >>I > >> >> > > firmly > >> >> > > > >> believe in that, and for me is a clear definition of Jewel > >> >>needs. > >> >> > > > >> > >> >> > > > >> Thoughts? > >> >> > > > > >> >> > > > My proposal lets our MDL and Jewel components use classList > >> >>heavily > >> >> in > >> >> > a > >> >> > > > PAYG way. It can be simplified if we are going to restrict > >> >>setting > >> >> of > >> >> > > > className after adding to the DOM. If you want to see what the > >> >>code > >> >> > > looks > >> >> > > > like with that assumption try making the changes or I will do > >>it. > >> >> > > > > >> >> > > > >> >> > > Alex, I prefer you do this. My only requirements are: > >> >> > > > >> >> > > * Have a JewelUIBase instead of the same code in all components. > >> >> > > * As I said, className will not be untouched after addToParent. > >> >>That's > >> >> a > >> >> > > huge part in MDL and Jewel > >> >> > > both sets add/remove/toggle styles at runtime. So make the > >>changes > >> >> > > modifying that rule in your mind. > >> >> > > * Is critical for me that components extending doesn't have to > >>add > >> >>new > >> >> > > methods that should be abstracted > >> >> > > in JewelUIBase and we can use basic API calls since we are > >>talking > >> >> about > >> >> > > heavy use (or principal use) in > >> >> > > this kind of components set. > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > I think we have proof that className is faster for when we > >>want to > >> >> use > >> >> > it > >> >> > > > at init time. I would like to see if we can create APIs for > >> >> > manipulation > >> >> > > > the classList at runtime that isn't JS-only and asssumes there > >>is > >> >>an > >> >> > > > element so folks can use those APIs at runtime instead being > >> >>tempted > >> >> to > >> >> > > > change className. > >> >> > > > > >> >> > > > >> >> > > I think that's the clue. While Basic makes all the duty before > >>add > >> >>to > >> >> > > parent, MDL and Jewel are constantly > >> >> > > adding, toggling and removing class selectors, that why we must > >>put > >> >>a > >> >> > clear > >> >> > > line between how UIBase works > >> >> > > (mainly like it's now) and how Jewel works (using heavy use of > >> >> classList > >> >> > > since is its nature, and 'll get rid completely of className use > >> >> > internaly) > >> >> > > > >> >> > > I hope we are reaching to something here. Could you change the > >> >> > > implementation taking into account the differences discussed > >>here? > >> >> > > > >> >> > > thanks > >> >> > > > >> >> > > > >> >> > > > >> >> > > > > >> >> > > > My 2 cents, > >> >> > > > -Alex > >> >> > > > >> > >> >> > > > >> > >> >> > > > > > >> >> > > > > > >> >> > > > >-- > >> >> > > > >Carlos Rovira > >> >> > > > >https://na01.safelinks.protection.outlook.com/?url= > >> >> > > > http%3A%2F%2Fabout.me%2 > >> >> > > > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> > > > 7C9fbf7c0d5e994a9acb6008d5 > >> >> > > > >a1ae2520%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> > > > 7C636592691687691520&s > >> >> > > > >data=TR5G34hZMVutbPgcwAzTtNlFR0mQb8 > quhoBewhsOnSc%3D&reserved=0 > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > Carlos Rovira > >> >> > > > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me% > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7C18aef785013e484cfcf108 > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> 7C63659319908588236 > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%3D&reserved=0 > >> >> > > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Carlos Rovira > >> >> > >> >>https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me% > >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7C18aef785013e484cfcf108 > >> >>d5a22445a7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> 7C63659319908588236 > >> >>8&sdata=P5v3BoebWGUeMXAsP5j7rd0y4rcjYPgYGKsAptIcLSQ%3D&reserved=0 > >> >> > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Cf4e0ef1e27e8407606cd08d5 > >a2c057b6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636593869391543673&s > >data=6DkfBSCL%2BBi9EhqUKaAcEbY%2FVLCy2My8bBKS67oohNQ%3D&reserved=0 > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
