28172 sujets

CSS et mise en forme, CSS3

Pages :
(reprise du message précédent)

Certes, vous avez raison, les <br> ("break-row") servent très exactement à insérer un retour à la ligne.
Toutefois il s'agit d'une des rares balises qu'il est impossible de personnaliser (pas d'émargement ni d'espacement entre-autres) or ce peut s'avérer pratique à terme. Donc non, ce n'est pas un soucis, mais un confort Smiley cligne
Perso les br je les réserve principalement pour insérer un passage à la ligne au sein même d'un paragraphe.

Pour les listes, dans votre démo vous aviez une architecture sous forme
ul puis puis div puis ul puis div...
Ma recommandation allait dans le sens de ce que vous présentez dans votre dernier message.
Après, oui bien sûr il est tout à fait correct d'imbriquer les listes. C'est même indispensable pour ce genre d'effet.

Une dernière chose. Faites attention, dans votre précédent snippet vous avez un espace entre la fermeture de h2 et l'image. Ca va vous fausser l'affichage. Si vraiment vous avez besoin d'un émargement à cet endroit, préférer le mettre en Css. Quand vous aurez à y revenir plus tard vous vous remercierez hihi

Bonne continuation.
Greg_Lumiere a écrit :
Une dernière chose. Faites attention, dans votre précédent snippet vous avez un espace entre la fermeture de h2 et l'image. Ca va vous fausser l'affichage. Si vraiment vous avez besoin d'un émargement à cet endroit, préférer le mettre en Css. Quand vous aurez à y revenir plus tard vous vous remercierez hihi

Bonne continuation.


Fausser l'affichage ? Pourtant, en testant avec plusieurs navigateurs, ça me semble plutôt correct. Devrais plutôt utiliser &nbsp; ? L'espace me sert juste à ne pas avoir l'image (d'une flèche) qui soit collé au titre, tout simplement.
De plus, utiliser le CSS pour un petit espace, ça me semble légèrement démesuré ou alors, je nais pas vraiment saisi votre idée.

