Voilà j'ai toujours un peu délaissé le JS, car ce langage peux être
désactivé par l'utilisateur, donc j'avais tendance à tout faire en php et
css.
aujourd'hui je me rend compte que c'était une erreur car je souhaite faire
une petite galerie photo et le js est le plus approprié des langages, donc
je suis obligé de m'y remettre.
Rhaaa la la ... mais ça n'aura donc jamais de fin ?
A ton avis ?-)
Pierre Goiffon
Bruno Desthuilliers wrote:
La dépréciation n'est pas l'abolition ...
ce qui revient à dire : devrait (dans le futur)
Vu la date de la spec HTML 4, le futur est passé depuis longtemps... Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de) continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag, quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de", mais de savoir si tu espère avoir un code raisonnablement correct et (en conséquence) un résultat raisonnablement fiable. (...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web ! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de rendu mode standard)
Pour en revenir au point de départ, un attribut name pour une image est très loin d'une "soupe de tags" : c'est parfaitement reconnu, et on peut parier qu'une page HTML 4.01 restera lisible en mode strict pendant encore quelques années, pour le moins.
Bruno Desthuilliers wrote:
La dépréciation n'est pas l'abolition ...
ce qui revient à dire : devrait (dans le futur)
Vu la date de la spec HTML 4, le futur est passé depuis longtemps...
Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de)
continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag,
quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de",
mais de savoir si tu espère avoir un code raisonnablement correct et (en
conséquence) un résultat raisonnablement fiable.
(...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict
Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste
qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web
! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de
rendu mode standard)
Pour en revenir au point de départ, un attribut name pour une image est
très loin d'une "soupe de tags" : c'est parfaitement reconnu, et on peut
parier qu'une page HTML 4.01 restera lisible en mode strict pendant
encore quelques années, pour le moins.
Vu la date de la spec HTML 4, le futur est passé depuis longtemps... Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de) continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag, quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de", mais de savoir si tu espère avoir un code raisonnablement correct et (en conséquence) un résultat raisonnablement fiable. (...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web ! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de rendu mode standard)
Pour en revenir au point de départ, un attribut name pour une image est très loin d'une "soupe de tags" : c'est parfaitement reconnu, et on peut parier qu'une page HTML 4.01 restera lisible en mode strict pendant encore quelques années, pour le moins.
Bruno Desthuilliers
Bruno Desthuilliers wrote:
La dépréciation n'est pas l'abolition ...
ce qui revient à dire : devrait (dans le futur)
Vu la date de la spec HTML 4, le futur est passé depuis longtemps... Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de) continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag, quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de", mais de savoir si tu espère avoir un code raisonnablement correct et (en conséquence) un résultat raisonnablement fiable. (...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Effectivement, je tends à être excessif dans ces domaines là. Peut-être une mauvaise habitude prise avec le C, langage avec lequel les conséquences d'un manque de rigueur peuvent être notoirement plus désastreux ? En tout état de cause, cette tendance m'a pour le moment plutôt bien réussi.
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web ! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de rendu mode standard)
C'est curieux, moi j'ai des rendus en mode respect des standards avec un doctype xhtml 1.0 strict...
Pour en revenir au point de départ, un attribut name pour une image est très loin d'une "soupe de tags" : c'est parfaitement reconnu,
Oui. C'est aussi: - inutilisable comme sélecteur CSS - inutilisable avec getElementById
Et ce aussi bien en html4.01 qu'en xhtml1.0
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Bruno Desthuilliers wrote:
La dépréciation n'est pas l'abolition ...
ce qui revient à dire : devrait (dans le futur)
Vu la date de la spec HTML 4, le futur est passé depuis longtemps...
Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de)
continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag,
quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de",
mais de savoir si tu espère avoir un code raisonnablement correct et
(en conséquence) un résultat raisonnablement fiable.
(...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict
Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Effectivement, je tends à être excessif dans ces domaines là. Peut-être
une mauvaise habitude prise avec le C, langage avec lequel les
conséquences d'un manque de rigueur peuvent être notoirement plus
désastreux ? En tout état de cause, cette tendance m'a pour le moment
plutôt bien réussi.
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste
qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web
! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de
rendu mode standard)
C'est curieux, moi j'ai des rendus en mode respect des standards avec un
doctype xhtml 1.0 strict...
Pour en revenir au point de départ, un attribut name pour une image est
très loin d'une "soupe de tags" : c'est parfaitement reconnu,
Oui. C'est aussi:
- inutilisable comme sélecteur CSS
- inutilisable avec getElementById
Et ce aussi bien en html4.01 qu'en xhtml1.0
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Vu la date de la spec HTML 4, le futur est passé depuis longtemps... Donc s/devraient/doivent/g
être évité, bien que les navigateurs peuvent (ont la permission de) continuer à les reconnaitre
Comme ils ont la permission d'essayer de rendre une soupe de tag, quelque puisse être le résultat.
La question n'est pas de savoir si "les navigateurs ont le droit de", mais de savoir si tu espère avoir un code raisonnablement correct et (en conséquence) un résultat raisonnablement fiable. (...)
... name n'est pas déprécié pour les images ...
Et ce, même avec une DDT html4.01 strict Ou alors j'ai vraiment loupé qque chose ? !
Oui: xhtml, et le DOM niveaux 1, 2 et maintenant 3...
C'est peu de dire que votre réponse est excessive !
Effectivement, je tends à être excessif dans ces domaines là. Peut-être une mauvaise habitude prise avec le C, langage avec lequel les conséquences d'un manque de rigueur peuvent être notoirement plus désastreux ? En tout état de cause, cette tendance m'a pour le moment plutôt bien réussi.
Si la recommandation HTML 4.01 est datée de décembre 1999, il reste qu'elle est la seule à être réellement utilisable aujourd'hui sur le Web ! Autrement dis, sur le Web hors HTML 4.01 Strict point de salut (pas de rendu mode standard)
C'est curieux, moi j'ai des rendus en mode respect des standards avec un doctype xhtml 1.0 strict...
Pour en revenir au point de départ, un attribut name pour une image est très loin d'une "soupe de tags" : c'est parfaitement reconnu,
Oui. C'est aussi: - inutilisable comme sélecteur CSS - inutilisable avec getElementById
Et ce aussi bien en html4.01 qu'en xhtml1.0
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
SAM
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Il serait peut-être pas inutile que tu puisses en même temps indiquer les effets de bords non désirés (je pense aux navigateurs pas au top).
Et puis, comme dit Pierre, le html4.01 n'est pas mort. Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
-- sm
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très
intéressant.
Il serait peut-être pas inutile que tu puisses en même temps indiquer
les effets de bords non désirés (je pense aux navigateurs pas au top).
Et puis, comme dit Pierre, le html4.01 n'est pas mort.
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond
(body et tags xhtml) de la forme, et y compris le dynamisme par JS.
Bonus : le html4.01 n'empêche pas de le faire.
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Il serait peut-être pas inutile que tu puisses en même temps indiquer les effets de bords non désirés (je pense aux navigateurs pas au top).
Et puis, comme dit Pierre, le html4.01 n'est pas mort. Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
-- sm
yoyo
SAM wrote:
SAM wrote:
Un grand spécialiste des galeries de photos (sans JS) : <http://www.cssplay.co.uk/menu/gallery.html>
c'est plutôt ça que j'avais tenté d'essayé de faire
Sauf que, normalement, il n'y a aucun JavaScript ;-)
oui je sais mais j'avais tenté de le faire avant de vouloir tenté un truc en js, bon mais c'est pas évident à mettre en oeuvre, en tout moi je suis pas arrivé a reproduire le code css.
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait) <http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées le roll-over déporté par méthode CSS y souffre des mêmes inconvénients qu'en JavaScript ... faut attendre la grande image en restant en survol sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire scroll pour revenir sur la grande image.
SAM wrote:
SAM wrote:
Un grand spécialiste des galeries de photos (sans JS) :
<http://www.cssplay.co.uk/menu/gallery.html>
c'est plutôt ça que j'avais tenté d'essayé de faire
Sauf que, normalement, il n'y a aucun JavaScript ;-)
oui je sais mais j'avais tenté de le faire avant de vouloir tenté un truc en
js, bon mais c'est pas évident à mettre en oeuvre, en tout moi je suis pas
arrivé a reproduire le code css.
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait)
<http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées
le roll-over déporté par méthode CSS y souffre des mêmes inconvénients
qu'en JavaScript ... faut attendre la grande image en restant en survol
sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire
scroll pour revenir sur la grande image.
Un grand spécialiste des galeries de photos (sans JS) : <http://www.cssplay.co.uk/menu/gallery.html>
c'est plutôt ça que j'avais tenté d'essayé de faire
Sauf que, normalement, il n'y a aucun JavaScript ;-)
oui je sais mais j'avais tenté de le faire avant de vouloir tenté un truc en js, bon mais c'est pas évident à mettre en oeuvre, en tout moi je suis pas arrivé a reproduire le code css.
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait) <http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées le roll-over déporté par méthode CSS y souffre des mêmes inconvénients qu'en JavaScript ... faut attendre la grande image en restant en survol sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire scroll pour revenir sur la grande image.
Bruno Desthuilliers
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Je crains d'être excessif...
Il serait peut-être pas inutile que tu puisses en même temps indiquer les effets de bords non désirés (je pense aux navigateurs pas au top).
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Et puis, comme dit Pierre, le html4.01 n'est pas mort.
Non. Ai-je dit une chose pareille ?
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Non plus. Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict. J'ai plus tendance à utiliser xhtml, mais surtout pour la compatibilité xml (et donc les outils disponibles).
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très
intéressant.
Je crains d'être excessif...
Il serait peut-être pas inutile que tu puisses en même temps indiquer
les effets de bords non désirés (je pense aux navigateurs pas au top).
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ?
C'est déjà fait, non ?
Et puis, comme dit Pierre, le html4.01 n'est pas mort.
Non. Ai-je dit une chose pareille ?
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond
(body et tags xhtml) de la forme, et y compris le dynamisme par JS.
Bonus : le html4.01 n'empêche pas de le faire.
Non plus. Tu notera d'ailleurs que dans l'exemple que je donnais,
j'utilisais le doctype html4.01 strict. J'ai plus tendance à utiliser
xhtml, mais surtout pour la compatibilité xml (et donc les outils
disponibles).
Maintenant, hein, chacun fait ce qu'il veut, n'est-ce pas...
Ha! quand même ! Merci ;-)
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Je crains d'être excessif...
Il serait peut-être pas inutile que tu puisses en même temps indiquer les effets de bords non désirés (je pense aux navigateurs pas au top).
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Et puis, comme dit Pierre, le html4.01 n'est pas mort.
Non. Ai-je dit une chose pareille ?
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Non plus. Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict. J'ai plus tendance à utiliser xhtml, mais surtout pour la compatibilité xml (et donc les outils disponibles).
SAM
SAM wrote:
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait) <http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées le roll-over déporté par méthode CSS y souffre des mêmes inconvénients qu'en JavaScript ... faut attendre la grande image en restant en survol sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire scroll pour revenir sur la grande image.
Meu non ! il suffit de mettre les vignettes dans un overflow:auto;
(pour IE peut-être est-ce + compliqué ?)
-- sm
SAM wrote:
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait)
<http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées
le roll-over déporté par méthode CSS y souffre des mêmes inconvénients
qu'en JavaScript ... faut attendre la grande image en restant en survol
sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire
scroll pour revenir sur la grande image.
Meu non !
il suffit de mettre les vignettes dans un overflow:auto;
Voici une version perso simplifiée (dont je ne sais ce qu'IE en fait) <http://stephane.moria> ux.pagesperso-orange.fr/truc/galerie_1.htm>
Mais les grandes images n'y sont pas pré ni post chargées le roll-over déporté par méthode CSS y souffre des mêmes inconvénients qu'en JavaScript ... faut attendre la grande image en restant en survol sur la petite (pas évident comme mécanisme car pas dans les habitudes)
le seule hic c'est que si tu as beaucoup de vignette tu es obligé de faire scroll pour revenir sur la grande image.
Meu non ! il suffit de mettre les vignettes dans un overflow:auto;
(pour IE peut-être est-ce + compliqué ?)
-- sm
SAM
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Je crains d'être excessif...
Ça dépend un peu à propos de quoi :-)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict.
Je généralisais.
-- sm
Mais surtout continue d'intervenir en tirant vers le haut, c'est très
intéressant.
Je crains d'être excessif...
Ça dépend un peu à propos de quoi :-)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ?
C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond
(body et tags xhtml) de la forme, et y compris le dynamisme par JS.
Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais,
j'utilisais le doctype html4.01 strict.
Mais surtout continue d'intervenir en tirant vers le haut, c'est très intéressant.
Je crains d'être excessif...
Ça dépend un peu à propos de quoi :-)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict.
Je généralisais.
-- sm
Bruno Desthuilliers
(snip)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Excuse-moi mais ça ne précise pas les effets de bords de *quoi* ...
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict.
Je généralisais.
Ta généralisation n'était-elle pas un peu excessive ?-)
(snip)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ?
C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Excuse-moi mais ça ne précise pas les effets de bords de *quoi* ...
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond
(body et tags xhtml) de la forme, et y compris le dynamisme par JS.
Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le
doctype html4.01 strict.
Je généralisais.
Ta généralisation n'était-elle pas un peu excessive ?-)
Les effets de bord de quoi ? De l'utilisation de name au lieu de id ? C'est déjà fait, non ?
Meuh non, relativement à des brouteurs pas assez évolués.
Excuse-moi mais ça ne précise pas les effets de bords de *quoi* ...
Néanmoins, bien sûr qu'on ne peut que préférer la séparation du fond (body et tags xhtml) de la forme, et y compris le dynamisme par JS. Bonus : le html4.01 n'empêche pas de le faire.
Tu notera d'ailleurs que dans l'exemple que je donnais, j'utilisais le doctype html4.01 strict.
Je généralisais.
Ta généralisation n'était-elle pas un peu excessive ?-)
SAM
Excuse-moi mais ça ne précise pas les effets de bords de *quoi* ...
Je doute que mon NC 4,5 arrive à rollovériser quoique ce soit avec ta solution (je peux plus le faire fonctionner sur ma config mais qd même)
Naaaan ! pas les biblis ! pas les biblis !
-- sm
Excuse-moi mais ça ne précise pas les effets de bords de *quoi* ...
Je doute que mon NC 4,5 arrive à rollovériser quoique ce soit avec ta
solution (je peux plus le faire fonctionner sur ma config mais qd même)
