Besoin d'un regard extérieur

Bonjour à tous

Comme je l'ai déjà dit, je suis en train de remettre à peu près d'équerre un site ancien.
Dans une période intermédiaire de ce travail, je tombe sur un problème que je ne comprends pas. Comme d'habitude il doit s'agir d'une chose évidente qui devrait me crever les yeux, mais ça fait plusieurs heures que je pédale dans le brouillard.

Pourriez vous jeter un coup d’œil sur http://www.osirisnet.net/tombes/nobles/roy/roy_01.htm
et son homologue http://tests.osirisnet.net/tombes/nobles/roy/roy_01.htm

Il s'agit de balises <table> contenant des images, avec un système d'encadrement basé sur des images en background.
C'est ce genre de choses que je voudrais améliorer, mon intention étant à terme de remplacer ces <table> par des <figure>.

Lors de la première étape de travail, je me contente de "greffer" la cascade de <table> dans un <article>. Je m'attendais à ce que la présentation reste la même, mais je constate que les <table> contenant des images se mettent à envahir toute la largeur de l'écran, alors qu'elles devraient se limiter à prendre la largeur du contenu.

Il doit s'agir d'un problème de CSS, mais je n'arrive pas à mettre le doigt dessus.

Votre aide serait précieuse.
Modifié par PapyJP (18 Jul 2016 - 14:53)

Bonjour !

Eh non, ce n'est pas un problème CSS, enfin pas tout à fait... Dans la page qui fonctionne, les cellules des tableaux ont pour attribut des width sans unité (ce qui doit les traduire en px, j'imagine...) tandis que dans la page qui a un comportement bizarre, les cellules des tableaux ont pour attribut des width avec pourcentage...

Zelena a écrit :
Bonjour !

Eh non, ce n'est pas un problème CSS, enfin pas tout à fait... Dans la page qui fonctionne, les cellules des tableaux ont pour attribut des width sans unité (ce qui doit les traduire en px, j'imagine...) tandis que dans la page qui a un comportement bizarre, les cellules des tableaux ont pour attribut des width avec pourcentage...

Oui, c'est mon programme de transformation qui calcule l'équivalent en pourcentage pour permettre, dans une certaine mesure, les width en pixels en width en %. L'objectif est de préparer une certaine capacité d'adaptation aux tailles d'écran.
En quoi cela peut il explique le phénomène?

Rien que pour voir, je vais retirer cette partie du programme, mais je je crois pas que cela change grand chose.

Ça alors! Tu as raison, ça marche, mais j'aimerais comprendre pourquoi...

Dans la doc on trouve
The width attribute of <td> is not supported in HTML5. Use CSS instead.
Mais quand je mets un <td style="width:xx%"> ça ne semble pas mieux marcher....
Modifié par PapyJP (18 Jul 2016 - 14:53)

sur les tables, en mode normal en tout cas (je ne sais pas pour le fixed) la largeur en % d'une cellule se réfère au parent de <table> et non à <table>. Les tableaux se dimensionnant en priorité par les enfants plutôt que par les parents, une taille en % est souvent source d'incompréhension.

kustolovic a écrit :
sur les tables, en mode normal en tout cas (je ne sais pas pour le fixed) la largeur en % d'une cellule se réfère au parent de <table>; et non à <table>. Les tableaux se dimensionnant en priorité par les enfants plutôt que par les parents, une taille en % est souvent source d'incompréhension.

Une raison de plus pour "un usage raisonné" des <table>, mais dans ce cas de figure, je me bats avec des <table> mal fichues, imbriquées, ... J'ai essayé de faire un programme qui les supprime totalement, mais c'est trop compliqué à programmer, il faudrait revoir les pages manuellement... et il y en a qu mois 800. A raison d'une heure par page, c'est une affaire de 6 mois de boulot!

Il n'y a que vous qui savez de quoi ont l'air toutes les pages...

Tel que je vois, je supprimerais tous les td qui ont pour un attribut background qui commence par /luluborder, ensuite tous les tr qui sont vides, ne devrait rester que <table><tr><td>Le contenu intéressant</td></tr></table>, à changer en <quelque chose>Le contenu intéressant</quelque chose>

Sinon...

PapyJP a écrit :

A raison d'une heure par page, c'est une affaire de 6 mois de boulot!

vous avez des amis ?


