/* ===========================================================================
   Vue TABLE -- seconde surface de saisie des heures (essai parallele, s17)

   Feuille SEPAREE de `heures.css` : les deux surfaces sont en concurrence, pas
   en heritage. Melanger leurs regles rendrait impossible de retirer la perdante
   sans casser la gagnante -- or l'une des deux partira.

   POLICES DE SAISIE A 16 px, non negociable : en dessous, Safari iOS zoome a la
   mise au point et n'en revient pas (defaut paye quatre fois dans ce projet).
   HAUTEURS A 36 px et non 44, ECART ASSUME avec le reste du projet (demande
   Thierry) : la ligne de saisie est une RANGEE de six champs cote a cote, pas
   six boutons isoles -- a 44 px elle ecrasait le tableau qu'elle sert a
   remplir. On raccourcit la boite, jamais le texte.
   =========================================================================== */

.tab-heures { padding: 0 .15rem 2rem; }

/* DEFILEMENT HORIZONTAL ASSUME. Six colonnes ne tiennent pas dans 390 px sans
   rendre chaque cellule illisible. Plutot que d'empiler les colonnes -- ce qui
   ne serait plus un tableau, et c'est un tableau qui est demande -- on laisse
   glisser. La DATE reste collee a gauche pour qu'on sache toujours quelle ligne
   on lit. */
.tab-cadre { overflow-x: auto; -webkit-overflow-scrolling: touch; }
/*  `table-layout: fixed` EST CE QUI FAIT OBEIR LES LARGEURS. En mode
    automatique -- le defaut -- le navigateur dimensionne chaque colonne sur son
    contenu le plus large, et le contenu le plus large est ici un CHAMP DE
    SAISIE : un `input[type=date]` reclame ~150 px d'office, un `input` sans
    `size` en reclame ~170. Mesure avant correction : la colonne Date faisait
    168 px pour des valeurs qui en demandent 60. Les declarations `width`
    ci-dessous n'etaient que des suggestions, et elles etaient ignorees.        */
.tab {
  border-collapse: collapse; table-layout: fixed; width: 100%; min-width: 600px;
  font: .84rem var(--sans); color: var(--encre);
}

/* --- en-tetes : le titre EST le bouton de tri ----------------------------- */
.tab thead th {
  position: sticky; top: 0; z-index: 2; background: var(--papier-2);
  border-bottom: 1.5px solid var(--encre); padding: 0; text-align: left;
  white-space: nowrap;
}
.tab-tri {
  width: 100%; background: none; border: none; cursor: pointer;
  font: .68rem var(--mono); text-transform: uppercase; letter-spacing: .07em;
  color: var(--encre-2); padding: .3rem .28rem; text-align: left;
  min-height: 30px;
}
.tab-tri.actif { color: var(--sapin); font-weight: 600; }
.tab-tri:hover { color: var(--sapin); }

.tab tbody td {
  padding: .16rem .28rem; border-bottom: 1px solid rgba(34,46,53,.12);
  vertical-align: middle;
}
/* UN JOUR SUR DEUX EST ASSOMBRI (30.07, jimma #3392, demande Thierry) : le
   tableau porte plusieurs lignes par journee, et rien ne disait ou l'une
   finissait. La classe est posee par `tableau.js` AU CHANGEMENT DE DATE, jamais
   par `nth-child` -- une rayure sur le rang alternerait a chaque ligne et ne
   dirait plus rien du jour.
   ASSOMBRIR ET NON ECLAIRCIR : le papier est deja le point le plus clair de la
   charte (#f3efe6), l'eclaircir n'irait vers rien. Le lavis est neutre
   (`--encre` a 6 %) et non teinte : les couleurs de cette vue DISENT quelque
   chose (bleu = pas encore descendue, rouge = a trancher), et un fond colore
   entrerait en concurrence avec elles.
   Il passe AVANT la regle de survol, qui doit continuer a se voir par-dessus. */
