Description
Le viewer PDF actuel (PdfViewerModal.html.twig) s'ouvre dans une modale contrainte — w-full h-full max-w-5xl max-h-[90vh] mx-4 — au lieu d'occuper tout l'écran. Pour un document PDF, souvent multi-pages et destiné à être lu, cet espace restreint (marges, plafond à 90vh/5xl) nuit à la lisibilité, surtout sur petits écrans.
Objectif : garder le même système de modale (même overlay, même mécanisme d'ouverture/fermeture) mais passer le viewer PDF en plein écran (100vw / 100vh, sans marge).
Cause
templates/components/PdfViewerModal.html.twig:2-8 :
- Ligne 2-6 :
<div id="pdf-viewer-modal"> avec classes hidden fixed inset-0 z-50 flex items-center justify-center bg-black/50 backdrop-blur-sm
- Ligne 7-8 : conteneur interne
w-full h-full max-w-5xl max-h-[90vh] mx-4 — c'est cette contrainte qui limite la taille réelle du viewer, pas la couche inset-0 (déjà plein écran)
Le JS d'ouverture (assets/js/pdf-viewer-modal.js:13-34, fonctions globales window.openPdfViewerModal/window.closePdfViewerModal) utilise le helper générique Modal (assets/js/modal.js) et n'a pas de notion de taille — la contrainte vient uniquement des classes Tailwind du template.
Piste de correction
- Retirer
max-w-5xl max-h-[90vh] mx-4 du conteneur interne pour occuper w-screen h-screen (ou équivalent sans marge)
assets/components/hc-modal.js:45 définit déjà un sizeMap générique avec une valeur fullscreen: '100%', actuellement non utilisée par la modale PDF — vérifier si ce helper peut être réutilisé ici plutôt que de dupliquer la logique de taille- Garder le même overlay/fond (
bg-black/50 backdrop-blur-sm) et le même mécanisme d'ouverture/fermeture (clic overlay, touche Échap, bouton fermer) qu'aujourd'hui — seul le gabarit de taille change
- Vérifier le rendu de l'
<iframe id="pdf-viewer-iframe"> (ligne 19-22 du template) en plein écran, notamment le viewer natif du navigateur à l'intérieur
Critères d'acceptation
Zone concernée
Frontend (CSS, Twig, JS)
Effort estimé
XS — moins d'1h
Description
Le viewer PDF actuel (
PdfViewerModal.html.twig) s'ouvre dans une modale contrainte —w-full h-full max-w-5xl max-h-[90vh] mx-4— au lieu d'occuper tout l'écran. Pour un document PDF, souvent multi-pages et destiné à être lu, cet espace restreint (marges, plafond à 90vh/5xl) nuit à la lisibilité, surtout sur petits écrans.Objectif : garder le même système de modale (même overlay, même mécanisme d'ouverture/fermeture) mais passer le viewer PDF en plein écran (100vw / 100vh, sans marge).
Cause
templates/components/PdfViewerModal.html.twig:2-8:<div id="pdf-viewer-modal">avec classeshidden fixed inset-0 z-50 flex items-center justify-center bg-black/50 backdrop-blur-smw-full h-full max-w-5xl max-h-[90vh] mx-4— c'est cette contrainte qui limite la taille réelle du viewer, pas la coucheinset-0(déjà plein écran)Le JS d'ouverture (
assets/js/pdf-viewer-modal.js:13-34, fonctions globaleswindow.openPdfViewerModal/window.closePdfViewerModal) utilise le helper génériqueModal(assets/js/modal.js) et n'a pas de notion de taille — la contrainte vient uniquement des classes Tailwind du template.Piste de correction
max-w-5xl max-h-[90vh] mx-4du conteneur interne pour occuperw-screen h-screen(ou équivalent sans marge)assets/components/hc-modal.js:45définit déjà unsizeMapgénérique avec une valeurfullscreen: '100%', actuellement non utilisée par la modale PDF — vérifier si ce helper peut être réutilisé ici plutôt que de dupliquer la logique de taillebg-black/50 backdrop-blur-sm) et le même mécanisme d'ouverture/fermeture (clic overlay, touche Échap, bouton fermer) qu'aujourd'hui — seul le gabarit de taille change<iframe id="pdf-viewer-iframe">(ligne 19-22 du template) en plein écran, notamment le viewer natif du navigateur à l'intérieurCritères d'acceptation
max-w/max-h).claude/layout.md)app_file_view(cf. SecurityHeadersListener : dérogation clickjacking basée sur le path plutôt que sur le nom de route #285)Zone concernée
Frontend (CSS, Twig, JS)
Effort estimé
XS — moins d'1h