Discuter:HTML dynamique

Un article de Wikipédia, l'encyclopédie libre.

Je ne vois pas pourquoi on devrait utiliser le mot-clé DHTML là où Javascript suffirait ; c'est à la limite du NPOV que de décréter que Javascript est « dynamique » là où il existe aussi d'autres langages qualifiés de dynamique (côté serveur par exemple.) Je propose une suppression de cette page. -- NucleoS

Contre la suppression, en revanche l'article devrait être totalement refait. Une très bonne description de DHTML (en anglais) se trouve à [1]. Marc Mongenet 13 jun 2004 à 20:37 (CEST)

mmmh... Cet article ne parle pas de DOM, qui fait pourtant partie de ce qu'on pourrait appeler DHTML. En furetant sur le net, j'ai finalement compris que DHTML était une appellation reconnue par à peu près tout le monde, et, même si je trouve toujours le nom mal choisi, j'en conviens, il est préférable de garder un article à son sujet. Toutefois, je crois que le rôle de cette page ne devrait être que de rediriger vers les articles ECMAScript, JavaScript et DOM. Qu'en pensez-vous ? -- NucleoS 13 jun 2004 à 22:50 (CEST)

Je propose un ensemble de techniques à la place de une technique, et ça permet de citer toutes les technologies pouvant entrer en oeuvre (coucou Nucleos :p) -- BenoitL 13 jun 2004 à 23:01 (CEST)
Salut Benoit ! Effectivement, un ensemble de techniques, c'est plus juste. Je crois que tu peux le modifier en attendant que la refonte de cette page ne se fasse. J'ai trouvé [2] sur le wikipedia anglophone, et pour le moment, je m'informe sur les technologies que je ne connais pas.
Effectivement, cet article est un peu ancien. Ce que j'aime, c'est qu'il montre l'historique de ce concept technico-marketing, notamment au point culminant du bruit autour de DHTML, il y a déjà de nombreuses années. Peu avant que la notion de DOM devienne connue en fait. Il montre bien que DHTML n'est qu'une étiquette assez vague placées sur des technologies bien définies (HTML, JavaScript, CSS, DOM) et que nous décrivons dans d'autres articles, nettement plus techniques. Marc Mongenet 14 jun 2004 à 00:30 (CEST)
Est-ce que la modification apportée convient ? Il ne resterait plus alors qu'à ajouter la partie historique décrivant l'approche marketing de la chose et son aspect un peu désuet de nos jours, ainsi qu'une brève description (sans entrer trop dans les détails) des interfaces incompatibles entre IE et Netscape avant la standardisation du DOM (document.layers, document.all -> document.getElementById). Les détails techniques devraient quant à eux prendre place dans l'article sur le DOM, qui devrait être élargi pour prendre en compte les DOM incompatibles originels. -- BenoitL 14 jun 2004 à 13:57 (CEST)
Oui, reste à élaborer l'historique de l'utilisation du terme. Concernant l'évolution des interfaces, je pense que l'article DOM serait plus approprié. Marc Mongenet 14 jun 2004 à 18:47 (CEST)
Voilà qui est fait, j'ai également enlevé le statut d'ébauche. Je m'attaquerai à l'article DOM plus tard si personne ne l'a fait entre-temps. -- BenoitL 15 jun 2004 à 11:35 (CEST)
Et bien fait. J'ai apporté plein de petites précisions. En principe je peux toutes les motiver (j'espère). Dis-moi s'il y en a que tu trouves fausses/gratuites/abusives. Marc Mongenet 15 jun 2004 à 13:36 (CEST)
Plutôt des choses imprécises où on perdait de l'information (il ne devrait pas y avoir besoin de lire tout l'article CSS pour savoir qu'il s'agit juste de modifier l'apparence du document). Je trouve encore que ma conclusion était meilleure quand je parlais de "science" plutôt que de connaissances techniques, car le cross-browser scripting n'a vraiment rien d'une sinécure. Mais bon c'est peut-être à la limite du neutre donc je laisse la tienne :) -- BenoitL 15 jun 2004 à 19:50 (CEST)
Concernant l'usage du mot science, il s'agissait plutôt du sens que mon Petit Robert définit ainsi : « VX ou LITTÉR. Connaissance exacte ou approfondie.» Comme il n s'agit pas du sens moderne et encyclopédique de science, j'avais peur que ça ne prête à confusion. Je suis cependant d'accord avec la perte d'information. Je propose l'ajout du « subtile », est-ce suffisant ? Marc Mongenet 16 jun 2004 à 02:15 (CEST)
Plusieurs petites remarques sur l'introduction. Marc Mongenet 16 jun 2004 à 03:05 (CEST)
Ma suppression du mot « déjà » devant « affiché » vient d'une mauvaise compréhension de ma part. Pour moi « être affiché » était synonyme d'« être à l'écran » alors qu'il fallait le comprendre comme l'action de la mise à l'écran. Je trouvais donc que ce « déjà » n'avait aucun sens. Cependant, si l'on considère que l'affichage est terminé une fois que tout est dessiné à l'écran, alors cette formulation est fausse. Les modification DHTML peuvent avoir lieu pendant l'action d'affichage comme après (onload, onclick ou onsubmit sont aussi anciens que JavaScript). Je sais que [3] contient after their initial display, mais cette formulation trompeuse a sans doute été créée par opposition à une modification faite sur le serveur, donc avant l'affichage. Lorsque DHTML a été vanté pour les clients, ce n'était pas pour mettre l'accent sur le moment où les modifications pouvaient avoir lieu, mais pour vanter l'étendue des modifications possibles. Marc Mongenet 16 jun 2004 à 03:05 (CEST)
Pour ce qui est de la modification de l'apparence du document, je pensais que « modifier une page Web » impliquait clairement que son apparence pouvait changer (qu'est-ce qui serait modifié sinon?). En outre, la formulation actuelle fait croire que modifier le « contenu HTML » (qu'est-ce au juste?) ne change pas l'apparence. Je ne comprend pas non plus très bien comment la phrase est construite. « Ces modifications peuvent à la fois concerner le contenu HTML du document, mais parfois aussi son apparence via les styles CSS.» Est-ce que ça signifie « Ces modifications peuvent à la fois concerner le contenu HTML du document et son apparence via les styles CSS.» ? Marc Mongenet 16 jun 2004 à 03:05 (CEST)

En voulant préciser l'introduction, j'ai finalement dû ajouter beaucoup de texte. Le premier paragraphe situe le sujet pour toutes les audiences sans entrer dans les détails : navigateur Web, page Web, c'est tout. Le second paragraphe fait le lien entre la description technique précise et tous les aspects pratiques grand public de DHTML. Le troisième paragraphe introduit tous les concept techniques couvert par le sujet (JavaScript, HTML, CSS, DOM), plus besoin de décrire les aspects pratiques au lecteurs qui sont arrivés jusque là. J'ai laissé tomber la séparation HTML-structure/CSS-style car je n'arrive pas à l'évoquer sans la simplifier outrancièrement, et de toute façon ça ne me paraît pas important pour cet article. Marc Mongenet 16 jun 2004 à 03:45 (CEST)

Quand j'écrivais affichage, je pensais en réalité chargement. J'ai remis cette précision que je trouve importante, surtout si on parle d'un sens actuel par rapport à un sens plus ancien. Ta nouvelle formulation laissait penser que seul le visiteur pouvait provoquer des actions, ce n'est pas exact non plus. Certaines se font automatiquement, lors des évènements comme le chargement initial de la page (onload), ou plus tard par l'intermédiaire de timers. Les autres modifications que j'ai encore apportées à l'article sont je pense assez triviales (orthographe) -- BenoitL 16 jun 2004 à 07:45 (CEST)
Bien vu pour les corrections. Il faut aussi que je me relise mieux, quelles horribles fautes. En revanche pour l'intro, je ne suis pas convaincu. La différence entre l'ancien sens et l'actuel, c'est que c'est maintenant le navigateur qui fait les modifications. Préciser que les modifications se font après le chargement pourrait faire croire qu'il existe une autre technologie permettant au navigateur de modifier avant le chargement... En outre, des modifications peuvent également avoir lieu pendant le chargement, c'est même un problème auquel il faut faire attention. Il faut donc corriger ce « après son chargement ». Moi je suis pour simplement l'ôter. Marc Mongenet 16 jun 2004 à 08:11 (CEST)

J'ai supprimmé « après son transfert depuis le serveur » car (1) les modifications peuvent aussi avoir lieu pendant le transfert et (2) la page n'a pas besoin de venir d'un serveur pour DHTML (sens actuel). En revanche j'ai ajouté «présentation» (rien trouvé de mieux) sans cela on pourrait croire que DHTML permet de changer la page sur le serveur (genre WebDAV). Marc Mongenet 16 jun 2004 à 08:51 (CEST)

Bof bof, il ne s'agit pas seulement de sa présentation mais aussi de son contenu (p. ex. ajout de la date courante ou modification d'un champ) ou son comportement (gestion des clics ou des mouvements de la souris). Quand j'écrivais après le transfert je pensais d'un point de vue logique (le code doit avoir été téléchargé avant d'être interprété), mais c'est vrai qu'en pratique le rendu progressif rend l'exécution d'une partie du code avant le transfert de la totalité de la page possible (ce n'est pas le cas pour XHTML). Je n'ai pas d'idée immédiate sur une formulation tout à fait satisfaisante donc je ne change pas pour l'instant, mais je ne suis pas entièrement satisfait :)Finalement, autant ne rien mettre, les paragraphes suivants étant suffisamment explicites sur ce qui est modifié et comment. -- BenoitL 16 jun 2004 à 12:44 (CEST)
Très juste, c'est bête d'introduire une imprécision alors qu'une bonne description suit immédiatement. C'est d'ailleurs bien parce que je n'arrivais pas à résumé correctement que j'avais créé cette description.:) Marc Mongenet 16 jun 2004 à 16:21 (CEST)

