Des div dans des div dans des div (...etc)

Bonjour !

J'ai failli intituler le sujet : "Les poupées russes du HTML".

Depuis... un certain temps, je m'efforce d'apprendre au mieux le HTML, le CSS, voire un peu de Javascript. J'essaye d'écrire un code qui soit léger, efficace, annoté pour qu'il soit facile à lire, facile à maintenir, rapide à télécharger. Au départ, c'est sans doute plus long que d'utiliser un template, un framework... ou tout un tas de solutions prêt à l'emploi mais à la fin, le code est réduit à sa portion congrue... et encore lisible par un être humain.

Bref, je me donne du mal (enfin pas trop quand même ...).

Mais je commence à me demander si tout ça en vaut la peine. Quand je regarde le code d'à peu près tout le monde, c'est quasiment incompréhensible. Des containers en pagaille, des classes multiples, du code redondant ou inutile... Rare est le code minimaliste. Il y a probablement des raisons à ça compte tenu de tous les inconvénients.

Tout ça me rend perplexe. Aussi j'aimerais bien savoir : comment voyez-vous l'évolution des pratiques de codage ? Des mises en 'écran' vite faites et on ne regarde pas le code si il y a un problème, un changement ? On reprend tout depuis le début ? (Comme on ne répare plus un appareil électrique, on le jette et on rachète un autre...)

Bonjour,
Tu mets le doigt sur un problème qui n'est pas propre au web mais touche plus généralement tous les langages pour lesquels des ateliers logiciels sont disponibles et mis en oeuvre.
En Java, par exemple, tu as des outils (ex. Jira) qui sont monstrueux lorsque tu t'avises de tout télécharger sous Eclipse.
La multiplicité des fichiers de configuration et leur plus ou moins bonne intégration entre eux pose parfois problème.
À min avis, ta démarche visant à produire du code le plus "propre" et simple possible reste la meilleure approche, ne serait-ce que parce qu'elle permet, justement, de mieux analyser / résoudre les problèmes liés aux conflits et non conformité des "frameworks" (il y en a toujours, quelle que soit leur qualité intrinsèque). Pour réparer un moteur, mieux vaut connaître la mécanique, même si aujourd'hui on te répond qu'il suffit juste de le remplacer par un autre.
Celui qui saut réparer repartira, celui qui ne sait pas attendra patiemment son nouveau moteur ou version du Framework (ce qui suppose une communauté réactive par ailleurs).
Bref, pour ma part j'investis dans la connaissance de fond sur HTML, CSS, Javascript et autres, sachant par expérience que cela évite bien des emm**** après et permet de mieux utiliser les surcouches disponibles.

Merci pour ta réponse.

C'est sûr qu'a priori savoir, c'est mieux que de ne pas savoir. Seulement dans une logique de production, le temps, c'est de l'argent. Le code produit par les logiciels ne ressemble pas à celui que produisent les êtres humains, je ne me vois pas le reprendre et je préfère faire tout moi-même (je fais quand même du copier-coller à partir de projets précédents). Je vais plus lentement qu'une machine et dans un contexte professionnel ce temps est quand même difficile à justifier quand des solutions clé en main existent.

J'ai l'impression de me positionner sur une niche.

Modifié par Zelena (31 Mar 2016 - 13:30)

Zelena a écrit :
Merci pour ta réponse.

C'est sûr qu'a priori savoir, c'est mieux que de ne pas savoir. Seulement dans une logique de production, le temps, c'est de l'argent. Le code produit par les logiciels ne ressemble pas à celui que produisent les êtres humains, je ne me vois pas le reprendre et je préfère faire tout moi-même (je fais quand même du copier-coller à partir de projets précédents). Je vais plus lentement qu'une machine et dans un contexte professionnel ce temps est quand même difficile à justifier quand des solutions clé en main existent.

J'ai l'impression de me positionner sur une niche.

Tu as répondu toi-même à la question.
Frameworks égale vite.
À la mano égale optimisé mais plus long.
Il n'y a pas vraiment de choix intermédiaire, à moins de disposer d'outils qui produisent des sites web mais en optimisant le code... Suivez mon regard

J'ai suivi votre regard et suis tombée sur votre signature.

Je suppose que 'outils qui produisent des sites web mais en optimisant le code', c'est l'objectif que vous visez avec votre projet Thot.

Un projet ambitieux...