Sinon, comme promis, je vous donne le lien du site. Il est plutôt simple (peu de pages) et je dois retravaillé encore les textes (je me concentre d'abord sur le code).

DNOI

J'imagine qu'à vos yeux, c'est un site tout ce qu'il y a de plus simple à réaliser et il y a certainement pas mal de points d'améliorations. Mais étant donné que cela fait près d'une quinzaine d'années que je n'avais plus touché au code HTML et CSS, ça n'a pas été simple de me remettre dans le bain et surtout de me mettre à jour. J'ai d'ailleurs beaucoup de lacune et j'ai du apprendre pas mal de choses rapidement.
J'aurais pu passer outre ça en utilisant des services permettant de créer rapidement des sites Internet mais j'ai toujours préféré faire tout moi-même. C'est plus gratifiant.
Modifié par Xhanxhand (21 Dec 2019 - 16:46)
Cet espace entre le titre et l'image fait donc forcément 1em de large. Qu'en sera-t'il quand pour une raison x ou y vous voudrez augmenter ou réduire cette distance ? Passerez-vous par le html pour ajouter autant d'espace que nécessaire ?!
Justement non, je n'y vois pas de démesure. C'est très exactement le rôle de Css, autant lui confier pleinement la tâche dans laquelle il excelle, non ?
Il est entendu bien sûr que je ne couche ici bas que mon avis et que vous fassiez comme bon vous semble me paraît tout à fait légitime.

Au moment où j'écris ces lignes je n'ai pas visité votre site. Je le ferais volontier par la suite et si vous le souhaitez, pourrais partager un feedback ; en toute objectivité bien sûr.

Mes yeux tentent de voir au delà de ce qui leur est présenté. J'ai sans cesse cette idée en tête qui commence par "et si demain... ?" Néanmoins ma conscience s'interdit de juger ; elle regarde le prisme comme s'il s'agissait d'une introspection.
Je comprends votre position. En effet se remettre à coder après avoir prit tant de distance n'est pas chose évidente tant les normes, standards et conventions ont changées. Et heureusement que de tels lieux existent et nous permettent d'échanger et confronter nos points de vue. Ils nous permettent de prendre du recul et d'en retirer une substance précieuse qui, finalement, ne saurait être acquise autrement.

Sachez que je partage amplement votre façon de voir les choses concernant les "préfab". Je suis moi aussi partisan du travail personnel.
C'est pourquoi j n'expose ici qu'un avis qui m'appartient et que je n'entends pas imposer. Juste vous pousser à la réflexion car au final, notre but, n'est-il pas finalement de rendre le web meilleur ?
Même si cet avis est personnel, il reste malgré tout intéressant.

Normalement, je n'aurais pas besoin de plus d'espace mais j'avoue que depuis longtemps, j'ai un mal fou à dompter les margin et padding (je pense que c'est à cela que vous faites références).

J'ai déjà eu des expériences qui donnent des résultats assez différent juste en retirant un px d'un margin ou padding.

Tient, petite question au passage. Vous parlez en em au lieu de px mais je dois dire que je ne sais pas réellement son avantage.

Il y a aussi des choses qui, pour mon point de vue, sont étrange.
Actuellement, j'essaye de trouver une solution pour afficher trois lignes donc chacune comporte une image suivit d'un texte. J'ai cherché à centrer ce bloc sans centré le contenu. J'ai tenté avec <p> et une liste, je n'y suis pas arrivé.

Je me suis résigné à utilisé un tableau de deux colonnes et trois lignes. Mais si je centre de manière classique, le contenu l'est également. J'ai du utiliser un margin auto. Pourquoi ? Je ne parviens pas à comprendre la logique et ce n'est pas faute de tenter.

Et maintenant, je bloque sur un simple alignement vertical. J'ai beau tenté tout un tas de solution, les images ne veulent rien savoir. J'ai continuellement une hauteur de cellule plus grande que mes images. Pourtant, je défini une hauteur égale à mes images.

A croire qu'il y a une hauteur minimale imposée. Mon inexpérience et mon manque de mise à jour m'amène a des prises de têtes aussi bête que ça ^^
Xhanxhand a écrit :

Normalement, je n'aurais pas besoin de plus d'espace mais j'avoue que depuis longtemps, j'ai un mal fou à dompter les margin et padding (je pense que c'est à cela que vous faites références).
Les émargements et espacements ne devraient pourtant pas être source de migraine. Mais peut-être est-ce question de philosophie dans le développement. J'y vois deux écoles.
La première est celle du "strictement tel que". C'est à dire que le développeur veut des espace de x pixels, définis à une précision au pixel près ; il les veut égaux sur toutes les plate-formes et en toute circonstance. Et là, bam, c'est droit dans le mur.
La seconde, celle que je pratique, serait plutôt celle du "c'est correct". Certes, l'affichage n'est pas identique sur toutes les plate-formes mais ça reste correct (par exemple, cet émargement est de 20px au final sur Chrome et 18px sur Firefox mais ça reste bien détaché de l'élément).

Ce qui m'amène au point suivant:
Xhanxhand a écrit :
Tient, petite question au passage. Vous parlez en em au lieu de px mais je dois dire que je ne sais pas réellement son avantage.
Perso les pixels, je les utilisent rarement. Uniquement pour les choses qui en toute circonstance doivent avoir une taille fixe. C'est le cas d'une bordure ou d'une outline. En effet, quelle que soit la taille de l'écran, une bordure de 1px reste à 1px. Aucun intérêt de la rendre responsive. Pour le reste c'est rem/em systématiquement (sauf pour mes gabarit où certains éléments se réfèrent au viewport [vw/vh]).
Par exemple, sur l'élément primaire (html/body) je ne définis jamais la taille de la police ; je laisse ce soin à l'utilisateur. En général son navigateur est à 16px par défaut. Pour rappel, le rem se réfère à cette valeur, soit 1rem (où qu'il soit) égal 16px.
Le em est un pourcentage de la valeur du parent. Donc un enfant direct de body réglé sur 0.5em fera en fait la moitié d'un rem (ici 8px). Ce qui implique que si le parent est lui même réglé sur .5rem, son enfant fera alors 4px (la moitié de la valeur de son parent qui fait déjà la moitié de l'élément le plus haut dans le dom) ; j'espère être clair dans mon explication lol

Travailler en rem/em revient à travailler en terme de proportion et non plus en terme de taille. Donc au lieu de dire "ici 18px et là 10px" on raisonne en terme de "x% plus grand et y% plus petit.
Le résultat devient alors plus fluide et peut importe si le rendu est différent selon le support et les réglages utilisateur, il reste homogène et cohérent.

Si vous le souhaitez, nous pourrons nous étendre plus sur ce sujet avec en appui un exemple concret, ce sera peut-être plus simple à comprendre.

Xhanxhand a écrit :

Il y a aussi des choses qui, pour mon point de vue, sont étrange.
Actuellement, j'essaye de trouver une solution pour afficher trois lignes donc chacune comporte une image suivit d'un texte. J'ai cherché à centrer ce bloc sans centré le contenu. J'ai tenté avec &lt;p&gt; et une liste, je n'y suis pas arrivé.
J'avoue avoir difficulté à cerner précisément votre question/problème. Néanmoins la prime idée qui me vient à l'esprit est de solliciter le layout flexbox qui facilite la vie en terme de centrage. Je n'en dis pas plus pour le moment. Pourquoi n'ouvririons-nous pas un autre topic sur ce point ?!
A la relecture je me dis qu'il suffit peut-être de travailler sur la marge du conteneur mais là encore, sans exemple concret, dur à dire...

Xhanxhand a écrit :

Je me suis résigné à utilisé un tableau de deux colonnes et trois lignes. Mais si je centre de manière classique, le contenu l'est également.
Qu'est-ce qu'une "manière classique pour vous ?

Xhanxhand a écrit :
J'ai du utiliser un margin auto. Pourquoi ? Je ne parviens pas à comprendre la logique et ce n'est pas faute de tenter.
La solution me semble pourtant être là. Margin = auto (left et right) donne une marge identique de chaque côté du conteneur sans influencer le contenu.

Mais en tout cas
Xhanxhand a écrit :

Et maintenant, je bloque sur un simple alignement vertical. J'ai beau tenté tout un tas de solution, les images ne veulent rien savoir. J'ai continuellement une hauteur de cellule plus grande que mes images. Pourtant, je défini une hauteur égale à mes images.
non, non et définitivement non ! Un tableau pour cela n'est clairement pas la solution à adopter. Tableau = données tabulaires, point barre ! C'est d'ailleurs peut-être plus pour cela que flexbox vous apportera le salut, mais sans tableau Smiley cligne

Xhanxhand a écrit :
A croire qu'il y a une hauteur minimale imposée. Mon inexpérience et mon manque de mise à jour m'amène a des prises de têtes aussi bête que ça ^^
Non il n'y a pas de hauteur imposée mais un contexte spécifique: le "table layout". Ce layout à ses propres règles et lois mais comme je l'ai dis précédemment, un tableau n'a pas sa place pour la présentation (même dans les mails maintenant).
On but tous, à un moment où un autre, sur des trucs qui semblent bêtes. C'est normal et c'est ainsi que nous progressons, n'est-il pas ?!

Ce qui me fait penser à une propriété indispensable à prendre en compte avant toute propriété liées au positionnement et au dimensionnement: box-sizing qui détermine comment seront calculées les boites.


Bref, nous sortons largement du sujet principal et en avons évoqués d'autres qui, je pense, méritent d'être traités indépendamment sous peine nous noyer.
En tout cas, merci pour toutes ces informations.

Je comprend mieux l'utilisation de "em", c'est assez proche des pourcentages.

Je ne voulais justement pas trop utiliser de tableau et j'ai fini par réussir ce que je souhaitais en utilisant les float. J'avais tester une première fois sans que cela ne fonctionne. Il suffit d'un rien, un attribut en plus pour que ça change tout (un overflow rajouter dans mon cas).

Mais vous avez raison. Nous avons beaucoup dévié du sujet mais ce fût très instructif. Un grand merci du temps que vous m'avez accordé Smiley biggrin
Pages :