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,
-Alex
On 2/23/18, 10:21 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>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 was
>starting from a clean setup,
>but the way MDL css operates, make me use typenames in the current way.
>
>Don't know if that can be changed or not, maybe if some things changed in
>royale new versions, that could happen,
>but I think maybe that's not the case, and could not have solution due to
>how MDL is done.
>
>Anyway, you know what I think about MDL library future. We should not have
>to invest many time with it, since I expect vivid to
>take its place. But anyone here is free to invest the time where he/she
>prefers.
>
>Thanks
>
>
>
>2018-02-23 18:36 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>:
>
>> 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 <aha...@adobe.com.invalid> wrote:
>>
>> >
>> >
>> > On 2/23/18, 8:50 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com>
>>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
>> > >classList is being wipped out and filled by className.
>> > >
>> > >That is ok?
>> >
>> > I don't know if that is "ok", but that is expected because you are
>> > manipulating element.classList directly but element.classList is
>>mapped
>> to
>> > className + typeNames.
>> >
>> > Here's a rough analogy: If you have an ArrayList wrap and track an
>>Array
>> > and then directly manipulate the Array, you can't guarantee that the
>> > ArrayList will still track the array.
>> >
>> > UIBase wraps an HTMLElement. The APIs on UIBase are supposed to be
>> > proxied into the element. If you manipulate the element directly, you
>> > have to sync up the wrapper's properties.
>> >
>> > Either work with the UIBase APIs to get the classList you want, or
>>after
>> > manipulating classList, update classNames as needed so the next
>>setting
>> of
>> > className or the addToParent call does not disturb your manipulated
>> > classList.
>> >
>> > -Alex
>> > >
>> > >On Fri, Feb 23, 2018, 17:26 Alex Harui <aha...@adobe.com.invalid>
>> wrote:
>> > >
>> > >> 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 in Flex are used to. Then the rest of the
>> names
>> > >>in
>> > >> classList map to className that custom Views or the user can set.
>> > >>
>> > >> So if your code wants to manipulate classList directly, it might be
>> > >>easier
>> > >> to manipulate className, or else, re-populate classname after
>> > >>manipulating
>> > >> classList by updating className with everything other than what is
>> > >> specified in typeNames.
>> > >>
>> > >> If you are saying that the shadow code is trying to get rid of
>> whatever
>> > >> was specified in typeNames, I suppose that's "ok" but that would
>>be a
>> > >>new
>> > >> pattern. It is more likely that if typeNames was set to Card that
>> there
>> > >> should be few if any properties in the Card selector that shadow
>> should
>> > >> affect. There really shouldn't be a reason to kick the names in
>> > >>typenames
>> > >> out of the classList.
>> > >>
>> > >> Of course, I could be wrong...
>> > >> -Alex
>> > >>
>> > >> On 2/23/18, 8:16 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com>
>> > wrote:
>> > >>
>> > >> >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 <aha...@adobe.com.invalid>
>> > >>wrote:
>> > >> >
>> > >> >>
>> > >> >>
>> > >> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki"
>><piotrzarzyck...@gmail.com>
>> > >> 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 build - it didn't help.
>> > >> >> >2) If I cannot setup typeNames and classNames inside my
>>component,
>> > >>how
>> > >> >>can
>> > >> >> >I achieve switching some UI parts of the component ? In MDL it
>>is
>> > >>quite
>> > >> >> >common that if I would like to change component I'm adding to
>>it
>> css
>> > >> >> >class.
>> > >> >> >[1] - This is the example. If I remove line it doesn't work.
>>There
>> > >>are
>> > >> >> >several places in MDL where we are doing such things. It is
>>common
>> > >>in
>> > >> >>JS
>> > >> >> >world doing such things.
>> > >> >>
>> > >> >> That's because the JS world doesn't have strong typing. They
>>can
>> > >> >> transform a TextInput into a TextArea and not care. I suspect
>>that
>> > >>if
>> > >> >>you
>> > >> >> set shadow at runtime it won't have an effect because typeNames
>>is
>> > >>not
>> > >> >> re-evaluated after adddedToParent. The className property is
>> > >>suppose to
>> > >> >> combine with typeNames and result in the element.classList by
>> setting
>> > >> >>(in
>> > >> >> addedToParent) the element.className to the space-separated
>>list of
>> > >> >> everything in typeNames and className. So, if MDL code
>>manipulates
>> > >> >> element.classList, I think it should be echoing those changes
>>into
>> > >>the
>> > >> >> className property, not typeNames. typeNames should be
>>considered
>> > >> >> "write-once" or "write during constructor" and not changed
>> > >>afterwards.
>> > >> >>It
>> > >> >> is the set of things that go in the element.classList that
>>should
>> be
>> > >> >> immutable. As immutable as declaring a true subclass.
>>className
>> is
>> > >>for
>> > >> >> the things that go in element.classList that can change at
>>runtime.
>> > >> >>
>> > >> >> My 2 cents,
>> > >> >> -Alex
>> > >> >>
>> > >> >> >
>> > >> >> >typeNames = element.className;
>> > >> >> >
>> > >> >> >Thoughts ?
>> > >> >> >
>> > >> >> >[1]
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.ap
>> > >> >>a
>> > >> >> >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com
>> > >> >> %7C55b6f3b3cb1b40e46bf108d
>> > >> >>
>> > >>
>> > >>>>>57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549967805810
>> > >>>>>82
>> > >> >>>9&
>> > >> >> >sdata=i9EZFYDPNqo4lakPPe1lB0NDfajXmqhMnDX7bxiBecc%3D&reserved=0
>> > >> >> >
>> > >> >> >Thanks,
>> > >> >> >Piotr
>> > >> >> >
>> > >> >> >
>> > >> >> >2018-02-23 15:55 GMT+01:00 Piotr Zarzycki
>> > >><piotrzarzyck...@gmail.com>:
>> > >> >> >
>> > >> >> >> 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, 15:13 Peter Ent
>><p...@adobe.com.invalid>
>> > >> wrote:
>> > >> >> >>
>> > >> >> >>> 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 have this: A Menu with a label inside of it.
>> > >>People
>> > >> >> >>>will
>> > >> >> >>> want to change the background color of the menu and the
>>color
>> of
>> > >>the
>> > >> >> >>> label's text. If I were doing this in plain HTML/JS/CSS, I
>> would
>> > >> >>set a
>> > >> >> >>> selector: .Menu .Label { color: blue; } but that's not
>> > >>supported in
>> > >> >> >>>the
>> > >> >> >>> Flash Player. So when I set up the typeName for the label
>> inside
>> > >>of
>> > >> >>the
>> > >> >> >>> Menu should I set it to: Menu_Label or MenuLabel or
>>Menu-Label?
>> > >>And
>> > >> >>is
>> > >> >> >>> using "." in a selector name a good idea? I would think the
>>CSS
>> > >> >> >>>processor
>> > >> >> >>> in the browser would be confused between ".x.y" and ".x .y"
>> which
>> > >> >>can
>> > >> >> >>>also
>> > >> >> >>> be written as ".x.y". Basically, we should have a consist
>> naming
>> > >> >> >>>pattern
>> > >> >> >>> here.
>> > >> >> >>>
>> > >> >> >>> ‹peter
>> > >> >> >>>
>> > >> >> >>> On 2/23/18, 4:09 AM, "Gabe Harbs" <harbs.li...@gmail.com>
>> wrote:
>> > >> >> >>>
>> > >> >> >>> >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-html-ComboBox_Button";
>> > >> >> >>> >
>> > >> >> >>> >Input and button are both external to the view class, but
>>are
>> > >> >>managed
>> > >> >> >>>by
>> > >> >> >>> >the view class. On the other hand, there is a chance that
>>the
>> > >>user
>> > >> >> >>>might
>> > >> >> >>> >wan to style them. I¹m not sure whether className or
>>typeNames
>> > >>is
>> > >> >>more
>> > >> >> >>> >appropriate hereŠ
>> > >> >> >>> >
>> > >> >> >>> >Harbs
>> > >> >> >>> >
>> > >> >> >>> >> On Feb 23, 2018, at 11:03 AM, Gabe Harbs
>> > >><harbs.li...@gmail.com>
>> > >> >> >>> wrote:
>> > >> >> >>> >>
>> > >> >> >>> >> I¹ll help.
>> > >> >> >>> >>
>> > >> >> >>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui
>> > >> >><aha...@adobe.com.INVALID
>> > >> >> >
>> > >> >> >>> >>>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 from outside the class.
>> There
>> > >> >>are a
>> > >> >> >>>few
>> > >> >> >>> >>> classes in Basic and lots of classes in MDL that should
>>be
>> > >> >> >>>upgraded to
>> > >> >> >>> >>>set
>> > >> >> >>> >>> typeNames in the constructor. Subclasses can append to
>>the
>> > >>base
>> > >> >> >>> >>>class's
>> > >> >> >>> >>> typeNames
>> > >> >> >>> >>>
>> > >> >> >>> >>> className is the opposite. It should never be set
>>inside
>> the
>> > >> >> >>> >>>component's
>> > >> >> >>> >>> class. It is for users of that component to set styles
>>on
>> > >>the
>> > >> >> >>> >>>component.
>> > >> >> >>> >>>
>> > >> >> >>> >>> Can we get a volunteer to clean this up?
>> > >> >> >>> >>>
>> > >> >> >>> >>> Thanks,
>> > >> >> >>> >>> -Alex
>> > >> >> >>> >>>
>> > >> >> >>> >>
>> > >> >> >>> >
>> > >> >> >>>
>> > >> >> >>>
>> > >> >> >
>> > >> >> >
>> > >> >> >--
>> > >> >> >
>> > >> >> >Piotr Zarzycki
>> > >> >> >
>> > >> >> >Patreon:
>> > >> >> >*
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.patr
>> > >> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> > >> >> %7C55b6f3b3cb1b40
>> > >> >>
>> > >>
>> > >>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549
>> > >>>>>96
>> > >> >>>78
>> > >> >>
>> > >>
>> > >>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q
>> %3D&reserv
>> > >>>>>ed
>> > >> >>>=0
>> > >> >> ><
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.patr
>> > >> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> > >> >> %7C55b6f3b3cb1b40
>> > >> >>
>> > >>
>> > >>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549
>> > >>>>>96
>> > >> >>>78
>> > >> >>
>> > >>
>> > >>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q
>> %3D&reserv
>> > >>>>>ed
>> > >> >>>=0
>> > >> >> >>*
>> > >> >>
>> > >> >>
>> > >>
>> > >>
>> >
>> >
>>
>
>
>
>--
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cf09a55618e334334731e08d5
>7aea628e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550069456141742&s
>data=dJ5lw%2Bh9g2E%2Bi8CTXbVYeon6R7s5bZVGsb79lzfkl9g%3D&reserved=0
