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
SAM
Le 23/01/15 08:11, Une Bévue a écrit :
bon, j'ai commencé à redessiner ma page en css en suivant les conseils de SAM, à savoir :
Le mieux est de toujours commencer à faire des règles de styles minimalistes où on ne précise pas le positionnement des éléments
bon, ben je n'y arrive pas, la page d'essai est en ligne : <http://studio.quatorze.free.fr/new_4_cli_lanp_recettes/>
grosso mondo c'est "comme je veux", mais j'ai du bidouiller un max pour avoir le menu horizontal dans le header.
Mais oui ! Pour sûr ! Et on complexifie le html pour commencer et on complexifie les css pour continuer Heureusement on n'a pas le code du JS ! Je n'ose imaginer !!! ;-)
donc j'ai utiliser du positioning... et aussi deux divs dans header : #header_left et #header_right
ouais ... et le système de flottaison ? jamais ? ou, simplement, du inline-block ?
et si on étroitise la page bien fort, ça reste acceptable, non ?
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 23/01/15 08:11, Une Bévue a écrit :
bon, j'ai commencé à redessiner ma page en css en suivant les conseils
de SAM, à savoir :
Le mieux est de toujours commencer à faire des règles de styles
minimalistes où on ne précise pas le positionnement des éléments
bon, ben je n'y arrive pas, la page d'essai est en ligne :
<http://studio.quatorze.free.fr/new_4_cli_lanp_recettes/>
grosso mondo c'est "comme je veux", mais j'ai du bidouiller un max pour
avoir le menu horizontal dans le header.
Mais oui !
Pour sûr !
Et on complexifie le html pour commencer
et on complexifie les css pour continuer
Heureusement on n'a pas le code du JS ! Je n'ose imaginer !!!
;-)
donc j'ai utiliser du positioning...
et aussi deux divs dans header : #header_left et #header_right
ouais ... et le système de flottaison ? jamais ?
ou, simplement, du inline-block ?
bon, j'ai commencé à redessiner ma page en css en suivant les conseils de SAM, à savoir :
Le mieux est de toujours commencer à faire des règles de styles minimalistes où on ne précise pas le positionnement des éléments
bon, ben je n'y arrive pas, la page d'essai est en ligne : <http://studio.quatorze.free.fr/new_4_cli_lanp_recettes/>
grosso mondo c'est "comme je veux", mais j'ai du bidouiller un max pour avoir le menu horizontal dans le header.
Mais oui ! Pour sûr ! Et on complexifie le html pour commencer et on complexifie les css pour continuer Heureusement on n'a pas le code du JS ! Je n'ose imaginer !!! ;-)
donc j'ai utiliser du positioning... et aussi deux divs dans header : #header_left et #header_right
ouais ... et le système de flottaison ? jamais ? ou, simplement, du inline-block ?
ouais ... et le système de flottaison ? jamais ? ou, simplement, du inline-block ?
euh, c'est ce que j'ai mis !
désolé mais la question était à propos du menu.
j'ai résolu en ajoutant : text-align: right; sur l'UL
et : ul.menu > li:last-child { margin-right: 16px; }
par contre le positionnement de #header_right ul.menu reste nécessaire pour le centrer verticalement.
j'ai essayé avec des margins, ça colle pas.
SAM
Le 23/01/15 14:43, Une Bévue a écrit :
j'ai résolu en ajoutant : text-align: right; sur l'UL
Ouais,
et : ul.menu > li:last-child { margin-right: 16px; }
oui, pas mal mais ... ça fait rien qu'en rajouter une couche !
par contre le positionnement de #header_right ul.menu reste nécessaire pour le centrer verticalement.
J'en sais rien je n'ai pas tout regardé tu es beaucoup trop compliqué !!!
j'ai essayé avec des margins, ça colle pas.
J'ai essayé avec du line-height automatique, ça marche pas non plus.
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même présentation avec beaucoup moins de moyens ? css : 80 lignes --> 62 html : 12 lignes --> 9 je pense que le menu y est à peu près centré verticalement, en employant une marge !!!
Pour ton problème de ul / li pour menu, perso j'ai ajouté un a dans le li Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien Ça permet en outre de régler tes problèmes de marges et paddings
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 23/01/15 14:43, Une Bévue a écrit :
j'ai résolu en ajoutant :
text-align: right;
sur l'UL
Ouais,
et :
ul.menu > li:last-child {
margin-right: 16px;
}
oui, pas mal
mais ...
ça fait rien qu'en rajouter une couche !
par contre le positionnement de #header_right ul.menu
reste nécessaire pour le centrer verticalement.
J'en sais rien
je n'ai pas tout regardé
tu es beaucoup trop compliqué !!!
j'ai essayé avec des margins, ça colle pas.
J'ai essayé avec du line-height automatique, ça marche pas non plus.
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même
présentation avec beaucoup moins de moyens ?
css : 80 lignes --> 62
html : 12 lignes --> 9
je pense que le menu y est à peu près centré verticalement,
en employant
une marge !!!
Pour ton problème de ul / li pour menu,
perso j'ai ajouté un a dans le li
Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien
Ça permet en outre de régler tes problèmes de marges et paddings
En effet, grossièrement, les ul et li sont margés et paddés à zéro et
c'est le contenu (actif) qui ménage sa place et espacements
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la
flottaison, ce n'est pas du "tout naturel" !
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
j'ai résolu en ajoutant : text-align: right; sur l'UL
Ouais,
et : ul.menu > li:last-child { margin-right: 16px; }
oui, pas mal mais ... ça fait rien qu'en rajouter une couche !
par contre le positionnement de #header_right ul.menu reste nécessaire pour le centrer verticalement.
J'en sais rien je n'ai pas tout regardé tu es beaucoup trop compliqué !!!
j'ai essayé avec des margins, ça colle pas.
J'ai essayé avec du line-height automatique, ça marche pas non plus.
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même présentation avec beaucoup moins de moyens ? css : 80 lignes --> 62 html : 12 lignes --> 9 je pense que le menu y est à peu près centré verticalement, en employant une marge !!!
Pour ton problème de ul / li pour menu, perso j'ai ajouté un a dans le li Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien Ça permet en outre de régler tes problèmes de marges et paddings
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Une Bévue
Le 23/01/15 15:44, SAM a écrit :
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même présentation avec beaucoup moins de moyens ? css : 80 lignes --> 62 html : 12 lignes --> 9
oui, je préfère cette solution.
je pense que le menu y est à peu près centré verticalement,
oui, oui, ça me va.
en employant une marge !!!
Pour ton problème de ul / li pour menu, perso j'ai ajouté un a dans le li Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien Ça permet en outre de régler tes problèmes de marges et paddings
bon, je verrai pour l'instant le onclick est géré par js (addEventListener).
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
Le 23/01/15 15:44, SAM a écrit :
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même
présentation avec beaucoup moins de moyens ?
css : 80 lignes --> 62
html : 12 lignes --> 9
oui, je préfère cette solution.
je pense que le menu y est à peu près centré verticalement,
oui, oui, ça me va.
en employant
une marge !!!
Pour ton problème de ul / li pour menu,
perso j'ai ajouté un a dans le li
Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien
Ça permet en outre de régler tes problèmes de marges et paddings
bon, je verrai pour l'instant le onclick est géré par js (addEventListener).
En effet, grossièrement, les ul et li sont margés et paddés à zéro et
c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles
(implicites ?) du css.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la
flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en -
mais les a dans li en +
As-tu regardé sur l'exemple donné en lien comment j'arrive à la même présentation avec beaucoup moins de moyens ? css : 80 lignes --> 62 html : 12 lignes --> 9
oui, je préfère cette solution.
je pense que le menu y est à peu près centré verticalement,
oui, oui, ça me va.
en employant une marge !!!
Pour ton problème de ul / li pour menu, perso j'ai ajouté un a dans le li Ça permet d'avoir le onclick ici et à défaut de JS d'avoir un lien Ça permet en outre de régler tes problèmes de marges et paddings
bon, je verrai pour l'instant le onclick est géré par js (addEventListener).
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
SAM
Le 23/01/15 17:45, Une Bévue a écrit :
Le 23/01/15 15:44, SAM a écrit :
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Ha! Non ! Ha! Non ! Là, c'est comme ça que *je* les ai réglés !!!! Parce qu'au contraire, ce ne sont pas du tout des comportement naturels aux listes à puce de se mettre en ligne et que leurs items ne soient pas indentés (avec retrait) de même ce n'est pas naturel que des A se comportent comme des DIV (blocs) Je voulais juste dire que seuls les liens finaux comportaient des espacement et marges (ainsi, non seulement leur texte est réactif mais aussi toute leur surface) facilitant pas là toute "correction" ultérieure ou même la seule gestion spatiale du schmilblick
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où : - les menus fonctionnaient en html (avec des liens donc) - le JS venait "béquiller" les liens en les neutralisant et amenant à d'autres pages dites "dynamiques" - les IE ne comprenaient pas les speudo-classes dynamiques en dehors des balises A (<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>) - ça permet d'être "accessible" (s'il y a de vrais liens !) - renforce naturellement la lisibilité de la page si css neutralisées
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 23/01/15 17:45, Une Bévue a écrit :
Le 23/01/15 15:44, SAM a écrit :
En effet, grossièrement, les ul et li sont margés et paddés à zéro et
c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles
(implicites ?) du css.
Ha! Non ! Ha! Non !
Là, c'est comme ça que *je* les ai réglés !!!!
Parce qu'au contraire, ce ne sont pas du tout des comportement naturels
aux listes à puce de se mettre en ligne et que leurs items ne soient pas
indentés (avec retrait) de même ce n'est pas naturel que des A se
comportent comme des DIV (blocs)
Je voulais juste dire que seuls les liens finaux comportaient des
espacement et marges (ainsi, non seulement leur texte est réactif mais
aussi toute leur surface) facilitant pas là toute "correction"
ultérieure ou même la seule gestion spatiale du schmilblick
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la
flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en -
mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où :
- les menus fonctionnaient en html (avec des liens donc)
- le JS venait "béquiller" les liens en les neutralisant et amenant à
d'autres pages dites "dynamiques"
- les IE ne comprenaient pas les speudo-classes dynamiques en dehors des
balises A
(<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>)
- ça permet d'être "accessible" (s'il y a de vrais liens !)
- renforce naturellement la lisibilité de la page si css neutralisées
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
En effet, grossièrement, les ul et li sont margés et paddés à zéro et c'est le contenu (actif) qui ménage sa place et espacements
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Ha! Non ! Ha! Non ! Là, c'est comme ça que *je* les ai réglés !!!! Parce qu'au contraire, ce ne sont pas du tout des comportement naturels aux listes à puce de se mettre en ligne et que leurs items ne soient pas indentés (avec retrait) de même ce n'est pas naturel que des A se comportent comme des DIV (blocs) Je voulais juste dire que seuls les liens finaux comportaient des espacement et marges (ainsi, non seulement leur texte est réactif mais aussi toute leur surface) facilitant pas là toute "correction" ultérieure ou même la seule gestion spatiale du schmilblick
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où : - les menus fonctionnaient en html (avec des liens donc) - le JS venait "béquiller" les liens en les neutralisant et amenant à d'autres pages dites "dynamiques" - les IE ne comprenaient pas les speudo-classes dynamiques en dehors des balises A (<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>) - ça permet d'être "accessible" (s'il y a de vrais liens !) - renforce naturellement la lisibilité de la page si css neutralisées
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Une Bévue
Le 23/01/15 22:15, SAM a écrit :
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Ha! Non ! Ha! Non ! Là, c'est comme ça que *je* les ai réglés !!!! Parce qu'au contraire, ce ne sont pas du tout des comportement naturels aux listes à puce de se mettre en ligne et que leurs items ne soient pas indentés (avec retrait) de même ce n'est pas naturel que des A se comportent comme des DIV (blocs) Je voulais juste dire que seuls les liens finaux comportaient des espacement et marges (ainsi, non seulement leur texte est réactif mais aussi toute leur surface) facilitant pas là toute "correction" ultérieure ou même la seule gestion spatiale du schmilblick
bon, ok, mais pour moi soit je met des href="havascript:void(0);" soit je met des span à la place du a.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où : - les menus fonctionnaient en html (avec des liens donc) - le JS venait "béquiller" les liens en les neutralisant et amenant à d'autres pages dites "dynamiques" - les IE ne comprenaient pas les speudo-classes dynamiques en dehors des balises A (<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>) - ça permet d'être "accessible" (s'il y a de vrais liens !) - renforce naturellement la lisibilité de la page si css neutralisées
pour moi ça n'a pas d'intérêt, mon code est mono page.
Le 23/01/15 22:15, SAM a écrit :
bon, je ne savais pas. c'est quand même curieux toutes ces règles
(implicites ?) du css.
Ha! Non ! Ha! Non !
Là, c'est comme ça que *je* les ai réglés !!!!
Parce qu'au contraire, ce ne sont pas du tout des comportement naturels
aux listes à puce de se mettre en ligne et que leurs items ne soient pas
indentés (avec retrait) de même ce n'est pas naturel que des A se
comportent comme des DIV (blocs)
Je voulais juste dire que seuls les liens finaux comportaient des
espacement et marges (ainsi, non seulement leur texte est réactif mais
aussi toute leur surface) facilitant pas là toute "correction"
ultérieure ou même la seule gestion spatiale du schmilblick
bon, ok, mais pour moi soit je met des href="havascript:void(0);" soit
je met des span à la place du a.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la
flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en -
mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où :
- les menus fonctionnaient en html (avec des liens donc)
- le JS venait "béquiller" les liens en les neutralisant et amenant à
d'autres pages dites "dynamiques"
- les IE ne comprenaient pas les speudo-classes dynamiques en dehors des
balises A
(<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>)
- ça permet d'être "accessible" (s'il y a de vrais liens !)
- renforce naturellement la lisibilité de la page si css neutralisées
pour moi ça n'a pas d'intérêt, mon code est mono page.
bon, je ne savais pas. c'est quand même curieux toutes ces règles (implicites ?) du css.
Ha! Non ! Ha! Non ! Là, c'est comme ça que *je* les ai réglés !!!! Parce qu'au contraire, ce ne sont pas du tout des comportement naturels aux listes à puce de se mettre en ligne et que leurs items ne soient pas indentés (avec retrait) de même ce n'est pas naturel que des A se comportent comme des DIV (blocs) Je voulais juste dire que seuls les liens finaux comportaient des espacement et marges (ainsi, non seulement leur texte est réactif mais aussi toute leur surface) facilitant pas là toute "correction" ultérieure ou même la seule gestion spatiale du schmilblick
bon, ok, mais pour moi soit je met des href="havascript:void(0);" soit je met des span à la place du a.
Dans mon exemple j'avoue avoir un peu "triché" puisque j'y emploie la flottaison, ce n'est pas du "tout naturel" !
ouais bon, c'est plsu simple que ce que j'avais fait : deux divs en - mais les a dans li en +
Le coup de se servir des a pour des menus vient de l'ancien temps où : - les menus fonctionnaient en html (avec des liens donc) - le JS venait "béquiller" les liens en les neutralisant et amenant à d'autres pages dites "dynamiques" - les IE ne comprenaient pas les speudo-classes dynamiques en dehors des balises A (<http://www.yoyodesign.org/doc/w3c/css2/selector.html#x36>) - ça permet d'être "accessible" (s'il y a de vrais liens !) - renforce naturellement la lisibilité de la page si css neutralisées
pour moi ça n'a pas d'intérêt, mon code est mono page.
SAM
Le 24/01/15 08:15, Une Bévue a écrit :
pour moi ça n'a pas d'intérêt, mon code est mono page.
Je sais bien que tu fais du tout JS (sinon Ruby) et à ta destination personnelle et certainement pas en fonction d'un quelconque IE
Néanmoins ... de faire, ou essayer de le faire, "comme il faut" je trouve que ça aide.
Et puis ... bien que les foules s'y fassent rares, sur les NGs les posts ne sont pas des échanges personnels même s'ils peuvent traiter de questions particulières
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 24/01/15 08:15, Une Bévue a écrit :
pour moi ça n'a pas d'intérêt, mon code est mono page.
Je sais bien que tu fais du tout JS (sinon Ruby) et à ta destination
personnelle et certainement pas en fonction d'un quelconque IE
Néanmoins ...
de faire, ou essayer de le faire, "comme il faut" je trouve que ça aide.
Et puis ...
bien que les foules s'y fassent rares, sur les NGs les posts ne sont pas
des échanges personnels même s'ils peuvent traiter de questions
particulières
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
pour moi ça n'a pas d'intérêt, mon code est mono page.
Je sais bien que tu fais du tout JS (sinon Ruby) et à ta destination personnelle et certainement pas en fonction d'un quelconque IE
Néanmoins ... de faire, ou essayer de le faire, "comme il faut" je trouve que ça aide.
Et puis ... bien que les foules s'y fassent rares, sur les NGs les posts ne sont pas des échanges personnels même s'ils peuvent traiter de questions particulières
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
SAM
Le 24/01/15 08:15, Une Bévue a écrit :
pour moi ça n'a pas d'intérêt, mon code est mono page.
cette fois-ci
il ne l'a pas toujours été
le sera t-il la prochaine fois ?
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 24/01/15 08:15, Une Bévue a écrit :
pour moi ça n'a pas d'intérêt, mon code est mono page.
cette fois-ci
il ne l'a pas toujours été
le sera t-il la prochaine fois ?
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
