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%2Fc01ebc2cc946570006d8f5cea607182e16eaf0
>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%2Fc01ebc2cc946570006d8f5cea607182e16eaf
>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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365524
>>77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyWyGL2HD7sl5ALI%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365524
>>77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyWyGL2HD7sl5ALI%3D&reserved
>>=0>*
>
