Hi Om, Alex, thanks for the suggestions but that not work. After sleep and thin about it a little more my understanding is that this is really not a problem of malfunctioning, is simply that we have properties that operates visual changes based on CSS, so the right way is yo apply the instruction *per property*, since is in that case where we need the property to be part of the frozen styles (if toggles to stay or is removed). In the rest of cases this not apply and other kind of use by the customer should allow him to override all if he want...if not he should make the same as we do to let class selector remain.
It's a bit of work, since I must to go through all the components making this change in all the properties that behaves similar, but...don't see other quick way where we could change in one point and affect all in the right way. Thanks! 2017-01-14 7:10 GMT+01:00 Alex Harui <aha...@adobe.com>: > 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 > > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
