Remplacement d'un tableau pas une mise en page tableless [Résolu]

Bonjour,

Ca faisait longtemps que voulait me passer totalement des tableaux pour la mise en page (je suis en xhtml 1.1 strict et j'avais encore un tableau dans mes pages).

Je souhaite donc m'en passer totalement.

Tout d'abord, commençons par l'existant : (url supprimée)

Et voici le projet : (url périmée)

On peut voir que j'ai ajouté quelques fieldset afin de pouvoir organiser les champs par groupe, ce sera plus clair si l'utilisateur décide d'utiliser de nombreux champs.

Et comme les fieldset et table faisait mauvais ménage, je me suis résolu à tenter de faire disparaitre le table.

Reste un soucis : les 2 petites icônes à droit, le globe terrestre et l'enveloppe (qui ne sont pas systématiquement affichés) entraînent un décalage de champs de texte vers la gauche, et je n'arrive décidément pas à corriger ce dernier bug.

Alors il y a peut-être un truc que je n'ai pas compris et qui est évident pour vous, il y a peut-être une astuce ergonomique qui me permettrait de gérer la fonctionnalité d'une autre manière (voir la version démo pour l'utilisation), ou encore peut-être que mon problème est insoluble.

Dans tous les cas, je serais heureux de recueillir votre avis car il faut bien avouer que je commence à me décourager...

Merci de vos réponses !
Modifié par ploc (15 Jul 2009 - 11:33)

a écrit :
les 2 petites icônes à droit [...] entraînent un décalage de champs de texte vers la gauche

Oui, car les <p> de ton formulaire ( ) héritent le text-align:center de div.container, et deux éléments centrés (input + icone) débordent à gauche et à droite par rapport à un seul (pas claire mon explication, mais bon passons).

Bref, il faut rétablir l'alignement à gauche normal dans le contenu de ton form. Un bête text-align:left sur les div.record p devrait faire l'affaire. Il ne te restera plus qu'à recréer l'espacement entre label/input avec le padding/margin-droit des div.record label.

ploc a écrit :
je suis en xhtml 1.1 strict

Euh non, pour deux raisons:

1. Le XHTML 1.1 Strict n'existe pas. Il n'y a qu'une seule version de XHTML 1.1, pas de Strict et Transitional.
2. Tu ne fais pas du XHTML 1.1 vu que tu envoies tes contenus en text/html, ce qui est admis (mais pas spécialement conseillé) en XHTML 1.0, et interdit en XHTML 1.1.

D'ailleurs le validateur du W3C te signale quantité d'erreurs...

Mon conseil: fais (et déclare) du HTML 4.01, Strict ou Transitional suivant ton besoin. Ça correspond bien mieux à l'usage que tu fais de (X)HTML.

(Bien entendu, le fait d'utiliser HTML 4 ou XHTML 1 n'oblige à rien en termes de propreté du code, de balisage sémantique, de séparation du contenu et de la mise en forme, etc.)

Florent V. a écrit :
1. Le XHTML 1.1 Strict n'existe pas. Il n'y a qu'une seule version de XHTML 1.1, pas de Strict et Transitional.

Disons que le XHTML 1.1 est intrinsèquement strict.

Dans le même genre, un peut dire qu'une Ferrari est intrinsèquement rouge, mais on peut quand même parler d'une Ferrari rouge.

Oui je sais, il existe des Ferrari jaunes ou noires, il y a des exceptions, c'est pour ça que le XHTML 1.1 est parfois servi en text/html (voir point suivant).

Florent V. a écrit :
2. Tu ne fais pas du XHTML 1.1 vu que tu envoies tes contenus en text/html, ce qui est admis (mais pas spécialement conseillé) en XHTML 1.0, et interdit en XHTML 1.1.

Je me suis basé sur une faq de Alsacreations pour aboutir à la conclusion que je voulais faire du XHTML 1.1 (pour être on the edge), mais qu'il me fallait le servir en test/html pour qu'il reste compatible avec IE 6 et 7.

Je vois bien que la conclusion de cette faq est cohérente avec le point de vue que tu exprimes, mais j'aimerais bien en savoir plus. En quoi mon choix est-il mauvais ?

Florent V. a écrit :
D'ailleurs le validateur du W3C te signale quantité d'erreurs...

Regarde la version démo, elle est bien valide pour le W3C. C'est pourtant du XHTML 1.1 servi en text/html.
Modifié par ploc (07 Jul 2009 - 15:02)

ploc a écrit :
Dans le même genre, un peut dire qu'une Ferrari est intrinsèquement rouge, mais on peut quand même parler d'une Ferrari rouge.

Oui je sais, il existe des Ferrari jaunes ou noires, il y a des exceptions, c'est pour ça que le XHTML 1.1 est parfois servi en text/html (voir point suivant).

Si je ne m'abuse, la couleur normale d'une Ferrari est Jaune. Le rouge est à cause de la couleur de l'italie en grand prix (le rouge donc)

Sinon, j'aimerais avoir également la réponse sur cette page valid xhtml 1.1 servie en text/html.

Et j'ai une question pour toi ploc : Puis-je connaitre le cheminement qui t'a fait conclure qu'il fallait du xhtml 1.1 pour ton projet ? J'ai plutôt l'habitude d'utiliser du xhtml 1.0 servi en text/html et j'aimerais bien savoir ce qui te pousse à utiliser ça. Merci
Modifié par Niaa (07 Jul 2009 - 17:40)

Niaa a écrit :
Si je ne m'abuse, la couleur normale d'une Ferrari est Jaune. Le rouge est à cause de la couleur de l'italie en grand prix (le rouge donc)

Ce sujet fait l'objet de nombreuses controverses et je ne souhaite pas relancer ce débat qui est pour le coup hors-sujet par rapport au point de départ. Reste qu'il n'y a pas de couleur "officielle" pour Ferrari. Seulement, demande à ton entourage, va consulter le site de Ferrari, tu verras que dans l'inconscient collectif, une Ferrari, c'est rouge !

Il parait que les premières Ferrari étaient jaune, c'est vrai. Mais cela s'explique par le fait que Enzo Ferrari était pilote pour Alfa Romeo dont la couleur officielle était rouge, il n'aurait donc pas pu reprendre la même couleur pour Ferrari. D'autres disent que c'est parce qu'il a quitté Alfa Romeo en mauvais terme et aurait donc choisi la couleur jaune. Et alors pourquoi aurait-il quitté le jaune pour revenir au rouge ? Bref, la question est sans fin, et finalement sans trop d'intérêt. Vous aviez ce que je voulais dire dans mon exemple initial de Ferrari, non ?

Niaa a écrit :
Et j'ai une question pour toi ploc : Puis-je connaitre le cheminement qui t'a fait conclure qu'il fallait du xhtml 1.1 pour ton projet ? J'ai plutôt l'habitude d'utiliser du xhtml 1.0 servi en text/html et j'aimerais bien savoir ce qui te pousse à utiliser ça. Merci

Simplement la volonté de pousser les standards dans l'arène du web, de montrer ce qu'on peut faire avec les standards. Et tant qu'à utiliser un standard, autant utiliser sa dernière version. Mais je me trompe peut-être de mode de pensée !
Modifié par ploc (07 Jul 2009 - 18:04)

a écrit :
Et tant qu'à utiliser un standard, autant utiliser sa dernière version.

Donc pour toi, l'XHTML est le successeur d'HTML ?

Si oui, c'est là qu'est ton problème ^^;


Servir de l'XHTML en text/html (en plus c'est indiqué : "html") c'est détourner l'XHTML de son vrai but (celui d'utiliser des objets xml). Avec l'XHTML 1.1 c'est encore plus vrai puisqu'il ne tolère pas le text/html. D'ailleurs tu argais que ta version démo était servie en text/html alors que dans son code source on trouve :

<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />

Accessoirement, pour être "on the edge" (of what exactly, who knows?) c'est plutôt de l'HTML 5 que tu devrait utiliser, mais comme il n'est pas encore bien implémenté dans les navigateur, tu peux toujours te contenter d'HTML 4.01 qui est LE standard HTML pour servir des pages en text/html.

Laurie-Anne a écrit :
Donc pour toi, l'XHTML est le successeur d'HTML ?
Si oui, c'est là qu'est ton problème ^^;

C'est ce que je crois oui. Si ce n'est pas le cas, à quoi sert-il ce xhtml ?

Laurie-Anne a écrit :
Servir de l'XHTML en text/html (en plus c'est indiqué : "html") c'est détourner l'XHTML de son vrai but (celui d'utiliser des objets xml).

Peut-être mais ce n'était pas mon but (de détourner l'xhtml), c'est juste une contrainte (ou un hack) pour conserver un semblant de compatibilité avec IE6 et IE7.

Laurie-Anne a écrit :
D'ailleurs tu argais que ta version démo était servie en text/html alors que dans son code source on trouve :

<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />

Ce qui compte, ce n'est pas le content-type des balises meta, c'est le vrai content-type, celui du header http !

Laurie-Anne a écrit :
Accessoirement, pour être "on the edge" (of what exactly, who knows?) c'est plutôt de l'HTML 5 que tu devrait utiliser, mais comme il n'est pas encore bien implémenté dans les navigateur, tu peux toujours te contenter d'HTML 4.01 qui est LE standard HTML pour servir des pages en text/html.

A l'époque où j'ai fait le choix, on ne parlait pas encore du html 5, donc c'est vite vu. Reprenons cette analyse aujourd'hui, pourquoi préférer du html 4.01 ou du xhtml 1.1 ? Qu'est-ce qui peut orienter le choix et faire pencher la balance d'un côté ou de l'autre ?
Modifié par ploc (08 Jul 2009 - 15:05)

ploc a écrit :
C'est ce que je crois oui. Si ce n'est pas le cas, à quoi sert-il ce xhtml ?

On a donc trouvé le problème... XHTML est un mélange d'HTML et de XML, mais certainement pas un successeur du premier. C'est un standard complètement différent dont le but est d'utiliser des applications XML.

ploc a écrit :
Ce qui compte, ce n'est pas le content-type des balises meta, c'est le vrai content-type, celui du header http !

Le problème, c'est surtout l'incohérence.

ploc a écrit :
A l'époque où j'ai fait le choix, on ne parlait pas encore du html 5, donc c'est vite vu. Reprenons cette analyse aujourd'hui, pourquoi préférer du html 4.01 ou du xhtml 1.1 ? Qu'est-ce qui peut orienter le choix et faire pencher la balance d'un côté ou de l'autre ?

Comme on dit : "seuls les imbéciles ne changent pas d'avis".

A partir du moment où XHTML 1.1 n'est pas exploitable pour la toile en dehors d'applications bien définie dont on sait que l'utilisateur utilisera un navigateur capable de comprendre le xhtml+xml, le choix est assez facile.

Faire du XHTML servi en text/html, c'est faire de l'HTML.

(Apparté sur les Ferrari et les analogies: l'analogie facile, c'est la mort de la pensée. La discussion sur la couleur des Ferrari dans ce sujet prouve bien à quel point on peut s'enliser dans une analogie non pertinente. Et comme dans 90% des cas on choisit mal ses analogies, le littéraire que je suis recommande fortement de s'en passer et de formuler ses arguments autrement.)

Sur l'appelation «XHTML 1.1 Strict»: on peut considérer que c'est un détail, maisil n'y a qu'une seule version de XHTML 1.1, et elle ne s'appelle pas XHTML 1.1 Strict. La notion de Strict/Transitional n'existe pas en XHTML 1.1, tout bêtement. Pas besoin d'aller chercher plus loin, et d'invoquer l'inconscient collectif.

ploc a écrit :
il y a des exceptions, c'est pour ça que le XHTML 1.1 est parfois servi en text/html (voir point suivant)

Cette exception-là s'appelle une erreur. Ça s'appelle ne pas respecter la spécification, et donc produire un document invalide.

ploc a écrit :
Je me suis basé sur une faq de Alsacreations pour aboutir à la conclusion que je voulais faire du XHTML 1.1 (pour être on the edge), mais qu'il me fallait le servir en test/html pour qu'il reste compatible avec IE 6 et 7.

- Cet article ne dit pas que faire du XHTML 1.1 c'est être à la page (ça serait même plutôt has been depuis deux-trois ans ).
- Cet article dit par contre qu'il est interdit de servir du XHTML 1.1 en text/html (c'est écrit noir sur blanc, je te laisse relire ).