.tab tbody tr.jour-alt td {
  background: color-mix(in srgb, var(--encre) 6%, transparent);
}
.tab tbody tr:hover td { background: color-mix(in srgb, var(--sapin) 4%, transparent); }
.tab tbody tr.jour-alt:hover td {
  background: color-mix(in srgb, var(--sapin) 6%, color-mix(in srgb, var(--encre) 6%, transparent));
}

/* --- le depli qui ouvre la saisie ----------------------------------------- */
/*  IL NE PORTE PAS D'APLAT, ET C'EST UNE REGLE, PAS UN GOUT : dans ce projet
    les boutons pleins (`--sapin`) sont ceux qui ECRIVENT. Celui-ci n'ecrit
    rien, il ouvre un formulaire -- le ✓ de la rangee, lui, reste plein.
    Melanger les deux rendrait la distinction inutile partout ailleurs.
    Il partage donc la forme de « charger la suite » (meme role : un geste de
    navigation, pleine largeur, 44 px pour se viser sans regarder). SELECTEURS
    GROUPES et non recopies : deux regles identiques divergent a la 3e retouche. */
.tab-suite button, .tab-plus {
  width: 100%; min-height: 44px; cursor: pointer;
  background: none; color: var(--encre);
  border: 1.5px solid var(--bord-fort); border-radius: 4px;
  font: 600 .8rem var(--sans-fort); letter-spacing: .04em;
}
/*  HAUTEUR DE MOITIE (Thierry, 30.07, sur capture de l'appareil) : 22 px et non
    44. ECART ASSUME avec la regle des cibles au doigt, et il se defend par la
    GEOMETRIE : les 44 px valent pour un bouton ETROIT, qu'il faut viser en deux
    dimensions. Celui-ci fait toute la largeur de l'ecran -- on ne le manque pas
    en x, et 22 px de haut restent au-dessus du seuil ou le doigt derape.
    C'est pour cette raison qu'il perd sa hauteur et que « charger la suite »
    GARDE la sienne : les deux se ressemblent, mais l'un est en tete d'ecran et
    l'autre au bas d'une liste qu'on vient de faire defiler, vise sans regarder.
    D'ou la SEPARATION de la regle ci-dessus, qui les groupait.                 */
/*  `padding: 0` ET `line-height: 1` NE SONT PAS COSMETIQUES : sans eux le
    rembourrage par defaut du bouton pousse la boite a 25 px sous WEBKIT (donc
    sur l'iPhone) contre 22 sous Chromium -- `min-height` ne fait que poser un
    plancher, il ne plafonne rien. Mesure du 30.07 aux deux moteurs.            */
/*  `display: block` N'EST PAS DECORATIF : un bouton est `inline-block`, il vit
    donc dans une LIGNE DE TEXTE et se pose sur sa ligne de base -- ce qui glisse
    1 px de plus AU-DESSUS de lui, et lui seul (mesure : 8,19 px en haut contre
    7,19 en bas, pour deux marges pourtant identiques a 7,19). En bloc, la boite
    du paragraphe epouse le bouton et les deux ecarts tombent d'aplomb. On retire
    la CAUSE plutot que de rattraper la marge du haut, qui aurait rendu les deux
    valeurs differentes dans la feuille pour paraitre egales a l'ecran.          */
.tab-plus { min-height: 22px; padding: 0; line-height: 1; display: block; }
/*  MARGES HAUT ET BAS IDENTIQUES (Thierry, 30.07, sur capture de l'appareil) :
    7 px de chaque cote, mesures.
    CE QUI RENDAIT LE HAUT TROIS FOIS PLUS EPAIS n'etait PAS cette marge -- elle
    valait deja 3 px contre 7 en bas. C'etaient les 19,2 px de `main`
    (`padding: 1.2rem 1rem 4rem`, style.css) : 19,2 + 4,8 de `.tab-heures` + 3,2
    d'ici = 27 px mesures en haut, contre 7 en bas. Regler la marge du bouton
    sans voir ca n'aurait rien change -- c'est la cause qu'il fallait retirer.
    `main` EST PARTAGE PAR TOUTES LES VUES : on ne touche donc pas la regle, on
    la NEUTRALISE POUR CETTE VUE SEULE, par `:has()` sur l'enfant direct. Pas de
    marge negative -- elle rognerait le parent sans le dire, et le jour ou le
    rembourrage de `main` changerait, le compte serait faux en silence. Si un
    moteur ignore `:has()`, la regle tombe et on retrouve l'espace d'avant :
    laid, jamais casse.
    `.entete` est en `position: sticky` MAIS RESTE DANS LE FLUX : ces 19,2 px ne
    lui servaient pas de degagement, rien ne passe dessous en les retirant.     */
