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" <harbs.li...@gmail.com> wrote:
>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 <carlosrov...@apache.org>
>>wrote:
>>
>> 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:
>>
>> element.classList.toggle("primary", value);
>> setClassName(computeFinalClassNames());
>> 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:
>>
>> COMPILE::JS
>> 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
>>set,
>> all can be managed with classList to add/remove since this is native and
>> manages all itself
>>
>> thoughts?
>>
>>
>>
>>
>>
>> 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
>>>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 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 [1] instead of create our own CSSClassList ?
>>>is
>>> well supported in the browsers we are targeting
>>>
>>> Something more "light" :)
>>>
>>> 4.- I know that order in html classes are not relevant, in the
>>>execution.
>>> 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
>>>
>>>
>>> [1]
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3s
>>>chools.com%2FJsref%2Fprop_element_classlist.asp&data=02%7C01%7Caharui%40
>>>adobe.com%7C8ce390a012154f8f2a8a08d588354aa0%7Cfa7b1b5a7b34438794aed2c17
>>>8decee1%7C0%7C0%7C636564684909764090&sdata=OOh4TK5LKB75CGn6U4%2BeaVC%2Fi
>>>V%2BHgGzDj8fqrBB%2BCcs%3D&reserved=0
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8ce390a012154f8f2a8a
>>>08d588354aa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656468490976
>>>4090&sdata=HDNJQ8VZuNS5lhOBU2ZsRrGQAgG5qOxiIQJKkOaTZV4%3D&reserved=0
>>>
>>>
>>
>>
>> --
>> Carlos Rovira
>>
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8ce390a012154f8f2a8a08
>>d588354aa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656468490976409
>>0&sdata=HDNJQ8VZuNS5lhOBU2ZsRrGQAgG5qOxiIQJKkOaTZV4%3D&reserved=0
>
