ok, I think I'll be subclassing in my branch and see where I get, in this
way the Piotr and Harbs can continue with things as they expect to.
In the other way, maybe it could seem that I'm worried to much about how
html looks, and maybe things like the layouts can wait, but I think is
I think people are more uncomfortable with the proposal to use
element.classList than any issue about order. It is hard for me to truly
understand without seeing code so I think you should push it to your
I agree with Piotr that we can't make the users (app dev) use
since Piotr and Harbs seems not to be very comfortable with the change, I
can subclass UIBase for Jewel and make that changes there. I don't want to
conflict in such central point of the framework,
Will it be ok for all of us?
2018-03-12 18:56 GMT+01:00 Alex Harui
I think is what I just pointed in the response to a Harbs emails. I think
once people set typenames and classnames, if we operate all through
element.classList, that solves all conflicts, since all classes are in a
managed list, if people wants to add or remove they can through the list.
I was reding from the begging and saw when the CSSClassList came.
I think Harbs solution is ok, the only problem I see is that in MDL, and
Jewel, we need to have functions per class that manages
add/remove of classes and override of compute function. That's what I don't
like of current
2018-03-12 17:14 GMT+01:00 Alex Harui :
> If HTMLElement.classList is exposed to the user (the app developer) then
> they can remove any of the items that were added from the typenames.
> There is no way to enforce immutability of the typenames. We can choose
> to give
Well, it isn't fair if someone writes to element.className, but we control
what happens when someone writes to UIBase.className. I just want it to
be as simple as possible and PAYG.
On 3/12/18, 9:21 AM, "Harbs" wrote:
>I’m pretty sure your solution will only work
I’m pretty sure your solution will only work if the user doesn’t set a
className of their own. Setting className overwrites the entire classList.
> On Mar 12, 2018, at 5:45 PM, Carlos Rovira wrote:
> I made some simplification that works ok in Jewel:
If HTMLElement.classList is exposed to the user (the app developer) then
they can remove any of the items that were added from the typenames.
There is no way to enforce immutability of the typenames. We can choose
to give up on that and require that app developers be careful, but I'd
I made some simplification that works ok in Jewel:
1.- remove CSSClassList and use element.classList since is native and
supported in all browsers we target, this simplifies code, and removes
classes from core.
2.- I still need to use some additional code that can be simplified. I'm
long thread and very useful read here. Since Jewel is very similar to MDL
in adding/removing classes I want to comment here some things:
1.- I just changed jewel typenames to the constructor and things works ok,
I could remove the createElement override
2.- I have into account the use of
Harbs please post code snippets so we can understand what you are
referring to. I'm not too concerned about how much code is baked into
MDL, but I'm more interested in the notion that there are just-in-case
patterns that are somehow more optimal than on-demand patterns. I'm
thinking there are
> On Mar 5, 2018, at 2:18 AM, Alex Harui wrote:
> Why are there so many empty strings and why do the cost so much? Should
> we reference a single global empty string?
If you mean in XML, I eliminated initializing *everything* in XML unless needed
and I saw a
Why are there so many empty strings and why do the cost so much? Should
we reference a single global empty string?
I don't think I follow why just-in-case code is less than not-just-in-case
code. I don't think I've ever really seen that. Can you provide more
On 3/4/18, 5:24 AM,
> On Mar 2, 2018, at 6:46 PM, Alex Harui wrote:
> Again, the principles of PAYG are that there is as little Just-in-case
> code as possible. AIUI, every MDL user will be downloading and
> initializing the ClassList prototype just-in-case. This is not true of
Again, the principles of PAYG are that there is as little Just-in-case
code as possible. AIUI, every MDL user will be downloading and
initializing the ClassList prototype just-in-case. This is not true of
Strings. It isn't just the cost of instantiation. There are download and
Thanks for such a good explanation. I think I will go with your class.
2018-03-02 10:36 GMT+01:00 Harbs :
> I do agree that this is pretty low on the list of priorities. I did not
> have a head to work on anything “serious” and the class lists was a nice
I do agree that this is pretty low on the list of priorities. I did not have a
head to work on anything “serious” and the class lists was a nice distraction
for me. I’m certainly fine with however Piotr handles this. I would like to
point out a few things:
1. Object instantiation is pretty
Maybe let's do this in that way. I could stay with your solution where I'm
using that array class, but we could move it to the MDL module. Since this
problem is specific right now to that. Maybe the computation won't be so
large like it is in case of MDL, where you have 5-6 properties and you need
Very nice, but IMO, this is over-engineering. We are talking about a
space-delimited list where some portion of it is considered "fixed"
another portion is user-settable and another portion comes from other
attributes. Some generic StringUtils or ListUtils might be more PAYG,
especially if they
What do you think of the CSSClassList class I just committed?
I *think* that makes the pattern more recognizable and probably is less heavy
if more than one class can be used.
> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki wrote:
> Harbs, Alex,
> I just
I just pushed implementation of computeFinalClassNames to
branch feature/type_names_class_name_issue124. You can review
implementation in this commit  and example of usage in Card and Button.
I have tested with Harbs example  and with Card by changing orders. It's
Let me play with implementation of that function. It seems to me that will
be much cleaner than current solution.
If user actually wanted to do anythin with className - let the overriding
On Wed, Feb 28, 2018, 21:51 Alex Harui wrote:
> On 2/28/18, 12:27 PM,
On 2/28/18, 12:27 PM, "Harbs" wrote:
>OK. I think that will work for DML components, but what if there’s a bead
>which needs to add class names? What would be the “right” way to do that?
>A bead cannot override the function on the strand.
Do we have beads that manipulate
OK. I think that will work for DML components, but what if there’s a bead which
needs to add class names? What would be the “right” way to do that? A bead
cannot override the function on the strand.
> On Feb 28, 2018, at 10:17 PM, Alex Harui wrote:
> I think you
I think you are missing that the element.className is set to
computeFinalClassNames. So the user is welcome to manipulate the
UIBase.className however they see fit. They can assign it a whole new
space-delimited list if they want. But what gets set on element.className
is computed from
The problem which sparked this whole issue is like this:
1. We have some components (i.e. in MDL) which add “pieces” to the class names
(such as “fab”, “raised”, “colored”, etc.
2. The client might subsequently set the className to something else.
3. When the component sets the “pieces” first
On 2/28/18, 10:44 AM, "Harbs" wrote:
>If it’s not public, I don’t see how a utility method could call it though.
I didn't think the utility methods like addClassName/removeClassName would
need to alter computeFinalClassNames().
AIUI, for most UIBase subclasses, the final
If it’s not public, I don’t see how a utility method could call it though.
> On Feb 28, 2018, at 8:21 PM, Alex Harui wrote:
> On 2/28/18, 9:50 AM, "Piotr Zarzycki" > wrote:
>> Ok Understand, but
On 2/28/18, 9:50 AM, "Piotr Zarzycki" wrote:
>Ok Understand, but do you agree that computeFinalClassNames - is
>which is in the UIBase ?
Yes, and probably protected instead of public. The one in UIBase just
appends typenames to className. It gets
Ok Understand, but do you agree that computeFinalClassNames - is something
which is in the UIBase ?
2018-02-28 18:47 GMT+01:00 Alex Harui :
> I think that in the shadow setter, it would change _shadow and call
> On 2/28/18,
I think that in the shadow setter, it would change _shadow and call
On 2/28/18, 9:33 AM, "Piotr Zarzycki" wrote:
>So we are getting back to the idea where you proposed to have function
>which computes everything.
So we are getting back to the idea where you proposed to have function
which computes everything.
override public function computeFinalClassNames():String
return super.computeFinalClassNames() + " " + _shadow;
Where does that function should be placed ? Does that function should be
I think am I not communicating the principles effectively.
First, IMO, addClassName and removeClassName should not be in UIBase.
Lots of apps can be written without needing these methods. I think they
can be written as utility functions.
Second, the computation of the final
Sorry about that. Let me show you code and I recorded GIF with problem
*Code in UIBase which I have implemented:*
addClassName and removeClassName .
addedToParent what is happen with internal field which I have added 
*Code for Testing*  - I'm adding first
I could not understand this explanation. Might be better to show actual
code. For example in #3, there is a cssClass variable that I don't know
about. Also you mention at the bottom setting something as empty, but I'm
not sure what that is.
However, IMO, this code should be in
Here is how I'm thinking to resolve that issue. I would take Harb's
proposition and add to UIBase addClassName() and removeClassName(). Next I
would add internal field _internalClassName:String.
1) Will check if provided class name exits in _className and in
I think I have analyzed everything and have some implementation
proposition. I will try to provide it later today.
2018-02-27 13:35 GMT+01:00 Harbs :
> ExpandableSearch broke too.
> > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki
ExpandableSearch broke too.
> On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki wrote:
> 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. :)
I know what you mean Harbs, but it may not be so easy to achieve. classList
and className at some point are wiped out.
When I was working on changes in MDL it happened in addedToParent.
The end of all process to save things was always concatenating.
I think having couple of functions is a good
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
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 : “” + “ “ +
You simply suggesting to have several functions instead of one which
On Mon, Feb 26, 2018, 20:21 Harbs wrote:
> Yes. Very thorough explanation. Thanks.
> It seems to me like there should be functions for addClassName() and
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
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
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
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:
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.
If you are using something more than MDL Dialog in your application it
would be great
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
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.
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
In terms of optimization (size/performance) a function like this is
potentially overkill for the Basic set. It is fine for MDL since MDL
I used your suggestion, added some additional things and I end up with
following utility . Usage will looks like that: . Do you think it
could be part of the framework ? It's working nicely with MDL.
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
It's just swapping. If I have following code  - 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
2018-02-23 21:11 GMT+01:00 Alex Harui
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
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 . The
question now how to propagate that code ? This is code for the component
which manipulates classList. Should I create some parent class ? General/
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
Also, I had to merge the compiler change from vivid-ui-set branch to get
Ok, maybe I had problems in the past due to what you say. Hope this changes
remove that problems too
2018-02-23 19:29 GMT+01:00 Alex Harui :
> Hi Carlos,
> I think we've separated out basic.css and stopped misusing "className" in
> the Basic components so
I think we've separated out basic.css and stopped misusing "className" in
the Basic components so typeNames should work as expected in subclasses
like MDL and possibly even Vivid.
Piotr might as well finish up MDL so we can see if there might be issues
that affect Vivid.
My 2 cents,
can't read all the thread right now, but I want to share a word of caution
When I started that library, I had to fight a lot with typenames and
Alex hopefully remember several emails about this topic.
I ended with the current solution. As I excluded basic css, I think I
Understand! :) Now I can agree with you that typeNames could be protected.
Let me play farther with MDL and see where I end up.
On Fri, Feb 23, 2018, 18:28 Alex Harui wrote:
> On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote:
On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote:
>Just the opposite. The typeNames get rid of everything what is setup in
>But className is being add typeNames. This is what is happen:
Just the opposite. The typeNames get rid of everything what is setup in the
But className is being add typeNames. This is what is happen:
className += typeNames
classList is being wipped out and filled by className.
TypeNames is supposed to override what is in classList. ClassList should
contain two sets of names. Immutable ones that come from typeNames like
TextInput or Card that map to the component that is pointed to by
element.royale_wrapper. That allows us to "extend" the set of
TypeSelectors as folks
I'm not sure what you put in the theme for MDL. But it shouldn't matter
whether it is in a theme or in MDL's defaults.css since nobody in
MDLTabsExample is trying to override it. MDL only needs its own theme if
someone will want to use the structural aspects of the MDL components (the
Reading what you are saying here regarding classList and className w have a
bug. typeNames shouldn't override what is inside classList, but this is
what has happened in addedToParent.
Am I understand you correctly?
On Fri, Feb 23, 2018, 17:11 Alex Harui wrote:
On 2/23/18, 7:32 AM, "Piotr Zarzycki" wrote:
>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
I have added separate theme for MDL - didn't touch basic.css at all. I did
add it as an
this doesn't change anything in Basic module.
On Fri, Feb 23, 2018, 17:05 Piotr Zarzycki
> I think I see where the issue may be, but not sure if it is an
I think I see where the issue may be, but not sure if it is an issue. I
have created separate project where I have only MDL Card component. I'm
setting property shardow = "2" . This property is being called, but I
don't have line with typeNames - it's deleted.
What is happen:
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
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
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
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.
On Fri, Feb 23,
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.
There’s some edge cases which seem problematic. One example:
ComboBoxBiew has the following:
input = new TextInput();
input.className = "ComboBoxTextInput";
button = new TextButton();
> 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 set in
I will look into the MDL.
2018-02-23 9:50 GMT+01:00 Alex Harui :
> 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
Mail list logo