main:has(> .tab-heures) { padding-top: 0; }
.tab-plus-rang { margin: .45rem .15rem; }
/*  OUVERT, IL DEVIENT DISCRET : la rangee de six champs qu'il vient de reveler
    est ce qu'on regarde, lui n'est plus qu'une porte de sortie. Il garde sa
    hauteur de cible -- on n'ampute pas un bouton parce qu'il a moins a dire. */
.tab-plus.ouvert {
  border-color: var(--bord); color: var(--encre-2); font-weight: 400;
}

/* --- ligne de saisie ------------------------------------------------------ */
/* Elle vit DANS le tableau, en tete : la colonne qu'on remplit est exactement
   sous son titre, et sous la valeur de la ligne precedente. C'est tout
   l'interet du format tabulaire -- la comparaison est immediate.
   ELLE N'EST PLUS PERMANENTE (jimma #3388) : `.tab-plus` la deplie, l'envoi la
   referme. Le CSS ci-dessous ne change pas pour autant -- c'est le gabarit qui
   decide de l'ecrire ou non, pas une regle d'affichage. */
.tab-saisie td {
  background: var(--carte); border-bottom: 2px solid var(--sapin);
  padding: .12rem .18rem;
}
/*  HAUTEUR RAMENEE A 36 px (demande Thierry : « trop grand et trop haut »).
    C'est un ECART ASSUME avec la regle des 44 px que suit le reste du projet :
    la ligne de saisie est UNE rangee de six champs cote a cote, pas six boutons
    isoles -- a 44 px elle ecrasait le tableau qu'elle sert a remplir.
    LA POLICE RESTE A 16 px, ET CELLE-LA N'EST PAS NEGOCIABLE : en dessous,
    Safari iOS zoome a la mise au point et n'en revient pas. Defaut deja paye
    QUATRE fois dans ce projet. On raccourcit la boite, jamais le texte.        */
.tab-saisie input, .tab-saisie select {
  width: 100%; min-width: 0;          /* min-width:0 : sans lui un champ ne
                                         passe pas sous sa taille de contenu */
  font: 16px var(--sans); padding: .1rem .25rem; min-height: 30px; height: 30px;
  border: 1px solid var(--bord); border-radius: 3px; background: #fff;
  color: var(--encre);
}
.tab-saisie input:focus, .tab-saisie select:focus {
  border-color: var(--sapin); outline: 2px solid color-mix(in srgb, var(--sapin) 30%, transparent);
}
/*  LA DATE : L'ICONE SEULE, ET SUR LE BUREAU UNIQUEMENT (demande Thierry --
    « la date est masquee -> garder que l'icone »).
    POURQUOI CETTE RESTRICTION AU BUREAU. Chromium rend un `input[type=date]` en
    DEUX morceaux : le texte editable (`::-webkit-datetime-edit`, « jj.mm.aaaa »)
    et la pastille de calendrier. Dans 76 px le texte est rogne et la colonne
    parait cassee. iOS Safari, lui, n'affiche AUCUNE pastille : il rend la valeur
    en clair et ouvre une roulette au toucher -- et Thierry constate qu'elle s'y
    affiche « en entier ».
    Masquer le texte partout retirerait donc a l'iPhone la seule chose qui l'y
    informe. La regle est bornee au bureau, ou la pastille existe pour prendre
    le relais.                                                                 */