Hello,
Projet ambitieux, certes, mais que je suppose faisable, sinon je ne me risquerais pas à perdre du temps dans ce qui peut se révéler une galère .
Ceci dit, c'est justement parce que j'ai fait le même constat que vous que j'ai initié ledit projet et commencé à y réfléchir.
Mon côté un brin perfectionnniste ne se satisfait pas vraiment du source HTML / CSS que je vois passer sur certaines pages.
Par ailleurs la notion de vitesse qui est imposée aujourd'hui est une chose dont j'ai parfaitement conscience, mon boulot actuel échappant pas à ce diktat des temps moderne.
En réunissant les deux, la conclusion s'impose pratiquement d'elle-même : On a besoin d'outils intégrés fiabilisant la production et suffisamment versatiles pour s'adapter.
J'y travaille... Et on verra bien jusqu'où je pourrai aller sans entrer dans un mur (mais j'ai un bon casque).
Si vous êtes intéressée par ces problématiques, vous pouvez suivre ce projet et y apporter tous les commentaires utiles. Ils seront les bienvenus.

sepecat a écrit :

Si vous êtes intéressée par ces problématiques, vous pouvez suivre ce projet et y apporter tous les commentaires utiles. Ils seront les bienvenus.

Je crains de ne pas être suffisamment calée pour réellement suivre... mais par contre si je peux passer commande : j'aimerais un produit suffisamment paramétrable pour s'adapter à ma façon de travailler et suffisamment souple pour s'adapter à toutes les situations (ça, c'est déjà votre objectif). Il n'a pas besoin de tout faire, il peut me laisser du travail (faut quand même justifier sa rémunération...)

Zelena a écrit :
j'aimerais un produit...

C'est justement ces petits "j'aimerais" qui sont importants à identifier et développer.
Je viens de mettre en ligne un billet traitant d'une petite fonctionnalité a priori insignifiante, mais qui facilitera la vie pour générer un site web crédible et conforme aux règles de la typographie.
Que ceux qui n'ont jamais loupé une espace insécable après un guillemet français me jettent la première pierre...

sepecat a écrit :

Pour satisfaire aux règles en vigueur en la matière, le générateur Thot offre la pos­sibilité d'utiliser un composant « citation », localisable (indication d'une langue), per­mettant d'obtenir lors de la sérialisation du site web :

un texte encadré par des guillemets adaptés à la langue de ce texte
l'insertion automatique des espaces insécables, lorsque cette mise en forme est requise

Il me semble qu'il s'agit du genre de perfectionnement courant dans les logiciels de mise en page voire dans les traitements de texte...

Pour ma part, l'image que j'ai en tête est celle du pilotage d'avion. Il y a les commandes manuelles et le pilotage automatique. Passer de l'un à l'autre est de la seule responsabilité du pilote et à tout moment, il peut reprendre aisément les commandes. Les instruments sont seulement là pour l'aider.

Il me semble que la question derrière ton post initial est celle de la différence qui existe entre un projet idéal (bien codé, bien optimisé, accessible, rétro-compatible jusqu'à l'Antiquité, etc.) et la vraie vie.

Dans la vraie vie d'un projet web standard, tout est rapidement rapporté à des questions de budget et de planning (qui n'est rien d'autre qu'une autre forme de budget) et la vraie marge de manœuvre ne va pas consister à décider si on produit ou pas un code parfait mais de déterminer quel est le niveau d'imperfection acceptable.

Partant de là, notre code est toujours le code spaghetti d'un autre...

Zelena a écrit :


Il me semble qu'il s'agit du genre de perfectionnement courant dans les logiciels de mise en page voire dans les traitements de texte...

Pour ma part, l'image que j'ai en tête est celle du pilotage d'avion. Il y a les commandes manuelles et le pilotage automatique. Passer de l'un à l'autre est de la seule responsabilité du pilote et à tout moment, il peut reprendre aisément les commandes. Les instruments sont seulement là pour l'aider.

La fonctionnalité en question est effectivement plutôt courante, bien que certains logiciels ne le fournissent pas.
En fait, il y a une petite subtilité que je n'ai pas mentionnée
Le générateur détecte automatiquement si la langue de la citation est identique ou non à celle de la page HTML.
Si différence il y a, le bloc de texte est de facto encadré d'une balise Span comportant l'attribut @lang qui correspond, histoire d'être conforme aux normes en matière d'internationalisation.
Tout ceci décharge le concepteur d'avoir à s'en préoccuper (tâche ingrate et laborieuse).
Je connais bien le monde de l'aérien et perso je préfère tout de même un pilote automatique me garantissant le respect des procédures d'atterrissage en VSV. Certains l'ont déconnecté et le résultat final fut plutôt explosif

