Thank you for the report.  I'm able to reproduce on 58.0.3010.0 windows.  An alternative HTML file is attached with the same repro.  Right click inspect on "footest" and click on the ".video .tile" in the rule name in the styles sidebar pane.

DevTools is matching the selected CSS rule and displaying it normally without whitespace.  Clicking on the selector reveals an input field with the actual carriage return, which is actually present in the source.

If many users have CSS minification steps that lead to line breaks in rules, perhaps we can replace line breaks with spaces before setting the input field text.

Deleted: doubleClass.html 138 bytes

doubleClass.html 138 bytes View Download

I inspect your .html, and you wrote a carriage return. In my case, my .css doesn't have (attachment). I also checked the space between the 2 classes, and it's a normal space caracter (not a tab or special caracter.

Deleted: screenshot.png 12.2 KB

	screenshot.png 12.2 KB View Download

Ok, I targeted the bug. I have a minifyer that create for multi classes a carriage return. Your last example (doubleClass.html) target the real bug at the end. My question is: how the chrome inspector should react? Because it displays it correctly, should not change when select, right?

luoe@: Could you please update the thread with respect to the above comment and let us know the actual and expected result of it, if it can be triaged from TE side.

Since DevTools doesn't know whether the CSS file is minified or not, I think it's reasonable for it to paste out the actual match with a line break.  (It doesn't appear broken before a click because we don't have white-space: pre).

I think the better way to go about this is to use CSS sourcemaps.  lushnikov@, would sourcemaps lead to the original style selectors in SSP?

Ok, understandable. Fixing the minifying output is the proper solution. thing that we can hardly debug now ;)

Sure, sourcemaps should point correctly. Closing this since devtools are behaving properly.