Developper avec les standards web

christophe C wrote:

bon, alors je résume :
- si je crée des titres de colonnes, je les met dans un th, qui est dans
un tr, qui est dans un thead.
- et si je crée des titres de ligne, je les met dans un th, qui est dans
un tr (au début), qui est dans un tbody.

C'est bien ça ?

Voila. Même chose avec un tfoot qui peut avoir une première cellule type
"Total :" qui serait alors l'entête de la ligne.

Pour faire un vrai bon tableau, on peut ajouter headers et scope.
Attention cependant, le th n'est à utiliser que s'il s'agit vraiment
d'un titre, c'est-à-dire qu'une synthèse devrait lire "th de la colonne
- th de la ligne - cellule", "th de la colonne - th de la ligne -
cellule", etc. Sinon, c'est un td avec un scope. :-)

Des exemples ici:
http://www.w3.org/TR/html401/struct/tables.html#h-11.4.1
en [fr] (mais la-grange semble ne pas répondre):
http://www.la-grange.net/w3c/html4.01/struct/tables.html#h-11.4.1

A force d'utiliser les tableaux pour la mise en page, de moins de moins
de monde sait faire un vrai tableau. :-p

--
Fabrice Bonny

http://openweb.eu.org/
http://opquast.org/

"Fabrice Bonny" <fbonny@club-internet.fr> a écrit dans le message de
news:41401003$0$305$7a628cd7@news.club-internet.fr

A force d'utiliser les tableaux pour la mise en page, de moins de
moins de monde sait faire un vrai tableau. :-p

A mon sens le vrai prb est plus profond : quasiment personne n'a l'habitude
de structurer des données textuelles. Indiquer un titre, une citation,
etc...

Et pourquoi donc les entreprises imposeraient à leurs équipes de
journalistes, rédacteurs etc de changer ? Ca coûte *très* cher et ça
n'apporte pour ainsi dire rien. Certes les équipes techniques sont très
souvent à niveau aujourd'hui pour un web "sémantique", mais c'est pour
d'autres raisons : les CSS en particulier apportent de nombreux avantages
directement profitables, et le respect des standards au sens large encore
plus. Supprimer tous les font OK, mais réellement structurer son contenu qui
le fait, même chez des gens techniques ?

La vision d'un web avec du contenu réellement structuré est, dans ce sens, à
mon avis profondément utopique.

Un exemple : depuis le temps que les standards se sont imposés, je ne
connais pas un seul CMS qui ait une interface convaincante pour structurer
son texte en titres, paragraphes, ...

Comme quoi hein, il va falloir trouver un réel compromis entre la belle
théorie et les contraintes de production. Et ça devient vraiment urgent.

Le Thu, 09 Sep 2004 22:30:43 +0200, Fabrice Bonny a écrit :

Pierre Goiffon wrote:

A mon sens le vrai prb est plus profond : quasiment personne n'a l'habitude
de structurer des données textuelles. Indiquer un titre, une citation,
etc...

Mauvais outils d'édition et mauvaises habitudes, le traitement de texte
wysiwyg a fait des ravages. Disons qu'avec une méthode de saisie pas
trop coercitive on devrait pouvoir remettre un peu d'ordre...

[...]

Ne me pousse pas au teasing. ;-)

Je peux aussi ? Bientôt sur vos écrans...

La vision d'un web avec du contenu réellement structuré est, dans ce sens, à
mon avis profondément utopique.

Disons avant-gardiste.

Je manque cruellement de balises html en ce moment a telle point qu'une
bonne partie de la sémantique que je sais actuellement gérer se retrouve
dans les noms de classe... Certaines balises html se révèlent
inutilisables selon moi <dfn> en est un exemple. En revanche <address> est
sous-exploitée car j'aimerai pouvoir mettre :

<address>
<name>toto</name>
<street>...</name>
<city>Paris</city>
<phone>+33 ...</phone>
<mail><a href='mailto:toto@...'>toto@...</mail>
</address>

plutôt que :

<address>
toto<br />
...<br />
...
</address>

Ça va certainement prendre du temps effectivement mais je crois que la
machine est lancée.

@+
fb

François Battail wrote:

Le Thu, 09 Sep 2004 22:30:43 +0200, Fabrice Bonny a écrit :

[...]

Je manque cruellement de balises html en ce moment a telle point qu'une
bonne partie de la sémantique que je sais actuellement gérer se retrouve
dans les noms de classe... Certaines balises html se révèlent
inutilisables selon moi <dfn> en est un exemple. En revanche <address> est
sous-exploitée car j'aimerai pouvoir mettre :

<address>
<name>toto</name>
<street>...</name>
<city>Paris</city>
<phone>+33 ...</phone>
<mail><a href='mailto:toto@...'>toto@...</mail>
</address>

plutôt que :

<address>
toto<br />
...<br />
...
</address>

Et avec un liste de définition :
<address>
<dl>
<dt>name</dt>
<dd>toto</dd>
...
</dl>
</address>

Ça va certainement prendre du temps effectivement mais je crois que la
machine est lancée.

@+
fb

Et comme ça :


--
Raphaël
http://www.r-wils.com/perso
« Don't mean a thing if you ain't got that swing ! »

Le Fri, 10 Sep 2004 17:19:27 +0200, Raphaël Wils a écrit :

François Battail wrote:

<snip au sujet d'<address> />

<address>
toto<br />
...<br />
...
</address>

Et avec un liste de définition :
<address>
<dl>
<dt>name</dt>
<dd>toto</dd>
...
</dl>
</address>

