1) si une page peut-être appelée depuis plusieurs autres pages du site ?
Exemple : une fiche article, une fiche utilisateur ou en core une fiche
client...
2) si les utilisateurs du site font usage du bouton "Retour" (history.back()
en javascript) ? Ou encore si ces utilisateurs "sautent" directement à
n'importe quelle page du site déjà visitée (via l'historique?) Ou même vers
une page non encore visitée (via un lien de leurs favoris?)
Le 10 May 2007 15:28:32 GMT, Olivier Miakinen <om+ écrivait dans fr.comp.lang.php:
S'il s'agit de retrouver le chemin suivi de façon efficace, je pense que la seule façon est avec un cookie. Au début de chaque page, on ajoute à une pile (conservée sous forme de cookie) la page courante, soit son identification ou un mot clé.
Est-ce que tu penses que ça pourrait fonctionner avec plusieurs fenêtres ou onglets ouverts sur le même site Personnellement j'en doute.
Je n'utilise pas ce concept de fil d'Ariane. Sur mon propre site de généalogie, les données sont très irrégulières et la navigation serait par exemple index niveau 1:index niveau 2:fiche 1:fiche 15:fiche 8: fiche 1234:fiche 1, donc chez moi, ce concept de chemin est inutile.
IL y a aussi le contexte de l'information affichée. Le chemin suivi pourrait être: région - sous-région - ville - service - autre ville avec le même service (donc le fil d'Ariane est alors remplacé par autre chose).
Je ne faisais que suggérer une façon de le réaliser.
Le cookie pourrait être par exemple: Top:World:Français:Informatique:Internet: puis on fait explode pour séparer en mots et afficher.
Et donc, même avec une seule fenêtre, quelqu'un qui passerait de la page française à l'anglaise avant de remonter vers la racine pourrait arriver par exemple à : Top:World:Français:Informatique:Internet:Internet:Computers:Top:World:(etc.)
Il s'agit de filtrer en conséquence et de ré-ordonner si l'information doit être affichée de façon hiérarchisée.
Mais à mon avis, le plus simple serait de faire en statique ce fil d'Ariane et non le générer selon le chemin suivi par le visiteur.
Beaucoup de sites interdisent l'entrée du visiteur qui n'a pas ses cookies actifs ou le redirigent vers une page de départ s'il arrive à l'intérieur. À l'auteur de décider si c'est essentiel.
*Beaucoup* de sites ? Quelle horreur. :-(
1000 sur 10 millions, c'est peu en proportion mais beaucoup en absolu!
Je faisais quelque chose du genre (à la demande du directeur de projet). Chaque page générée avait une date et si on regardait la page 3 jours plus tard, je redirigeais vers la page d'accueil. Je m'aperçois à la longue que c'est plutôt une question de mégalomanie (il veut que tout le monde voit son nom, donc les forcer à passer par la présentation).
Moi j'utilise plutôt l'IP pour identifier les visiteurs et limiter le nombre de pages vues (anti-aspirateur, essentiel avec 80 000 pages).
Je voyais ça avec les vieux sites utilisant des cadres (angl: frames) mais heureusement c'est de plus en plus rare.
Et si le but est de remplacer l'historique, il me semble plus simple d'utiliser cet historique.
[OUI]
Denis
Le 10 May 2007 15:28:32 GMT, Olivier Miakinen <om+news@miakinen.net>
écrivait dans fr.comp.lang.php:
S'il s'agit de retrouver le chemin suivi de façon efficace, je pense
que la seule façon est avec un cookie. Au début de chaque page, on
ajoute à une pile (conservée sous forme de cookie) la page courante,
soit son identification ou un mot clé.
Est-ce que tu penses que ça pourrait fonctionner avec plusieurs fenêtres
ou onglets ouverts sur le même site Personnellement j'en doute.
Je n'utilise pas ce concept de fil d'Ariane. Sur mon propre site de
généalogie, les données sont très irrégulières et la navigation serait
par exemple index niveau 1:index niveau 2:fiche 1:fiche 15:fiche 8:
fiche 1234:fiche 1, donc chez moi, ce concept de chemin est inutile.
IL y a aussi le contexte de l'information affichée. Le chemin suivi
pourrait être:
région - sous-région - ville - service - autre ville avec le même
service (donc le fil d'Ariane est alors remplacé par autre chose).
Je ne faisais que suggérer une façon de le réaliser.
Le cookie pourrait être par exemple:
Top:World:Français:Informatique:Internet:
puis on fait explode pour séparer en mots et afficher.
Et donc, même avec une seule fenêtre, quelqu'un qui passerait de la page
française à l'anglaise avant de remonter vers la racine pourrait arriver
par exemple à :
Top:World:Français:Informatique:Internet:Internet:Computers:Top:World:(etc.)
Il s'agit de filtrer en conséquence et de ré-ordonner si l'information
doit être affichée de façon hiérarchisée.
Mais à mon avis, le plus simple serait de faire en statique ce fil
d'Ariane et non le générer selon le chemin suivi par le visiteur.
Beaucoup de sites interdisent l'entrée du visiteur qui n'a pas
ses cookies actifs ou le redirigent vers une page de départ
s'il arrive à l'intérieur. À l'auteur de décider si c'est essentiel.
*Beaucoup* de sites ? Quelle horreur. :-(
1000 sur 10 millions, c'est peu en proportion mais beaucoup en absolu!
Je faisais quelque chose du genre (à la demande du directeur de
projet). Chaque page générée avait une date et si on regardait la
page 3 jours plus tard, je redirigeais vers la page d'accueil. Je
m'aperçois à la longue que c'est plutôt une question de
mégalomanie (il veut que tout le monde voit son nom, donc les forcer
à passer par la présentation).
Moi j'utilise plutôt l'IP pour identifier les visiteurs et limiter le
nombre de pages vues (anti-aspirateur, essentiel avec 80 000 pages).
Je voyais ça avec les vieux sites utilisant des cadres (angl: frames)
mais heureusement c'est de plus en plus rare.
Et si le but est de remplacer l'historique, il me semble plus simple
d'utiliser cet historique.
Le 10 May 2007 15:28:32 GMT, Olivier Miakinen <om+ écrivait dans fr.comp.lang.php:
S'il s'agit de retrouver le chemin suivi de façon efficace, je pense que la seule façon est avec un cookie. Au début de chaque page, on ajoute à une pile (conservée sous forme de cookie) la page courante, soit son identification ou un mot clé.
Est-ce que tu penses que ça pourrait fonctionner avec plusieurs fenêtres ou onglets ouverts sur le même site Personnellement j'en doute.
Je n'utilise pas ce concept de fil d'Ariane. Sur mon propre site de généalogie, les données sont très irrégulières et la navigation serait par exemple index niveau 1:index niveau 2:fiche 1:fiche 15:fiche 8: fiche 1234:fiche 1, donc chez moi, ce concept de chemin est inutile.
IL y a aussi le contexte de l'information affichée. Le chemin suivi pourrait être: région - sous-région - ville - service - autre ville avec le même service (donc le fil d'Ariane est alors remplacé par autre chose).
Je ne faisais que suggérer une façon de le réaliser.
Le cookie pourrait être par exemple: Top:World:Français:Informatique:Internet: puis on fait explode pour séparer en mots et afficher.
Et donc, même avec une seule fenêtre, quelqu'un qui passerait de la page française à l'anglaise avant de remonter vers la racine pourrait arriver par exemple à : Top:World:Français:Informatique:Internet:Internet:Computers:Top:World:(etc.)
Il s'agit de filtrer en conséquence et de ré-ordonner si l'information doit être affichée de façon hiérarchisée.
Mais à mon avis, le plus simple serait de faire en statique ce fil d'Ariane et non le générer selon le chemin suivi par le visiteur.
Beaucoup de sites interdisent l'entrée du visiteur qui n'a pas ses cookies actifs ou le redirigent vers une page de départ s'il arrive à l'intérieur. À l'auteur de décider si c'est essentiel.
*Beaucoup* de sites ? Quelle horreur. :-(
1000 sur 10 millions, c'est peu en proportion mais beaucoup en absolu!
Je faisais quelque chose du genre (à la demande du directeur de projet). Chaque page générée avait une date et si on regardait la page 3 jours plus tard, je redirigeais vers la page d'accueil. Je m'aperçois à la longue que c'est plutôt une question de mégalomanie (il veut que tout le monde voit son nom, donc les forcer à passer par la présentation).
Moi j'utilise plutôt l'IP pour identifier les visiteurs et limiter le nombre de pages vues (anti-aspirateur, essentiel avec 80 000 pages).
Je voyais ça avec les vieux sites utilisant des cadres (angl: frames) mais heureusement c'est de plus en plus rare.
Et si le but est de remplacer l'historique, il me semble plus simple d'utiliser cet historique.
[OUI]
Denis
Bruno Desthuilliers
Bonjour,
Comment gérer un fil d'Ariane ? En particulier :
1) si une page peut-être appelée depuis plusieurs autres pages du site ? Exemple : une fiche article, une fiche utilisateur ou en core une fiche client...
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton système qui représente cette arborescence, tu ne peux pas construire un fil d'ariane. En dehors de ça, le fait que plusieurs "noeuds" de cette arborescence pointent en fait vers la même page est sans incidence - normalement, l'URI devrait permettre de déterminer sans ambiguité où on est.
2) si les utilisateurs du site font usage du bouton "Retour" (history.back() en javascript) ? Ou encore si ces utilisateurs "sautent" directement à n'importe quelle page du site déjà visitée (via l'historique?) Ou même vers une page non encore visitée (via un lien de leurs favoris?)
Là je ne vois pas le rapport. Le "fil d'ariane" n'est pas un historique des déplacements du visiteur, mais un indicateur de position dans une arborescence.
Bonjour,
Comment gérer un fil d'Ariane ? En particulier :
1) si une page peut-être appelée depuis plusieurs autres pages du site ?
Exemple : une fiche article, une fiche utilisateur ou en core une fiche
client...
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton
système qui représente cette arborescence, tu ne peux pas construire un
fil d'ariane. En dehors de ça, le fait que plusieurs "noeuds" de cette
arborescence pointent en fait vers la même page est sans incidence -
normalement, l'URI devrait permettre de déterminer sans ambiguité où on est.
2) si les utilisateurs du site font usage du bouton "Retour" (history.back()
en javascript) ? Ou encore si ces utilisateurs "sautent" directement à
n'importe quelle page du site déjà visitée (via l'historique?) Ou même vers
une page non encore visitée (via un lien de leurs favoris?)
Là je ne vois pas le rapport. Le "fil d'ariane" n'est pas un historique
des déplacements du visiteur, mais un indicateur de position dans une
arborescence.
1) si une page peut-être appelée depuis plusieurs autres pages du site ? Exemple : une fiche article, une fiche utilisateur ou en core une fiche client...
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton système qui représente cette arborescence, tu ne peux pas construire un fil d'ariane. En dehors de ça, le fait que plusieurs "noeuds" de cette arborescence pointent en fait vers la même page est sans incidence - normalement, l'URI devrait permettre de déterminer sans ambiguité où on est.
2) si les utilisateurs du site font usage du bouton "Retour" (history.back() en javascript) ? Ou encore si ces utilisateurs "sautent" directement à n'importe quelle page du site déjà visitée (via l'historique?) Ou même vers une page non encore visitée (via un lien de leurs favoris?)
Là je ne vois pas le rapport. Le "fil d'ariane" n'est pas un historique des déplacements du visiteur, mais un indicateur de position dans une arborescence.
Bruno Desthuilliers
Avez-vous lu attentivement mes questions, ou me suis-je mal exprimé ? Ou encore quelque chose m'échappe ?
Réponse C.
Bref, s'agissant du site sur lequel je travaille, toutes les pages sont, physiquement, dans un même dossier.
Et ? Même si historiquement, pour un site statique, il y a une correspondance quasiment[1] univoque entre URI et chemin de fichier, ces deux concepts restent disjoints. Si tu regarde un CMS comme Spip, le site a une structure arborescente évidente, qui n'a aucun rapport avec l'organisation physique des fichiers.
[1] rien n'empêche de faire des liens (symboliques ou non) pour avoir un même fichier dans deux dossiers...
A la limite, on pourrait imaginer réorganiser tout cela dans des dossiers... MAIS, une fiche article, par exemple, c'est toujours une fiche article... Partout dans le site, c'est la même, qu'elle soit demandée depuis une branche de l'arborescence dédiée à la saisie de commande, ou d'une autre branche liée aux statistiques articles, ou n'importe quoi d'autre... Serait-ce que vous me conseillez de *dupliquer* les pages ? Autant de fiche article que d'endroit où elle peut être appelée ? Simplement lourd, non ?
Non seulement lourd mais aussi totalement inepte.
Accessoirement, ce que tu décris est une application web (orienté traitement), pas un site web (orienté contenu). Je ne vois pas clairement ce qu'un fil d'ariane vient faire là-dedans, mais si tu en veux vraiment un, il devrait ressembler à quelquechose comme "articles
id_article" (ou "articles >> id_categorie >> id_article", etc...). Le fait que tu arrives à la fiche article depuis la saisie d'une
commande ou depuis les stats articles est sans rapport. Si ton souci est de pouvoir revenir à la page précédente quelle qu'elle soit, tu peux soit ouvrir la fiche article dans un pop-up, soit stocker l'URI de la page appelante dans la session (puisqu'il est probable que tu utilises les sessions dans ce contexte), soit tout simplement passer cette URI (ou au moins la partie suffisante) en paramètre.
Avez-vous lu attentivement mes questions, ou me suis-je mal exprimé ?
Ou encore quelque chose m'échappe ?
Réponse C.
Bref, s'agissant du site sur lequel je travaille, toutes les pages sont,
physiquement, dans un même dossier.
Et ? Même si historiquement, pour un site statique, il y a une
correspondance quasiment[1] univoque entre URI et chemin de fichier, ces
deux concepts restent disjoints. Si tu regarde un CMS comme Spip, le
site a une structure arborescente évidente, qui n'a aucun rapport avec
l'organisation physique des fichiers.
[1] rien n'empêche de faire des liens (symboliques ou non) pour avoir un
même fichier dans deux dossiers...
A la limite, on pourrait imaginer réorganiser tout cela dans des dossiers...
MAIS, une fiche article, par exemple, c'est toujours une fiche article...
Partout dans le site, c'est la même, qu'elle soit demandée depuis une
branche de l'arborescence dédiée à la saisie de commande, ou d'une autre
branche liée aux statistiques articles, ou n'importe quoi d'autre...
Serait-ce que vous me conseillez de *dupliquer* les pages ?
Autant de fiche article que d'endroit où elle peut être appelée ?
Simplement lourd, non ?
Non seulement lourd mais aussi totalement inepte.
Accessoirement, ce que tu décris est une application web (orienté
traitement), pas un site web (orienté contenu). Je ne vois pas
clairement ce qu'un fil d'ariane vient faire là-dedans, mais si tu en
veux vraiment un, il devrait ressembler à quelquechose comme "articles
id_article" (ou "articles >> id_categorie >> id_article", etc...).
Le fait que tu arrives à la fiche article depuis la saisie d'une
commande ou depuis les stats articles est sans rapport. Si ton souci est
de pouvoir revenir à la page précédente quelle qu'elle soit, tu peux
soit ouvrir la fiche article dans un pop-up, soit stocker l'URI de la
page appelante dans la session (puisqu'il est probable que tu utilises
les sessions dans ce contexte), soit tout simplement passer cette URI
(ou au moins la partie suffisante) en paramètre.
Avez-vous lu attentivement mes questions, ou me suis-je mal exprimé ? Ou encore quelque chose m'échappe ?
Réponse C.
Bref, s'agissant du site sur lequel je travaille, toutes les pages sont, physiquement, dans un même dossier.
Et ? Même si historiquement, pour un site statique, il y a une correspondance quasiment[1] univoque entre URI et chemin de fichier, ces deux concepts restent disjoints. Si tu regarde un CMS comme Spip, le site a une structure arborescente évidente, qui n'a aucun rapport avec l'organisation physique des fichiers.
[1] rien n'empêche de faire des liens (symboliques ou non) pour avoir un même fichier dans deux dossiers...
A la limite, on pourrait imaginer réorganiser tout cela dans des dossiers... MAIS, une fiche article, par exemple, c'est toujours une fiche article... Partout dans le site, c'est la même, qu'elle soit demandée depuis une branche de l'arborescence dédiée à la saisie de commande, ou d'une autre branche liée aux statistiques articles, ou n'importe quoi d'autre... Serait-ce que vous me conseillez de *dupliquer* les pages ? Autant de fiche article que d'endroit où elle peut être appelée ? Simplement lourd, non ?
Non seulement lourd mais aussi totalement inepte.
Accessoirement, ce que tu décris est une application web (orienté traitement), pas un site web (orienté contenu). Je ne vois pas clairement ce qu'un fil d'ariane vient faire là-dedans, mais si tu en veux vraiment un, il devrait ressembler à quelquechose comme "articles
id_article" (ou "articles >> id_categorie >> id_article", etc...). Le fait que tu arrives à la fiche article depuis la saisie d'une
commande ou depuis les stats articles est sans rapport. Si ton souci est de pouvoir revenir à la page précédente quelle qu'elle soit, tu peux soit ouvrir la fiche article dans un pop-up, soit stocker l'URI de la page appelante dans la session (puisqu'il est probable que tu utilises les sessions dans ce contexte), soit tout simplement passer cette URI (ou au moins la partie suffisante) en paramètre.
Pascal PONCET
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton système qui représente cette arborescence, tu ne peux pas construire un fil d'ariane.
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton
système qui représente cette arborescence, tu ne peux pas construire un
fil d'ariane.
Complètement d'accord !
En fait, dans les sites où les pages sont très hiérarchisées, le système
du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML
qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou
en tout cas anti-ergonomiques.
Un "fil d'ariane" correspond à une arborescence. Si tu n'a rien dans ton système qui représente cette arborescence, tu ne peux pas construire un fil d'ariane.
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
Thief13
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
Complètement d'accord !
En fait, dans les sites où les pages sont très hiérarchisées, le système
du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML
qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou
en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour
dans la section formations, il y à 5 niveau de profondeur. ce site est
encore en cour de remplissage)
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
Pascal PONCET
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
J'ai été voir. Désolé, je reste sur ma position. Mais comme le thème du site est très "visuel", il est difficile de juger sereinement (voire de juger tout court). Ca devient une affaire de goût, plus que d'ergonomie. Ce sont les limites du Web et de ses standards...
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour
dans la section formations, il y à 5 niveau de profondeur. ce site est
encore en cour de remplissage)
J'ai été voir. Désolé, je reste sur ma position.
Mais comme le thème du site est très "visuel", il est difficile de juger
sereinement (voire de juger tout court). Ca devient une affaire de goût,
plus que d'ergonomie.
Ce sont les limites du Web et de ses standards...
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
J'ai été voir. Désolé, je reste sur ma position. Mais comme le thème du site est très "visuel", il est difficile de juger sereinement (voire de juger tout court). Ca devient une affaire de goût, plus que d'ergonomie. Ce sont les limites du Web et de ses standards...
filh
Thief13 wrote:
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Thief13 <Thief13@nospam.com> wrote:
Complètement d'accord !
En fait, dans les sites où les pages sont très hiérarchisées, le système
du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML
qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou
en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour
dans la section formations, il y à 5 niveau de profondeur. ce site est
encore en cour de remplissage)
Ça marche pas dans safari... (y compris avec le webkit de développement)
dommage...
Pleins de choses se supperposent sur les menus.
Et ils ne sont pas au bon endroit.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Complètement d'accord ! En fait, dans les sites où les pages sont très hiérarchisées, le système du "fil d'Ariane" remplace avantageusement les menus imbriqués en DHTML qui, au-delà de 3 niveaux d'arborescence, deviennent inexploitables ou en tout cas anti-ergonomiques.
ça dépend comment c'est pensé (cf http://www.aries3d.org, faire un tour dans la section formations, il y à 5 niveau de profondeur. ce site est encore en cour de remplissage)
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Thief13
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML... en plus, ce design demande une résolution de 1024x768 (choix pourris, mais bon...)
Ça marche pas dans safari... (y compris avec le webkit de développement)
dommage...
Pleins de choses se supperposent sur les menus.
Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML... en plus, ce design
demande une résolution de 1024x768 (choix pourris, mais bon...)
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML... en plus, ce design demande une résolution de 1024x768 (choix pourris, mais bon...)
filh
Thief13 wrote:
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant (corrigé dans les versions de développement) , mais je ne fais pas non plus des trucs trop fou en css.
en plus, ce design demande une résolution de 1024x768 (choix pourris, mais bon...)
Bah j'ai...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Thief13 <Thief13@nospam.com> wrote:
Ça marche pas dans safari... (y compris avec le webkit de développement)
dommage...
Pleins de choses se supperposent sur les menus.
Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant
(corrigé dans les versions de développement) , mais je ne fais pas non
plus des trucs trop fou en css.
en plus, ce design
demande une résolution de 1024x768 (choix pourris, mais bon...)
Bah j'ai...
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Ça marche pas dans safari... (y compris avec le webkit de développement) dommage... Pleins de choses se supperposent sur les menus. Et ils ne sont pas au bon endroit.
FiLH
Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant (corrigé dans les versions de développement) , mais je ne fais pas non plus des trucs trop fou en css.
en plus, ce design demande une résolution de 1024x768 (choix pourris, mais bon...)
Bah j'ai...
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Thief13
FiLH Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant (corrigé dans les versions de développement) , mais je ne fais pas non plus des trucs trop fou en css.
bin oui tant que ça, la preuve ! si tu vallide la page, tu verra que le seul problème, c'est dans une URL ou il y a un & à la place d'un & Et ça ne fait pas passer Firefox en mode Quirk...
FiLH
Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant
(corrigé dans les versions de développement) , mais je ne fais pas non
plus des trucs trop fou en css.
bin oui tant que ça, la preuve ! si tu vallide la page, tu verra que le
seul problème, c'est dans une URL ou il y a un & à la place d'un &
Et ça ne fait pas passer Firefox en mode Quirk...
FiLH Safari respecte difficilement le CSS et le XHTML...
Bah... tant que ça ? J'avoue être tombé sur un seul bug pour l'instant (corrigé dans les versions de développement) , mais je ne fais pas non plus des trucs trop fou en css.
bin oui tant que ça, la preuve ! si tu vallide la page, tu verra que le seul problème, c'est dans une URL ou il y a un & à la place d'un & Et ça ne fait pas passer Firefox en mode Quirk...
