Formalize the structure for review request fields and polish styling.
Review Request #13292 — Created Sept. 28, 2023 and submitted — Latest diff uploaded
The structure of our review request fields were sort of all over the
place. We reused the same class names that sections on the review
request box used, we had a whole separate set of styling and tags for
the details section (which hard-coded a
<table>), and we didn't really
have any good places for improving any styling without further
complicating the rats nest of styles we already had.
This change redoes all this, fixing some styles and preparing for
further fixes in the next change.
We have two new review request CSS components:
rb-c-review-request-field: A wrapper for an editable field or
displayed field value.
rb-c-review-request-fieldset: A collection of fields or other
content, with an optional label.
All fields make use of these, regardless of presentation. The details
pane no longer uses a
<table>, but rather uses a tabular fieldset,
which uses CSS table layout (note that CSS Grid is not an option, since
subgrids aren't widely-supported yet, and those would be needed due to
The fields have a minimum height and line height, ensuring that the page
doesn't jump when going in and out of an inline editor.
The summary field's inline editor now spans the width of the review
request box without triggering wrapping and layout shift like it used
Label information is now provided when registering the fields, which is
fed into the inline editors, helping provide accessible labels.
This change will form the base of the final part of this series of
review request UI work, which will fix various headaches and a
regression we currently have with layout.
Tested this in desktop and mobile modes at different font sizes, making
sure there were no page jumps when going in or out of edit mode for any
Went through the accessibility tree and made sure labels were present
for all the fields and major sections of the review request box.
Unit tests pass.