I verified that this CL causes lot of styling breakages across various WebUIs. See attachments. Some of these reproduce only with optimize_webui=false GN flag, and some with both true/false.

Even though the original CL seems to be fixing something to be according to spec, it seems that several places across Chrome code rely on the existing CSS specificity. We should fix those first, before relanding the Blink change (will send a revert shortly).

Deleted: upper_case_buttons.png 17.6 KB

	upper_case_buttons.png 17.6 KB View Download

Deleted: pink_buttons.png 215 KB

	pink_buttons.png 215 KB View Download

Sure, I'll take a look. I need to rebuild though so I might not be able to get to it properly until tomorrow.

This changed some selectors' specificity, could you point me to where the CSS of those pages live?

A revert for now sounds fine though, specially given it's a simple change. Thanks.

Also, sorry for the breakage :(

If you could avoid reverting the WPT tests it'd be great, if it's possible.

 - The mispositioned ripples exist on various elements under [1] (cr-radio-button, cr-toggle, cr-checkbox).
- The button styling exists under 2 and 3 (they are both applied at the same time)
- The pink FAB (floating action buttons) styling is under [4] and [5].

Note that optimize_webui=true vs false changes the final CSS, so that explains why some bugs only occur in one of the two configurations.

Also note, that these are just the breakages identified with a very short audit. Most likely there are more.

[1] https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/ 
[2] https://cs.chromium.org/chromium/src/ui/webui/resources/cr_elements/paper_button_style_css.html
[3] https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/paper-button/paper-button.html
[4] https://cs.chromium.org/chromium/src/chrome/browser/resources/pdf/elements/viewer-zoom-toolbar/viewer-zoom-button.html
[5] https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/paper-fab/paper-fab.html

> If you could avoid reverting the WPT tests it'd be great, if it's possible.

I just clicked "revert" via gerrit, which will revert the entire CL. Do you want me to cancel that, and let you send a more specific revert?

Never mind, the revert already landing. Sorry for not seeing your comment earlier.

Yeah, is alright, I can submit the tests separately :)

Revert landed so marking this as fixed, https://chromium-review.googlesource.com/c/chromium/src/+/1250054.

Let's stay in touch before when a new CL is attempted to ensure all breakages have been identified (might take a while to fix though).

Thanks!

This would be a problem with Polymer in general, right?

> This would be a problem with Polymer in general, right?

It is possible that some of the Polymer UI elements [1] are relying on the previous behavior as well. If I had to guess, both Chromium and third_party/polymer code might need to be tweaked.


[1] https://cs.chromium.org/chromium/src/third_party/polymer/v1_0/components-chromium/

Hmm, are those elements broken in WebKit and Gecko then? That looks bad.

WebUI code only runs in Chrome, so not sure whether Polymer third_party elements behave on WebKit or Gecko.

If this is Shadow DOM v0, we possibly need to keep the old specificity for sheets in v0 trees.

The breakages reported here are with Shadow DOM v0. I did not check whether they reproduce with Shadow DOM v1 (you can do so by adding --enable-features=WebUIPolymer2 in the command line, migration is still in progress, tracked by issue 738611).