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" <aha...@adobe.com.INVALID> 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" <piotrzarzyck...@gmail.com> 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 <piotrzarzyck...@gmail.com>:
>>
>>> 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%7Cfa7b1b5a7b34438794aed2c178decee1%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 <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.pa
>>>t
>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca44c142f0dd
>>>c
>>>455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549
>>>9
>>>70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJRFFjSWC8LaxmWI%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549
>>>9
>>>70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJRFFjSWC8LaxmWI%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549970
>>6
>>64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJRFFjSWC8LaxmWI%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549970
>>6
>>64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJRFFjSWC8LaxmWI%3D&reserved=0>
>>*
>

Reply via email to