royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: TypeNames vs ClassName
Date Fri, 23 Feb 2018 16:16:20 GMT
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 <aharui@adobe.com.invalid> wrote:

>
>
> On 2/23/18, 7:32 AM, "Piotr Zarzycki" <piotrzarzycki21@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 <piotrzarzycki21@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 <pent@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.lists@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.lists@gmail.com>
> >>> wrote:
> >>> >>
> >>> >> I¹ll help.
> >>> >>
> >>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui <aharui@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
> >>*
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message