typeNames are classSelectors meant to act like TypeSelectors. Like DataGrid or DropDownList. If the customer sets className it shouldn't affect typeNames.
Can the customer also use the classList API? If so, then you may need yet another thing like typeNames like "internalClassNames" which is the list controlled by the component developer and different from the classNames specified by the customer. Or maybe the way you are currently using classNames inside MDL should actually be changing typeNames. My 2 cents, -Alex On 1/13/17, 6:44 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >On Jan 13, 2017 6:30 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > >Hi, > >found an issue with MDL and custom class. > >If you declare a component that has some new custom additional class (lets >call "someClass"), and has some property that modifies the className (in >our case always through classList API), let's say is a button, and this is >the example: > ><mdl:Button colored="true" className="someClass"/> > >the result is the colored className is remove from the list of applied >classes, since is not part of "typeNames" and className implementation >overrides all > >We must say that properties that modifies className in MDL like "ripple", >"colored", etc... are by definition "behaviors" that use CSS (classNames) >to modify some visual aspect of the component or control, so me want don't >be affected if we apply a custom className like "someClass" right? > >So If we set "colored" to true, we want the component maintains the >className that is applied and if we set to false we want to be remove from >classNames, and in no other way, > >so the solution I have is to add a line in *each* property of each >component in MDL just behind the classList.add or classList.toggle >instruction that should be: > >typeNames = element.className; > >So, in this way we make the property part of typeNames while is activated >and if removed, we remove as well from typeNames, giving the control of >that visual aspect only to the setter of the property > >I'll make that change tomorrow (it's very late here), if no body finds any >problem. > >After much testing I don't see other way > >Thanks > > >I ran into a similar problem with FontAwesome. I think this is a good way >to fix this. > >Can we override the classname setter to do > >typeNames = element.className; > > after calling super? > >Then maybe we dont need to do this in the future? > >Thanks, >Om > > > >-- >Carlos Rovira >http://about.me/carlosrovira
