Wiki !
WIKI !
Discussions actives
Nouveaux fils RSS 1.0 pour joueboulimiques (21)L'Abominable Blogue des Neiges (15)
Moteurs de recherche, jouebs et poissons (13)
Des jouebs pas aussi valides qu'ils le pretendent (18)
Karl joue a cache cache (8)
30 minutes sur la plage
Le joueb experimental de Biz
Touche pas a mes standards
On m'a violemment reproche d'avoir ecrit ce que j'ai ecrit la semaine derniere a propos des standards. Je ne serais qu'un gros troll en manque de clics (essayez de me comprendre, il faut que je vende 100 bouquins sur Amazon pour recevoir mon cheque cadeau :O) qui provoque pour susciter du traffic. Mouais. Je ne suis pas convaincu. Je viens de me relire, et je ne me trouve pas si provocateur que ca. J'ai expose mes opinions, vous etes libres de ne pas etre d'accord avec, mais admettez qu'on puisse parler des standards en disant autre chose que c'est super, depuis que j'ai mis mon CV en XHTML1.1, je passe moins de temps sur mon ordinateur a le mettre a jour et ma femme est revenue a la maison ! Desole, quand je lis des trucs du meme style, j'ai envie de repondre que tout n'est pas si parfait. Vous etes pourtant les premiers a reconnaitre qu'il y a du bon et du mauvais. Bien evidemment, vous mettez l'accent sur le bon. Ca me paraitrait vraiment malsain si personne ne mettait l'accent sur le mauvais. Et s'il vous plait, arretez d'etre si succeptibles, on peut rire de tout, meme des standards.
Personnellement, j'apprecie beaucoup l'ironie d'anonyme qui se moque gentillement de mes skins qui sont si faciles a editer dans un editeur de texte. :-)
Personnellement, j'apprecie beaucoup l'ironie d'anonyme qui se moque gentillement de mes skins qui sont si faciles a editer dans un editeur de texte. :-)
Ecrit par Biz, le Mercredi 28 Août 2002, 05:15 dans la rubrique "Joueb".
Commentaires :
Anonyme
28-08-02
à 09:09
Amaya - Karl
Amaya n'est définitivement pas un outil pour débutant. C'est une plateforme de test. :) Il est très instable, a un mauvais support de CSS, etc.
C'est un outil avec des capacités magnifiques mais qui ne permet pas l'utilisation "Mainstream".
L'outil est Open Source et pas encombré par une license GNU en passant. Il peut donc être récupéré par n'importe-quelle société, travaillé, repackagé et vendu.
C'est un outil avec des capacités magnifiques mais qui ne permet pas l'utilisation "Mainstream".
L'outil est Open Source et pas encombré par une license GNU en passant. Il peut donc être récupéré par n'importe-quelle société, travaillé, repackagé et vendu.
Anonyme
28-08-02
à 18:06
Re: Amaya
"L'outil est Open Source et pas encombré par une license GNU"
Pour certains programmeurs, c'est un desavantage d'avoir une license type BSD :)
Pour certains programmeurs, c'est un desavantage d'avoir une license type BSD :)
Re: c'est quoi le mauvais deja?
Merci de ton point de vue. Tu te situes dans quelle categorie ? Ecriveur de pages web ? D'outils ? Utilisateur d'outils ?
Reponse a ta question : avant d'etre "ecriveur d'outil-"facile/democratique"- d'aide-a-la-publication-sur-la-Toile", je suis simplement un ecriveur de pages web et de scripts qui ecrivent des pages web. C'est surtout de ce point de vue la que je me place. Oui, le commun mortel se fout de l'html 2 ou de l'xhtml 2.3, et oui, les outils comme Niutopia peuvent rendre tout ca transparent a leur yeux. On est d'accord la dessus. Mais ce n'est pas pour ca qu'il faut faire n'importe quoi avec l'xhtml.
Ce qui je pense pourrait etre ameliore :
- la simplicite, la non-verbosite, la tolerance. on pourrait tres bien rendre beaucoup plus de choses optionnelles. Les attributs "alt" dans les images, par exemple. Simplifier le doctype (juste <xhtml2>..</xhtml2> par exemple). Tout ca dans l'optique qu'on puisse ecrire une page web de tete. Un exemple : j'ecris souvent des petits scripts en Perl qui font quelques trucs et qui ensuite generent des resultats en HTML. Tres souvent, je peux ecrire le script Perl de tete. Mais ca m'etonnerait que j'arrive a me rappeler de la declaration du doctype en 3 lignes. Moi j'ai envie de generer un truc comme ca <html><body><ul><li>truc 1</li><li>truc 2</li></ul></body></html>. (oui, je peux copier/coller le doctype d'ailleurs).
- la presentation. A chaque fois que j'essaie de faire un truc en CSS, je n'y arrive pas et ca me frustre. Et je n'essaie pas de faire des trucs compliques. Y a vraiment du boulot a faire la dedans. Rendre tout ca plus souple et elastique. Typiquement, ca ne sert A RIEN de permettre que les elements se chevauchent : on ne voit plus celui d'en dessous. Moi j'imaginerais bien un navigateur qui trouve tout seul comment positionner les boites/elements sans qu'elles se chevauchent. Une sorte de modelisation par contraintes : je veux telle boite a gauche de telle boite, mais au dessus de tel autre, et si possible dans la premiere moitie de la page. Ajoutez ca aux CSS et je me convertis tout de suite !
- la separation structure/presentation. Plus j'y reflechis, plus je trouve que ce n'est pas adapte a tout. Melanger structure et presentation, c'est pas si mal que ca. On devrait garder une couche ou structure et presentation sont melangees. Libre a chacun d'avoir une autre couche en dessous ou elles sont separees. Un peu comme le principe des skins de Niutopia : on a des objets de differentes classes, c'est la structure. Et avec la skin, on genere la couche ou presentation et structure sont melanges : de l'html avec des tables par exemple. Avec une autre skin, je peux generer l'xml qui contient ma structure, que les robots etc. peuvent lire directement. Vous allez dire que c'est parce que j'ai l'habitude des tables, mais c'est vraiment comme ca que je "vois" les pages web. C'est comme ca que j'ai envie de definir ma presentation, pas avec une formule compliquee et pas dynamique pour 2 sous pour calculer une enorme marge pour mettre un truc a droite. (cf les CSS sans tableaux avec 3 colonnes a la glish).
Juste un commentaire sur "l'outil facile/democratique" : c'est pas forcement ca, soit tu utilises l'outil tel quel en changeant juste les couleurs, les blocs les categories etc. Mais si tu connais un peu d'HTML ou de CSS ou de XHTML etc. tu peux faire des trucs bien plus interessants et originaux. Exemples : Lise, Zh9lkvff9ck, Chroniques de l'imaginaire, Sevenz.
Reponse a ta question : avant d'etre "ecriveur d'outil-"facile/democratique"- d'aide-a-la-publication-sur-la-Toile", je suis simplement un ecriveur de pages web et de scripts qui ecrivent des pages web. C'est surtout de ce point de vue la que je me place. Oui, le commun mortel se fout de l'html 2 ou de l'xhtml 2.3, et oui, les outils comme Niutopia peuvent rendre tout ca transparent a leur yeux. On est d'accord la dessus. Mais ce n'est pas pour ca qu'il faut faire n'importe quoi avec l'xhtml.
Ce qui je pense pourrait etre ameliore :
- la simplicite, la non-verbosite, la tolerance. on pourrait tres bien rendre beaucoup plus de choses optionnelles. Les attributs "alt" dans les images, par exemple. Simplifier le doctype (juste <xhtml2>..</xhtml2> par exemple). Tout ca dans l'optique qu'on puisse ecrire une page web de tete. Un exemple : j'ecris souvent des petits scripts en Perl qui font quelques trucs et qui ensuite generent des resultats en HTML. Tres souvent, je peux ecrire le script Perl de tete. Mais ca m'etonnerait que j'arrive a me rappeler de la declaration du doctype en 3 lignes. Moi j'ai envie de generer un truc comme ca <html><body><ul><li>truc 1</li><li>truc 2</li></ul></body></html>. (oui, je peux copier/coller le doctype d'ailleurs).
- la presentation. A chaque fois que j'essaie de faire un truc en CSS, je n'y arrive pas et ca me frustre. Et je n'essaie pas de faire des trucs compliques. Y a vraiment du boulot a faire la dedans. Rendre tout ca plus souple et elastique. Typiquement, ca ne sert A RIEN de permettre que les elements se chevauchent : on ne voit plus celui d'en dessous. Moi j'imaginerais bien un navigateur qui trouve tout seul comment positionner les boites/elements sans qu'elles se chevauchent. Une sorte de modelisation par contraintes : je veux telle boite a gauche de telle boite, mais au dessus de tel autre, et si possible dans la premiere moitie de la page. Ajoutez ca aux CSS et je me convertis tout de suite !
- la separation structure/presentation. Plus j'y reflechis, plus je trouve que ce n'est pas adapte a tout. Melanger structure et presentation, c'est pas si mal que ca. On devrait garder une couche ou structure et presentation sont melangees. Libre a chacun d'avoir une autre couche en dessous ou elles sont separees. Un peu comme le principe des skins de Niutopia : on a des objets de differentes classes, c'est la structure. Et avec la skin, on genere la couche ou presentation et structure sont melanges : de l'html avec des tables par exemple. Avec une autre skin, je peux generer l'xml qui contient ma structure, que les robots etc. peuvent lire directement. Vous allez dire que c'est parce que j'ai l'habitude des tables, mais c'est vraiment comme ca que je "vois" les pages web. C'est comme ca que j'ai envie de definir ma presentation, pas avec une formule compliquee et pas dynamique pour 2 sous pour calculer une enorme marge pour mettre un truc a droite. (cf les CSS sans tableaux avec 3 colonnes a la glish).
Juste un commentaire sur "l'outil facile/democratique" : c'est pas forcement ca, soit tu utilises l'outil tel quel en changeant juste les couleurs, les blocs les categories etc. Mais si tu connais un peu d'HTML ou de CSS ou de XHTML etc. tu peux faire des trucs bien plus interessants et originaux. Exemples : Lise, Zh9lkvff9ck, Chroniques de l'imaginaire, Sevenz.
Anonyme
28-08-02
à 14:00
CSS, Perl, etc - Karl
Tu es un développeur Stéphane, tu n'es pas un simple utilisateur.
Pour ton script Perl, ton truc si veux pas te souvenir du doctype, cela s'appelle une librairie... c'est écrit une fois pour toute.
Pour CSS, le modèle par contraintes, je t'ai déjà dit que cela existait dans le standard CSS. C'est l'implémentation qui a fait défaut. Ce qui est d'autant plus ironique alors que le modèle est le même que celui des tableaux que tu aimes tant.
display: table.
C'est donc pas un problème de standard mais bien d'implémentation. car il n'y a aucune différence entre div et un td au niveau du modèle.
http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display
table, inline-table, table-row-group, table-column, table-column-group, table-header-group, table-footer-group, table-row, table-cell, and table-caption
These values cause an element to behave like a table element (subject to restrictions described in the chapter on tables).
Pour ton script Perl, ton truc si veux pas te souvenir du doctype, cela s'appelle une librairie... c'est écrit une fois pour toute.
Pour CSS, le modèle par contraintes, je t'ai déjà dit que cela existait dans le standard CSS. C'est l'implémentation qui a fait défaut. Ce qui est d'autant plus ironique alors que le modèle est le même que celui des tableaux que tu aimes tant.
display: table.
C'est donc pas un problème de standard mais bien d'implémentation. car il n'y a aucune différence entre div et un td au niveau du modèle.
http://www.w3.org/TR/REC-CSS2/visuren.html#propdef-display
table, inline-table, table-row-group, table-column, table-column-group, table-header-group, table-footer-group, table-row, table-cell, and table-caption
These values cause an element to behave like a table element (subject to restrictions described in the chapter on tables).
Anonyme
28-08-02
à 14:12
Re: CSS, Perl, etc - Karl
Donc, plutôt que d'utiliser les tables HTML pour faire la mise en page, on va utiliser des tables CSS ? Wow :)
Anonyme
29-08-02
à 05:06
Re: Re: CSS, Perl, etc - Karl
Ce n'est pas ce que tu voulais ? De quoi tu te plains :))))
Là encore cela illuste un des principes fondamentaux de la séparation structure/Style. Les éléments table, tr, td ont une sémantique particulière et un modèle théorique de présentation associé.
Tu vires la sémantique des éléments de tableaux (présentation tabulée de données) et tu gardes le modèle de présentation, c'est cela le "diplay: table".
Et c'est exactement ce que tu réclames au début de ton article.
Là encore cela illuste un des principes fondamentaux de la séparation structure/Style. Les éléments table, tr, td ont une sémantique particulière et un modèle théorique de présentation associé.
Tu vires la sémantique des éléments de tableaux (présentation tabulée de données) et tu gardes le modèle de présentation, c'est cela le "diplay: table".
Et c'est exactement ce que tu réclames au début de ton article.
Re: Re: Re: CSS, Perl, etc - Karl
Sauf que ce n'est pas moi qui ait ecrit ce commentaire. ;-)
Et si vous vous inscriviez, afin de rendre ces commentaires un peu plus semantiques ? Promis, je ne vendrai pas vos adresses e-mails. Et vous aurez le droit a votre propre tetoucom.
Et si vous vous inscriviez, afin de rendre ces commentaires un peu plus semantiques ? Promis, je ne vendrai pas vos adresses e-mails. Et vous aurez le droit a votre propre tetoucom.
Anonyme
29-08-02
à 06:23
Re: Re: Re: Re: CSS, Perl, etc - Karl
Désolé, c'est moi :)
Je ne savais pas si mon post serait accepté vu que je ne suis pas inscrit, et que c'est la première fois que je poste, euh, voilà. Pour ce qui est de m'inscrire, je sais pas, on verra, j'aime pas l'idée de m'inscrire pour poster des commentaires :)
(Franchement, ça serait pas mal si on pouvait signer le commentaire d'un pseudo, même si on n'est pas inscrit... non ?)
En tout cas, je trouve ça très très drôle de dire que les mises en page vont être sauvées en remplaçant les tables HTML par des tables en CSS, qui donc ne seront pas reconnues par tous les browsers d'avant 2005. Contrairement aux tables HTML. Dont tous les browsers (y compris texte) savent quoi faire, qu'ils savent gérer même quand c'est de la pure mise en page.
Le W3C, toujours comique.
Garoo.
Je ne savais pas si mon post serait accepté vu que je ne suis pas inscrit, et que c'est la première fois que je poste, euh, voilà. Pour ce qui est de m'inscrire, je sais pas, on verra, j'aime pas l'idée de m'inscrire pour poster des commentaires :)
(Franchement, ça serait pas mal si on pouvait signer le commentaire d'un pseudo, même si on n'est pas inscrit... non ?)
En tout cas, je trouve ça très très drôle de dire que les mises en page vont être sauvées en remplaçant les tables HTML par des tables en CSS, qui donc ne seront pas reconnues par tous les browsers d'avant 2005. Contrairement aux tables HTML. Dont tous les browsers (y compris texte) savent quoi faire, qu'ils savent gérer même quand c'est de la pure mise en page.
Le W3C, toujours comique.
Garoo.
Re: CSS, Perl, etc - Karl
"Pour ton script Perl, ton truc si veux pas te souvenir du doctype, cela s'appelle une librairie... c'est écrit une fois pour toute."
Oui. Mais non. Je ne code pas sur ma machine. Je code sur celle de mon ISP, celles de mon boulot etc. Je ne peux pas installer tous les modules Perl que je veux et souvent le Perl en question a 3 ans pour diverses raisons. Non, XML::Parser n'est pas present partout. C'est pour ca que j'aime bien les formats simples.
Pour les tables, sur le papier, ca a l'air pas mal. Encore que ca manque d'exemples, je n'ai pas vraiment reussi a comprendre si ca serait possible de separer structure et presentation. Est ce qu'au lieu de mettre mes boites en ligne, je pourrai les mettre en colonnes, le tout sans rien toucher a la partie qui contient le contenu ?
Il y a un truc que je trouve surprenant par contre : les </td>, </tr> etc. sont optionnels ?!?!
<TABLE>
<COL width="40">
<TR> <TH>Long distance calls
<TR> <TD> 1.30
<TR> <TD> 2.50
<TR> <TD> 10.80
<TR> <TD> 111.01
<TR> <TD> 85.
<TR> <TD> 90
<TR> <TD> .05
<TR> <TD> .06
</TABLE>
Oui. Mais non. Je ne code pas sur ma machine. Je code sur celle de mon ISP, celles de mon boulot etc. Je ne peux pas installer tous les modules Perl que je veux et souvent le Perl en question a 3 ans pour diverses raisons. Non, XML::Parser n'est pas present partout. C'est pour ca que j'aime bien les formats simples.
Pour les tables, sur le papier, ca a l'air pas mal. Encore que ca manque d'exemples, je n'ai pas vraiment reussi a comprendre si ca serait possible de separer structure et presentation. Est ce qu'au lieu de mettre mes boites en ligne, je pourrai les mettre en colonnes, le tout sans rien toucher a la partie qui contient le contenu ?
Il y a un truc que je trouve surprenant par contre : les </td>, </tr> etc. sont optionnels ?!?!
<TABLE>
<COL width="40">
<TR> <TH>Long distance calls
<TR> <TD> 1.30
<TR> <TD> 2.50
<TR> <TD> 10.80
<TR> <TD> 111.01
<TR> <TD> 85.
<TR> <TD> 90
<TR> <TD> .05
<TR> <TD> .06
</TABLE>
Anonyme
29-08-02
à 05:03
Re: Re: CSS, Perl, etc - Karl
Je te parle d'une librairie en local. Il suffit de te créer une fonction à toi, et elle est définie une fois pour toutes. Ton script perl si tu l'installes sur la machine et qui tourne tu peux très bien avoir un compagnong juste à côté, mais je pense que tu avais compris.
Pour les tableaux :
Je vais te faire une réponse comme ta question ;) De quelle version de HTML tu parles ? (HTML 2.0, 3.2, 4.01, XHTML 1.0, XHTML 1.1?)
Quand tu m'auras donné cette info, je pourrais te répondre :)
Pour les tableaux :
Je vais te faire une réponse comme ta question ;) De quelle version de HTML tu parles ? (HTML 2.0, 3.2, 4.01, XHTML 1.0, XHTML 1.1?)
Quand tu m'auras donné cette info, je pourrais te répondre :)
Anonyme
28-08-02
à 14:06
Objets Niutopia - Karl
Tes objets Niutopia aujourd'hui, ils sont extraits de quoi ???
D'une base de données ? C'est pas de la séparation ce que tu fais là :)
D'une base de données ? C'est pas de la séparation ce que tu fais là :)
Re: Objets Niutopia - Karl
Non, de fichiers XML qui stockent les objets Perl (tableaux et tables de hachage). J'ai toujours trouve qu'utiliser une base de donnees pour un systeme de joueb, c'etait comme catapulter des mammouths pour enfoncer un clou. Et puis c'est lent.
Je crois que le stockage d'objets Perl est la meilleure utilisation d'xml que j'ai vue pour l'instant. :O)
Je crois que le stockage d'objets Perl est la meilleure utilisation d'xml que j'ai vue pour l'instant. :O)
Anonyme
28-08-02
à 18:33
Re: c'est quoi le mauvais deja?
<i>Tu te situes dans quelle categorie ? Ecriveur de pages web ? D'outils ? Utilisateur d'outils ?</i>
Ca depend evidemment! Quand je suis presse, je suis un simple ecrivaillon via Textarea. J'aime les outils qui facilitent le travail repetitif et je n'aime pas les limitations que je ne comprend pas (genre laisser passer les blockquote et bloquer les q de EtP)
Quand je change de chapeau (je suis informaticien, helas), j'aime ce qui est strict, parce que cela me facilite le boulot. e.g. j'aimerai bien que http://diveintopython.org/fr/dialect_divein.html
marche pour toutes les pages web de la terre.
A propos des alt dans les images, comme j'ai la chance d'avoir deux yeux en etat, je vais meme pas parler d'accessibilite. Par contre, quand je fais un "captureur" de pages web, j'avoue que pouvoir remplacer l'image par "image: alt" ca me facilite bien plus la vie que "image: img07.jpg" (je t'accorde que parfois j'ai de la change et l'image est bien nommee)
un exemple de captureur de page web (pas ecrit par moi): http://www.aaronsw.com/weblog/000532
Pour les elements qui se chevauchent en CSS, ben cela permet des trucs genre les menus flottants, non ? (genre la table des matieres toujours presente de http://www.w3.org/QA/2002/04/Web-Quality )
<i>uste un commentaire sur "l'outil facile/democratique" : c'est pas forcement ca, soit tu utilises l'outil tel quel en changeant juste les couleurs, les blocs les categories etc. Mais si tu connais un peu d'HTML ou de CSS ou de XHTML etc. tu peux faire des trucs bien plus interessants et originaux. </i>
On est d'accord, c'est deux niveaux d'usage differents. Ca correspond a deux niveaux d'outils. Mais celui qui connait un peu de xHTML, il est capable de faire tout seul son joueb. Donc il est encore plus "exigeant" vis-a-vis de l'outil, qui doit, encore une fois, lui faciliter la vie, pas lui demander d'apprendre un n-ieme pseudo-language (UserTalk est mon exemple favori) ou une n-ieme (re)invention de la rue pour obtenir une approximation de resultat equivalent a ce qu'il pourrait faire a la main avec son editeur de texte favori.
Bien sur, toute regle etant faite pour etre brisee, tu _peux_ inventer une nouvelle facon de faire qui t'oblige a apprendre des choses, pour obtenir ensuite un resultat plus rapidement.
En tout cas, la validite du code et la bonne utilisation des balises, ca reste quand meme une necessite pour moi (en tant que consommateur _informatique_ de donnees)
Ca depend evidemment! Quand je suis presse, je suis un simple ecrivaillon via Textarea. J'aime les outils qui facilitent le travail repetitif et je n'aime pas les limitations que je ne comprend pas (genre laisser passer les blockquote et bloquer les q de EtP)
Quand je change de chapeau (je suis informaticien, helas), j'aime ce qui est strict, parce que cela me facilite le boulot. e.g. j'aimerai bien que http://diveintopython.org/fr/dialect_divein.html
marche pour toutes les pages web de la terre.
A propos des alt dans les images, comme j'ai la chance d'avoir deux yeux en etat, je vais meme pas parler d'accessibilite. Par contre, quand je fais un "captureur" de pages web, j'avoue que pouvoir remplacer l'image par "image: alt" ca me facilite bien plus la vie que "image: img07.jpg" (je t'accorde que parfois j'ai de la change et l'image est bien nommee)
un exemple de captureur de page web (pas ecrit par moi): http://www.aaronsw.com/weblog/000532
Pour les elements qui se chevauchent en CSS, ben cela permet des trucs genre les menus flottants, non ? (genre la table des matieres toujours presente de http://www.w3.org/QA/2002/04/Web-Quality )
<i>uste un commentaire sur "l'outil facile/democratique" : c'est pas forcement ca, soit tu utilises l'outil tel quel en changeant juste les couleurs, les blocs les categories etc. Mais si tu connais un peu d'HTML ou de CSS ou de XHTML etc. tu peux faire des trucs bien plus interessants et originaux. </i>
On est d'accord, c'est deux niveaux d'usage differents. Ca correspond a deux niveaux d'outils. Mais celui qui connait un peu de xHTML, il est capable de faire tout seul son joueb. Donc il est encore plus "exigeant" vis-a-vis de l'outil, qui doit, encore une fois, lui faciliter la vie, pas lui demander d'apprendre un n-ieme pseudo-language (UserTalk est mon exemple favori) ou une n-ieme (re)invention de la rue pour obtenir une approximation de resultat equivalent a ce qu'il pourrait faire a la main avec son editeur de texte favori.
Bien sur, toute regle etant faite pour etre brisee, tu _peux_ inventer une nouvelle facon de faire qui t'oblige a apprendre des choses, pour obtenir ensuite un resultat plus rapidement.
En tout cas, la validite du code et la bonne utilisation des balises, ca reste quand meme une necessite pour moi (en tant que consommateur _informatique_ de donnees)
Anonyme
28-08-02
à 09:13
Web Sémantique - Karl
Stéphane - relis encore une fois ce que tu as écris sur le Web sémantique et tu verras que cela ne va pas. Sépare ton argumentation, pose là en différents points et ce sera plus clair.
Pour l'instant, cela ne va nulle part car tu mélanges beaucoup de choses ensemble. Je vais te répondre comme je l'ai promis aujourd'hui sur la grange et je vais tenter de t'expliquer les différences.
Cela n'a rien avec un doctype ou un HTML permissif. Tu mélanges en gros : le web sémantique, la facilité d'utilisation d'une technologie, les outils, la documentation (ou l'absence de doc) comme vient de le dire l'anonyme, etc. ce qui fait que ton propos perds de sa substance et de son impact.
Pour l'instant, cela ne va nulle part car tu mélanges beaucoup de choses ensemble. Je vais te répondre comme je l'ai promis aujourd'hui sur la grange et je vais tenter de t'expliquer les différences.
Cela n'a rien avec un doctype ou un HTML permissif. Tu mélanges en gros : le web sémantique, la facilité d'utilisation d'une technologie, les outils, la documentation (ou l'absence de doc) comme vient de le dire l'anonyme, etc. ce qui fait que ton propos perds de sa substance et de son impact.
Lien croisé
Bruit Blanc - Rien qu'une pierre de l'Edifice. : " Bernard
: "on peut rire de tout, même des standards" [url]"
: "on peut rire de tout, même des standards" [url]"
Lien croisé
Bruit Blanc - Rien qu'une pierre de l'Edifice. : " Cypoulet
: "on peut rire de tout, même des standards" [url]"
: "on peut rire de tout, même des standards" [url]"
Lien croisé
JY's weblog : " Stéphane : Touche pas a mes standards. Putain Stéphane, tes pages valident pas XHTML ??! T'assure pas. C'est pourtant intéressant de passer 8 heures à construire une page qui au final déconne dans les navigateurs utilisés par les gens. "
Lien croisé
Bruit Blanc - Rien qu'une pierre de l'Edifice. : " Choufette
: "on peut rire de tout, même des standards" [url]"
: "on peut rire de tout, même des standards" [url]"
c'est quoi le mauvais deja?
Donc, desole par avance si je te froisse, mais c'est quoi le "mauvais" dans les standards selon toi pour moi qui suis en train d'ecrire mon commentaire a travers un textarea ??
Perso, la seule chose que je trouve de "mauvais", c'est une documentation uniquement technique (et la plupart du temps en anglais uniquement): il manque une version vulgarisee. Par exemple le B A BA du html que je peux faire lire a mon papa, sans peur qu'il comprenne de travers (alors pour mettre en gras j'utilise H6 c'est ca?)
Et aussi un manque d'outil correct. Certes, y'a Amaya, mais j'ai du mal avec Amaya au jour le jour. Et ecrire avec Amaya ne m'a pas super convaincu non plus.