@media (min-width: 821px) {
  .tab-saisie input[type="date"] {
    padding: 0; text-align: center; color: transparent;
  }
  .tab-saisie input[type="date"]::-webkit-datetime-edit { display: none; }
  .tab-saisie input[type="date"]::-webkit-calendar-picker-indicator {
    margin: 0 auto; padding: 0; opacity: .75; cursor: pointer;
  }
  .tab-saisie input[type="date"]:hover::-webkit-calendar-picker-indicator { opacity: 1; }
}

.tab-ok {
  min-height: 30px; min-width: 30px; cursor: pointer;
  background: var(--sapin); color: #fff; border: none; border-radius: 4px;
  font-size: 1.1rem; line-height: 1;
}

/* --- largeurs : calees sur le CONTENU, pas sur les champs ----------------- */
/*  Demande Thierry : « reduire date a la largeur des valeurs deja saisies,
    largeur mandat = NdD REN (exe) ». Les valeurs commandent, les champs de
    saisie s'y plient (ils sont en `width:100%` dans leur cellule).
      date     : « 28.07.26 » -- 76 px, le minimum ou le champ natif reste
                 utilisable ; les valeurs, elles, n'en demandent que 60 ;
      mandat   : « NdD REN (exe) » dans sa pastille -- 13 caracteres ;
      personne : les INITIALES seules (3 caracteres au plus : PoD).
    REMARQUE n'a AUCUNE largeur declaree, volontairement : en `table-layout:
    fixed` elle recupere tout le reste, et c'est la seule colonne dont le
    contenu est vraiment variable.                                             */
.tc-date_jour { width: 76px; white-space: nowrap; font-family: var(--mono); }
.tc-mandat_nom { width: 132px; }
.tc-type_nom { width: 124px; }
.tc-heures { width: 54px; }
.tc-personne_nom { width: 46px; text-align: center; font-family: var(--mono);
                   font-size: .78rem; color: var(--encre-2); }
.tc-sup { width: 42px; text-align: center; }
/*  En largeur fixe, une cellule ne s'elargit plus : ce qui deborde doit etre
    COUPE PROPREMENT plutot que de pousser le tableau. */
.tab tbody td { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; }
/*  PAS DE GRAS (demande Thierry) : dans une colonne de chiffres alignes a
    droite, l'alignement suffit a guider l'oeil -- le gras ne hierarchise rien
    puisque toutes les valeurs sont de meme nature.
    ET PAS DE TAILLE PROPRE NON PLUS (jimma #3390 : « taille heures = taille
    texte ») : la duree etait a .9rem quand le tableau est a .84 -- un ecart de
    7 % qui ne dit rien, puisque la colonne est deja reperee par son alignement
    et par sa chasse fixe. AUCUN RACCOURCI `font:` ICI, volontairement : il
    porterait une taille, et c'est precisement ce qu'on veut voir HERITER de
    `.tab` -- y compris le .82rem de la media query mobile, qu'un raccourci
    ecraserait sans qu'on s'en apercoive.                                      */
.tab-num { text-align: right; font-family: var(--mono); color: var(--sapin); }
/*  LA COULEUR DIT L'ORIGINE DE LA LIGNE (jimma #3389). Deux gestes identiques a
    l'ecran n'ont pas la meme portee : corriger une ligne DEJA descendue dans
    Access modifiera la comptabilite au prochain passage de la synchro, corriger
    une ligne nee dans JIMAYA non. L'editeur le dit deja en une phrase ; la
    couleur le dit pour la colonne entiere, sans l'ouvrir.
    LE BLEU EST LE DEFAUT, ET C'EST DELIBERE : si les classes cessaient d'etre
    posees, tout passerait au bleu -- « rien n'est descendu », un etat FAUX mais
    BRUYANT. L'inverse (tout en encre) affirmerait en silence que tout est
    synchronise, et personne n'irait verifier.                                 */