J'ai remplacé la mention aux bases de données par une mention plus générale au traitement de données de formulaire car les sites fonctionnant avec une base de donnée n'étaient pas courant en 1995. Marc Mongenet 17 jun 2004 à 11:49 (CEST)


Rebonjour à tous deux :)

Je trouve toujours la définition première assez inadaptée. Telle quel, j'aurais tendance à dire qu'elle correspond plutôt à la définition des bookmarklets, si vous voyez ce que je veux dire.

Il faudrait éventuellement recourrir à un des points suivant :

  • La modification entraînée par un code DHTML est souvent personnalisée.
  • LMEPUCD (la modification entr...) ne fait pas appel à un langage de description (XHTML) ou de personnalisation de l'affichage (CSS).
  • Cela entraîne que LMEPUCD fait appel non pas à une simple représentation, mais à une représentation interactive et/ou animée de la page web.

De la même manière, à moins que vous ne vouliez parler de SSI, php et .Net, le DHTML ne sert que rarement "avant que celles-ci /modifications/ ne soient reflétées à l'écran" (sic !) Il y a d'abord éventuellement un problème d'accord (j'ai l'impression que ce n'est pas des modifications que l'on parle, mais plutôt de la page web.) Et ensuite, les modifications peuvent s'effectuer avant, pendant, après le chargement complet de la page.

