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.apa > >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com > %7C55b6f3b3cb1b40e46bf108d > >57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549967805810829& > >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%7C6365499678 > >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%7C6365499678 > >05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved=0 > >>* > >