/*  ETENDU A LA DATE ET AU MANDAT (Thierry, 30.07) : les trois colonnes qu'on
    parcourt du regard disent le meme etat, plutot qu'un seul chiffre a droite.
    L'ETAT EST SUR LE `<tr>` -- une ligne est descendue ou non, une cellule n'a
    pas d'etat propre. La TACHE reste a `--encre-2`, volontairement : elle n'a
    pas ete demandee, et teinter la 4e colonne ferait de la couleur le sujet du
    tableau au lieu d'un renseignement en marge.
    Le selecteur nomme `.tab-pil` et non la cellule : la pastille porte sa
    propre `color`, une regle sur le `<td>` serait sans effet dessus (heritage
    perdu des qu'un descendant declare la sienne).

    QUATRE ETATS depuis la migration `20260730153000` -- c'est `v_heures.etat_sync`
    qui les rend, la feuille ne fait que les peindre :
      a_descendre   bleu   -- nee ici, jamais partie dans Access
      a_jour        encre  -- partie, et identique a ce qu'Access a recu
      a_redescendre orange -- partie, MAIS modifiee depuis
      a_trancher    rouge  -- comparaison impossible, `sync_ref` manque
    UNE VARIABLE PAR ETAT, PUIS UNE SEULE REGLE POUR LES TROIS COLONNES : sans
    ca il faudrait douze selecteurs (quatre etats fois trois colonnes), et la
    cinquieme couleur en demanderait trois de plus. Les proprietes personnalisees
    HERITENT -- posee sur le `<tr>`, `--etat` est lue par ses cellules.
    LE REPLI DE `var(--etat, ...)` EST LE BLEU, delibere : si une ligne arrivait
    sans etat, elle crierait « rien n'est parti » -- faux mais BRUYANT. Le repli
    inverse affirmerait en silence que tout est en ordre.                       */
tr.etat-a_descendre   { --etat: var(--sapin); }
tr.etat-a_jour        { --etat: var(--encre); }
tr.etat-a_redescendre { --etat: var(--sync-redescendre); }
tr.etat-a_trancher    { --etat: var(--rouge); }
tr[class^="etat-"] .tc-date_jour,
tr[class^="etat-"] .tc-mandat_nom .tab-pil,
tr[class^="etat-"] .tab-num { color: var(--etat, var(--sapin)); }

/* --- pastilles de libelle ------------------------------------------------- */
/* Reprise de la forme de Microsoft Lists : le mandat et la tache se REPERENT
   d'un coup d'oeil dans une colonne, ils ne se lisent pas mot a mot. */
/* La pastille de MANDAT est un BOUTON (elle ouvre la correction de la ligne),
   celle de TACHE reste un span. D'ou les remises a zero ci-dessous : sans
   `border: none` un bouton porte le cadre gris du systeme, et la colonne de
   132 px n'a pas de quoi le loger.
   POURQUOI ELLE, ET PAS UNE COLONNE DE PLUS AVEC UN CRAYON : les six colonnes
   tiennent a 337 px pres sur un iPhone SE (mesure du banc, s17) -- une septieme
   les ferait deborder. La pastille est deja la, et ne change pas de taille. */
.tab-pil {
  display: inline-block; max-width: 100%; overflow: hidden; text-overflow: ellipsis;
  white-space: nowrap; vertical-align: bottom;
  padding: .08rem .38rem; border-radius: 10px; border: none; margin: 0;
  text-align: left; cursor: pointer; color: var(--encre);
  background: color-mix(in srgb, var(--sapin) 12%, var(--papier-2));
  font: .8rem var(--sans-fort);
}
.tab-pil-t {
  background: var(--papier-2); font-weight: 400;
  color: var(--encre-2); font-family: var(--mono); font-size: .74rem;
}

.tab-sup {
  background: none; border: none; cursor: pointer; color: var(--encre-2);
  font-size: .85rem; min-height: 30px; min-width: 30px; padding: 0;
}
.tab-sup:hover { color: var(--rouge); }
.tab-vide { color: var(--encre-2); font-style: italic; padding: .8rem .4rem; }

