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 <p> 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
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.