Update readonly text field style

[m-akinc]

Pull Request

🤨 Rationale

Brandon changed a few things in the text field design, most notably the readonly style.

👩‍💻 Implementation

1. All three appearance modes now have an outline (and no background shading) when readonly:
   
2. Block appearance, when disabled, no longer looks like underline. It is just a more dimmed version of the normal block styling.
3. The background shading for block appearance is slightly darker.
4. Readonly mode (for all appearances) now uses an I-beam cursor (rather than replacing it with the standard cursor)
5. I reordered the CSS to follow our grouping/ordering guidelines.

🧪 Testing

Manual testing in Storybook

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[jattasNI]

Friendly reminder to review the UI status checks and approve them if they look good.

Looks good to me but I also added @mollykreis as a reviewer since my CSS knowledge is still a work in progress and she left good feedback on #345. Let's wait for an approval from her or @rajsite before merging.

[rajsite]

Instead of using :not can we rely on the cascade, see #345 (comment)

[m-akinc]

I thought this scenario made sense for using :not (our guidelines seem to allow for using :not sometimes). Consider these designs:

All three appearances have the same readonly style, but their disabled styles are slight transformations of their default styles. When both readonly and disabled, we want the disabled style to take precedence. It seems that a simple way to achieve this is to use [readonly]:not([disabled]) in the selector. Otherwise, for each style, I have to explicitly style the [readonly][disabled] case, making sure to overwrite all the settings that were specified in the [readonly] case. That seemed messier to me, but if you disagree, I'll make the change.

[rajsite]

That seemed messier to me, but if you disagree, I'll make the change.
Otherwise, for each style, I have to explicitly style the [readonly][disabled] case

Can you make a quick branch to compare them? I don't think I understand why this would be so "messy".

If the squad agrees that we prefer to mix explicit states with :not logic then lets do what folks think is more maintainable. We should come up with guidelines so we can review it consistently.

I'm going to push hard against seeing things like element:not(blah1):not(blah2):not(balh3) because that becomes unmaintainable. Folks making patches tend to avoid disentangling chained not selectors and instead add more to the chain. I'm essentially advocating for never entangling them in the first place.

If we look at FAST's usages the vast majority seem to be for the disabled state as well. Would could say that disabled state is an exception and it's okay to sprinkle every other line with :not([disabled])

I think for the disabled state in specific, the reason FAST goes through the hoops for saying all this stuff does not apply to the disabled state is because there is not an easy way to trump all the selectors. Ideally we just want to put disabled state at the end and have it override all the intermediate states. The layers proposal will help with this: https://www.youtube.com/watch?v=ilrPpSQJb3U. And I think migrating to layers will be easier with explicit states.

[rajsite]

Approved as we don't need to necessarily block the PR on this discussion

[m-akinc]

I will submit like this and try it without :not so we can compare.

[rajsite]

sounds good 👍