Modifié par Zelena (18 Jul 2016 - 17:50)

Oui, j'ai fait un code un peu plus sophistiqué qui remplace les <table> qui contiennent des images par quelque chose de plus sympa, en fait un appel à JavaScript pour générer très simplement une balise <figure>. C'est la prochaine étape, j'espère y arriver après quelques heures de travail.
Le principal ennui c'est que les 800 pages en question ne sont pas homogènes. À chaque fois je tombe sur une nouvelle situation imprévue.
Quant aux copains, à mon âge on n'en a pas beaucoup qui accepteraient de perdre du temps à appliquer MON design. A la limite ils feraient leur propre design, ce qui paumerait davantage le malheureux propriétaire du site.
Ce site est intéressant tant pour les milliers de photos que pour ses textes qui font la renommée du spécialiste qui les écrit. On ne peut pas lui demander en plus d'être féru de HTML, CSS, JavaScript. PHP...
Modifié par PapyJP (18 Jul 2016 - 19:16)

PapyJP a écrit :

Ce site est intéressant tant pour les milliers de photos que pour ses textes qui font la renommée du spécialiste qui les écrit. On ne peut pas lui demander en plus d'être féru de HTML, CSS, JavaScript. PHP...

Qui sait ? Quand on aime les hiéroglyphes...

PapyJP a écrit :
Oui, j'ai fait un code un peu plus sophistiqué qui remplace les &lt;table&gt; qui contiennent des images par quelque chose de plus sympa, en fait un appel à JavaScript pour générer très simplement une balise &lt;figure&gt;. C'est la prochaine étape, j'espère y arriver après quelques heures de travail.
Le principal ennui c'est que les 800 pages en question ne sont pas homogènes. À chaque fois je tombe sur une nouvelle situation imprévue.
Quant aux copains, à mon âge on n'en a pas beaucoup qui accepteraient de perdre du temps à appliquer MON design. A la limite ils feraient leur propre design, ce qui paumerait davantage le malheureux propriétaire du site.
Ce site est intéressant tant pour les milliers de photos que pour ses textes qui font la renommée du spécialiste qui les écrit. On ne peut pas lui demander en plus d'être féru de HTML, CSS, JavaScript. PHP...

J'avais précédemment signalé l'existence de librairies Java telles que JSoup permettant d'importer des pages HTML existantes et reconstituer un DOM aisément modifiable.
Si le stock est de l'ordre de 800 pages, franchement je me pencherais sur une solution de ce type, ne serait-ce que pour faire un nettoyage itératif.
Si je comprends bien le processus actuel, les tables contenant des ressources graphiques son réécrites à la volée via javascript.
Pas sûr que ce soit une solution optimale à mon humble avis.
D'une part on ajoute une surcouche qui alourdit les pages en question, d'autre part rien n'est réglé sur le fond du problème.
Il me semble préférable de faire passer ces pages HTML dans une "moulinette" qui les remettra d'aplomb, au besoin après plusieurs passages successifs opérant chacun une restructuration ciblée. À moins que lesdites pages ne soient pas statiques mais générées dynamiquement, auquel cas c'est le source les générant qu'il convient de modifier.
A priori, vu le contexte, cela ressemble plus cependant à du "statique" accumulé au fil du temps par strates successives et qu'il faut aujourd'hui remettre d'équerre.
Quoi qu'il en soit, comme indiqué supra. La solution javascript me ferait fuir en courant...
Bon courage toutefois pour cette oeuvre de restauration.

Merci de ta réponse.
Ce que je fais, c'est un programme en PHP qui utilise les outils de gestion DOM. Il génère une fois pour toutes une nouvelle page HTML, donc une fois le programme passé il n'y a plus de couche supplémentaire en JavaScript, de temps perdu à tout restructurer, etc.
Pourquoi en PHP? Justement parce que ce langage possède des outils puissants de gestion du DOM -- en fait à peu près pareil que ce qu'on trouve en JavaScript -- et en plus il permet de sauvegarder le résultat dans un fichier.
Le programme marche assez bien, mais c'est la structure du DOM originel qui est un boulet, surtout que ces 800 pages ont été faites sur 15 ans, sans modèle de page bien structuré. Le seul critère de l'auteur c'était qu'il soit satisfait du rendu sur son écran.
Je ne peux pas le lui reprocher, simplement ça ne facilite pas le travail!