- add aria attributes on load with the gaufre api script so that people
already using la gaufre don't necessarely *have* to update their code
- add the aria patterns in given code examples/react components. In some
cases, our small page load JS code isn't enough: for example on SPAs
where gaufre buttons might be loaded after page load.
thanks @inseo
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.
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.
- we have a static astro website under /website. It has the
implementation docs of the homepage/gaufre templates, and it handles the
few API endpoints (the gaufre js, backgrounds, logos)
- we have a vite app under /packages/integration. It has the react
components generating the homepage and the gaufre button, and their css.
Its used to generate an npm package