"En outre, une succession rapide de modifications peut donner l'apparence d'une animation." Alors, une animation est une succession rapide de modifications ? J'aurais plutôt tendance à dire que le DHTML peut simplement montrer une animation, mais je ne suis pas sûr qu'une animation (littéralement : quelque chose qui bouge) soit une suite de modifications de la page web.

Désolé pour le petit retard dans les commentaires :)

NucleoS 10 jul 2004 à 18:42 (CEST)

Pour la définition initiale, tu as raison, il manque la notion fondamentale voulue par l'auteur pour en exclure les bookmarklets, mais je ne comprends pas tes "points suivants" :) Ce que fait le DHTML c'est bien influer soit sur l'arbre DOM (qui est la représentation interne de la page), soit sur les propriétés CSS qui lui sont appliquées lors de l'affichage.
Et oui, une animation est une suite de modification des propriétés d'un élément de la page. Pour faire un effet de fondu on changera la couleur (ou l'opacité) d'un élément un petit peu à la fois, pour faire un effet de déroulement on augmentera petit à petit sa hauteur, etc. Ce que tu veux dire, c'est que c'est la nature même d'une animation et pas seulement une apparence ? -- BenoitL 11 jul 2004 à 17:10 (CEST)
Je suis d'accord, la version précédente était trop générale car elle semblait inclure l'ensemble des opérations d'affichage des navigateurs, comme "text zoom", "use style" et même les redimensionnements de fenêtre (un reflow modifie l'affichage de la page après tout). Mais la version actuelle donne l'impression que l'auteur de la page est en train de tirer les ficelles à distance pendant l'affichage ! Je crois qu'il faut plutôt mettre l'accent sur le fait que DHTML recouvre des techniques de programmation à disposition de l'auteur de la page (et non de l'auteur du navigateur, qui utilise C++ et n'a pas besoin de DHTML).
Concernant les bookmarlets, il me semble qu'elle reposent justement sur les techniques DHTML, qu'y a-t-il à exclure ? Marc Mongenet 11 jul 2004 à 21:28 (CEST)
Finalement, je crois que Nucleos trouvait l'ancienne définition trop restrictive plutôt que trop large ! Je suis d'accord avec les deux.:-) Concernant le "avant que celles-ci /modifications/ ne soient reflétées à l'écran", l'idée originale était de mettre l'accent sur la modification du DOM, qui entraîne une modification sur l'écran à la vitesse de la lumière, d'où l'usage de "reflété" (subtile, non ?). Mais la première version de la phrase était inélégante, et celle-ci porte à confusion un lecteur attentif. À revoir donc, pfou. Marc Mongenet 11 jul 2004 à 21:39 (CEST)

