Formalize the structure for review request fields and polish styling.

Review Request #13292 — Created Sept. 28, 2023 and submitted

Information

Review Board
release-6.x

Reviewers

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
nested tags).

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
to.

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
inline fields.

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.

Summary ID
Formalize the structure for review request fields and polish styling.
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 nested tags). 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 to. 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.
2788c9ba9a4730d66c3e617e511060fde00d69f1

maubin
  1. Ship It!
  2. 
      
david
  1. Ship It!
  2. 
      
chipx86
Review request changed
Status:
Completed
Change Summary:
Pushed to release-6.x (901e9aa)