Demande de simplification de code

Bonjour à tous

je débute donc depuis à peu près 2 mois et j'aimerai un conseil sur un code.
j'aimerai savoir comment simplifier mon code, qu'il soit moins long et surtout utiliser au maximum les flex-box.
je vous mets le lien code pen.
Je vous remercie de votre attention et votre aide.

lien ici: http://codepen.io/darkodeur/pen/GNavJj

Pardon j'ai oublié de préciser que je ne suis que sur html5 et css3, je n'ai pas encore commencer JS.

Bonjour,

Qu'est-ce que tu entends par moins 'long'?

Côté HTML, ben il te faut bien du contenu.

Côté CSS, tu peux te renseigner sur les méthodes BEM ou OOCSS et utiliser les classes pour regrouper les propriétés qui sont utilisées par plusieurs éléments.

Tu dis vouloir utiliser au maximum flexbox. Je m'y connais pas trop encore en flexbox mais d'après les tutos que j'ai vu, j'ai l'impression qu'un CSS écrit en flexbox est bien plus court qu'un CSS écrit en block et inline-block.

PapyJP a écrit :

Quelle importance ?

Le CSS n'est pas conçu pour cela, il y a bien des précompilateurs mais ce qu'ils génèrent finalement est aussi verbeux que ce que tu écrirais à la main.

Les fichiers CSS ne sont finalement pas très gros par rapport à la moindre image. Généralement le même fichier CSS est utilisé dans de nombreuses pages et se retrouve en cache dans le navigateur de l'utilisateur, donc n'est chargé qu'une seule fois.
Vouloir réduire leur taille est une perte de temps.

Je recommande de mettre au point le ficher CSS sans s'occuper de la taille, et réduire la taille ensuite si on y tient.
Mon expérience de développeur professionnel, c'est que la maintenabilité du code est toujours beaucoup plus importante que n'importe quoi d'autre, et la maintenabilité passe par la lisibilité, ce qui veut dire des commentaires, de l'indentation de texte, des noms de classes et d'objets qui soient parlant, etc., toutes choses qui conduisent à augmenter la taille des fichiers.

Je suis d'accord avec toi sur le fait que la maintenabilité du source doit primer.
Toutefois, j'ai pu constater que la minification dudit source lorsqu'il passe du statut développement à celui de production dans mon générateur HTML réduit de façon tout à fait significative la taille des fichiers, y compris et cela m'a un peu étonné, pour des feuilles de style à l'origine peu importantes.
Supprimer les espaces et mises en forme n'est pas la seule opération de réduction qu'opère le générateur lors de ce passage puisqu'il convertit aussi les noms de classes CSS en codes de taille réduite, ce qui, le tout mis bout à bout, représente in fine un nombre d'octets économisés plutôt conséquent.
J'en déduis donc que ton approche est tout à fait pertinente lorsqu'on évoque un traitement manuel, mais que dans un environnement basé sur des générateurs ce sont eux qui emportent la mise.

@sepecat
Pour moi, l'intérêt principal de la "minification" n'est pas de réduire la taille des fichiers, mais de compliquer le travail de ceux qui voudraient faire de la rétro-ingénierie sur le code. C'est principalement le cas pour le JavaScript, qui peut représenter du code très complexe, et de plus a très souvent une taille importante quand on veut faire des choses sophistiquées. Je ne vois pas vraiment de cas où cela s'applique à du CSS de façon pertinente.
De toutes façon, dans ce cas, tu ne fais pas la maintenance su code mnifié, mais celui du code complet et tu minifies après chaque modification, ce qui est une étape supplémentaire à faire au moment de la livraison, pas dans la conception ou le développement..

Il est sûr que minifier un fichier en réduit la taille d'un facteur facilement supérieur à 2 ou 3, mais si je prends l'exemple du site sur lequel je travaille, le plus gros fichier CSS fait 22ko, ce qui n'est pas grand chose. Pour le même site, l'icône apple-touch http://www.osirisnet.net/apple-touch-icon-114x114.png fait 24Ko. Je ne pense pas qu'une personne qui débute devrait croire que c'est une chose importante à faire dans la gestion d'un site, si on y tient vraiment, c'est à faire à la fin.
Peut être serait-ce à faire si le fichier CSS devenait énorme, disons 60K, mais avant d'avoir pondu un fichier de cette taille, il faut des mois de travail, et si durant ce travail on se préoccupe de la taille du fichier, on perd son temps et on se complique inutilement le travail, on s'encombre l'esprit de préoccupations inutiles, etc.