/* --- « charger la suite » --------------------------------------------------
   LE FILET PORTE L'INFORMATION, PAS L'APLAT -- meme regle que la page de
   synchro. Un aplat plein en ferait le point le plus voyant du tableau alors
   qu'il ne fait que LIRE : les boutons pleins (`--sapin`) sont ceux qui
   ECRIVENT, et melanger les deux rendrait la distinction inutile.
   Pleine largeur et 44 px : c'est une cible au doigt, en bas d'une liste qu'on
   vient de faire defiler -- on la vise sans regarder. */
.tab-suite { margin: .6rem .4rem 1.2rem; }
.tab-suite button {
  width: 100%; min-height: 44px; cursor: pointer;
  background: none; color: var(--encre);
  border: 1.5px solid var(--bord-fort); border-radius: 4px;
  font: 600 .8rem var(--sans-fort); letter-spacing: .04em;
}
.tab-suite button:disabled { color: var(--encre-2); cursor: default; }

/* --- mobile --------------------------------------------------------------- */
/* Selecteurs REPETES EN ENTIER : une media query n'ajoute aucune specificite,
   et redeclarer une propriete d'un raccourci `font:` la perdrait. */
@media (max-width: 820px) {
  .tab-heures { padding: 0 .2rem 3rem; }
  /*  BUDGET DE LARGEUR, CALE SUR CE QUE LE MOTEUR DE SAFARI DEMANDE VRAIMENT.
      Regle posee par Thierry : les QUATRE premieres colonnes doivent tenir a
      l'ecran, Remarque non -- et on peut donc elargir un peu.
      352 px disponibles a 390 : 76 + 108 + 116 + 50 = 350.

      24 px PRIS A LA DATE ET DONNES A LA TACHE (Thierry, 30.07, sur capture de
      l'appareil : « Gestion d… », « Informati… » -- tronques en permanence).
      CE QUI A CHANGE, ET POURQUOI LA MESURE DE 89 px NE COMMANDE PLUS : elle
      valait quand la rangee de saisie etait PERMANENTE, donc quand le champ
      natif etait a l'ecran en meme temps que les valeurs. Depuis le depli
      (jimma #3388) il n'y parait que le temps d'une saisie. On ne paie donc plus
      28 px de mou en PERMANENCE pour un champ VISIBLE PAR INTERMITTENCE : la
      colonne suit desormais la VALEUR (« 30.07.26 », 72 px mesures sous WebKit).
      CONSEQUENCE ASSUMEE, ET C'EST LE COUT DU REGLAGE : rangee ouverte, le champ
      de date SORT ROGNE sur l'iPhone -- il reclame 89 px et n'en recoit que 67,
      l'ANNEE est coupee. Le jour et le mois, eux, restent lisibles, et le
      toucher ouvre la roulette native complete. Ne pas « corriger » ce rognage
      en rendant ses 24 px a la date sans redemander : ce serait retronquer la
      Tache, qui est lue tout le temps.                                         */
  .tab { min-width: 520px; font: .82rem var(--sans); table-layout: fixed; }
  .tc-mandat_nom { width: 108px; }
  .tc-type_nom { width: 116px; }
  .tc-heures { width: 50px; }
  .tc-personne_nom { width: 40px; text-align: center; font-family: var(--mono);
                     font-size: .74rem; color: var(--encre-2); }
  .tc-sup { width: 34px; text-align: center; }
  .tab tbody td { padding: .14rem .22rem; }
  .tab-saisie td { padding: .1rem .12rem; }
  /* Selecteur REPETE EN ENTIER : une media query n'ajoute aucune specificite */
  .tab-saisie input, .tab-saisie select {
    font: 16px var(--sans); min-height: 30px; height: 30px; padding: .1rem .2rem;
  }
  /* La DATE reste visible pendant le defilement horizontal : sans elle on ne
     sait plus quelle ligne on lit une fois arrive a la colonne Remarque. */
  /*  76 px ET NON 72 : « 30.07.26 » demande 72 px mesures (8 caracteres de
      chasse fixe + les .14rem de rembourrage), on garde 4 px de marge pour la
      police de repli, qui n'a pas la meme chasse si IBM Plex Mono tarde. En
      dessous, la valeur sort tronquee -- « 27.07… », l'annee coupee, defaut deja
      constate a 62 px.                                                        */
  .tc-date_jour { position: sticky; left: 0; z-index: 1; background: var(--papier);
                  width: 76px; white-space: nowrap; font-family: var(--mono); }
  .tab-saisie .tc-date_jour { background: var(--carte); }
  .tab thead .tc-date_jour { z-index: 3; background: var(--papier-2); }
  /* LA COLONNE DATE DOIT ALTERNER AUSSI (30.07, jimma #3392). Elle est `sticky`
     et porte donc son PROPRE fond OPAQUE -- sans quoi les lignes defileraient
     visiblement dessous. Ce fond ecrase le lavis translucide pose sur la
     rangee : sans cette regle, la premiere colonne serait la seule a ne pas
     alterner, et la rayure se lirait comme un defaut plutot que comme un
     reperage. Le lavis est donc REFAIT ICI SUR `--papier`, opaque, avec le
     meme dosage -- deux ecritures pour une seule intention, imposees par le
     `sticky`. Toucher l'une sans l'autre les fait diverger EN SILENCE. */
  .tab tbody tr.jour-alt .tc-date_jour {
    background: color-mix(in srgb, var(--encre) 6%, var(--papier));
  }
}