Bonjour !

STPo a écrit :
Il me semble que la question derrière ton post initial est celle de la différence qui existe entre un projet idéal (bien codé, bien optimisé, accessible, rétro-compatible jusqu'à l'Antiquité, etc.) et la vraie vie.

C'est vrai que ma question initiale est un peu philosophique voire académique.

Cependant, elle traitait moins de la situation présente - où on fait au mieux avec ce qu'on a, compte tenu des contraintes - que de l'évolution des pratiques.

Ceux qui ont quelques années au compteur ont pu voir la façon dont on code évoluer. La variable d'ajustement est, en ce moment, le temps... surtout. C'est pour cela que l'on s'accommode du code spaghetti... qui entraine ses propres problèmes.

J'ai quelques raisons de penser que le prix de l'énergie va augmenter. Il est possible qu'il va falloir davantage optimiser que ce qu'on fait maintenant (un code propre a aussi ses avantages). Et c'est sur ça que j'aurais aimé avoir des points de vue.


Modifié par Zelena (01 Apr 2016 - 14:12)

Falloir optimiser d'avantage le code mais à quel prix ? Sans contrepartie tu ne produis rien donc la question ne se pose même pas. La perfection, ça se pose sur des sites d'envergure ce qui n'est pas le cas de la grande majorité des sites produits et généralement tu ne vas pas aller chercher des optimisations sur 2/3 divs de plus ou de moins qui sont quantité négligeable.

Je cherche personnellement bien plus à être consistant dans tout ce que je code que d'avoir un code minimal et donc non factorisé. Ce que font, je pense, la majorité des professionnels en utilisant des outils, cms, frameworks, bibliothèques, etc...

Je voyais certainement les choses un peu à ta manière lorsque j'ai commencé à travailler il y a 6 ans mais comme l'a dit STPo, ça ne correspond pas à la vrai vie.

bzh a écrit :
(...) et généralement tu ne vas pas aller chercher des optimisations sur 2/3 divs de plus ou de moins qui sont quantité négligeable. (...)

Bonjour !

2/3 divs en plus... Si ce n'est que ça, je ne vais pas râler...

Peut-être que je n'ai pas eu de chance, parce que tous les sites j'ai regardés, ça allait bien plus loin que ça.

Mais même si il y en a 50 de plus ce n'est pas dramatique. Relativement au rendu total d'une page c'est absolument négligeable et tant que les templates sont bien organisés/indentés et que le code suit la syntaxe peu importe.

Il faut aussi penser que l'inté c'est long et même très long aujourd'hui avec les différents média et que tu ne peux pas passer trop de temps à faire un code "parfait". Un inté c'est 300 à 600€ / jour et il n'est pas rare de passer une dizaine de jours sur un projet donc ça peut vite donner un chiffre important. A moins d'avoir une enveloppe très large, sur le temps imparti tu vas plutôt chercher à maximiser ce que tu produis pour que ton client en ait pour son argent et sortir ton projet dans les temps.

Les outils évoluent, mais toutes les questions que tu soulèves se posaient déjà quand des OOCSS ou Blueprint ont vu le jour, ce qui ne date pas exactement d'hier. Et si l'on pousse un peu plus loin la DeLorean on se rappellera du doux temps des layouts intégralement en tables, pas non plus des exemples de lisibilité et de performance.

Courir après les deadlines et les plannings n'a rien de symptomatique de notre époque, en plus de dix ans de web j'ai toujours subi cette contrainte comme principale variable d'ajustement... Le temps c'est de l'argent, et l'argent est le nerf de la guerre.

STPo a écrit :
Et si l'on pousse un peu plus loin la DeLorean on se rappellera du doux temps des layouts intégralement en tables, pas non plus des exemples de lisibilité et de performance.

Si je ne m'abuse, pour faire des mises en page sophistiquées, ces tables étaient indispensables.

Le temps, c'est de l'argent ? Admettons. Dès lors, pouvoir comparer - entre le produit d'un framework et une mise en page minimaliste - est un luxe...

Cela dit c'est toujours celui qui est en situation de production qui a le dernier mot et donc je ne tiens pas à l'avoir.