Add panel component

[davidhunter08]

Description

Add panel component for use on confirmation pages.

Large screens

Small screens

Checklist

• Tested against our testing policy (Resolution, Browser & Accessibility)
• Follows our coding standards and style guide
• CHANGELOG entry

[edwardhorsford]

@davidhunter08 can you add some screenshots?

[edwardhorsford]

add comment for why this is differenet?

[davidhunter08]

Not sure a comment is needed, having different sizing (padding) on desktop and mobile is pretty much standard. Or do you mean the fact we're calculating the padding size (by subtracting the border width)?

[davidhunter08]

Font sizes

After reviewing the panel font sizes, taking into consideration the proposed type scale updates, I've change the panel body font size to 24px(20px on mobile).

[anandamaryon1]

@davidhunter08 Thoughts on padding? I can see this totals 40px with the border and padding. Our cards tend to have 32px padding. I wonder whether this should have the same padding amount as cards? Possibly not an issue since they shouldn't ever appear on the same page. But worth considering?

Side note, any idea why the panel includes a 4px border? I assume for print/high-contrast styles?

[davidhunter08]

@davidhunter08 Thoughts on padding? I can see this totals 40px with the border and padding. Our cards tend to have 32px padding. I wonder whether this should have the same padding amount as cards? Possibly not an issue since they shouldn't ever appear on the same page. But worth considering?

It makes sense and looks ok having the padding 32px.

32px	40px

Side note, any idea why the panel includes a 4px border? I assume for print/high-contrast styles?

I presumed this was for changed/forced colours, same as the buttons, but I haven't tested it. We can test in the accessibility lab.

[anandamaryon1]

Tested on Windows with high contrast, 4px transparent border shows white 👍

[frankieroberto]

Looks good to me. Left some minor suggestions.

I also tested it locally without the body as I don’t think that’ll always be needed, and looks good.

[frankieroberto]

I wonder if this would be slightly nicer if there was a title object, with text or html and headingLevel as attributes? Might be slightly more consistent with text and html params elsewhere, and then we could potentially also allow adding classes to the heading if needed?

That said, might be over-complicated and introduces a deviation from the govuk component?

Suggested change

	{% set headingLevel = params.headingLevel if params.headingLevel else 1 -%}
	<div class="nhsuk-panel
	{%- if params.classes %} {{ params.classes }}{% endif %}"
	{{- nhsukAttributes(params.attributes) }}>
	<h{{ headingLevel }} class="nhsuk-panel__title">
	{{ params.titleHtml | safe if params.titleHtml else params.titleText }}
	</h{{ headingLevel }}>
	{% set headingLevel = params.title.headingLevel if params.title.headingLevel else 1 -%}
	<div class="nhsuk-panel
	{%- if params.classes %} {{ params.classes }}{% endif %}"
	{{- nhsukAttributes(params.attributes) }}>
	<h{{ headingLevel }} class="nhsuk-panel__title">
	{{ params.title.html | safe if params.title.html else params.title.text }}
	</h{{ headingLevel }}>

[davidhunter08]

I'm not too sure tbh. I am leaning more towards keeping it as is, as (like you said) it might be over-complicating it.

Maybe the question is, does it currently do all the things we need it to do? If yes, then probably best keeping it in line with the govuk component.

It'd be good to get others thoughts on this - cc @anandamaryon1 @edwardhorsford

[anandamaryon1]

Inclined to agree @davidhunter08, aligning with gov is a good reason. Once we do a discovery and decide whether we will adopt govuk frontend, it could be that we don't adopt and we diverge more (though unlikely) and make changes like this, but before that, we should align where we can.

[frankieroberto]

That makes sense to me - although perhaps we should quickly check in with the govuk team on if they have any plans to change this.