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?


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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654996780581082
> >>>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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654996
> >>>78
> >>
> >>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved
> >>>=0
> >> ><
> >>
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >> %7C55b6f3b3cb1b40
> >>
> >>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654996
> >>>78
> >>
> >>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved
> >>>=0
> >> >>*
> >>
> >>
>
>

Reply via email to