Dans ma vie professionnelle, j'ai eu à faire de l'informatique de système sur des machines de très petite taille, et nous nous préoccupions beaucoup de "l’optimisation", mais la leçon que m'a apprise le chef du premier projet sur lequel j'ai travaillé, c'est qu'il faut d'abord faire marcher le programme, ensuite regarder ce qui DOIT être modifié (et non pas ce qui PEUT être modifié) pour améliorer les performances. L'expérience m'a appris
1) que ce qui doit être modifié est rarement ce que l'on croit
2) qu'il est relativement facile de faire ces améliorations a posteriori
Modifié par PapyJP (25 Dec 2016 - 12:54)

Merci encore à tous pour votre aide je prends note!!!!

@pictural

C'est vrai qu'en vacances je lis autre chose, mais c'est vrai aussi que si on veut comprendre ce qu'il y a dans un bout de code informatique (HTML ou autre) il est préférable que l'on reconnaisse directement les nom des objets sans avoir à se référer à une table ou autre bidule.

Dans le projet dont j'ai parlé plus haut, la taille de la mémoire de l'ordinateur devait être d'environ 100k mots de 18 bits, et le nom des variables était limité à 6 caractères (majuscules comme il se doit, ce qui permettait de mettre 3 caractères dans les sacro-saints 18bits).
Je me souviens d'une anglaise qui travaillait avec nous sur les entrées (Input) et sorties (output) du système.
Elle avait appelé toutes ses variables du genre X2801I (I comme Input) et X4801O (O comme Output).
D'une part ça n'avait aucun sens en soi, mais en plus je ne vous dis pas les problèmes entre la lettre O et le chiffre 0, la lettre I et le chiffre 1...
Dans ce genre de situation, il est souvent préférable de tout réécrire que de vouloir essayer de s'y retrouver dans ce m...

Dans l'industrie, les gens qui font la maintenance du code ont souvent en charge plusieurs dizaines, voire plusieurs centaines de milliers de lignes de code écrites par d'autres personnes. Nous avions une sorte de "revue de livraison" du code des développeurs aux mainteneurs, qui conduisait souvent à modifier le code pour le rendre plus aéré, plus lisible, avec des noms de variables évitant les confusions, etc.
Sinon le roman policier devient un roman russe: on ne sait pas de quel personnage il s'agit tant les noms nous semblent étranges et similaires.
Modifié par PapyJP (25 Dec 2016 - 18:22)

j'ai appris beaucoup de choses ce ces échanges merci encore!!!

Ah ! c'est vraiment passionnant.

Je me souviens qu'il y a 4 ou 5 ans, dans un html avec js plutôt ambitieux au regard de mes apprentissages (éternels), une douzaine de map area polygoniques commençaient à m'épuiser. Je n'ai pu retourner la paix à mon âme que par un jeu (simplissime) de commentaires, dont ceux du html <!-- note1 ... --> <!-- note2 ... --> <!-- note3 ... -->. Ainsi par Ctrl+F[ note1 ] de mon Bloc-notes, j'accédais comme une flèche aux écritures belliqueuses pour les mater.

Or, qui parmi les premiers apprentis se discipline aux auto-commentaires ? Ça doit être surement réservé aux meilleurs des pros ...

-"Huuu" !
Modifié par pictural (25 Dec 2016 - 18:56)

Ouais...
Les commentaires sont utilises, mais je m'en méfie car on oublie souvent de les mettre à jour quand on modifie le code, et le résultat est qu'on n'y comprend plus rien deux ans après.
Je me souviens d'un type qui mettait des commentaires idiots, genre:

xyz = xyz + 1 /* ajouter 1 à xyz */

ce qui n'apporte pas grand chose!
Par contre on ne savait pas à quoi correspondait cette variable.
Il aurait été préférable de l'appeler "nbPages" ou quelque chose de ce genre pour le rendre plus parlant.

Oui, bien sûr, les dates de mise à jour sont écrites en clair dans un commentaire en tête des pages... quand j'y pense, mais le plus souvent je le fais au moment de la livraison au propriétaire du site.