Si le fait d'être «on the edge» t'intéresse, je te recommande de faire du HTML 5.
Si ton but est d'étendre tes documents HTML avec des objets XML (notamment SVG et MathML), alors tu peux faire du XHTML (1.1 pourquoi pas), en le servant en application/xhtml+xml afin qu'il soit parsé par le parser XML des navigateurs (pour ceux qui l'acceptent).

ploc a écrit :
En quoi mon choix est-il mauvais ?

En pratique il n'a que très peu de conséquences. Très concrètement, ton code est du HTML (pas du XML), plutôt dans la ligne de HTML 4.01. Si tu t'amusais à envoyer ce code en application/xhtml+xml, tu te retrouverais avec des erreurs de parsing (et donc une page qui ne s'affiche pas) car ton code n'est pas du XML bien formé. Donc déclarer ce code pour ce qu'il est (du HTML 4) serait une simple question de logique.

ploc a écrit :
Regarde la version démo, elle est bien valide pour le W3C. C'est pourtant du XHTML 1.1 servi en text/html.

Il s'agit soit d'un bug du validateur, soit d'une limitation dans son mode de fonctionnement. Il ne vérifie apparemment pas le type MIME déclaré par le serveur (text/html pour la page que tu indiques).

ploc a écrit :
Reprenons cette analyse aujourd'hui, pourquoi préférer du html 4.01 ou du xhtml 1.1 ? Qu'est-ce qui peut orienter le choix et faire pencher la balance d'un côté ou de l'autre ?

HTML 4:
- est compatible (à 95% ou plus) avec tous les navigateurs existants;
- est tolérant aux erreurs (un code mal formé sera interprété tant bien que mal par les navigateurs);
- permet de décrire des documents simples, de les relier par des liens, d'utiliser CSS et JavaScript, et d'inclure des contenus riches via des plugins (Flash notamment).

XHTML 1.1:
- n'est pas compatible avec un navigateur majeur du marché (Internet Explorer, y compris dans sa version 8);
- est intolérant aux erreurs (un code mal formé ne sera pas interprété et donc la page ne sera pas affichée);
- permet de décrire des documents simples, de les relier par des liens, d'utiliser CSS et JavaScript, d'inclure des contenus riches via des plugins (Flash notamment), et d'inclure des contenus XML appartenant à un espace de nom autre que HTML (SVG, MathML, et un peu ce qu'on veut).

Pour ton usage, comme pour 99% des usages sur le Web, HTML 4 est plus approprié.

a écrit :
Ça s'appelle ne pas respecter la spécification, et donc produire un document invalide.

Servir du XHTML 1.1 en "text/html" est valide depuis cette année. La recommendation officielle a en effet été revue à cause du mauvais support d'"application/xhtml+xml" par les navigateurs. Le validateur est simplement à jour .

Merci marcv de ta réponse précise, concise et rapide. Elle m'a donné tous les éléments me permettant d'arriver à mes fins !

marcv a écrit :
les <p> de ton formulaire ( ) héritent le...

Y'a une blaque ici ?

marcv a écrit :
(pas claire mon explication, mais bon passons)

J'ai compris pourtant...

marcv a écrit :
Bref, il faut rétablir l'alignement à gauche normal dans le contenu de ton form. Un bête text-align:left sur les div.record p devrait faire l'affaire. Il ne te restera plus qu'à recréer l'espacement entre label/input avec le padding/margin-droit des div.record label.

C'est limpide... une fois l'explication donnée. J'ai pourtant cherché pas mal de temps dans mon coin avant de poster sur le forum d'Alsacréations... Alors je me dis que j'ai probablement une faiblesse dans le domaine des CSS : si j'ai compris le principe global du C de CSS (cascading), je dois probablement ne pas bien maîtriser quoi hérite de quelles propriétés de quoi... (quelle est la hiérarchie CSS). Auriez-vous un support de documentation (site web, bouquin, pdf) à me conseiller pour m'améliorer sur ce sujet ?

Autre question, est-ce que vous auriez des outils à me conseiller afin de pouvoir mieux analyser la page web que j'édite, de comprendre l'articulation des éléments de la page et les liens avec la feuille de syle css afin de comprendre quels sont les attributs de chaque élément. J'ai cru entendre parler d'extension Firefox qui allaient dans ce sens (firebug ?).

Enfin, si vous avez des remarques plus générales sur la structuration de ma page html, et sur les styles css, n'hésitez pas à faire preuve de votre maîtrise de ces technologies à partir du code écrit par un autre...

http://ploc.free.fr/phpmyaddressbook/demo/

Dernière petite question, peut-on forcer la mémorisation d'information dans le presse-papier ? C'est une demande utilisateur de pouvoir effectuer un copier/coller des coordonnées d'un contact. Je voudrais donc rajouter un bouton permettant de mettre dans le presse-papier les coordonnées du contact affiché. Je me dis que ca n'est pas possible, mais on sait jamais...
Modifié par ploc (10 Jul 2009 - 11:07)

a écrit :
quoi hérite de quelles propriétés de quoi... (quelle est la hiérarchie CSS). Auriez-vous un support de documentation

Oui

a écrit :
outils à me conseiller afin de pouvoir mieux analyser la page web que j'édite

Firebug et la Web Developer Toolbar. Indispensables autant l'un que l'autre.

a écrit :
peut-on forcer la mémorisation d'information dans le presse-papier

À ma connaissance, pas de manière standard. C'est peut-être possible, toutefois :
- moyennant un réglage du navigateur (donc ça te limite à une utilisation en intranet)
- via des fonctions propriétaires, et donc différentes sous chaque browser (si elles existent...)
Modifié par marcv (10 Jul 2009 - 11:22)

Laurie-Anne a écrit :
XHTML est un mélange d'HTML et de XML, mais certainement pas un successeur du premier. C'est un standard complètement différent dont le but est d'utiliser des applications XML.

[...]

A partir du moment où XHTML 1.1 n'est pas exploitable pour la toile en dehors d'applications bien définie dont on sait que l'utilisateur utilisera un navigateur capable de comprendre le xhtml+xml, le choix est assez facile.

Dans tout ça, je comprends seulement que ton avis est que XHTML ne doit pas être utilisé dans mon cas.

Surtout, je ne comprends pas à quoi sert XHTML et dans quels cas l'utiliser...

marcv a écrit :
Servir du XHTML 1.1 en "text/html" est valide depuis cette année. La recommendation officielle a en effet été revue à cause du mauvais support d'"application/xhtml+xml" par les navigateurs. Le validateur est simplement à jour .

Bon, donc le valideur est à jour, le code xhtml de l'ancienne version comme celui de la nouvelle version sont tous les 2 valides.

Je vais vous paraître obtus, mais je ne vois toujours pas l'utilité de ne pas laisser en l'état.

Je pourrais :
- modifier le content-type
- modifier le xhtml en html 4 (concrêtement, ça veut dire quoi ?)

Mais je ne vois pas la raison qui m'amènerait à le faire. Notez que je suis de bonne volonté (je fais pas de mauvais esprit), j'aimerais seulement comprendre le pourquoi...

ploc a écrit :
Surtout, je ne comprends pas à quoi sert XHTML et dans quels cas l'utiliser...

Et c'est là qu'est le coeur du problème. Il y a quelques années, quand est apparu le XHTML, de nombreux experts on cru à tord (mais à l'époque on ne le savait pas) que XHTML serait le successeur de l'HTML, car il permettait de faire plus (applications XML). Malheureusement, cette croyance a été véhiculée jusqu'à aujourd'hui, peu sont les experts qui ont avoué s'être trompé et nombreux sont les débutants qui tombent sur des ressources datant de 2005 qui n'ont pas été mise à jour (il y a même des livres qui sont sorti cette année qui annoncent encore XHTML comme successeur d'HTML).

XHTML, a l'heure actuelle n'apporte rien de plus que l'HTML dans 99% des cas (le % restant représentant des projets particulièrement ciblés).

Un de mes profs de fac nous avait un jour dit (traduction approximative d'un vieux souvenir) que tant qu'on n'aurait pas des fichiers .xhtml on ne ferait jamais réellement du XHTML.

ploc a écrit :
Mais je ne vois pas la raison qui m'amènerait à le faire. Notez que je suis de bonne volonté (je fais pas de mauvais esprit), j'aimerais seulement comprendre le pourquoi...

Le pourquoi, c'est que pour me couper un morceau de fromage, je peux utiliser le hachoir géant de cuisine, mais que le petit couteau est tout aussi bien, moins dangereux et prévu pour ça.
Modifié par Laurie-Anne (10 Jul 2009 - 11:55)

Laurie-Anne a écrit :
Malheureusement, cette croyance a été véhiculée jusqu'à aujourd'hui, peu sont les experts qui ont avoué s'être trompé et nombreux sont les débutants qui tombent sur des ressources datant de 2005 qui n'ont pas été mise à jour (il y a même des livres qui sont sorti cette année qui annoncent encore XHTML comme successeur d'HTML).

C'est le cas des tutoriels d'Alsacréations, qui sont en XHTML 1.0 ?
Modifié par ploc (10 Jul 2009 - 14:45)

Laurie-Anne a écrit :
cette croyance a été véhiculée jusqu'à aujourd'hui, peu sont les experts qui ont avoué s'être trompé

Pardon, il ne s'agissait pas d'une croyance, XHTML était clairement destiné à remplacer HTML. Y avoir cru, avoir utilisé et recommandé le XHTML à l'époque est tout à fait normal, car c'est l'orientation que prenait alors le développement web. Le fait que les plans aient été revus aujourd'hui ne signifie pas que ceux qui croyaient au XHTML au début (moi le premier, et, soyons honnêtes, certainement chacun d'entre vous) se sont "trompés".

Pour en revenir à ton cas, ploc, le plus important n'est pas le format que tu choisis, mais plutôt que ton code soit propre et valide. Si XHTML vient un jour à être obsolète, d'abord c'est pas pour demain et ensuite tu auras déjà refait ton site 15 fois. Alors, relativise
Modifié par marcv (10 Jul 2009 - 12:41)

marcv a écrit :
Pour en revenir à ton cas, ploc, le plus important n'est pas le format que tu choisis, mais plutôt que ton code soit propre et valide. Si XHTML vient un jour à être obsolète, d'abord c'est pas pour demain et ensuite tu auras déjà refait ton site 15 fois. Alors, relativise

Si je comprends bien ce que dis marcv et les autres, le plus logique serait d'évoluer petit à petit vers du html 5 (du moins, quand les navigateurs proposeront un support correct) mais il serait excessif de porter mon code de xhtml 1.1 vers html 4.

J'ai bien compris ?
Modifié par ploc (10 Jul 2009 - 14:48)

Chacun t'a déjà donné son avis, ploc, tu as assez d'éléments pour décider par toi-même. Dans tous les cas, comme je te l'ai dit, xhtml ou html c'est vraiment une question secondaire. Ce qui compte c'est surtout ce que tu vas en faire.