J'ai un éditeur de HTML en ligne qui fonctionne très bien, sauf lorsque
le texte contient des liens (<A href).
Les liens relatifs sont automatiquement remplacés par leur équivalent en
adressage absolu.
Le problème, c'est que l'adresse est calculée par rapport à la page qui
exécute le script,
ce qui n'a pas forcément de rapport avec le contexte dasn lequel sera
effectivement affichée la page finale.
La transformation semble se produire quand on entre le code dans innerHTML.
Pour illustrer le problème, voici un exemple du code :
<SCRIPT>
function setHTML()
{
var div = document.getElementById("testDiv");
div.innerHTML = '<A href="test.htm">Test href</A>'
alert(div.innerHTML)
}
</SCRIPT>
<INPUT NAME="test" TYPE="button" SIZE="10" VALUE="test" onClick="setHTML()">
<DIV id="testDiv">test</DIV>
Lorsqu'on clique sur le bouton, on met « <A href="test.htm"> » dans le
HTML de la div,
mais avec MSIE, l'alert montre effectivement «<A
href="http://localhost/test/test.htm"> »
Avec FF l'adresse est inchangée.
Y a-t-il un moyen pour demander à Big Brother de se mêler de ses affaires ?
Je suis capable de gérer mes adresses tout seul !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles LAURENT [MVP]
"Claude Schneegans" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un éditeur de HTML en ligne qui fonctionne très bien, sauf | lorsque le texte contient des liens (<A href). | Les liens relatifs sont automatiquement remplacés par leur équivalent | en adressage absolu. | Le problème, c'est que l'adresse est calculée par rapport à la page | qui exécute le script, ce qui n'a pas forcément de rapport avec le | contexte dasn lequel sera effectivement affichée la page finale. [...]
Ce comportement me semble être en accord avec la rfc1808 portant sur les URLs relatives. L'adresse relative est résolue dynamiquement en fonction du contexte d'exécution : http://www.ietf.org/rfc/rfc1808.txt
En local, l'adresse relative sera résolue en http://localhost/<...>
-- Gilles LAURENT [MVP] http://glsft.free.fr
"Claude Schneegans" <schneegans@internetique.com> a écrit dans le
message de
news:Oy5scOXyHHA.276@TK2MSFTNGP06.phx.gbl
| Bonjour,
Bonjour,
| J'ai un éditeur de HTML en ligne qui fonctionne très bien, sauf
| lorsque le texte contient des liens (<A href).
| Les liens relatifs sont automatiquement remplacés par leur équivalent
| en adressage absolu.
| Le problème, c'est que l'adresse est calculée par rapport à la page
| qui exécute le script, ce qui n'a pas forcément de rapport avec le
| contexte dasn lequel sera effectivement affichée la page finale.
[...]
Ce comportement me semble être en accord avec la rfc1808 portant sur les
URLs relatives. L'adresse relative est résolue dynamiquement en fonction
du contexte d'exécution :
http://www.ietf.org/rfc/rfc1808.txt
En local, l'adresse relative sera résolue en http://localhost/<...>
"Claude Schneegans" a écrit dans le message de news: | Bonjour,
Bonjour,
| J'ai un éditeur de HTML en ligne qui fonctionne très bien, sauf | lorsque le texte contient des liens (<A href). | Les liens relatifs sont automatiquement remplacés par leur équivalent | en adressage absolu. | Le problème, c'est que l'adresse est calculée par rapport à la page | qui exécute le script, ce qui n'a pas forcément de rapport avec le | contexte dasn lequel sera effectivement affichée la page finale. [...]
Ce comportement me semble être en accord avec la rfc1808 portant sur les URLs relatives. L'adresse relative est résolue dynamiquement en fonction du contexte d'exécution : http://www.ietf.org/rfc/rfc1808.txt
En local, l'adresse relative sera résolue en http://localhost/<...>
-- Gilles LAURENT [MVP] http://glsft.free.fr
Claude Schneegans
Réponse tardive, mais bon...
Ce comportement me semble être en accord avec la rfc1808 portant sur les URLs relatives. L'adresse relative est résolue dynamiquement en fonction
du contexte d'exécution.
Certes,... SAUF QUE : La rfc1808 fixe les règles pour « parser l'url ». Mais quand on donne une valeur à innerHTML, on demande de stocker du HTML, pas de le décoder ni de l'exécuter. Ceci ne doit être fait en principe que lorsque le HTML doit effectivement être affiché. Et même là, les urls ne doivent pas encore être décodés. Ils ne le sont en principe que lors de la préparation de la requête HTTP à envoyer au serveur. c'-à-d. uniquement lorsque le lecteur click sur un lien, ou lorsqu'un code JS qqconque demande l'ouverture d'une page.
J'ai fini par régler le problème, mais c'est assez galère.
Réponse tardive, mais bon...
Ce comportement me semble être en accord avec la rfc1808 portant sur les
URLs relatives. L'adresse relative est résolue dynamiquement en fonction
du contexte d'exécution.
Certes,... SAUF QUE :
La rfc1808 fixe les règles pour « parser l'url ».
Mais quand on donne une valeur à innerHTML, on demande de stocker du
HTML, pas de le décoder ni de l'exécuter.
Ceci ne doit être fait en principe que lorsque le HTML doit
effectivement être affiché.
Et même là, les urls ne doivent pas encore être décodés. Ils ne le sont
en principe que lors
de la préparation de la requête HTTP à envoyer au serveur.
c'-à-d. uniquement lorsque le lecteur click sur un lien, ou lorsqu'un
code JS qqconque demande l'ouverture d'une page.
J'ai fini par régler le problème, mais c'est assez galère.
Ce comportement me semble être en accord avec la rfc1808 portant sur les URLs relatives. L'adresse relative est résolue dynamiquement en fonction
du contexte d'exécution.
Certes,... SAUF QUE : La rfc1808 fixe les règles pour « parser l'url ». Mais quand on donne une valeur à innerHTML, on demande de stocker du HTML, pas de le décoder ni de l'exécuter. Ceci ne doit être fait en principe que lorsque le HTML doit effectivement être affiché. Et même là, les urls ne doivent pas encore être décodés. Ils ne le sont en principe que lors de la préparation de la requête HTTP à envoyer au serveur. c'-à-d. uniquement lorsque le lecteur click sur un lien, ou lorsqu'un code JS qqconque demande l'ouverture d'une page.
J'ai fini par régler le problème, mais c'est assez galère.
Gilles LAURENT [MVP]
"Claude Schneegans" a écrit dans le message de news: | Réponse tardive, mais bon...
...mieux vaut tard que jamais ;-)
| J'ai fini par régler le problème, mais c'est assez galère.
En effet, la méthode innerHtml semble formater le contenu de l'attribut href en adresse absolue. Une solution de contournement pourrait être d'écrire l'adresse relative dans un attribut privé (ici m_href) puis ensuite parcourir le DOM dans le but de réaliser la substitution des attributs (m_href -> href). Ci-dessous un exemple de script :
<script> function setHTML() { var div = document.getElementById("testDiv"); div.innerHTML = '<A m_href="test.htm">Test href</A>';
var colAnchors = document.getElementsByTagName("*"); for (var i = 0; i < colAnchors.length; i++) { if (colAnchors[i].m_href) { colAnchors[i].setAttribute("href", colAnchors[i].m_href); colAnchors[i].removeAttribute("m_href"); } }
alert(div.innerHTML); } </script>
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Claude Schneegans" <schneegans@internetique.com> a écrit dans le
message de
news:OpMZp0c6HHA.4252@TK2MSFTNGP05.phx.gbl
| Réponse tardive, mais bon...
...mieux vaut tard que jamais ;-)
| J'ai fini par régler le problème, mais c'est assez galère.
En effet, la méthode innerHtml semble formater le contenu de l'attribut
href en adresse absolue. Une solution de contournement pourrait être
d'écrire l'adresse relative dans un attribut privé (ici m_href) puis
ensuite parcourir le DOM dans le but de réaliser la substitution des
attributs (m_href -> href). Ci-dessous un exemple de script :
<script>
function setHTML()
{
var div = document.getElementById("testDiv");
div.innerHTML = '<A m_href="test.htm">Test href</A>';
var colAnchors = document.getElementsByTagName("*");
for (var i = 0; i < colAnchors.length; i++) {
if (colAnchors[i].m_href) {
colAnchors[i].setAttribute("href", colAnchors[i].m_href);
colAnchors[i].removeAttribute("m_href");
}
}
alert(div.innerHTML);
}
</script>
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"Claude Schneegans" a écrit dans le message de news: | Réponse tardive, mais bon...
...mieux vaut tard que jamais ;-)
| J'ai fini par régler le problème, mais c'est assez galère.
En effet, la méthode innerHtml semble formater le contenu de l'attribut href en adresse absolue. Une solution de contournement pourrait être d'écrire l'adresse relative dans un attribut privé (ici m_href) puis ensuite parcourir le DOM dans le but de réaliser la substitution des attributs (m_href -> href). Ci-dessous un exemple de script :
<script> function setHTML() { var div = document.getElementById("testDiv"); div.innerHTML = '<A m_href="test.htm">Test href</A>';
var colAnchors = document.getElementsByTagName("*"); for (var i = 0; i < colAnchors.length; i++) { if (colAnchors[i].m_href) { colAnchors[i].setAttribute("href", colAnchors[i].m_href); colAnchors[i].removeAttribute("m_href"); } }
alert(div.innerHTML); } </script>
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Claude Schneegans
Une solution de contournement pourrait être d'écrire l'adresse relative dans un attribut privé
Voilà, c'est précisément ce que j'ai fait. Avec l'étape préalable durant laquelle mon éditeur HTML doit créer les faux href avant d'insérer dans innerHTML.
Une solution de contournement pourrait être
d'écrire l'adresse relative dans un attribut privé
Voilà, c'est précisément ce que j'ai fait.
Avec l'étape préalable durant laquelle mon éditeur HTML doit
créer les faux href avant d'insérer dans innerHTML.
Une solution de contournement pourrait être d'écrire l'adresse relative dans un attribut privé
Voilà, c'est précisément ce que j'ai fait. Avec l'étape préalable durant laquelle mon éditeur HTML doit créer les faux href avant d'insérer dans innerHTML.