Et voilà encore un p'tit retard dans les commentaires. Heureusement que Wikipédia est un truc qui avance tout seul. Les modifications me conviennent pour la définition première. J'ai cependant (évidemment) encore quelques commentaires sur la page en elle-même. (1) Je crois tout d'abord que les titres et sous-titres d'un article doivent être utilisés pour décrire précisément chaque partie d'un article (mais je n'arrive pas à trouver un beau titre pour la définition, ce qui relève peut-être un manque de structure.), à moins qu'on utilise aucun titre. (2) Ensuite, cette succession de modifications conduisant à une animation, ça me fait penser à un webmestre qui code quelque chose pour que la chose n'arrête pas de se modifier, alors que j'ai tendance à croire qu'une animation, une fois lancée, est indépendante et n'a plus besoin des modifications décrites par le webmestre. Si c'est précisément ce que vous voulez décrire, ok. Mais je trouve ça étrange, parce que finalement, la description du webmestre, une fois analysée, n'est pas réutilisée en tant que telle par le navigateur (une espèce de "compilation doit s'opérer.)

(1) Cet article est un peu particulier. Je dirais que c'est plus un article étymologique qu'autre chose, ce qui donne finalement une suite de définitions. C'est normal pour un concept aussi fumeux que DHTML... En général la définition tient entièrement dans le paragraphe d'introduction et après on développe le sujet. Ici on développe plutôt la définition elle-même (en revoyant vers les "vrais" sujet comme JavaScript, DOM...). Marc Mongenet 30 jul 2004 à 15:49 (CEST)
(2) Oui, je crois que c'est exactement ce qu'on veut dire. Une animation en DHTML demande effectivement l'exécution de fonctions de script tant qu'il y a animation. À chaque fois que quelque-chose bouge, c'est que du script a été exécuté et qu'il a fait bouger la chose. DHTML n'est pas conçu pour les animations comme MPEG ou même les GIF animées. Dans une animation DHTML, il y a effectivement interprêtation "continue" du script (JavaScript). Par « continue » il faut entendre que c'est rythmé par des événements discrets, comme un horloge ou des déplacements de souris, c'est pas forcément 100% de CPU. Quant à savoir s'il y a "compilation" dans le navigateur, c'est de sa cuisine interne, conceptuellement ce n'est pas le cas, c'est ce qui compte ici. Marc Mongenet 30 jul 2004 à 15:49 (CEST)

[modifier] Dynamic HTML ou HTML dynamique

Je pense qu'il est plus correct de considérer Dynamic HTML comme un nom propre (comme DirectSound) plutôt que comme un nom commun (comme la programmation orientée objet). Si on se réfère à un des (le ?) premiers documents sur le sujet Dynamic HTML: The Next Generation of User-Interface Design, on constate que Dynamic est systématiquement écrit avec une majuscule. En outre, Dynamic HTML tient plus du langage marketing (du même article Dynamic HTML is a feature of Microsoft® Internet Explorer version 4.0.) que du concept informatique. Ce slogan est d'ailleurs passé de mode, alors que le concept informatique (DOM) a continué à se développer.

D'un autre côté on remarque que de nombreux sites francophones ont traduit Dynamic HTML en HTML dynamique. Cette traduction fait pencher la balance vers le second titre. Elle donne aussi à penser qu'il s'agit du nom générique d'une technique informatique, plutôt d'une expression à la mode ou d'un pur nom de produit.

Qu'en conclure ? Nommer l'article Dynamic HTML en considérant qu'il ne s'agit que d'un concept marketing qui a toujours été officiellement vanté sous ce nom (bien qu'il ait été souvent traduit) ou HTML dynamique en considérant qu'il s'agit d'un concept flou, connu sous plusieurs langues ? J'hésite encore, le processus de traduction ayant sombré avec le terme : On a HTML dynamique, mais on n'a pas HTMLD, on est resté à DHTML dans toutes les langues. C'est qui me fait penser que HTML dynamique est resté un traduction littérale, facile mais pas assumée. Contrairement à programmation orientée objet qui a donné POO (en fait je ne suis même pas sûr que orienté objet vienne de l'anglais).

Marc Mongenet 1 nov 2004 à 15:50 (CET)

J'ai hésité aussi en le voyant, et puis finalement je ne vois pas trop le problème. En réalité, ce qu'on va lier ou rechercher dans la boîte n'est jamais "Dynamic HTML", mais "DHTML". Donc que l'article s'appelle l'un ou l'autre n'a pas pour moi grande importance. Cependant, si on parle de HTML dynamique au delà du concept marketing dans un autre article, le lien sera plus direct dans cette nouvelle forme.
Conclusion : Je peux imaginer qu'un article fasse un lien HTML dynamique, je suis certain que des articles font des liens DHTML, mais je ne vois pas un article faire un lien Dynamic HTML, donc le changement est bénéfique en termes de redirections. -- BenoitL 1 nov 2004 à 18:31 (CET)