Je ne veux pas faire apparaître name ;-) en revanche si html me
permettait une approche structurée je gérerais alors au niveau de toute
la chaîne la sémantique d'une adresse. Mais si je ne peux pas rendre le
résultat et qu'en plus cela n'a pas un intérêt exploitable
aujourd'hui (exemple imaginaire : Google lance un service d'annuaire
[postal] pour retrouver des coordonnées à partir des données
collectées sur les sites) je ne vais pas forcer "mes" utilisateurs à une
saisie contraignante alors que /dans cet exemple/ ils n'en retireront
aucun avantage direct ou indirect.

@+
fb

"François Battail" <francois.battail@wanadoo.fr.invalid> a écrit dans
le message de news:pan.2004.09.10.15.12.12.697518@wanadoo.fr.invalid

A mon sens le vrai prb est plus profond : quasiment personne n'a
l'habitude de structurer des données textuelles. Indiquer un titre,
une citation, etc...

Mauvais outils d'édition et mauvaises habitudes, le traitement de
texte wysiwyg a fait des ravages. Disons qu'avec une méthode de
saisie pas trop coercitive on devrait pouvoir remettre un peu
d'ordre...

Et ça me désespère de lire ce genre de réponses.
Le prb n'est pas dans l'outil de saisie : ce n'est quand même pas compliqué
de sélectionner un bout de texte et de le marquer comme "titre". Non, le
problème c'est pourquoi passer du temps à le faire : on voit très bien ce
que ça coûte, voyez vous de votre côté quelque chose qui justifie ce massif
investissement ?

Bien sûr ici on ne parle pas des champs adresse, etc. Ceux ci sont bien
structurées dans les bdd sous jacentes au contenu depuis les tout débuts, et
cela a été fait à raison : c'est déjà le cas sur de très nombreux
formulaires papiers ou non, et l'utilisation est souvent immédiate
(affichage d'un plan, ...) donc ça semble tout à fait justifié pour tout le
monde. Techniquement, sortir ces champs en (X)HTML structuré ne pose aucun
problème aux développeurs, juste un changement de template pour schématiser.

Non le problème, ce sont les champs texte de contenu : 1000, 2000, 3000
signes.
Et on ne stocke pas des contenus rédactionnels uniquement pour les sortir
sur le Web en général, du moins il ne vaut mieux pas rendre ses champs de
BDD (ou autre moyen de stockage...) dépendants du médium de sortie.

Bref, comme d'habitude, c'est possible (qu'est-ce qui ne l'est pas...), mais
voyez donc quels investissements cela demande ! D'autant que les systèmes de
publication ont des années dans les pates maintenant, ils ne sont plus tout
jeunes et donc plus tout flexibles.

"Mahi mahi" <bab@france.nc> a écrit dans le message de
news:414628d8$0$17690$626a14ce@news.free.fr

Le HTML n'est pas dégénéré !!! Pour une fois qu'un "outil"
informatique n'a pas été conçu uniquement pour les informaticiens

En quoi délimiter dans un texte une citation et préciser son auteur
concerne des non techniciens aujourd'hui ? Expliquez moi...

Je ne parle pas des balises, je parle du concept web qui tolère
beaucoup d'erreurs

Oh, je n'avais pas compris ça à vous lire ! Merci de la précision.

Je répondais sur la structuration excessive des contenus en regard des
contextes dans lequel se font les sites - le "monde réel", en quelques
sorte. Cette structuration, elle, est à mon avis uniquement une
problématique des techniciens aujourd'hui. En ce sens, le HTML tel que
défini par le W3C, qui penche de plus en plus vers une structuration
avancée, n'est pas vraiment à destination des personnels non techniques.

Plus généralement, autant n'importe qui pouvait réaliser facilement un site
il y a quelques années, autant si l'on souhaite suivre la même voie que le
W3C on s'impose l'intervention de personnels techniques.

"François Battail" <francois.battail@wanadoo.fr.invalid> a écrit dans
le message de news:pan.2004.10.02.05.11.35.874075@wanadoo.fr.invalid

Comment obliger un utilisateur à
structurer un champ texte de n signes ?

L'approche n'est pas forcément bonne : "un champ". Voyons plutôt
l'aspect document : tous les systèmes à ma connaissance demandent
quelques méta informations avant d'être en mesure de saisir le contenu
même du document

Je parle bien du rédactionnel en lui même, et pas des données que l'on peut
facilement typer autour : titre, dates de création et modifications, auteur,
...

La possibilité de réutiliser du contenu et de
placer des liens sur des articles déjà existants et ce genre de choses
n'est pas du domaine du traitement de texte, c'est là qu'il y a
inadéquation entre l'outil et le média. De plus en web on ne gère pas
un document mais un site ce qui plaide pour une approche centralisée
et donc des outils adaptés. Une saisie contraignante n'a de sens que
si les bénéfices sont directement perceptibles par l'utilisateur

Oui. C'est exactement ce qui m'a amené à réagir au message de Fabrice et
pour moi le centre de la problématique : le décallage entre les utilisations
aujourd'hui et la philosophie du "Web sémantique".

A mon sens - je me répète - ce n'est du qu'au fait que la structuration est
(sur le Web du moins) une préoccupation de techniciens pour des problèmes
purement techniques. Ca ne devrait pas, en l'état, ennuyer le rédacteur, le
commercial, etc. Car comme tu le dis, un non technicien n'a pas vraiment de
bénéfice à structurer du contenu.

Bref je ressent plutôt là un problème de philosophie : imposer aux
utilisateurs des obscurantismes techniques, et pour forcer le trait
exagémérement, avoir une vision du web telle que l'on peut l'avoir dans un
bureau d'université, déconnecté de toute logique industrielle.

Voila