while the idea is great at first, in fact it's a bit weird to publish a
new package version for something people don't actually use except the
docs website… and it makes it easier to publish website updates.
Duplicate a bit to ease up everything
the 100vh takes too much place sometime, making the close button being
rendered behind the browser UI. now we use the "svh" unit when
available, which is the same as vh but making sure we dont overlap with
browser UI.
command used (assuming Marianne-Regular.woff2 is in website/public/fonts
dir, taken from the dsfr):
glyphhanger \
--subset="./Marianne-Regular.woff2" \
--formats=woff2 \
--whitelist="DémarchessimplifiéesFranceTransfertGristNotepaddel'ÉtatRDVServicePublicResanaTchapWebConférencedel'ÉtatWebinairedel'ÉtatFermer✕
"
we had feedback where text in the popup was rendered with completely
random characters… adding the unicode range should help?
this is done following up Tchap integration.
- the popup placement script was really dumb and assumed the gaufre
button was always placed at the top right of the page. Tchap can't do
that and uses it at the bottom left. Now the popup places itself
correctly wherever the button is on the page.
On mobile now we have a "modal" mode for the popup where it takes all
the viewport.
- Tchap uses the gaufre inside their own popup component. This was not
something we handled before. Now you can set up a
'lasuite--gaufre-borderless' class on your html or body tag so that the
gaufre doesn't render its box shadow or blue border, making it easier to
integrate in a already made popup.
rework a bit the backgrounds transformation script so that we can later
easily force a specific background for a specific service. This comes
from a request from france-transfert but they changed their mind in the
end. Felt like the logic is good to keep for later though.
small test that anchors the popup to the left of the viewport, this
quickly fixes the popup going out of viewport if the Gaufre button is
used on the left of a header bar
iframe was great because we controlled our page context to style things
easily, handle assets easily.
But since it's not on the same domain as the services consuming it, it
implied configuration here and there. Also some behaviors were annoying
to implement (for example, keyboard navigation). I'm sure everything we
do is possible via iframe but I feel like I'll go from barrier to
barrier at every new thing we want to do…
I feel like, at the cost of handling style-conflicts, just rendering
everything in the real page context is more future-proof.
- the CSS that included the DSFR excerpt we needed styled some base html
tags directly. It might collide with a service CSS already there. Now a
postcss plugin applies a CSS prefix to everything
- we output in the lib two DSFR file versions: one with prefixed
selectors, one raw.
