-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix wrapping of long lines of text in summary list #1169
Fix wrapping of long lines of text in summary list #1169
Conversation
319d0e1
to
a680f22
Compare
Is there a better way to guess the next pull request ID in GitHub for the changelog? Fixed it and pushed again. |
@colinrotherham you could guess what the next ID is by bumping the number, but we just open the PR then add a CHANGELOG entry... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me!
I've tested this cross browser too.
Thanks for the great work updating the example Colin.
@MoJ-Longbeard are you happy with this? 😄
We'll need a section person from the team to also check and approve this.
@NickColley, Apologies if I am being too pernickety, but I am slightly concerned that this CSS deactivates the table's "natural" resizing. |
a680f22
to
cb48f7a
Compare
@MoJ-Longbeard I tried that option, but can't find a better solution. I'd say that wrapping by default is sensible, but manually choosing to add I've added another example to this pull request: <p class="govuk-body" style="white-space: nowrap;">
michelle.longish.name@example.com
</p> The Summary List "extreme" example now demonstrates text wrapping for the two new long rows, but never goes narrower than the width of this paragraph. |
Just a note, the examples in the design system iframes are a little squished than they would be in real life, if you 'open in a new window' you'll see the actual result. |
cb48f7a
to
ea0bc30
Compare
Quickly modified to list the non-standard |
Spoke with @MoJ-Longbeard and @colinrotherham on Slack. The current situation is:
So there's no perfect solution, without perhaps using JavaScript, which we will not want to do. We think that since super long words are edge cases, this fix will not break the majority of content in summary lists unnecessarily. |
Yes. I agree. As you say, neither option is perfect. |
Thanks everyone, @MoJ-Longbeard let us know how soon you need a release for this. We tend to wait a bit between releases but can prioritise a quick release if you are blocked. 👍 |
[PR alphagov#1169](alphagov#1169) added in some CSS: - ``word-break: break-word;``, followed by - ``word-break: break-all;`` ``word-break: break-word;`` is the favoured behaviour, but isn't fully supported. ``word-break: break-all;`` is the fallback behaviour, it sometimes results in unfavourable wrapping mid-word. The order for this CSS needs to be changed to, otherwise the less favourable `break-all` takes precedence. ```CSS word-break: break-all; word-break: break-word; ```
[PR alphagov#1169](alphagov#1169) added in some CSS: - ``word-break: break-word;``, followed by - ``word-break: break-all;`` ``word-break: break-word;`` is the favoured behaviour, but isn't fully supported. ``word-break: break-all;`` is the fallback behaviour, it sometimes results in unfavourable wrapping mid-word. The order for this CSS needs to be changed to, otherwise the less favourable `break-all` takes precedence. ```CSS word-break: break-all; word-break: break-word; ``` **caniuse** said: > Chrome, Safari and other WebKit/Blink browsers also support the unofficial break-word value The implication here being that it is not fully supported, so ``word-break: break-all;`` is still needed as a fallback. Discussed with [Colin Rotherham](https://github.com/colinrotherham)
[PR alphagov#1169](alphagov#1169) added in some CSS: - ``word-break: break-word;``, followed by - ``word-break: break-all;`` ``word-break: break-word;`` is the favoured behaviour, but isn't fully supported. ``word-break: break-all;`` is the fallback behaviour, it sometimes results in unfavourable wrapping mid-word. The order for this CSS needs to be changed to, otherwise the less favourable `break-all` takes precedence. ```CSS word-break: break-all; word-break: break-word; ``` **caniuse** said: > Chrome, Safari and other WebKit/Blink browsers also support the unofficial break-word value The implication here being that it is not fully supported, so ``word-break: break-all;`` is still needed as a fallback. Discussed with [Colin Rotherham](https://github.com/colinrotherham)
I think we should use overflow-wrap. word-break: https://jsfiddle.net/lee_kowalkowski/efvb7uxm/3/ |
@leekowalkowski-hmrc looks like that might be a good option, do we know how well it works with legacy browsers? https://caniuse.com/#search=overflow-wrap |
@NickColley Yes, it looks like we need
|
As raised by @MoJ-Longbeard, we noticed very long links or lines of text aren't automatically wrapped inside the summary list value (but they are in the summary list key).
This pull request adds automatic wrapping to both key and value.
Before
Shows the summary list scrolling off the screen
After
Shows how text is automatically wrapped, only if it's too long to fit
For compatibility with other browsers, we need to provide multiple values for
word-break
: