Refactor & Redesign: Eligibility Index, Eligibility Confirm form pages

[machikoyasuda]

closes #947

What this PR does

This PR shows how the two pages, Eligibility Index and Eligibility Confirm, can be created with a one-off html file that inherit from page or base and overrides main_content, while also allowing the form input area to be properly aligned for its own unique page design.

This PR also will refactor the Radio Button and Text Input CSS with variables and Bootstrap classes.

Eligibility Index / Radio Buttons

• Set and send offset-lg-1 col-lg-9 to the form includes to set the form as 9-col wide and aligned with the headline and explanatory text
• Creates custom template, eligibility/index.html that inherits from base
• Radio Button label: Needs to be a different headline size
• Radio Button spacing: Variable-ize and correct it
• Renames radio button form files so clarify that these templates are only for the Verifier radio button form
• Button text logic
• Do the copy/link for the button text

Eligibility Confirm / Text Inputs

• Set and send offset-lg-3 col-lg-6 to the form includes, to set the form as 6-col wide and centered
• Build off of the already-built eligibility/confirm.html and add on headline, explanatory-text and form
• Text input spacing and colors: Correct it
• Text input helper text: Correct it

Form template

• Refine and finish responsive button (and button with text) alignment logic.
• Form margin styles

Form submit buttons

• Simplify form submit button classes, bring back the disabled state
• Simplify form submit buttons (Login.gov, Continue, Submit) CSS code with variables. All buttons except for header/sign out buttons.

Other

• Update view tests

Form logic

• Update: The two Form classes now set their own classes key and value within the init() function. I use form.classes to pass in the correct string of CSS classes to get the form classes in. I undid all the Page.classes related changes.
• Uses page.context_dict() to set ctx["show_help_text"] = True to show the help text next to the button on the Index page.

Screenshots

Eligibility Index

Eligibility Confirm

Now with the Previous Buttons, too ✨ ✨ ✨

Mobile

[thekaveman]

Reviewing changes now 👀

[thekaveman]

Just a comment: since this now inherits from base.html, there's really no need for these {% block %} sections -- they are meant to create (or use) placeholders in a parent template.

We could just have the content inside the blocks directly here:

• {% block icon_title %}
• {% block paragraph_content %}
• {% block forms %}

And same comment for eligibility/index.html

[machikoyasuda]

Ended up keeping {% block paragraph_content %} and {% block forms %} and modifying how the nav_buttons work cos it was messing up the width of the page

[thekaveman]

Just curious, why keep those two block?

[machikoyasuda]

Forms has to be block cos I'm overriding both form and the CTA

I opted to put paragraph content in block because I wanted to be able to set their own padding for the paragraphs from the inside.

I don't want to set padding on paragraph_content at the base.html level, because in the cases where there is a page with a blank paragraph_content, it will still add padding. And we don't want that.

[machikoyasuda]

cc @angela-tran @thekaveman

I need to override paragraph_content b/c:

1. I need to add these classes pt-4 pb-4 pb-lg-8 which set padding-bottom to 64px, among other things, from the inside of the parent div.

2. If we add pt-4 pb-4 pb-lg-8 to the main parent itself, when there are pages without paragraph_content (which most pages don't have paragraph_content), the pages will have a giant 64px blank space. Padding applies even if the div inside is empty. We should not be adding padding classes to divs that might be empty/un-used in the base template.

[thekaveman]

Ok I don't want any of this to be blocking for this PR since it really doesn't matter to the end result...

Forms has to be block cos I'm overriding both form and the CTA

There isn't anything to override. {% block %} is used to place content in specific spot (the block) defined in a parent template. The parent here base.html does not define a {% block forms %}, so there is no spot to place/override anything. In confirm.html, this block turns into... exactly nothing in the rendered HTML.

By using {% block forms %} here, it creates a block that another template, inheriting from confirm.html, could fill in; that doesn't really make sense / isn't our use-case for these form pages.

I opted to put paragraph content in block because I wanted to be able to set their own padding for the paragraphs from the inside... I don't want to set padding on paragraph_content at the base.html level

So here it looks like a change to put the paragraphs into {% block explanatory-text %} which makes sense - the base.html defines this, so this places the paragraphs in that spot in the base template.

[machikoyasuda]

This PR is now using templates that inherit from the latest base.html. I had to make 2 small changes to base.html to make the alignment all work:

1. Adds the page title to the title: 800bd9c#diff-e2ae5f60bb472effafac24b079fcbb1ffd09dcc5d8df2d22cab07417d222f925L12-L13

2. When adding the previous button bar to the nav-buttons section, having a row be a parent of a row previous_page_row broke the alignment. (There was no longer a container width constraining the div, so the whole page would scroll horizontally passed 100 viewport width, and makes the window scroll and look like a lot of blank space). So I took the <div class="row"> out from base.html, so that the includes itself can add it. We need to be able to set the height on the row. A future refactor could add these styles to the nav-buttons div itself, but it's not necessary for the time being.

cc @angela-tran @thekaveman

[thekaveman]

This looks really good!

Possible regression?

I'm not sure if this is a minor regression on Mobile, but the "Previous" button should have border-width: 2px, it went back to 1px here?

Eligibility Index

Figma - Desktop

This PR running locally - Desktop

Figma - Mobile

This PR running locally - Mobile

Eligibility Confirm

Figma - Desktop

This PR running locally - Desktop

Figma - Mobile

This PR running locally - Mobile

[angela-tran]

I started this review earlier today and am just now submitting it.

I feel like I actually want to look at the CSS changes more closely, but don't want to prolong submitting the comments that I do have

[angela-tran]

This PR is now using templates that inherit from the latest base.html. I had to make 2 small changes to base.html to make the alignment all work:

1. Adds the page title to the title: [800bd9c#diff-e2ae5f60bb472effafac24b079fcbb1ffd09dcc5d8df2d22cab07417d222f925L12-L13](https://github.com/cal-itp/benefits/commit/800bd9c76b3f6581ef763a9b05388d7286ef86c9#diff-e2ae5f60bb472effafac24b079fcbb1ffd09dcc5d8df2d22cab07417d222f925L12-L13)

2. When adding the previous button bar to the nav-buttons section, having a `row` be a parent of a `row previous_page_row` broke the alignment. (There was no longer a container width constraining the div, so the whole page would scroll horizontally passed 100 viewport width, and makes the window scroll and look like a lot of blank space). So I took the `<div class="row">` out from base.html, so that the includes itself can add it. We need to be able to set the `height` on the row. A future refactor _could_ add these styles to the nav-buttons div itself, but it's not necessary for the time being.

cc @angela-tran @thekaveman

Some of my commits on #1013 do the same thing, which is ok - the merging is fine. Not sure if there's a way to more clearly delineate what belongs in which PR.

Edit: maybe it's just because this PR and #1013 both involved trying to use the grid, and in the process of doing so, we're going to notice things that need to be tweaked. Fortunately we both were thinking of the same tweaks.

[machikoyasuda]

@angela-tran @thekaveman

Today's update:

1. Added back CSS declarations to make the buttons have a 2px border.
2. Passing in help text here: a8a6c63 -- I left the /help link with #what-is-cal-itp anchor, but it should be changed to whatever future question tackles what the difference between the two eligibility verifier options are, once we update the Help page.

Happy to go over any more reviews over Zoom!

[angela-tran]

Other than @thekaveman's question at #1023 (comment), everything on this PR looks resolved to me