Les dix décisions ouvertes par la revue du 7 octobre

Préparé le 7 octobre 2026 au soir, pour Emmanuel. Dix points, numérotés 22 à 31 dans la section 14 du plan WordPress, ouverts par la revue complète du prototype (rapport : docs/revue-2026-10-07/RAPPORT.md, ses numéros entre parenthèses). Ce sont des choix de rendu, pas de code : tant qu'ils ne sont pas tranchés, le prototype garde la maquette. Les images viennent du prototype ; les simulations sont des règles CSS posées par-dessus le temps d'une capture, rien n'est changé dans le prototype.

Décidé le 08/10Emmanuel a tranché les dix points : la recommandation partout, sauf la constellation (29, rien : seul le mouvement réduit l'arrête) et le fil d'Ariane (31 e, abandonné). Les choix sont cochés dans chaque case Décision et reportés dans le plan, section 14. Ceux qui changent le rendu (22, 23, 24, 28, 29, 31 b, c et f) se font d'abord dans le prototype.
Nouveau le 07/10 au soirLe reste de la revue est corrigé dans le prototype et dans le code WordPress en réserve (journal du 07/10). Il reste ces dix choix, et les points 1 à 21 encore ouverts, sur la page des décisions du 07/10. Les points 22, 23, 24 et 28 sont à trancher avant de copier site.css et frise.js dans le thème : ils changent des règles que les 39 blocs et tous les gabarits vont recopier.

Les dix points en un coup d'œil

PointLa questionRecommandéDécidé le 08/10À trancher avant de
22La frise sur tablette en portrait, sur écran 4:3 et sur téléphone en paysageC : frise verticale en portrait ou sur écran bas, et échelle plafonnée par la largeur (1300, pas 1100)Ccopier site.css et frise.js dans le thème
23Le contraste de l'ouverture du chapitre 01A : texte brun ; rouge un peu plus foncé pour le menu de ContestationA ; rouge #d92e56créer les champs de couleur des rubriques
24Le texte secondaire à 50 % de brunA : un seul jeton de texte secondaire à 65 % (#827161)Acopier site.css
25La page Crédits dans WordPressA : structure et noms dans le gabaritAécrire page-credits.php
26L'icône du siteA : le réglage « Icône du site » de WordPressAécrire header.php
27Un champ e-mail dans le formulaire de contactA : un champ e-mail obligatoireAécrire page-contact.php et choisir l'extension de formulaire
28Le pied de page sur tabletteA : le pied empilé du téléphone sous 1000 pxAfiger footer.php
29Arrêter ce qui bouge tout seul (bandeau, constellation)A pour le bandeau (le bouton Pause de la vidéo l'arrête aussi), B pour la constellationBandeau A ; constellation : rienécrire l'accueil et Vision alternative
30Les archives par date de WordPressA : les couperAla première page de test
31Sept petits choix de mise en pageVoir le pointLes recommandations, sauf e : fil d'Ariane abandonnégénérer les 32 blocs (31 c), le reste au fil de l'eau

Tous se tranchent par Emmanuel. Avis utile de Ryan (direction artistique) pour 23, 24 et 31 a, puisqu'ils s'écartent de la maquette ; du client pour 27 (questions 2.6 et 2.12) et 31 e (le fil d'Ariane décidé avec lui le 22/09).

1. Les écrans que la maquette ne prévoit pasPoints 22 et 28

22La frise sur tablette en portrait, sur écran 4:3 et sur téléphone en paysage

La question

Toute la frise est mesurée en pixels de maquette, à l'échelle de la hauteur de l'écran (--px-h, une seule échelle depuis le 06/10). C'est exact en paysage large. Mais plus l'écran est étroit par rapport à sa hauteur, plus les blocs débordent : sur une tablette tenue en portrait (820 x 1180), 27 blocs sur 39 ont un titre ou une carte plus large que l'écran, donc jamais visible en entier. Que fait-on pour ces écrans ?

Pourquoi maintenant : --px-h est l'unité de toute la CSS des 39 blocs, et la règle qui fait passer la frise en vertical (« 768 px et moins ») est écrite dans 97 requêtes média de site.css et dans frise.js. On la fixe avant de les copier dans le thème, pas après.

Ce qu'il faut regarder
La frise sur une tablette en portrait : le titre du bloc 19 sort de l'écran
Aujourd'hui, tablette en portrait : le titre du bloc 19 sort de l'écran.
La frise verticale du téléphone, à 768 px de large : les blocs se suivent vers le bas
Aperçu de l'option A : la frise verticale du téléphone, telle qu'elle s'affiche déjà à 768 x 1180. Tout se lit, rien ne dépasse.
Simulation : la frise rétrécie par la largeur, en portrait
L'option B seule en portrait (simulation, plafond à 1100 comme le proposait le plan) : tout rétrécit (texte des cartes de 19 à 11 px), la moitié basse de l'écran reste vide, et la troisième ligne du titre dépasse encore.
La frise sur un téléphone tenu en paysage : texte minuscule
Téléphone en paysage, aujourd'hui (image doublée pour la lecture) : cartes à 7 px de texte, liens de la bande de 8 px de haut.
La fin de la frise sur un écran 4:3 : le pied coupé à gauche
Écran 4:3, aujourd'hui : au bout de la frise, le pied est coupé à gauche.
Simulation : le pied entier sur l'écran 4:3, avec l'échelle plafonnée à 1300
L'option B avec un plafond à 1300 (simulation) : le pied tient en entier ; le reste de la frise rétrécit de 7 % (texte des cartes de 12,5 à 11,7 px).
Mesuré le 07/10 : ce que change le plafond, selon sa valeur
ÉcranAujourd'huiPlafond à 1100 (plan)Plafond à 1300
1024 x 768 (4:3)pied coupé de 65 pxaucun effet : pied coupé de 65 pxtout tient (pied à 3 px du bord)
1000 x 900 (fenêtre réduite)pied coupépied coupé de 164 pxtout tient
1280 x 800, 1512 x 982 et plustout tientaucun effetaucun effet

ALa frise verticale dès que l'écran est en portrait ou bas

Pour le visiteur
Tablette en portrait et téléphone en paysage voient la frise du téléphone, qui défile vers le bas : tout se lit.
Pour notre travail
Une seule condition à la place de « 768 px et moins » : (max-width: 768px), (orientation: portrait), (max-height: 519px), et son contraire. Elle remplace 97 requêtes média de site.css (par un script) et deux de frise.js et hero-video.js. La navigation suit (en-tête en haut), comme toutes les pages qui basculent à 768 px.
Risque
Sur une grande tablette en portrait (1024 x 1366), la mise en page du téléphone s'étire : à regarder page par page. Ne règle pas l'écran 4:3, qui reste en paysage.

BL'échelle plafonnée par la largeur

Pour le visiteur
La frise reste horizontale partout ; sur un écran presque carré, elle rétrécit juste assez pour que l'élément le plus large tienne.
Pour notre travail
Une ligne : --px-h: min(calc(100vh / 982), calc((100vw - 76px) / 1300)), (frise.js mesure les blocs eux-mêmes : rien à y changer). 1300 et non 1100 : le plus large élément est le pied (1227 px de maquette).
Risque
Seule, en portrait : texte à 11 px et moitié basse vide (image ci-dessus).

CA et B ensembleRecommandé

Pour le visiteur
Portrait et écrans bas : la frise du téléphone. Paysage presque carré (4:3, fenêtre réduite) : la frise horizontale, un peu plus petite, rien de coupé.
Pour notre travail
Les deux changements, dans le prototype d'abord, puis captures avant / après sur les huit formats du banc d'essai, puis copie dans le thème.
Risque
Le plus de travail des quatre, et la règle commune touche toutes les pages en portrait.

DRien

Pour le visiteur
Tablette en portrait : 27 blocs sur 39 coupés. Téléphone en paysage : texte à 7 px. Écran 4:3 : pied coupé.
Risque
Ces écrans sont courants : une tablette se tient souvent en portrait, un téléphone se tourne.
Recommandation : C, avec un plafond à 1300 et non 1100 (mesuré le 07/10).A règle le portrait et le téléphone en paysage ; B règle ce qui reste en paysage presque carré. Le plan recommandait déjà C ; la simulation corrige seulement la valeur du plafond.
Tenez un téléphone en paysage devant la frise : que lisez-vous ? Une tablette en portrait doit-elle voir le site de l'ordinateur ou celui du téléphone ?

Décision

ABCD

Décidé le 08/10 : C, frise verticale en portrait ou sur écran bas, échelle plafonnée à 1300.

28Le pied de page sur tablette

La question

Le pied de page de l'ordinateur (la grille de Daria) se réduit avec la largeur de l'écran, sans plancher : à 820 px de large, son texte fait 9,7 px et ses liens 8 px de haut. Le téléphone a son pied empilé, à partir de 768 px. Que montre-t-on entre les deux ?

Pourquoi maintenant : footer.php est commun à tout le site ; sa règle se fige avant de devenir le gabarit du thème (I11).

Le pied de page de l'ordinateur à 820 px de large : texte minuscule
Aujourd'hui à 820 px (taille réelle) : texte à 9,7 px.
Le pied de page empilé du téléphone
Aperçu de l'option A : le pied empilé, tel qu'il s'affiche à 768 px.

ALe pied empilé sous 1000 px environRecommandé

Pour le visiteur
Sur tablette, le pied du téléphone : lisible, liens faciles à toucher.
Pour notre travail
La requête média du pied passe de 768 à 1000 px (son bloc de la section du pied de page).
Risque
Entre 769 et 1000 px, la navigation reste une colonne à droite au-dessus d'un pied empilé : à vérifier en capture. Si le point 22 retient A, les tablettes en portrait ont déjà le pied empilé.

BUn plancher de 15 px

Pour le visiteur
Le texte reste lisible.
Risque
Le texte ne réduit plus, la grille si : il déborde de ses cases.

CRien

Risque
Contact, réseaux et mentions illisibles sur tablette.

Décision

A, sous pxBC

Décidé le 08/10 : A, le pied empilé sous 1000 px.

2. Lisible et utilisable par tousPoints 23, 24 et 29

Les seuils cités sont ceux des règles d'accessibilité du web (WCAG 2.2, niveau AA), que le projet applique déjà à la vidéo de l'accueil : un rapport de contraste d'au moins 4,5:1 pour un texte courant, 3:1 pour un grand texte (24 px, ou 18,7 px en gras).

23Le contraste de l'ouverture du chapitre 01

La question

Le chapitre 01 s'ouvre sur un fond brun clair (#c6bdac), avec le grand titre « 01 Contexte » et le menu des chapitres en crème : 1,82:1, sous les deux seuils. C'est la maquette. Les chapitres 04 et 05 ont déjà du texte brun sur leur fond clair. Que fait-on du 01 ?

Pourquoi maintenant : dans WordPress, les couleurs d'une ouverture deviennent des champs de la rubrique ; on fixe un couple texte / fond qui passe avant de créer ces champs (I4).

L'ouverture 01 Contexte : texte crème sur brun clair
Aujourd'hui (la maquette) : crème sur brun clair, 1,82:1.
Simulation : le même écran avec le texte en brun
Option A (simulation) : texte brun, 7,52:1, comme les chapitres 04 et 05.
Simulation : le même écran sur un fond brun plus foncé
Option B (simulation, fond #827161) : le crème passe à 4,57:1, mais les noms de la bande, en brun, tombent à 2,99:1.

ATexte brun sur ce fondRecommandé

Pour le visiteur
Titre et menu lisibles ; le chapitre garde sa couleur.
Pour notre travail
Une règle : la couleur du texte de .evt--01-rubrique-contexte.
Risque
Un écart à la maquette, sur un seul écran.

BUn fond plus foncé

Pour le visiteur
Le crème reste, l'écran devient sombre.
Pour notre travail
Une règle pour le fond, mais la bande posée sur le bas du bloc devient illisible et la couleur du chapitre se retrouve dans la barre des chapitres du téléphone : la changer partout.
Risque
Le chapitre 01 ne ressemble plus à la maquette.

CLa maquette telle quelle

Pour le visiteur
Titre et menu difficiles à lire (vue faible, soleil sur l'écran).
Risque
Le premier écran de la frise sous les seuils.

Le chapitre 03 (Contestation) : le grand titre passe, mais le menu (18 px, graisse 600, crème sur #e7315c) est à 4,11:1. Le mettre en gras ne suffit pas : en gras, un texte n'est « grand » qu'à partir de 18,7 px. Un rouge à peine plus foncé, #d92e56, donne 4,58:1 ; ou un menu en 19 px gras (seuil de 3:1).

Recommandation : A pour le chapitre 01 ; #d92e56 pour le rouge de Contestation.A suit ce que la maquette fait déjà sur les chapitres 04 et 05. Le rouge se change en une ligne (le jeton --rouge) : il fonce aussi le fond des titres du chapitre 03, la bande et le survol de Ressources, de 6 %, à peine visible.

Décision

ABC

Contestation : rouge #d92e56, menu en 19 px gras, ou rien ?

Décidé le 08/10 : A, texte brun ; Contestation, rouge #d92e56.

24Le texte secondaire à 50 % de brun

La question

Les textes secondaires (adresse et lien Itinéraire des cartes d'action, textes des moments clés, intitulés de Crédits, métadonnées de Presse, types de Ressources, coordonnées de Contact, intitulés de la fiche thème) sont en brun à 50 %, le « Brown-opacity » de la maquette : 2,97:1, pour un seuil de 4,5:1. Remonte-t-on ce brun ?

Pourquoi maintenant : la même intention est écrite de six façons dans site.css (--taupe, --brun-50, --color-brown-opacity, --brun-voile, deux color-mix()). Le thème doit naître avec un seul jeton, sinon il recopie les six variantes et l'échec dans tous les gabarits (I5).

Une carte d'action, adresse et Itinéraire en brun à 50 %
Aujourd'hui : adresse et « Itinéraire » à 50 %, 2,97:1.
Simulation : la même carte avec le texte secondaire à 65 %
Option A (simulation) : 65 %, #827161, 4,57:1.
Les colonnes de Crédits, intitulés en brun à 50 %
Crédits aujourd'hui : intitulés à 50 %.
Simulation : les colonnes de Crédits avec les intitulés à 65 %
Crédits, option A (simulation) : la hiérarchie reste, le texte se lit.

AUn seul jeton de texte secondaire à 65 % (#827161)Recommandé

Pour le visiteur
La différence entre texte principal et secondaire reste ; tout se lit.
Pour notre travail
Un jeton dans la section 1 de site.css (--texte-secondaire), les textes y renvoient ; le 50 % reste pour les traits et les bordures, où il ne gêne pas.
Risque
Un brun un peu plus soutenu que la maquette.

BBrun plein

Pour le visiteur
13,67:1, mais plus aucune différence entre un nom et son intitulé.
Risque
La hiérarchie de la maquette disparaît.

CLa maquette telle quelle

Risque
Sept pages et la fiche thème sous le seuil ; la seule faute que Lighthouse relève sur la fiche.

Décision

ABC

Décidé le 08/10 : A, un seul jeton à 65 % (#827161).

29Arrêter ce qui bouge tout seul

La question

Trois choses bougent toutes seules : la vidéo de l'accueil (elle a un bouton Pause), le bandeau d'actualités sous la vidéo (il s'arrête au survol de la souris ou au clavier, jamais au toucher) et la constellation de Vision alternative (elle dérive sans fin, sans aucun arrêt). La règle WCAG 2.2.2 demande un moyen d'arrêter ce qui bouge plus de 5 secondes à côté d'autre contenu. Ajoute-t-on un arrêt aux deux autres ?

Pourquoi maintenant : le bandeau devient une boucle WordPress sur la page d'accueil, et la constellation un gabarit ; le bouton s'écrit avec eux (M43, N7). Le mouvement réduit du système arrête déjà tout, mais peu de visiteurs le connaissent.

L'accueil : la vidéo, son bouton Pause en bas à droite, et le bandeau d'actualités dessous
L'accueil : le bouton Pause (en bas à droite de la vidéo) n'arrête que la vidéo ; le bandeau dessous continue de défiler.

AUn bouton Pause

Pour le visiteur
Bandeau : le bouton Pause de la vidéo arrête aussi le bandeau (rien de nouveau à l'écran). Constellation : un petit bouton Pause, comme celui de la vidéo.
Pour notre travail
Quelques lignes dans hero-video.js ; un bouton et quelques lignes dans constellation.js.
Risque
Un élément hors maquette sur Vision alternative.

BUn arrêt au toucher

Pour le visiteur
Un doigt posé arrête, comme la souris au survol.
Pour notre travail
Quelques lignes, aucun élément visible.
Risque
Personne ne le devine ; la règle demande un moyen, un bouton est le seul sûr.

CLe mouvement réduit seulement (aujourd'hui)

Risque
Le visiteur gêné par le mouvement doit connaître le réglage de son système.
Recommandation : A pour le bandeau (le bouton de la vidéo arrête les deux) ; pour la constellation, B au minimum, A si Ryan accepte un bouton.Le bandeau est sur la page la plus vue et le bouton existe déjà. La dérive de la constellation est voulue par la maquette : un arrêt au toucher ne la change pas, un bouton la complète.

Décision

Bandeau

ABC

Constellation

ABC

Décidé le 08/10 : bandeau A (le bouton Pause de la vidéo l'arrête aussi) ; constellation C, rien (seul le mouvement réduit l'arrête).

3. Ce que l'Alliance gère, et ce que le thème écritPoints 25, 26 et 27

25La page Crédits dans WordPress

La question

La page Crédits : un titre, une phrase, et des colonnes « rôle, puis noms » (dix rôles). Le plan se contredit : sa section 3 met la structure dans page-credits.php, sa section 13 « le texte de la page dans l'éditeur ». Un éditeur de texte ne fait pas ces colonnes. Où vivent les noms ?

Pourquoi maintenant : c'est la page d'Imane ; le gabarit s'écrit dès qu'on sait où sont les noms.

La page Crédits : titre, phrase, colonnes de rôles et de noms
La page Crédits du prototype.

AStructure et noms dans le gabaritRecommandé

Pour l'Alliance (admin)
Rien à gérer ; la page existe dans l'admin pour son adresse et son titre.
Pour notre travail
Le tableau PHP du prototype passe tel quel dans page-credits.php.
Risque
Un nom à corriger demande un développeur ; les crédits changent rarement (à chaque nouvelle équipe).

BStructure dans le gabarit, un champ texte par rôle

Pour l'Alliance (admin)
Dix cases, un nom par ligne.
Pour notre travail
Dix champs ACF à créer, et le gabarit les lit.
Risque
De l'admin pour une page que l'Alliance ne touchera sans doute jamais.

CTout dans l'éditeur, sans colonnes

Pour le visiteur
Une liste simple.
Risque
Un écart à la maquette.

Décision

ABC

Décidé le 08/10 : A, structure et noms dans le gabarit.

26L'icône du site

La question

Le prototype a son icône (le « M » brun de l'ancien logo, depuis le 07/10) en trois fichiers : SVG, ICO et 180 px pour l'iPhone, écrits dans l'en-tête de chaque page. WordPress a son propre réglage, « Icône du site » (Apparence, Personnaliser, Identité du site). Lequel garde-t-on ?

Pourquoi maintenant : ces balises vont dans header.php, ou n'y vont pas.

L'icône du site, le M beige sur fond brun
favicon.svg
L'icône pour l'iPhone, 180 px
apple-touch-icon.png (180 px, affichée à moitié)

ALe réglage « Icône du site » de WordPressRecommandé

Pour l'Alliance (admin)
Elle peut la changer elle-même, sans développeur.
Pour notre travail
Un PNG carré d'au moins 512 px, une ligne de plus dans docs/outils/icones.py ; WordPress écrit lui-même ses balises (32, 180, 192 et 270 px).
Risque
Plus de SVG : l'icône est un PNG, nette quand même.

BLes fichiers du thème, comme le prototype

Pour l'Alliance (admin)
Ne peut pas la changer.
Pour notre travail
Les trois balises de template-parts/tete.php passent dans header.php.
Risque
Si quelqu'un remplit un jour le réglage de WordPress, deux icônes sont déclarées.

Décision

AB

Décidé le 08/10 : A, le réglage « Icône du site » de WordPress.

27Un champ e-mail dans le formulaire de contact

La question

Le formulaire de la maquette a quatre champs : Nom, Prénom, Sujet, Message. Aucun champ e-mail : quand un message arrive, l'Alliance ne peut pas répondre. Ajoute-t-on un champ e-mail, obligatoire ?

Pourquoi maintenant : page-contact.php reprend ce HTML, et l'extension de formulaire a besoin de la liste définitive des champs (I13). Les étiquettes et l'autocomplétion sont déjà ajoutées dans le prototype.

Le formulaire de contact : Nom, Prénom, Sujet, Message
La maquette : quatre champs.
Simulation : le formulaire avec un champ E-mail sous le prénom
Option A (simulation) : un champ « E-mail » sous le prénom, 51 px de plus.

AUn champ e-mail obligatoireRecommandé

Pour le visiteur
Il donne son adresse et reçoit une réponse.
Pour notre travail
Un champ type="email", autocomplete="email", avec son étiquette, sur le modèle des autres.
Risque
Un écart à la maquette, de 51 px.

BLa maquette telle quelle

Pour l'Alliance
Des messages sans moyen de répondre, sauf si le visiteur écrit son adresse dans le message.

Dans les deux cas, une page Confidentialité devient nécessaire dès que le formulaire collecte des données (elle est en « # » dans le pied de page aujourd'hui). Le client a deux questions ouvertes : 2.6 (quelle adresse reçoit les messages) et 2.12 (veut-il ce champ).

Décision

ABAttendre la réponse du client (2.12)

Décidé le 08/10 : A, un champ e-mail obligatoire.

4. Les détailsPoints 30 et 31

30Les archives par date de WordPress

La question

WordPress crée tout seul des pages d'archives par date (/2025/, /2025/06/) et pose alors la classe date sur le <body>. Or .date est aussi une classe de la frise (la date d'un bloc, position: absolute) : sur ces pages, tout le corps serait placé comme une date. Personne ne les utilise. Les coupe-t-on ?

Pourquoi maintenant : la classe vient de WordPress (get_body_class()), pas de nous ; sans rien faire, on le découvrirait le jour où un article existe pour une date et qu'un moteur de recherche visite /2025/ (N14).

// Pas d'archives par date : personne ne les utilise, et leur classe « date » sur le <body>
// est aussi une classe de la frise (position: absolute)
function marais_sans_archives_date() {
    if ( is_date() ) {
        global $wp_query;
        $wp_query->set_404();
        status_header( 404 );
    }
}
add_action( 'template_redirect', 'marais_sans_archives_date' );

ALes couper (le code ci-dessus, dans functions.php)Recommandé

Pour le visiteur
Une adresse par date mène à la page 404.
Pour notre travail
Une fonction, un bloc de plus dans functions.php.

BPréfixer les classes génériques de la frise

Pour notre travail
.date, .titre, .carte, .image renommées dans des centaines de règles et les 34 blocs.
Risque
Un gros renommage, juste avant la copie dans le thème.

Décision

AB

Décidé le 08/10 : A, les archives par date coupées.

31Sept petits choix de mise en page

Chacun se tranche en une phrase. Le c est le seul à fixer avant de générer les 32 blocs de la frise dans le thème.

Le choixLes optionsRecommandé
a (M9)Crédits : le lien « Techniques infographiques Web » est souligné ; la maquette ne souligne que « Haute École Francisco Ferrer ».Garder le soulignement ; suivre la maquette.Le garder (un lien se reconnaît), et le signaler à Ryan pour la maquette.
b (M10)Premier écran de la frise : le nom « Aujourd'hui » de la bande passe sous la fin de la date du bloc 02 (« 1994 »).Remonter la date de 26 px de maquette ; un fond sous les noms de la bande ; rien.Remonter la date : une règle dans la CSS du bloc 02.
c (M11)Carte d'un bloc de la frise : seule sa flèche (21 x 19 px) est un lien ; ailleurs sur le site, les cartes sont cliquables en entier.Toute la carte cliquable ; la flèche seule.Toute la carte : .carte__lien::after { inset: 0 }, une règle pour les 32 cartes.
d (N1)Moments clés : cinq cartes sur trois colonnes, une case vide au bout de la deuxième rangée.Laisser la case vide ; la dernière carte s'étire ; deux colonnes quand le nombre ne tombe pas juste.Laisser la case vide : le nombre de cartes changera à chaque action, et la grille marche avec tous.
e (N19)Le fil d'Ariane, décidé avec le client le 22/09 : absent de la maquette FINALE, du prototype et du plan.L'ajouter sur les fiches ; l'abandonner.Le reposer au client à la prochaine réunion ; d'ici là, la maquette FINALE fait foi.
f (M50)Le focus clavier : aucune règle commune, 35 éléments sur 36 gardent l'anneau bleu du navigateur.Une règle commune (contour brun de 2 px, décalé de 2 px) ; l'anneau du navigateur.La règle commune, dans la section 1 de site.css.
g (N26)L'intro 3D : sa place dans le site n'est pas décidée, mais ses 5 Mo de vidéos partiraient dans le thème avec assets/.Ne pas les copier tant que sa place n'est pas décidée ; les copier.Ne pas les copier : les exclure de l'étape 4 de la section 19 du plan.
La date 19.08.1994 du bloc 02 qui recouvre le nom Aujourd'hui de la bande
b : « Aujourd'hui » sous « 1994 » (1512 x 982).
La phrase de Crédits avec ses deux liens soulignés
a : les deux liens de Crédits, soulignés.
Une carte de la frise : seule la flèche en bas à droite est un lien
c : la carte du bloc 22 ; seule la petite flèche en bas à droite est un lien.
Les moments clés : cinq cartes sur trois colonnes, une case vide
d : les moments clés, une case vide au bout de la deuxième rangée.

Décisions

a, le lien de Crédits

Décidé le 08/10 : gardé souligné (signalé à Ryan pour la maquette).

b, la date du bloc 02

Décidé le 08/10 : remontée de 26 px de maquette.

c, la carte de la frise

Décidé le 08/10 : toute la carte cliquable.

d, la rangée incomplète

Décidé le 08/10 : la case vide reste.

e, le fil d'Ariane

Décidé le 08/10 : abandonné (la maquette FINALE n'en a pas).

f, le focus

Décidé le 08/10 : une règle commune, contour brun de 2 px décalé de 2 px.

g, l'intro 3D

Décidé le 08/10 : vidéos et code hors du thème tant que sa place n'est pas décidée.

Après les décisions

  1. Chaque décision est reportée et datée dans le plan WordPress, section 14, et dans la liste des décisions du fichier de reprise.
  2. Celles qui changent le rendu (22, 23, 24, 28, 29, 31 b, c et f) se font d'abord dans le prototype, avec des captures avant / après sur les huit formats du banc d'essai, puis le thème recopie le prototype.
  3. Celles qui ne concernent que WordPress (25, 26, 27, 30, 31 g) passent dans le plan et le code en réserve (docs/en-reserve/wordpress-gabarits/).
  4. Ensuite, l'ordre de construction de la section 19 du plan.