/* --- REEQUILIBRAGE DES COLONNES SUR LE BUREAU (Thierry, 01.08) -------------
   Tache +25 % (124 -> 155), Remarque -50 % (384 -> 192), texte de la Remarque
   a la taille de celui de la Tache. Regle d'abord posee dans la fenetre Samaya
   du widget, puis remontee ICI a la demande de Thierry (« on teste comme ca sur
   pwa ») -- c'est donc une DECISION, pas un effet de bord : la premiere version
   de ces lignes avait change la PWA sans qu'on l'ait voulu, et avait ete retiree.

   MOTIF MESURE : 28 valeurs de Tache sur 60 sortaient TRONQUEES dans 124 px,
   pendant que la Remarque en occupait 384 pour un contenu qui n'en demande
   jamais plus de 175. La colonne la plus large etait celle qui avait le moins a
   montrer. A +25 %, la Tache en tronque encore 12 sur 60 (0 a partir de 191) :
   c'est la consigne qui commande, pas la mesure.

   C'EST `tc-sup` QUI DEVIENT LA COLONNE SOUPLE. En `table-layout: fixed`, une
   colonne SANS largeur declaree prend tout ce qui reste ; si TOUTES en ont une,
   le moteur repartit le surplus sur toutes, proportionnellement -- mesure :
   declarer 155 et 192 rendait 191 et 236, les deux consignes se perdaient en
   route. Il faut donc UNE colonne souple, et la corbeille est la seule qui
   puisse grossir sans rien dire : l'espace en trop devient une marge muette au
   bord droit. `text-align: left` avec, sinon le 🗑 se centrerait au milieu de
   cette marge, loin de la ligne qu'il supprime.
   CE QUE CA DONNE ICI : `main` est plafonne a 880 px, le tableau fait donc
   ~848 px et il reste ~193 px de marge a droite. La fenetre Samaya, elle, est
   CALEE sur ses colonnes (725 px) et n'en laisse aucune -- une fenetre se
   dimensionne, une page de navigateur non.

   BORNE A `min-width: 821px`, ET EN FIN DE FEUILLE. Sur l'iPhone il n'y a rien
   a reequilibrer : la Remarque y vaut deja 96 px pour un texte qui en demande
   171, la reduire de moitie la rendrait illisible. Et une media query n'ajoute
   AUCUNE specificite : ecrit plus haut, ce bloc perdait contre les `.tc-*` de
   base declarees apres lui (mesure : la feuille disait 155, l'ecran rendait
   160). Le piege est ecrit dans cette meme feuille depuis s17.               */
@media (min-width: 821px) {
  .tc-type_nom { width: 155px; }
  .tc-remarques { width: 192px; font-size: .74rem; }
  .tc-sup { width: auto; text-align: left; }
}