Problem/Motivation
In the footer pattern preview, the bottom copy text is bigger than expected (see screenshot attached). It's because the p tag is missing, which handles the font-size in DSFR CSS.
Steps to reproduce
Visible on the /patterns page, in the footer preview.
Proposed resolution
Add p tag in preview.
| Comment | File | Size | Author |
|---|---|---|---|
| Capture d’écran du 2023-08-18 11-21-30.png | 7.99 KB | mh_nichts |
Issue fork ui_suite_dsfr-3381854
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mh_nichtsComment #4
pdureau commentedThe root cause of this issue seems to be upstream:
We need a child element for the styles to be applied, so a markup like this will have the wrong styles:
<div class="fr-footer__bottom-copy">Just a plain text</div>You did that and I am not sure it is enough because most of site builers and developers will forget to wrap bottom_copy content into an HTML element :
What about this?
I am proposing DIV instead of P to prevent some Web browser to move bottom_copy DOM tree out of .fr-footer__bottom-copy
Comment #5
mh_nichtsThanks for your comment.
You're right that the root cause is the missing child element : any element (like div) would do to match the expected appearance. However, it should be a p tag for accessibility reasons : this is a text and should semantically tagged as such, in order to be correctly handled by assistive technologies (if it's only a div, it could be completely bypassed in some situations, and the info would be missed).
That's also why there should be a p tag according to the DSFR documentation : https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/pi...
I agree that the best would be to handle the child tag in the Twig file, but I thought you wanted to let the freedom to site builders/developers to put any HTML text they wanted (maybe several p tags), that's why I handled it only in the preview.
Your suggestion would solve this point, but as it's only a div element, as you said, most site builders/developers will still forget to put a p tag, so it will still be an accessibility fail...
I'm wondering, as this license text is mandatory (according to the DSFR documentation), maybe the best way to follow all the constraints is to include it completely in the Twig file (tag & translatable text) ? So we would be sure that it's not forgotten, it's the correct text, and the correct tag ? (but it wouldn't be customizable anymore)
Comment #6
pdureau commentedThat's why I proposed a DIV element instead of a P element. And also to avoid weird DOM behaviour
This P element can be injected as part of the slot value.
It is also a solution. I prefer the one not according the text, but I will also accept this proposal.
Comment #7
pdureau commentedComment #8
mh_nichtsComment #9
mh_nichtsAs discussed together, we put a div to be sure of the appearance, and leave to the developer/webmaster the responsibility to use p tags for accessibility.
Comment #11
pdureau commentedthanks
Comment #12
pdureau commented