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

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...

On 2/23/18, 7:37 AM, "Piotr Zarzycki" <> 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 <>:
>> Alex,
>> I have started to work on MDL and move all typeNames from createElement
>> 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
>> 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
>> [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] 
>> Thanks,
>> Piotr
>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki <>:
>>> 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
>>> 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 <> wrote:
>>>> I have been guilty of this and have been using typeNames now. I've
>>>> 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
>>>> 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
>>>> Flash Player. So when I set up the typeName for the label inside of
>>>> 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
>>>> 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
>>>> here.
>>>> ‹peter
>>>> On 2/23/18, 4:09 AM, "Gabe Harbs" <> 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
>>>> >wan to style them. I¹m not sure whether className or typeNames is
>>>> >appropriate hereŠ
>>>> >
>>>> >Harbs
>>>> >
>>>> >> On Feb 23, 2018, at 11:03 AM, Gabe Harbs <>
>>>> wrote:
>>>> >>
>>>> >> I¹ll help.
>>>> >>
>>>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui
>>>> >>>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
>>>> >>>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
>>>> 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: 
>Piotr Zarzycki

Reply via email to