From looking at the paper-input demo[1], it seems like there's a style difference between paper-input and cr-input for the "disabled" attribute. Looking at the expected video, the behavior looks like a disabled paper-input, but the cr-input in this dialog[2] uses the "readonly" attribute, which isn't quite the same. That being said, the "disabled" attribute in cr-input doesn't look like the one in paper-input (dashed underline, etc).

It seems like this regressed when switching from paper-input to cr-input in https://chromium-review.googlesource.com/c/chromium/src/+/1089863/.

Demetrios, do you know if the style difference for "disabled" cr-inputs is intentional in Chrome?


[1] https://www.webcomponents.org/element/@polymer/paper-input/demo/demo/index.html
[2] https://cs.chromium.org/chromium/src/chrome/browser/resources/settings/printing_page/cups_edit_printer_dialog.html?rcl=6c061c7fec21b3bb683b1adc3aa14dfa72b9a59c&l=82

>  That being said, the "disabled" attribute in cr-input doesn't look like the one in paper-input (dashed underline, etc).

> Demetrios, do you know if the style difference for "disabled" cr-inputs is intentional in Chrome?

Yes, the changes in style are intentional. As part of MD Refresh most of the original MD styles (which are used in all paper-* elements by default) are obsolete.

Regarding the I-beam pointer itself, I'll take a closer look, but at first glance, a read-only field should be able to be copied, and therefore the I-beam pointer makes sense I think.

Yeah, I agree about copying, etc. for readonly. Maybe this should actually be "disabled"?

The "disabled" and "readonly" states, AFAICT have been designed from a UX standpoint to be standalone states, such that "readonly" does not need to be always appear along with "disabled".

Closing this as WAI.

Yeah, what I meant was that maybe this field is intended to be "disabled" *instead* of "readonly", but I don't really know the history here. Weifang, are you fine with closing this out as WAI?