dom.element.getAttribute returns unnormalized style properties

[Tobiasz Cudnik]

In some cases IE8 and webkit returns uppercases css properties after getAttribute('style'). To prevent this, place for browser-wide code should be introduced to this method and there the css normalization could be done.

[Garry Yao]

The jQuery chaining coding style is convention compliant at L411, which means line break should not happen before dot.

[Frederico Caldeira Knabben]

There fix impacts on performance. Can you point use to a practical usage of it? Do we have any issue in the editor that is related to it?

[Frederico Caldeira Knabben]

Replying to garry.yao:

The jQuery chaining coding style is convention compliant at L411, which means line break should not happen before dot.

For that case, the coding style helps on readability, so it should be acceptable (this rule is also part of our coding styles).

[Garry Yao]

It's used by L730 of styles plugin, and actually, there's very few places of our codebase is retrieving 'style' attribute, so PF would not be a big problem.

				// The 'class' element value must match (#1318).
				if ( attName == 'class' && element.getAttribute( attName ) != attributes[ attName ] )
					continue;

[Frederico Caldeira Knabben]

Replying to garry.yao:

It's used by L730 of styles plugin

:? Sorry but, L730 is talking about the "class" attribute, and this ticket is related to the "style" attribute.

[Tobiasz Cudnik]

So what's the status of this ticket ? If this fix is unnecessary then TC element.html should be fixed, because it relays on exact results from getAttribute( 'style' ).

[Frederico Caldeira Knabben]

We don't need to fix things simply to make TCs pass. They must be useful, and they must mainly impact on the editor features. Otherwise we instead have TCs to get fixed.

If you see any part of the code that may be impacted by this, then please reopen this ticket with more details.