Ok, maybe I had problems in the past due to what you say. Hope this changes
remove that problems too

thanks

2018-02-23 19:29 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:

> 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=i9EZFYDPNqo4lakPPe1lB0NDfajXmq
> hMnDX7bxiBecc%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
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to