[beta4] Missing p tag in footer bottom copy preview

The root cause of this issue seems to be upstream:

.fr-footer__bottom-copy * {
  font-size: 0.75rem;
  line-height: 1.25rem;
}

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 :

    bottom_copy:
      preview: '<p>Unless otherwise stated, all content on this site is licensed under <a href="https://github.com/etalab/licence-ouverte/blob/master/LO.md" target="_blank">etalab-2.0 license</a></p>'

What about this?

-        <div class="fr-footer__bottom-copy">{{ bottom_copy }}</div>
+       <div class="fr-footer__bottom-copy"><div>{{ bottom_copy }}</div></div>

I am proposing DIV instead of P to prevent some Web browser to move bottom_copy DOM tree out of .fr-footer__bottom-copy

Thanks 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)

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 proposed a DIV element instead of a P element. And also to avoid weird DOM behaviour

it should be a p tag for accessibility reasons. 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...

This P element can be injected as part of the slot value.

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 ?

It is also a solution. I prefer the one not according the text, but I will also accept this proposal.

As 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.

thanks