• 
      

    Add standard CSS component classes for forms.

    Review Request #10831 — Created Jan. 19, 2020 and submitted

    Information

    Review Board
    release-4.0.x

    Reviewers

    This adds a new set of CSS component classes for defining forms in a
    standard way. This consists of:

    • rb-c-form: The CSS class for <form> elements, providing modifiers
      for standard alignment, functions for controlling alignment, and
      classes for an action area (for buttons).

    • rb-c-form-fieldset: The CSS class for <fieldset> elements,
      providing modifiers for collapsed fieldsets and classes for
      descriptive and field content areas.

    • rb-c-form-row: The CSS class for a row of fields in a form.

    • rb-c-form-field: The CSS class for a field, providing standard
      styling for labels, inputs, errors, and help text, as well as
      modifiers for controlling some basic parts of the display.

    It also introduces new namespaces for variables and methods, helping
    other pieces of UI adopt the same styling used in forms, and to help
    specialize form display. Older definitions in defs.less now make use
    of these variables.

    There's a few small improvements to other stylesheets to help
    incorporate a form and display it correctly on mobile. For instance,
    to display properly, we recommend a page using a form to use
    <body class="is-content-flush-on-mobile"> and
    <div class="page-content-box -is-content-flush">, and this led to a
    fix needed in rb-c-content-header to display the header correctly.
    The recommendations are documented in the rb-c-form component.

    Upcoming changes to the administration UI will make use of these new
    classes, replacing the older Django classes that used to comprise the
    admin UI change forms.

    Made use of all these styles in an upcoming change for the administration
    UI. Tested on mobile and desktop mode.

    Summary ID
    Add standard CSS component classes for forms.
    This adds a new set of CSS component classes for defining forms in a standard way. This consists of: * `rb-c-form`: The CSS class for `<form>` elements, providing modifiers for standard alignment, functions for controlling alignment, and classes for an action area (for buttons). * `rb-c-form-fieldset`: The CSS class for `<fieldset>` elements, providing modifiers for collapsed fieldsets and classes for descriptive and field content areas. * `rb-c-form-row`: The CSS class for a row of fields in a form. * `rb-c-form-field`: The CSS class for a field, providing standard styling for labels, inputs, errors, and help text, as well as modifiers for controlling some basic parts of the display. It also introduces new namespaces for variables and methods, helping other pieces of UI adopt the same styling used in forms, and to help specialize form display. Older definitions in `defs.less` now make use of these variables. There's a few small improvements to other stylesheets to help incorporate a form and display it correctly on mobile. For instance, to display properly, we recommend a page using a form to use `<body class="is-content-flush-on-mobile">` and `<div class="page-content-box -is-content-flush">`, and this led to a fix needed in `rb-c-content-header` to display the header correctly. The recommendations are documented in the `rb-c-form` component. Upcoming changes to the administration UI will make use of these new classes, replacing the older Django classes that used to comprise the admin UI change forms.
    401ff88a76f3abe002b2128ba7dfb16634b9ab6b

    Description From Last Updated

    Where is this teal color coming from?

    daviddavid

    The green help text makes things pretty visually noisy. Can we just use a dark grey?

    daviddavid
    chipx86
    david
    1. 
        
    2. Show all issues

      Where is this teal color coming from?

      1. Django 1.11's icon set. Addressing that mess is a project for another day.

    3. Show all issues

      The green help text makes things pretty visually noisy. Can we just use a dark grey?

      1. My aim with the green was to keep all text from blurring together, being basically a shade of black. We have a grey today in the UI, and I always felt it wasn't comfortablwe to read. The green was a pretty big change when I added it, but having spent a lot of time with this UI so far, I think it works pretty well. That said, I'll play with other options.

      2. Been messing around with this. I honestly do prefer the green, but can see where it may draw too much attention to itself. I think it's a double-edged sword. It stands out better, which can be good, but it means your eyes are drawn to it more and less to other field content. With a grey, it doesn't stand out as much, and kind of blends in with everything else, but it also means your eyes aren't jumping to it.

        I prefer the green, but will go with a grey.

    4. 
        
    chipx86
    david
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-4.0.x (8523664)