Si j'ai le droit de la mettre apres c'est mieux car les entêtes sont construites par php et cela me permettrait de ne pas y toucher.
On peut mettre une balise script n'importe où on veut (certains FAI en mettent même après le </html> sur les pages persos !) le navigateur s'en dépatouillera.
C'est *mal* mais ça fonctionne ;-)
Il suffit que les scripts soient rangés dans le bon ordre relativement à celui de la lecture de la page (du fichier)
Si j'ai le droit de la mettre apres c'est mieux car les entêtes sont
construites par php et cela me permettrait de ne pas y toucher.
On peut mettre une balise script n'importe où on veut
(certains FAI en mettent même après le </html> sur les pages persos !)
le navigateur s'en dépatouillera.
C'est *mal* mais ça fonctionne ;-)
Il suffit que les scripts soient rangés dans le bon ordre relativement à
celui de la lecture de la page (du fichier)
Si j'ai le droit de la mettre apres c'est mieux car les entêtes sont construites par php et cela me permettrait de ne pas y toucher.
On peut mettre une balise script n'importe où on veut (certains FAI en mettent même après le </html> sur les pages persos !) le navigateur s'en dépatouillera.
C'est *mal* mais ça fonctionne ;-)
Il suffit que les scripts soient rangés dans le bon ordre relativement à celui de la lecture de la page (du fichier)
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que l'on veut dans un élément HEAD.
<!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut mettre un élément SCRIPT à tous les endroits où les éléments A, IMG, OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document --> <!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation --> <!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et aussi dans les autres éléments qui ne contiennent normalement que des éléments de type block (BLOCKQUOTE et FORM).
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments
d'en-tête répétables -->
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du
document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que
l'on veut dans un élément HEAD.
<!ENTITY % special
"A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut
mettre un élément SCRIPT à tous les endroits où les éléments A, IMG,
OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document -->
<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation -->
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et
aussi dans les autres éléments qui ne contiennent normalement que des
éléments de type block (BLOCKQUOTE et FORM).
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que l'on veut dans un élément HEAD.
<!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut mettre un élément SCRIPT à tous les endroits où les éléments A, IMG, OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document --> <!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation --> <!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et aussi dans les autres éléments qui ne contiennent normalement que des éléments de type block (BLOCKQUOTE et FORM).
En conclusion : sauf erreur ou omission, l'élément SCRIPT est autorisé pratiquement partout.
Olivier Miakinen
Stéphane je sais que tu n'aimes pas beaucoup les réponses basées sur les documents de référence, préférant voir comment se comportent en général les différents navigateurs. Néanmoins je crois utile de savoir quand même ce qui est en principe « permis » ou pas.
Le 09/10/2007 11:49, SAM répondait à jf tanguy :
On peut mettre une balise script n'importe où on veut
Presque n'importe où.
(certains FAI en mettent même après le </html> sur les pages persos !) le navigateur s'en dépatouillera.
Si on peut éviter, c'est quand même mieux. De même, on évitera de la mettre juste avant <html>, juste après <html>, juste avant </html>, ou entre </head> et <body>. Mais c'est bon à peu près partout à l'intérieur de <head>...</head> et de <body>...</body>.
C'est *mal* mais ça fonctionne ;-)
Ça fonctionne dans les navigateurs les plus connus, mais c'est *mal* ;-)
[Il faut] que les scripts soient rangés dans le bon ordre relativement à celui de la lecture de la page (du fichier)
Stéphane je sais que tu n'aimes pas beaucoup les réponses basées sur les
documents de référence, préférant voir comment se comportent en général
les différents navigateurs. Néanmoins je crois utile de savoir quand
même ce qui est en principe « permis » ou pas.
Le 09/10/2007 11:49, SAM répondait à jf tanguy :
On peut mettre une balise script n'importe où on veut
Presque n'importe où.
(certains FAI en mettent même après le </html> sur les pages persos !)
le navigateur s'en dépatouillera.
Si on peut éviter, c'est quand même mieux. De même, on évitera de la
mettre juste avant <html>, juste après <html>, juste avant </html>, ou
entre </head> et <body>. Mais c'est bon à peu près partout à l'intérieur
de <head>...</head> et de <body>...</body>.
C'est *mal* mais ça fonctionne ;-)
Ça fonctionne dans les navigateurs les plus connus, mais c'est *mal* ;-)
[Il faut] que les scripts soient rangés dans le bon ordre relativement à
celui de la lecture de la page (du fichier)
Stéphane je sais que tu n'aimes pas beaucoup les réponses basées sur les documents de référence, préférant voir comment se comportent en général les différents navigateurs. Néanmoins je crois utile de savoir quand même ce qui est en principe « permis » ou pas.
Le 09/10/2007 11:49, SAM répondait à jf tanguy :
On peut mettre une balise script n'importe où on veut
Presque n'importe où.
(certains FAI en mettent même après le </html> sur les pages persos !) le navigateur s'en dépatouillera.
Si on peut éviter, c'est quand même mieux. De même, on évitera de la mettre juste avant <html>, juste après <html>, juste avant </html>, ou entre </head> et <body>. Mais c'est bon à peu près partout à l'intérieur de <head>...</head> et de <body>...</body>.
C'est *mal* mais ça fonctionne ;-)
Ça fonctionne dans les navigateurs les plus connus, mais c'est *mal* ;-)
[Il faut] que les scripts soient rangés dans le bon ordre relativement à celui de la lecture de la page (du fichier)
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Certains scripts php se permettent d'écrire directement le javascript dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car le fichier javascript est toujours indépendant pour les modifs sur le serveur, mais le nombre de requêtes http est diminué.
Qu'en pensez-vous ?
JF TANGUY
la question est simple et quasi pas du Javascript ..
En effet. fcwi.auteurs aurait probablement été plus adapté.
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que l'on veut dans un élément HEAD.
<!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut mettre un élément SCRIPT à tous les endroits où les éléments A, IMG, OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document --> <!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation --> <!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et aussi dans les autres éléments qui ne contiennent normalement que des éléments de type block (BLOCKQUOTE et FORM).
En conclusion : sauf erreur ou omission, l'élément SCRIPT est autorisé pratiquement partout.
Merci pour vos infos.
selon votre expérience est-il plus intéressant d'inclure (avec php, ce
qui laisse mon source lisible) le script directement dans la page http
ou le laisser dans un fichier séparé.
Certains scripts php se permettent d'écrire directement le javascript
dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car le fichier
javascript est toujours indépendant pour les modifs sur le serveur, mais
le nombre de requêtes http est diminué.
Qu'en pensez-vous ?
JF TANGUY
la question est simple et quasi pas du Javascript ..
En effet. fcwi.auteurs aurait probablement été plus adapté.
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments
d'en-tête répétables -->
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du
document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que
l'on veut dans un élément HEAD.
<!ENTITY % special
"A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut
mettre un élément SCRIPT à tous les endroits où les éléments A, IMG,
OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document -->
<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation -->
<!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et
aussi dans les autres éléments qui ne contiennent normalement que des
éléments de type block (BLOCKQUOTE et FORM).
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Certains scripts php se permettent d'écrire directement le javascript dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car le fichier javascript est toujours indépendant pour les modifs sur le serveur, mais le nombre de requêtes http est diminué.
Qu'en pensez-vous ?
JF TANGUY
la question est simple et quasi pas du Javascript ..
En effet. fcwi.auteurs aurait probablement été plus adapté.
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que l'élément SCRIPT peut se retrouver autant de fois que l'on veut dans un élément HEAD.
<!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">
Sans aller vérifier dans toute la doc, on devine ici que l'on peut mettre un élément SCRIPT à tous les endroits où les éléments A, IMG, OBJECT, etc. sont autorisés.
<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- corps du document --> <!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT)+ -- longue citation --> <!ELEMENT FORM - - (%block;|SCRIPT)+ -(FORM) -- formulaire interactif -->
L'élément SCRIPT est en outre autorisé directement dans le BODY, et aussi dans les autres éléments qui ne contiennent normalement que des éléments de type block (BLOCKQUOTE et FORM).
En conclusion : sauf erreur ou omission, l'élément SCRIPT est autorisé pratiquement partout.
Olivier Miakinen
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Cela se discute pour un script d'une dizaine de lignes, mais de manière générale je préfère un fichier séparé, pour plusieurs raisons.
1) Raison philosophique (mais surtout de lisibilité) de séparation des tâches (structure = HTML, présentation = CSS, script = JS).
2) Raison économique : un navigateur ne reconnaissant pas JavaScript n'aura pas besoin de charger le .js si c'est un fichier séparé alors qu'il sera obligé de se farcir le code s'il est mélangé au HTML.
3) Raison pratique : dans un fichier séparé on n'est pas obligé de faire des bidouilles du genre de « / » au lieu de « / » pour ne pas troubler le navigateur.
Certains scripts php se permettent d'écrire directement le javascript dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car [...] le nombre de requêtes http est diminué.
Dans le cas où du code JavaScript serait réutilisable entre plusieurs pages HTML, avoir un fichier à part permet aussi d'économiser la bande passante puisqu'il sera chargé une seule fois et mis en cache.
[ citation intégrale ]
De grâce, merci de ne pas recopier l'intégralité des articles précédents ! Voir : http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
selon votre expérience est-il plus intéressant d'inclure (avec php, ce
qui laisse mon source lisible) le script directement dans la page http
ou le laisser dans un fichier séparé.
Cela se discute pour un script d'une dizaine de lignes, mais de manière
générale je préfère un fichier séparé, pour plusieurs raisons.
1) Raison philosophique (mais surtout de lisibilité) de séparation des
tâches (structure = HTML, présentation = CSS, script = JS).
2) Raison économique : un navigateur ne reconnaissant pas JavaScript
n'aura pas besoin de charger le .js si c'est un fichier séparé alors
qu'il sera obligé de se farcir le code s'il est mélangé au HTML.
3) Raison pratique : dans un fichier séparé on n'est pas obligé de faire
des bidouilles du genre de « / » au lieu de « / » pour ne pas troubler
le navigateur.
Certains scripts php se permettent d'écrire directement le javascript
dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car [...]
le nombre de requêtes http est diminué.
Dans le cas où du code JavaScript serait réutilisable entre plusieurs
pages HTML, avoir un fichier à part permet aussi d'économiser la bande
passante puisqu'il sera chargé une seule fois et mis en cache.
[ citation intégrale ]
De grâce, merci de ne pas recopier l'intégralité des articles
précédents ! Voir :
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Cela se discute pour un script d'une dizaine de lignes, mais de manière générale je préfère un fichier séparé, pour plusieurs raisons.
1) Raison philosophique (mais surtout de lisibilité) de séparation des tâches (structure = HTML, présentation = CSS, script = JS).
2) Raison économique : un navigateur ne reconnaissant pas JavaScript n'aura pas besoin de charger le .js si c'est un fichier séparé alors qu'il sera obligé de se farcir le code s'il est mélangé au HTML.
3) Raison pratique : dans un fichier séparé on n'est pas obligé de faire des bidouilles du genre de « / » au lieu de « / » pour ne pas troubler le navigateur.
Certains scripts php se permettent d'écrire directement le javascript dans la page http d'autre font références a un fichier.
Je pencherait personnellement vers l'inclusion php, car [...] le nombre de requêtes http est diminué.
Dans le cas où du code JavaScript serait réutilisable entre plusieurs pages HTML, avoir un fichier à part permet aussi d'économiser la bande passante puisqu'il sera chargé une seule fois et mis en cache.
[ citation intégrale ]
De grâce, merci de ne pas recopier l'intégralité des articles précédents ! Voir : http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
SAM
Merci pour vos infos.
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Qu'en pensez-vous ?
J'en pense que pour un bon usage de la bande passante (et des requêtes ... mais ... moins) et par là un chargement des pages optimisé pour le visiteur
il est *toujours* mieux d'externaliser le plus possible (JS et CSS) surtout si le code des fichiers externes est utilisé dans plusieurs pages.
et ce indépendamment de tous les avantages de la gestion de ces fichiers externes (puisqu'on peut tt aussi facilement réaliser des includes en PHP)
Merci pour vos infos.
selon votre expérience est-il plus intéressant d'inclure (avec php, ce
qui laisse mon source lisible) le script directement dans la page http
ou le laisser dans un fichier séparé.
Qu'en pensez-vous ?
J'en pense que pour un bon usage de la bande passante
(et des requêtes ... mais ... moins) et par là un chargement des pages
optimisé pour le visiteur
il est *toujours* mieux d'externaliser le plus possible (JS et CSS)
surtout si le code des fichiers externes est utilisé dans plusieurs pages.
et ce indépendamment de tous les avantages de la gestion de ces fichiers
externes
(puisqu'on peut tt aussi facilement réaliser des includes en PHP)
selon votre expérience est-il plus intéressant d'inclure (avec php, ce qui laisse mon source lisible) le script directement dans la page http ou le laisser dans un fichier séparé.
Qu'en pensez-vous ?
J'en pense que pour un bon usage de la bande passante (et des requêtes ... mais ... moins) et par là un chargement des pages optimisé pour le visiteur
il est *toujours* mieux d'externaliser le plus possible (JS et CSS) surtout si le code des fichiers externes est utilisé dans plusieurs pages.
et ce indépendamment de tous les avantages de la gestion de ces fichiers externes (puisqu'on peut tt aussi facilement réaliser des includes en PHP)
Mihamina Rakotomandimby
Olivier Miakinen wrote:
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce "langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Olivier Miakinen wrote:
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments
d'en-tête répétables -->
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du
document -->
On voit ici que
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce
"langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- éléments d'en-tête répétables --> <!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- en-tête du document -->
On voit ici que
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce "langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Olivier Miakinen
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce "langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Je n'en ai jamais trouvé de vraiment transcendant, probablement parce qu'il n'existe que des versions payantes de SGML. Mais je trouve qu'il suffit d'avoir une vague idée de ce que cela doit vouloir dire pour comprendre ce que cela dit exactement ; et la vague idée, je l'ai en comparant les descriptions textuelles élément par élément (le reste de la norme) avec la DTD elle-même.
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce
"langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Je n'en ai jamais trouvé de vraiment transcendant, probablement parce
qu'il n'existe que des versions payantes de SGML. Mais je trouve qu'il
suffit d'avoir une vague idée de ce que cela doit vouloir dire pour
comprendre ce que cela dit exactement ; et la vague idée, je l'ai en
comparant les descriptions textuelles élément par élément (le reste de
la norme) avec la DTD elle-même.
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce "langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Je n'en ai jamais trouvé de vraiment transcendant, probablement parce qu'il n'existe que des versions payantes de SGML. Mais je trouve qu'il suffit d'avoir une vague idée de ce que cela doit vouloir dire pour comprendre ce que cela dit exactement ; et la vague idée, je l'ai en comparant les descriptions textuelles élément par élément (le reste de la norme) avec la DTD elle-même.
Laurent vilday
Olivier, est-ce que tu aurait un lien qui explique comment "décoder" ce "langage" des "normes" HTML? Je ne m'y suis jamais profondément plongé...
Je n'en ai jamais trouvé de vraiment transcendant, probablement parce qu'il n'existe que des versions payantes de SGML.
