Character count message should be placed correctly in markup without Javascript

[hannalaakso]

The character count Javascript moves the count message ("You have x characters remaining") in the DOM to be inside govuk-form-group. This was probably useful when the message markup was created dynamically. However this functionality is now redundant. The JS should be removed and the count message markup placed inside govuk-form-group in the component markup. This is so that we don't unnecessarily rely on Javascript for the correct order of DOM elements.

It’s important that the count message markup is inside govuk-form-group so that it gets wrapped within the error block (see screen grab below).

We put off making this change this in #1594 as it's a breaking change.

Done when

• TBC
• "Details of breaking change" section below completed to help with writing release notes

Details of breaking change

• which users are affected: TBC
• the change that’s been made: TBC
• changes users will have to make: TBC
• impact of users not making those changes: TBC

[36degrees]

I think this would require us to add something to the textarea API that allows us to insert this inside the form-group.

[hannalaakso]

Yes, we’d need to add it to the textarea API and tweak the textarea macro template so that it can accept a hint which would render below <textarea> but inside .govuk-form-group. But that is actually quite a strange requirement since the character count component is the only thing that needs to do this and most of the time inserting a hint below the textarea for any other purposes is not something we'd recommend teams do.

In conclusion, I don't think we should do this - it's a bit of an irregularity (ideally the JS wouldn’t need to move the markup around) but it's not causing any problems and if anything, adding it into the textarea API could actually lead to it being misused in other contexts.

Tempted to just close this issue but will leave it open for a bit longer for any other comments.

[lfdebrux]

If we made this change, would that mean that the hint would appear below the text area for users who have turned off JavaScript? That would seem like surprising/wrong behaviour to me.

[36degrees]

If we made this change, would that mean that the hint would appear below the text area for users who have turned off JavaScript? That would seem like surprising/wrong behaviour to me.

No – the hint and error message are standard, there's nothing special going on with them. However, at the minute the character count 'info message' ('You can enter up to X characters', which is separate to the hint) is outside of the form group in the component HTML, and the JS moves it inside the form group.

That means that when JS is disabled and the input is in the error state, the info message appears outside of it:

It also means we have to 'move' the margin that's normally applied to the form group for all (?) other form inputs from the form group to the character count wrapper:

govuk-frontend/src/govuk/components/character-count/_index.scss

Lines 7 to 14 in 133ea4f

	.govuk-character-count {
	@include govuk-responsive-margin(6, "bottom");
	.govuk-form-group,
	.govuk-textarea {
	margin-bottom: govuk-spacing(1);
	}
	}

(Otherwise there would be a 30px margin between the form group and the info message, and only a small margin between the info message and the next component)

I think the pros to fixing this are:

• the character count would display as expected when JS is disabled / fails and the component is in the error state
• we can remove the JS that moves the element inside the form group, which is 'surprising' behaviour
• we can remove the special treatment / duplication of the bottom margin which is normally applied to the character count

However as Hanna as pointed out the downside is we need to extend the textarea's API to allow the passing of content to be added before the closing tag of the form group div. I don't think it'd have to be specific to hints though – we could allow e.g. an 'arbitrary' formGroup.beforeHtml / formGroup.afterHtml to be passed, which might also be useful for scenarios like those described in #924.

[colinrotherham]

This is now ready to review as part of #4566