2018-03-12 17:14 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> 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.
> Given that, if you've found a way to eliminate the need for CSSClassList,
> that's great.
> IMO, the immutable things from typenames should be last in the list. My
> eye reads left to right and doesn't want to have to skip over stuff that
> will be the same.
*TOTALLY *agree with that. I tend to omit stuff because it looks the same,
so having typedefs at the beginning makes it so like that.
> My 2 cents,
> On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
> >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
> >element.classList.toggle("primary", value);
> >classList has its own toggle function that makes super easy to manage adds
> >and removes, so no need to have a custom function in royale
> >that uses:
> >override protected function computeFinalClassNames():String
> >return super.computeFinalClassNames() + " " + element.classList;
> >I'd like to remove that and change the "setClassName" call to nothing, if
> >we change UIBase to simple use classList
> >My guess is that we can have "typenames" and "classNames" but once all
> >all can be managed with classList to add/remove since this is native and
> >manages all itself
> >2018-03-12 14:01 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>:
> >> Hi,
> >> long thread and very useful read here. Since Jewel is very similar to
> >> in adding/removing classes I want to comment here some things:
> >> 1.- I just changed jewel typenames to the constructor and things works
> >> I could remove the createElement override
> >> 2.- I have into account the use of typenames as something inmutable (as
> >> part of definition of a component) and classNames as things that are
> >>put by
> >> developer, or change at runtime due to some user operation
> >> Then:
> >> 3.- Why not use classList  instead of create our own CSSClassList ?
> >> well supported in the browsers we are targeting
> >> Something more "light" :)
> >> 4.- I know that order in html classes are not relevant, in the
> >> And most of people here doesn't mind if typenames are before or after
> >> classNames. So hope this doesn't make any problem to anyone here:
> >> Can I change the code to put typeNames before classNames in
> >> computeFinalClassNames? I think this not affects anyone since is a small
> >> change and helps me to get organized classnames and identify things. I
> >> think is better to see in final html typeNames first then classNames so
> >> "inheritance" (to call it some way), could be easy detected by the eye
> >> Thanks
> >> Carlos
> >> 
> >> --
> >> Carlos Rovira
> >Carlos Rovira