@tbosch I've moved the normalization of class names to the ProtoViewBuilder so we are not messing with the casing for class names that come from JS (class directive or host properties). IMO we could / should do this with attribute and style names as well, but wanted to check with you first.

Could you PTAL?

This looks good, the only question is which interface we want to provide for people that use the Renderer directly: Before this PR they would always send over camelCase class/attribute/style names and let the renderer decide whether it supports camelCase or not. I.e. directives would be more independent of the renderer than with the PR.

Having said this, we also have issues with the auto camel casing (#3001). So yes, let's do it, but please mark this as a BREAKING CHANGE.

@tbosch I would say that the renderer shouldn't touch CSS class casing (hence this change, that was done to fix #3001). We do those case-converting massaging only to handle [class.my-class]=exp properly.

Agree that it is a breaking change, will mark as one (although I don't think it is going to break peoples code, hopefully)

Should we merge this as is or wait for more changes to come?

@tbosch I've updated the commit message to add info about the breaking change. Let's land this one so it doesn't become bit-rotten - I will take care of attributes and styles in a separate PR.

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.}