My thinking is that there are a set of defaults in typeNames that match
fake type selectors and should almost never be changed at runtime.  What
scenario made you want to change typeNames outside the component?

Then there is another set of class names that you specify outside the
component.  There should already be a classname setter for MXML.
Specifying a space-delimited set of strings seems more common than using
classList Array and Arrays are more painful to write in MXML.  HTMLElement
already has a classList Array API.  I just think folks are more used to
strings.

So given a "Fixed" set and a "variable" set, you need to concatenate the
two sets.  We could split the sets and use array APIs, but that might
actually be slower.

And then for MDL, there is a third set which is the set of attributes like
"shadow" which is why you would override the computation.

My 2 cents,
-Alex

On 2/26/18, 11:44 AM, "Harbs" <[email protected]> wrote:

>I think my main point was that we wouldn’t need computeFinalClassNames()
>which would be overridden in subclasses.
>
>If there’s simple a _classList:Array which would have something like:
>protected function applyClassNames():void
>{
>       element.className = className ? className : “” + “ “ + _classList.join(“
>“).trim();
>}
>
>Which could replace the setClassName() method.
>
>The rest was simply how to go about building the _classList.
>
>We’re probably more or less saying the same thing.
>
>> On Feb 26, 2018, at 9:35 PM, Piotr Zarzycki <[email protected]>
>>wrote:
>> 
>> Harbs,
>> 
>> You simply suggesting to have several functions instead of one which
>> computes things?
>> 
>> 
>> 
>> On Mon, Feb 26, 2018, 20:21 Harbs <[email protected]> wrote:
>> 
>>> Yes. Very thorough explanation. Thanks.
>>> 
>>> It seems to me like there should be functions for addClassName() and
>>> removeClassName() which would add and remove the classNames from a
>>>list.
>>> When the className is computed, the list should be concatenated to
>>> classNames (and possibly typeNames — although we might not need
>>>typeNames
>>> if there’s a general list). We might also want a clearClassNames()
>>>method
>>> to allow removal of “default” classNames for classes which have such a
>>>need.
>>> 
>>> I do think we also need a className setter so classNames could be
>>> specified in mxml, but we might be able to do away with typeNames. That
>>> might simplify things.
>>> 
>>> My $0.02,
>>> Harbs
>>> 
>>> 
>>>> On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki
>>>><[email protected]>
>>> wrote:
>>>> 
>>>> Hi Alex,
>>>> 
>>>> Great reading and explanation. My first thought was to have something
>>> which
>>>> computes className together, but currently it is needed for MDL only
>>>> almost. I went with this additional function Utility.
>>>> I think there won't be too much time when we will need such ability
>>>>like
>>>> switching and adding shadow css classes etc.
>>>> 
>>>> If other also think about such function I would be happy to implement
>>>>it.
>>>> It will really get rid of a lot of dump code and even some
>>>>workarounds in
>>>> MDL. Live would be much easier.
>>>> 
>>>> +1 to have such functions.
>>>> 
>>>> All of that should land on the Wiki or somewhere in the documentation.
>>>> 
>>>> Waiting for thoughts from others.
>>>> 
>>>> Thanks, Piotr
>>>> 
>>>> 2018-02-26 18:50 GMT+01:00 Alex Harui <[email protected]>:
>>>> 
>>>>> Here's my view of this problem space.  This is my opinion, not
>>>>>marching
>>>>> orders.  Everything is up for discussion.  This is what the current
>>>>>code
>>>>> is trying to do, though.  Also, important note:  The order of names
>>>>>in
>>> the
>>>>> HTMLElement.className does not matter.  CSS style precedence is
>>> determined
>>>>> by the order of declarations in the CSS file.  OK, lots of reading
>>> ahead:
>>>>> 
>>>>> HTML and JavaScript do not really have a first-class notion of a
>>>>>Class
>>>>> like we do in ActionScript.  IOW, no such thing as true subclassing,
>>>>> especially in a way that supports Reflection APIs like
>>>>> flash.utils.getQualifiedClassName.  So, there is a fixed set of
>>>>>types in
>>>>> the browser, such as Button, Input, Div (which, by the way, are
>>>>> implemented as instances of HTMLButtonElement, HTMLInputElement,
>>>>> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed
>>>>>set
>>> of
>>>>> Type Selectors in CSS.  You can't really make up new Type selectors,
>>> AFAIK.
>>>>> 
>>>>> A CSS Class selector is the way that you can distinguish one set of,
>>> say,
>>>>> HTMLDivElements, from another set of HTMLDivElements.  Since you
>>>>>can't
>>>>> make subclasses and new type selectors, you set the HTML class or
>>>>> JavaScript HTMLElement.className/classList on individual HTML
>>>>>elements
>>> and
>>>>> declare them to be of class "BigButton" or whatever.  It is their
>>>>>form
>>> of
>>>>> subclassing.
>>>>> 
>>>>> In Flex/Flash/SWF/ActionScript, folks are used to being able to make
>>>>>a
>>>>> subclass of Button called BigButton.  And add a Type Selector for it
>>>>>in
>>> a
>>>>> CSS file as "BigButton {}" and not ".BigButton {}".  And the
>>>>>Flex/Royale
>>>>> compilers know that if you don't have a BigButton in the final
>>>>>output,
>>> it
>>>>> doesn't output the CSS for BigButton, making your app smaller.  If
>>>>>you
>>> use
>>>>> class selectors and ".BigButton" the Flex/Royale compilers do not
>>>>>search
>>>>> the code to see if some code sets className to "BigButton" and it
>>>>>really
>>>>> probably never can since you might have code that does:
>>>>> 
>>>>> var kinds:Array ["Big", "Little", "Puny"];
>>>>> Foo.className = kinds[i] + "Button";
>>>>> 
>>>>> So, IMO, in Royale we want to leverage ActionScript types and
>>>>>pretend to
>>>>> extend the Type Selectors subsystem in CSS.  I think we can't
>>>>>actually
>>>>> truly do it since the "*" selector will be masked by our fake Type
>>>>> Selectors, but it should be good enough, and it allows the compiler
>>>>>to
>>>>> prune CSS that isn't used.
>>>>> 
>>>>> So, I think we want a convention where each class sets the "typename"
>>>>> property to itself if it wants to support a fake Type Selector.  I
>>>>> considered having the compiler auto-generate it but that isn't really
>>> PAYG
>>>>> for small lightweight subclasses that won't ever have a fake Type
>>> Selector.
>>>>> 
>>>>> Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors
>>> from
>>>>> ancestor classes apply to subclasses.  We did that because it was a
>>>>>pain
>>>>> to have to copy all of Label's Type Selector into a MultilineLabel
>>>>>Type
>>>>> Selector and that duplication made the CSS file bigger.  So we want
>>>>>to
>>>>> mimic that on the JS side as well.
>>>>> 
>>>>> So to make all of that happen, any new "type" of component should set
>>>>> typeName to itself somewhere.  So Button and DataGrid should just
>>>>>have
>>>>> typeNames="Button" or typeNames="DataGrid".  But subclasses of these
>>> types
>>>>> can append themselves, so MultilineLabel does: typenames+="
>>>>> MultilineLabel".  That gets appended to Label's typeNames so the
>>>>> MultilineLabel's final typenames is "Label MultilineLabel".
>>>>> 
>>>>> Recently, I proposed that the best place to allow appending of
>>>>>typeNames
>>>>> is in the constructor.  It makes appending easier (after the call to
>>>>> super()) and eliminates the need for simple subclasses to have to
>>>>>add a
>>>>> createElement call just to override typenames.
>>>>> 
>>>>> And that's why I think typeNames should never be set from "outside"
>>>>>the
>>>>> class and maybe we should make it protected.  It is there to
>>>>>represent a
>>>>> new Type Name that folks can use to style EVERY instance of that
>>>>>type in
>>>>> their app without having to make up a new className and try to to
>>>>>miss
>>>>> setting that className on some MXML/HTML tag.  And similarly the code
>>> in a
>>>>> class should never set className on itself, because className should
>>>>>be
>>>>> reserved to be used by consumers of that component to further
>>> distinguish
>>>>> sets of instances of that component from other instances.
>>>>> 
>>>>> And that's why, when we build complex views, we might make an
>>>>>instance
>>> of
>>>>> a TextInput in ComboBoxView and assign it a className.  We want to
>>>>> distinguish that TextInput from other TextInputs in the users app or
>>>>>in
>>>>> other views.  So we assign the TextInput in ComboBox a useful
>>>>>className
>>>>> like ComboBoxTextInput.  We could take the time to actually subclass
>>>>> TextInput and make a ComboBoxTextInput extends TextInput and then
>>>>>make a
>>>>> new type selector available in the CSS.  That would be cleaner, but
>>>>>it
>>> has
>>>>> a couple of disadvantages:  I think a subclass is more code than a
>>>>>CSS
>>>>> class selector, and it clutters the documentation.  I did play around
>>> with
>>>>> some convention to allow us to prune class selectors by somehow
>>>>> associating them with a type, but I'm not sure there's a great answer
>>>>> there.  But if you look in HelloWorld.css you'll see unused class
>>>>> selectors in there.
>>>>> 
>>>>> There is no API to allow the consumer of the ComboBox to set
>>>>>classNames
>>> on
>>>>> the inner TextInput, so we document (or imply by its being in the
>>>>>CSS)
>>>>> that there is a class called ComboBoxTextInput.  We do this in order
>>>>>to
>>>>> not need advanced selector support on the SWF side.  Otherwise, we
>>>>>would
>>>>> probably build out shadow DOMs and use descendant selectors.
>>>>> 
>>>>> Then, as if that wasn't complex enough (and you are still reading
>>>>>this),
>>>>> className is used in the browser as a convenient way to set buckets
>>>>>of
>>>>> styles on an element.  So lots of code in real web pages are
>>>>>dynamically
>>>>> changing the className/classList to add "shadow" or "emphasized" or
>>> things
>>>>> like that.  IMO, that's because there is no other way to do that in
>>>>> HTML/JS/CSS.  But because AS classes are not transformable at runtime
>>> (you
>>>>> can't turn an instance of Label into MultilineLabel, you have to
>>>>> instantiate a MultilineLabel and replace the Label instance), and
>>> because
>>>>> we have an extensible type selector system, we further want to allow
>>>>> className to be used to add buckets of style attributes dynamically
>>>>>at
>>>>> runtime.
>>>>> 
>>>>> Yes, attributes like "shadow" could modify the typename instead of
>>>>> className.  In the end it does not matter as long as all strings end
>>>>>up
>>> in
>>>>> the HTMLElement.classList, and as I said at the top, the order does
>>>>>not
>>>>> matter.  The main goal is to list them all.  And, I suppose, to make
>>>>> changing at runtime easy.  I personally would lean away from having a
>>>>> shadow attribute change typenames because mentally for me, you can't
>>>>> change an AS class at runtime.  So, that's why I think className is
>>>>> better, and I would imagine that folks who don't use Royale would be
>>>>> setting className to include "shadow" and know that their other code
>>> can't
>>>>> just set className.
>>>>> 
>>>>> Or maybe we just need to put the code that computes the final
>>>>> className/classList in an overridable method so that components that
>>>>>do
>>>>> have attributes that affect the classList can have all of that
>>>>>computed
>>>>> on-demand.  So in UIBase, where we currently set className, we could
>>> have
>>>>> 
>>>>> element.className = computeFinalClassNames();
>>>>> 
>>>>> Where:
>>>>> 
>>>>> public function computeFinalClassNames():String
>>>>> {
>>>>> return this.className + " " + this.typeNames;
>>>>> }
>>>>> 
>>>>> And in MDL, or any component with attributes:
>>>>> 
>>>>> private var _shadow:String;
>>>>> public function get shadow():Boolean
>>>>> {
>>>>> return _shadow != null;
>>>>> }
>>>>> public function set shadow(value:Boolean):void
>>>>> {
>>>>> _shadow = value ? "mdl-shadow" : null;
>>>>> }
>>>>> override public function computeFinalClassNames():String
>>>>> {
>>>>> return super.computeFinalClassNames() + " " + _shadow;
>>>>> }
>>>>> 
>>>>> HTH,
>>>>> -Alex
>>>>> 
>>>>> On 2/26/18, 5:14 AM, "Harbs" <[email protected]> wrote:
>>>>> 
>>>>>> Yes. The changes did break things.
>>>>>> 
>>>>>> I committed an alternate way of fixing things.
>>>>>> 
>>>>>> There is a discussion on Github on how strictly we avoid changing
>>>>>> typeNames:
>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fgithub.co
>>>>>> m%2Fapache%2Froyale-asjs%2Fcommit%2Fc01ebc2cc946570006d8f5cea607
>>>>> 182e16eaf0
>>>>>> fe%23r27788371&data=02%7C01%7Caharui%40adobe.com%
>>>>> 7Cb8a821250e814e93f88308d
>>>>>> 57d1af51c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636552477096186200&
>>>>>> sdata=%2BwCkmLjlAHyDACH294G4bEutIbK%2FDLsAkkSIhUc3cqA%3D&reserved=0
>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fgithub.c
>>>>>> om%2Fapache%2Froyale-asjs%2Fcommit%2Fc01ebc2cc946570006d8f5cea607
>>>>> 182e16eaf
>>>>>> 0fe%23r27788371&data=02%7C01%7Caharui%40adobe.com%
>>>>> 7Cb8a821250e814e93f88308
>>>>>> d57d1af51c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>> 7C636552477096186200
>>>>>> 
>>>>>>&sdata=%2BwCkmLjlAHyDACH294G4bEutIbK%2FDLsAkkSIhUc3cqA%3D&reserved=0>
>>>>>> 
>>>>>> Thoughts?
>>>>>> Harbs
>>>>>> 
>>>>>>> On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki <
>>> [email protected]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I just pushed changes to MDL. With couple of exceptions all
>>>>>>>typeNames
>>>>>>> landed to constructor. Thanks to that changes some components
>>>>>>>started
>>> to
>>>>>>> work better. I'm wondering whether I do not break anything.
>>>>>>> 
>>>>>>> Harbs,
>>>>>>> 
>>>>>>> If you are using something more than MDL Dialog in your
>>>>>>>application it
>>>>>>> would be great to get feedback whether I didn't break for you
>>> anything.
>>>>>>> :)
>>>>>>> 
>>>>>>> Thanks, Piotr
>>>>>>> 
>>>>>>> 2018-02-24 17:53 GMT+01:00 Alex Harui <[email protected]>:
>>>>>>> 
>>>>>>>> Sorry, I wasn't clear.  The function itself can go in Basic or
>>>>>>>>better
>>>>>>>> yet,
>>>>>>>> Core, since I don't think it has any dependencies and can be use
>>>>>>>> anywhere.
>>>>>>>> I was just saying that I would prefer if none of the Basic
>>>>>>>>components
>>>>>>>> or
>>>>>>>> UIBase used your new function.  You should be able to write a
>>>>>>>>Royale
>>>>>>>> app
>>>>>>>> with Basic and not bring in that function. Not that it isn't
>>>>>>>>useful,
>>>>>>>> but
>>>>>>>> it isn't truly "basic" given that Basic components are supposed to
>>> have
>>>>>>>> typeNames.
>>>>>>>> 
>>>>>>>> My 2 cents,
>>>>>>>> -Alex
>>>>>>>> 
>>>>>>>> On 2/24/18, 8:17 AM, "Piotr Zarzycki" <[email protected]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I was going to put it somewhere in the Basic, but I can leave it
>>>>>>>>>in
>>>>>>>>> the
>>>>>>>>> MDL. The className can be undefined in the case where you wanted
>>>>>>>>>to
>>>>>>>>> add
>>>>>>>>> something to such "undefinded" string you will got:
>>>>>>>>> 
>>>>>>>>> "undefined myClass". - I probably cannot escape from that...
>>>>>>>>> 
>>>>>>>>> Maybe I'm missing some way.
>>>>>>>>> 
>>>>>>>>> 2018-02-24 17:00 GMT+01:00 Alex Harui <[email protected]>:
>>>>>>>>> 
>>>>>>>>>> Looks ok to me.  Seems like you don't need COMPILE::JS.  It
>>>>>>>>>>should
>>>>>>>>>> work
>>>>>>>>>> on
>>>>>>>>>> all platforms.  We can have lots of utility functions in
>>>>>>>>>> org.apache.royale.utils.
>>>>>>>>>> 
>>>>>>>>>> In terms of optimization (size/performance) a function like
>>>>>>>>>>this is
>>>>>>>>>> potentially overkill for the Basic set.  It is fine for MDL
>>>>>>>>>>since
>>> MDL
>>>>>>>>>> has
>>>>>>>>>> already picked up additional overhead in order to style
>>> "everything".
>>>>>>>>>> But
>>>>>>>>>> I subscribe to what I learned from a wise programmer many years
>>> ago:
>>>>>>>>>> If
>>>>>>>>>> you truly understand the problem space, you can often find a
>>> smaller,
>>>>>>>>>> faster solution.  Like I said, if you know that there "must" be
>>>>>>>>>>at
>>>>>>>>>> least
>>>>>>>>>> one string from typenames as the last string, the replacement is
>>> much
>>>>>>>>>> easier.  All of the extra null checking and trimming in your
>>> version
>>>>>>>>>> is
>>>>>>>>>> not really needed for the specific problem of replacing from a
>>>>>>>>>>set
>>> of
>>>>>>>>>> string you know about that don't need trimming.
>>>>>>>>>> 
>>>>>>>>>> My 2 cents,
>>>>>>>>>> -Alex
>>>>>>>>>> 
>>>>>>>>>> On 2/24/18, 4:50 AM, "Piotr Zarzycki"
>>>>>>>>>><[email protected]>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Alex,
>>>>>>>>>>> 
>>>>>>>>>>> I used your suggestion, added some additional things and I end
>>>>>>>>>>>up
>>>>>>>>>>> with
>>>>>>>>>>> following utility [1]. Usage will looks like that: [2]. Do you
>>>>>>>>>>> think it
>>>>>>>>>>> could be part of the framework ? It's working nicely with MDL.
>>>>>>>>>>> 
>>>>>>>>>>> [1]
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>> https%3A%2F%2Fpaste.apa
>>>>>>>>>>> che.org%2FtsaF&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>> 7C91e633a78bea4fc4c89908d
>>>>>>>>>>> 57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>>> 7C636550734524475642&
>>>>>>>>>>> 
>>>>>>>>>>>sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D&reserved=
>>>>>>>>>>>0
>>>>>>>>>>> [2]
>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>> https%3A%2F%2Fpaste.apa
>>>>>>>>>>> che.org%2Fxbfb&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>> 7C91e633a78bea4fc4c89908d
>>>>>>>>>>> 57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>>> 7C636550734524475642&
>>>>>>>>>>> 
>>> sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D&reserved=0
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, Piotr
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 2018-02-23 21:31 GMT+01:00 Alex Harui
>>>>>>>>>>><[email protected]>:
>>>>>>>>>>> 
>>>>>>>>>>>> Well, whether you like it or not, the wrapper is mapping a
>>>>>>>>>>>> space-delimited
>>>>>>>>>>>> list to the array so if you manipulate the array you have to
>>>>>>>>>>>> back-calculate the string.  IMO, in HTML, the "class" property
>>> is a
>>>>>>>>>>>> string
>>>>>>>>>>>> and people are used to entering a space-delimited list.
>>>>>>>>>>>>That's
>>> why
>>>>>>>>>> we
>>>>>>>>>>>> have a className property on UIBase.  So that folks have
>>> something
>>>>>>>>>>>> similar
>>>>>>>>>>>> in MXML.
>>>>>>>>>>>> 
>>>>>>>>>>>> So, unfortunately, your problem can't be as simple as
>>> manipulating
>>>>>>>>>>>> classList via its APIs.  Also consider that the classList API
>>> might
>>>>>>>>>>>> itself
>>>>>>>>>>>> be doing a string search in the array.
>>>>>>>>>>>> 
>>>>>>>>>>>> If you have the string "Piotr Alex Harbs" and want to replace
>>> Alex
>>>>>>>>>> with
>>>>>>>>>>>> Peter and you know that Alex can't be the last item because
>>>>>>>>>>>>the
>>>>>>>>>>>> last
>>>>>>>>>>>> item
>>>>>>>>>>>> is the typeName which is never null or "", then a simple
>>>>>>>>>> String.replace
>>>>>>>>>>>> call should work.
>>>>>>>>>>>> 
>>>>>>>>>>>> className = className.replace(oldName + " ", newName + " ");
>>>>>>>>>>>> 
>>>>>>>>>>>> HTH,
>>>>>>>>>>>> -Alex
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/23/18, 12:21 PM, "Piotr Zarzycki" <
>>> [email protected]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> It's just swapping. If I have following code [1] - it is
>>>>>>>>>>>>>easier
>>> to
>>>>>>>>>>>>> manipulate classList than className which is simple string.
>>>>>>>>>>>>>What
>>>>>>>>>>>> utility
>>>>>>>>>>>>> could look like ? It would be manipulating strings, which is
>>> less
>>>>>>>>>>>>> convenient.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>> https%3A%2F%2Fpaste.apa
>>>>>>>>>>>>> che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>> 7C061f7278ca3748bfaee408d
>>>>>>>>>>>>> 57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>>>>> 7C636550141162759398&
>>>>>>>>>>>>> 
>>>>>>>>>>>>>sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D&reserved=
>>>>>>>>>>>>>0
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2018-02-23 21:11 GMT+01:00 Alex Harui
>>>>>>>>>>>>><[email protected]
>>>> :
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Just compiler.  No need for asjs changes at this time I
>>>>>>>>>>>>>>think.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I'm still unclear on why you need to manipulate classList
>>>>>>>>>> directly.
>>>>>>>>>>>> Is
>>>>>>>>>>>>>> there some code that is in the JS from Material that
>>> manipulates
>>>>>>>>>>>>>> classList?  Or are you just trying to swap out a name on the
>>>>>>>>>>>> classList?
>>>>>>>>>>>>>> If the latter, why not just create some utility function
>>>>>>>>>>>>>>that
>>>>>>>>>>>> operates
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> className and not the underlying element?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -Aleex
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2/23/18, 11:58 AM, "Piotr Zarzycki" <
>>>>> [email protected]
>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> You did merge vivid compiler changes or also changes from
>>>>>>>>>>>>>>>asjs
>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> As for my work on MDL. I ended up with something like that
>>> [1].
>>>>>>>>>> The
>>>>>>>>>>>>>>> question now how to propagate that code ? This is code for
>>>>>>>>>>>>>>>the
>>>>>>>>>>>>>> component
>>>>>>>>>>>>>>> which manipulates classList. Should I create some parent
>>> class ?
>>>>>>>>>>>>>> General/
>>>>>>>>>>>>>>> for MDL only, or Bead which will be included into such
>>> classes ?
>>>>>>>>>>>>>>> Theoretically bead could listen for initComplete.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>> https%3A%2F%2Fpaste.apa
>>>>>>>>>>>>>>> che.org%2F1dy2&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>>>> 7C8e313e7d7f9d4608759f08d
>>>>>>>>>>>>>>> 57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>>>>>>>>>>>>>> 7C636550127203173382&
>>>>>>>>>>>>>>> sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%
>>>>>>>> 3D&reserved=0
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Piotr
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 2018-02-23 20:53 GMT+01:00 Alex Harui
>>> <[email protected]
>>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> I think I have Maven using the basic.css appropriately.
>>> There
>>>>>>>>>> is
>>>>>>>>>>>> no
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>> to default to including a SWC in Maven and then not use it
>>> in a
>>>>>>>>>>>> child
>>>>>>>>>>>>>>>> project, so all example poms that aren't MDL need to
>>>>>>>>>>>>>>>>bring in
>>>>>>>>>> the
>>>>>>>>>>>>>>>> BasicTheme.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Also, I had to merge the compiler change from vivid-ui-set
>>>>>>>>>> branch
>>>>>>>>>>>> to
>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> the theme SWC to work in Maven.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Alex
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 2/23/18, 8:04 AM, "Alex Harui"
>>>>>>>>>>>>>>>><[email protected]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> MDL does not want the basic.css theme.  That is why we
>>>>>>>>>>>>>>>>>are
>>>>>>>>>> moving
>>>>>>>>>>>>>>>> styles
>>>>>>>>>>>>>>>>> from Basic:swc's defaults.css to themes/basic.css.  I see
>>> that
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> Maven
>>>>>>>>>>>>>>>>> plugin doesn't allow specification of a theme, so that's
>>>>>>>>>> another
>>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> can do it if nobody wants to take that on.  So, yes, move
>>> the
>>>>>>>>>>>> Button
>>>>>>>>>>>>>>>>> selectors from defaults.css to basic.css if that helps,
>>>>>>>>>>>>>>>>>but
>>> I
>>>>>>>>>>>> will
>>>>>>>>>>>>>> say
>>>>>>>>>>>>>>>>> that I didn't notice those styles taking effect in my
>>>>>>>>>>>>>>>>>local
>>>>>>>>>>>> version
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> MDLTabsExample and assumed that mdl had overridden those
>>>>>>>>>> styles.
>>>>>>>>>>>> As
>>>>>>>>>>>>>>>>> Carlos said, in the end we want basic.css to be compliant
>>> CSS
>>>>>>>>>> so
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> move anything with ClassReference as the value without
>>>>>>>>>> discussing
>>>>>>>>>>>>>>>> first.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> TypeNames should be set after the call to super().  Look
>>>>>>>>>>>>>>>>>at
>>>>>>>>>> Label
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> MultilineLabel.  They are working fine for me.  They are
>>> being
>>>>>>>>>>>> used
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> RoyaleStore.  There might have been issues before
>>>>>>>>>>>>>>>>>yesterday
>>>>>>>>>>>> because
>>>>>>>>>>>>>>>> lots
>>>>>>>>>>>>>>>>> of Basic components were setting ClassName, but I went
>>>>>>>>>>>>>>>>>and
>>>>>>>>>>>> cleaned
>>>>>>>>>>>>>>>> that up
>>>>>>>>>>>>>>>>> although I could have missed a few.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> In complex Views, you have two choices:  Make a subclass
>>>>>>>>>>>>>>>>>or
>>>>>>>>>>>> assign
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> className.  We should try to set set typeNames.  In fact,
>>>>>>>>>> maybe
>>>>>>>>>>>> we
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>> make typeNames protected.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> So, for ComboBoxView, the current code is setting a
>>>>>>>>>>>>>>>>>custom
>>>>>>>>>>>> className
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>> is valid.  Users can then style it further by adding a
>>>>>>>>>>>>>>>> .ComboBoxTextInput
>>>>>>>>>>>>>>>>> selector to their CSS. However, class selectors are not
>>>>>>>>>> pruned by
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> compiler.  So in other cases, we have created a real
>>> subclass
>>>>>>>>>> (in
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> case "ComboBoxTextInput extends TextInput) and then the
>>>>>>>>>>>>>>>>>CSS
>>>>>>>>>> would
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> the "." in front so it would look like a type selector
>>>>>>>>>>>>>>>>>and
>>> the
>>>>>>>>>>>>>> compiler
>>>>>>>>>>>>>>>>> would prune it from apps that don't use a ComboBox.  Not
>>> sure
>>>>>>>>>>>> which
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> better/faster,
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Regarding Peter's point about Labels in Menus.  The issue
>>>>>>>>>> isn't
>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> Flash
>>>>>>>>>>>>>>>>> can't handle it.  It is that our SimpleCSSValuesImpl
>>>>>>>>>>>>>>>>>lookup
>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>>>>> descendant and other advanced selectors.  The techniques
>>>>>>>>>>>>>>>>>for
>>>>>>>>>>>>>>>> ComboBoxView
>>>>>>>>>>>>>>>>> is how we avoid requiring a more complex lookup on the
>>>>>>>>>>>>>>>>>SWF
>>>>>>>>>> side.
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>> menu
>>>>>>>>>>>>>>>>> code should not be setting typeNames on other things,
>>>>>>>>>>>>>>>>>only
>>>>>>>>>>>> itself.
>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>>>>> not sure if on the JS side, avoiding descendant selectors
>>>>>>>>>> speeds
>>>>>>>>>>>>>>>> things up
>>>>>>>>>>>>>>>>> in the browser or not.  We could create an IValuesImpl
>>>>>>>>>>>>>>>>>with
>>>>>>>>>>>>>> descendant
>>>>>>>>>>>>>>>>> selector support on the SWF side and probably will
>>>>>>>>>>>>>>>>>someday.
>>>>>>>>>>>>>> Volunteers
>>>>>>>>>>>>>>>>> are welcome to take that on.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Of course, I could be wrong...
>>>>>>>>>>>>>>>>> -Alex
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 2/23/18, 7:37 AM, "Piotr Zarzycki"
>>>>>>>>>> <[email protected]
>>>>>>>>>>> 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> A bit more on point 1. and let's take for the example
>>> simple
>>>>>>>>>>>>>> Button.
>>>>>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>> have some styles for Button in Basic.css. MDL Button
>>> extends
>>>>>>>>>>>>>>>> TextButton -
>>>>>>>>>>>>>>>>>> some styles naturally has been added from default.css.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> If I create theme I should achieve that my theme classes
>>> will
>>>>>>>>>>>>>> override
>>>>>>>>>>>>>>>>>> default.css Button styles and I should be good yes ?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Am I understand it correctly ?
>>>>>>>>>>>>>>>>>> Thanks, Piotr
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 2018-02-23 16:32 GMT+01:00 Piotr Zarzycki
>>>>>>>>>>>>>> <[email protected]
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> typeNames = element.className;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thoughts ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>>>> https%3A%2F%2Fpaste.a
>>>>>>>>>>>>>>>>>>> p
>>>>>>>>>>>>>>>>>>> ache.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>>>>>> 7Ca44c142f0ddc455c70bf
>>>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>>>> 8d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>>>> cee1%7C0%7C0%7C636549970664822
>>>>>>>>>>>>>>>>>>> 4
>>>>>>>>>>>>>>>>>>> 53&sdata=1sSgdfBy%2BAv%2FsFIYwVFFHvVlhtJ3w3TW%
>>>>>>>>>>>>>>>> 2FiDEyPVYGmo%3D&reserved=0
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Piotr
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki
>>>>>>>>>>>>>>>> <[email protected]>:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>> 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" <
>>> [email protected]
>>>>>>>>> 
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I¹ll help.
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Feb 23, 2018, at 10:50 AM, Alex Harui
>>>>>>>>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>>>>>>>>>> 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.pa
>>>>>>>>>>>>>>>>>>> t
>>>>>>>>>>>>>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%
>>> 40adobe.com
>>>>>>>>>>>>>>>> %7Ca44c142f0dd
>>>>>>>>>>>>>>>>>>> c
>>>>>>>>>>>>>>>>>>> 455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>>>> cee1%7C0%7C0%7C636549
>>>>>>>>>>>>>>>>>>> 9
>>>>>>>>>>>>>>>>>>> 70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>>>>>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserve
>>>>>>>>>>>>>>>>>>> d
>>>>>>>>>>>>>>>>>>> =0
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>>>> https%3A%2F%2Fwww.pa
>>>>>>>>>>>>>>>>>>> t
>>>>>>>>>>>>>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%
>>> 40adobe.com
>>>>>>>>>>>>>>>> %7Ca44c142f0dd
>>>>>>>>>>>>>>>>>>> c
>>>>>>>>>>>>>>>>>>> 455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>>>> cee1%7C0%7C0%7C636549
>>>>>>>>>>>>>>>>>>> 9
>>>>>>>>>>>>>>>>>>> 70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>>>>>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserve
>>>>>>>>>>>>>>>>>>> d
>>>>>>>>>>>>>>>>>>> =0>*
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Piotr Zarzycki
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Patreon:
>>>>>>>>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>>>> https%3A%2F%2Fwww.pat
>>>>>>>>>>>>>>>>>> r
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>>>>>>>>>>>>>>>> %7Ca44c142f0ddc4
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> 5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>>>> cee1%7C0%7C0%7C636549970
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>>>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserved=
>>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>>>> https%3A%2F%2Fwww.pat
>>>>>>>>>>>>>>>>>> r
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>>>>>>>>>>>>>>>> %7Ca44c142f0ddc4
>>>>>>>>>>>>>>>>>> 5
>>>>>>>>>>>>>>>>>> 5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>>>> cee1%7C0%7C0%7C636549970
>>>>>>>>>>>>>>>>>> 6
>>>>>>>>>>>>>>>>>> 64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>>>>>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserved=0>
>>>>>>>>>>>>>>>>>> *
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Piotr Zarzycki
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Patreon:
>>>>>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>>>> 7C8e313e7d7f9d46
>>>>>>>>>>>>>>> 08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>> cee1%7C0%7C0%7C6365501272
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5ay
>>>>>>>>>>>> lHwldhGDulDOE%3D&reserved=0
>>>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>>>> 7C8e313e7d7f9d46
>>>>>>>>>>>>>>> 08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>>>> cee1%7C0%7C0%7C6365501272
>>>>>>>>>>>>>>> 03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5ay
>>>>>>>>>>>>>> lHwldhGDulDOE%3D&reserved=0>*
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Piotr Zarzycki
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Patreon:
>>>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>> 7C061f7278ca3748
>>>>>>>>>>>>> bfaee408d57afb14a9%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>> cee1%7C0%7C0%7C6365501411
>>>>>>>>>>>> 
>>>>>>>>>>>>> 62759398&sdata=rpVtPRF2nJb03vSLEIQiK0K3uzGMs6
>>>>>>>>>> 6vbTZtOxsVXKs%3D&reserved=0
>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>>>> 7C061f7278ca3748
>>>>>>>>>>>>> bfaee408d57afb14a9%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>>>> cee1%7C0%7C0%7C6365501411
>>>>>>>>>>>>> 62759398&sdata=rpVtPRF2nJb03vSLEIQiK0K3uzGMs6
>>>>>>>>>>>> 6vbTZtOxsVXKs%3D&reserved=0>*
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> 
>>>>>>>>>>> Piotr Zarzycki
>>>>>>>>>>> 
>>>>>>>>>>> Patreon:
>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>> 7C91e633a78bea4f
>>>>>>>>>>> c4c89908d57b853bdf%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>> cee1%7C0%7C0%7C6365507345
>>>>>>>>>>> 24475642&sdata=dG08yDIsBZVQ1XNIJIjCCqFgQwgmNQ
>>>>>>>>>> HJQSQ7ds5O%2F38%3D&reserved=0
>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>>>> 7C91e633a78bea4f
>>>>>>>>>>> c4c89908d57b853bdf%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>>>> cee1%7C0%7C0%7C6365507345
>>>>>>>>>>> 24475642&sdata=dG08yDIsBZVQ1XNIJIjCCqFgQwgmNQ
>>>>>>>>>> HJQSQ7ds5O%2F38%3D&reserved=0
>>>>>>>>>>>> *
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> 
>>>>>>>>> Piotr Zarzycki
>>>>>>>>> 
>>>>>>>>> Patreon:
>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>> 7C0c4af859745d4f
>>>>>>>>> 1e55fb08d57ba22da3%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>> cee1%7C0%7C0%7C6365508588
>>>>>>>>> 
>>>>>>>>>36682085&sdata=vcTmV4sMSk3ZfhGCKd4mX6%2ByAb8saVYLysyZnCX%2FV8M%3D&
>>>>>>>> reserved
>>>>>>>>> =0
>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>>>>> https%3A%2F%2Fwww.patr
>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
>>>>>>>> 7C0c4af859745d4f
>>>>>>>>> 1e55fb08d57ba22da3%7Cfa7b1b5a7b34438794aed2c178de
>>>>>>>> cee1%7C0%7C0%7C6365508588
>>>>>>>>> 
>>>>>>>>>36682085&sdata=vcTmV4sMSk3ZfhGCKd4mX6%2ByAb8saVYLysyZnCX%2FV8M%3D&
>>>>>>>> reserved
>>>>>>>>> =0>*
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Piotr Zarzycki
>>>>>>> 
>>>>>>> Patreon:
>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fwww.pat
>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>>>>> %7Cb8a821250e81
>>>>>>> 4e93f88308d57d1af51c%7Cfa7b1b5a7b34438794aed2c178de
>>>>> cee1%7C0%7C0%7C6365524
>>>>>>> 77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyW
>>>>> yGL2HD7sl5ALI%3D&reserved
>>>>>>> =0
>>>>>>> 
>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>>>>> https%3A%2F%2Fwww.pat
>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>>>>> %7Cb8a821250e81
>>>>>>> 4e93f88308d57d1af51c%7Cfa7b1b5a7b34438794aed2c178de
>>>>> cee1%7C0%7C0%7C6365524
>>>>>>> 77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyW
>>>>> yGL2HD7sl5ALI%3D&reserved
>>>>>>> =0>*
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Piotr Zarzycki
>>>> 
>>>> Patreon: 
>>>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
>>>>atreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb882e40d
>>>>29e54251b55508d57d517307%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>>36552711206488528&sdata=p8smFyRPQlUdwJsVnwXdtNMMrdvm1R1Aewe5sg5Wd88%3D&
>>>>reserved=0
>>>> 
>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.p
>>>>atreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cb882e40d
>>>>29e54251b55508d57d517307%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>>>>36552711206488528&sdata=p8smFyRPQlUdwJsVnwXdtNMMrdvm1R1Aewe5sg5Wd88%3D&
>>>>reserved=0>*
>>> 
>>> 
>>> 
>
>

Reply via email to