@mhevery this is a follow up PR addressing your comment in PR #3498.

I've decided to not add binding to class since it would create strange corner cases, ex.:
<div class="{{exp}}"> <-- throws since there is no class property vs.
<div class="{{exp}}" ng-class="otherExp"> <-- oh, now it works, but creates many corner cases since both expressions can change.

Instead I'm injecting @Attribute('class') initialClasses: string so interpolation on class behaves consistently, regardless of the presence of the NgClass directive.

But we could map class to className property just like we map innerHTML so <div class="{{exp}}"> should work regardless of ng-class

Ah, ok, this could work. I will add some more tests tommorow to see if we are not bumping into non-obvious corner cases.

thanks!

On Mon, Aug 10, 2015 at 2:10 PM, Pawel Kozlowski notifications@github.com
wrote:

Ah, ok, this could work. I will add some more tests tommorow to see if we
are not bumping into non-obvious corner cases.

—
Reply to this email directly or view it on GitHub
#3557 (comment).

@mhevery so, I went over some use cases and I can see one problem with mapping class -> className. As soon as we do this binding to [class] "takes over" classes on a given DOM element and can potentially "destroy" CSS classes set by other attributes / binding / directives. Few examples:

• <div [class.foo]="showFoo" [class]="exp"> - here any change to exp will wipe out foo
• <div class="foo" with-host> where with-host has host: {"[class]": "expr"} - here any change to exp will wipe out foo (currently host attribute class has special treatement)
• <div [class]="exp" im-touching-classlist> where im-touching-classlist is a directive that manipulates classList - here any change to exp will wipe out changes done by im-touching-classlist

I must admit that currently I don't have great idea on how to handle all those corner cases :-/ Given this I would like to re-discuss introducing class -> className mapping as it might be opening a can of worms :-(

//cc: @vsavkin

@pkozlowski-opensource All of your points are valid and I share the same concerns. These issues exists whether or not we map class-name to class since you could just write <div [class.foo]="showFoo" [class]="exp" [class-name]="exp" class="foo {{exp}}" class-name="foo {{exp}}" ...> and get in the same issue regardless of wether we map class to className.

So I think the discussion of

• (a) how do we merge the different ways we have for expressing class bindings in an unsurprising ways with
• (b) weather or not we should map class to className

are really independent. Ignoring (a) do you see a down side of doing (b)? I think (b) is desirable.

@mhevery I think I've implemented both binding to [class] (aliased to className) and did all the changes to NgClass to properly clean up / take changes to [class] into account. It seem to work "correctly" for a surprising number of cases :-)

PTAL

Putting into .35 milestone as the associated issue is in .35

Can you answer my two questions? Otherwise LGTM.

Merging PR #3557 on behalf of @mhevery to branch presubmit-mhevery-pr-3557.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}