Nous pouvons narguer Ballmer pour cette dépression nerveuse à moitié folle, mais son message a frappé la cible. Si vous ne donnez pas aux développeurs les outils et les connaissances dont ils ont besoin pour travailler avec votre système, ils connaîtront non seulement des difficultés, mais ils ne pourront pas non plus développer ce sur quoi vous travaillez!



Hélas, dans la pratique, on voit qu'à cet égard, les développeurs eux-mêmes peuvent être leurs pires ennemis. Ils choisissent de terribles «cadres» qui les obligent à travailler plus dur plutôt que plus intelligemment, ou ils affichent délibérément leur ignorance des principes fondamentaux et copient le code de quelqu'un d'autre dans l'espoir qu'il accomplira la tâche requise.



Dans aucun autre domaine, cela n'est plus évident que dans une attitude arrogante, indifférente, voire carrément méprisante envers le HTML. Il n'y a pas de limite aux non-sens et aux déclarations erronées sans fin de ceux qui sont incapables d'écrire une seule ligne dans cette langue.



En un mot, les développeurs ne prennent pas assez le HTML au sérieux, mais que se passe-t-il si vous leur montrez leur faiblesse? En réponse, nous n'attendrons qu'un flot sans fin d'excuses dénuées de sens pour expliquer pourquoi ils ne devraient pas être distraits par sa mise en œuvre correcte!

Liste des excuses faibles

"HTML n'est pas un vrai langage de programmation"

C'est une séquence de commandes que les ordinateurs suivent pour accomplir une tâche. S'il y a une autre définition d'un langage de programmation, alors en quatre décennies d'écriture de logiciel, je ne l'ai pas entendue. Est-ce que Turing est complet? Non ... mais néanmoins il indique à l'ordinateur comment transmettre la signification grammaticale et structurelle du contenu d'une manière indépendante de la machine. Il existe des règles d'utilisation de ses balises, de son ordre et de sa syntaxe.

"Personne ne se soucie du code s'il semble correct pour l'utilisateur."

Exactement jusqu'au moment où vous rencontrez des utilisateurs aveugles. Le HTML n'est pas seulement à quoi ressemble la page ... Non! Je vais le réparer - HTML ne concerne pas du tout l'apparence de quelque chose. Le HTML est nécessaire pour communiquer ce que devraient être les éléments en termes de grammaire et de structure afin que l'agent utilisateur puisse transmettre cette valeur à l'utilisateur. Nous avons donc du CSS pour décrire à quoi devraient ressembler les éléments. Si l'une de vos balises, identifiants ou classes communique à quoi devraient ressembler les éléments, c'est que vous avez choisi le mauvais code en vous basant sur de fausses hypothèses.



Lecteurs d'écran (logiciel de lecture d'une page à voix haute), livres électroniques en braille, ATS… ce sont toutes des cibles non visuelles; et n'oubliez pas que les moteurs de recherche n'ont pas non plus d'yeux. Ils ne se soucient même pas de l'apparence de votre page.



En outre, il est important pour les internautes que votre page soit plus lente ou plus chère à héberger, qu'elle enfreigne les consignes d'accessibilité pour les personnes handicapées ou qu'elle obstrue l'ensemble de la chaîne disponible. Balisage non sémantique , DIV sans fin et sans signification qui ne font rien, classes de présentation - ils s'additionnent tous et affectent le résultat!



Vous entendrez les mêmes excuses pour de nombreux autres aspects du développement Web, et c'est presque toujours un mensonge. Que ce soit une sémantique mauvaise / cassée, des problèmes d'accessibilité pour les personnes handicapées, un JS optionnel gonflé, l'utilisation de technologies "d'application Web" pour des choses qui ne devraient pas être une application, etc., etc.



Très souvent, en utilisant tout cela, l'utilisateur se rend compte que quelque chose ne va pas, mais ne peut pas l'expliquer. Les utilisateurs ne sont pas des programmeurs, ils ne savent pas quelle est l'erreur et qui en est responsable, mais ils sentent que quelque chose ne va pas, tout est aléatoire.



Qu'en est-il du prochain perdant malheureux qui doit soutenir le résultat de votre travail, qui contient toutes les erreurs de la liste, comment NE PAS utiliser le HTML? Les gens discutent toujours de la façon dont leur terrible «cadre» brisé est censé «nous aider à travailler ensemble». Comment deux ou dix fois la quantité de code non conforme aux règles de base du HTML et violant le but même du langage, peuvent-ils «améliorer la collaboration»?

"Mais les exemples dans les frameworks fonctionnent exactement comme ça, et ils ont été écrits par des experts"

Ce ne sont pas des spécialistes du développement Web. Ce sont plutôt des spécialistes du marketing, de la propagande et de la tromperie. Le balisage dans des exemples de systèmes tels que Bootstrap et Tailwind sont des pratiques HTML cauchemardesques. Ils puent un horrible mélange de «je ne veux pas apprendre le HTML et le CSS» et «le balisage des années 90 me manque», abandonnant plus de vingt ans de progrès. Ce n'est pas parce qu'ils sont utilisés par des millions de sites («la majorité ne peut pas se tromper») et que des experts autoproclamés leur chanter des louanges (appel à l'autorité), ne les rend pas bonnes ou des pratiques similaires.

"Le code Vanilla est plus difficile à utiliser."

Vous rendez les choses difficiles. Voici le problème: en ignorant les règles sémantiques de structuration et tout l'intérêt du HTML, vous rendez le travail plus difficile. Contribuer à cela est le fait que les appâts noob comme W3Schools (alias W3fools) regorgent d'informations inexactes, de simplifications vulgaires et de l'absence totale de la plupart des concepts de base du HTML.



Le contenu doit définir le balisage, le contenu + le balisage + l'environnement cible / les capacités de l'agent utilisateur doivent définir la structure. En suivant la sémantique de base, et en améliorant progressivement et en utilisant la séparation correcte des fonctionnalités, vous vous retrouverez avec un ensemble d'instructions qui facilitent la création de pages faciles à entretenir. Si vous rencontrez des problèmes avec cela et pensez que ces "frameworks HTML / CSS" vous facilitent la vie, alors vous ne connaissez pas assez HTML ou CSS pour effectuer l'une des tâches.



En général, Tailwind est plus simple que le HTML / CSS vanille, il vous suffit d'apprendre plus de 500 classes, dont 90% existent déjà en tant que propriétés CSS, puis d'ignorer presque toutes les règles d'utilisation du HTML!



Au cas où vous ne l'auriez pas compris, c'était du sarcasme.

"Vous attachez trop d'importance au HTML"

J'entends ce non-sens tout le temps, et je suis ennuyé par sa myopie!



C'est comme dire que je fais trop attention au sol sous le chantier ou aux matériaux utilisés pour créer les fondations. Si vous négligez de tels détails, alors ne soyez pas surpris que tout s'effondre de manière "incompréhensible" ou soit aspiré dans un gouffre karstique!



Le HTML est le fondement et la pierre angulaire. Si vous le négligez, ne soyez pas surpris que les résultats soient un désastre complet.



En effet, bon nombre des idées fausses que les développeurs Web utilisent pour se convaincre de ne pas s'inquiéter pour l'avenir ne sont pas différentes de celles qui mènent à tous les désastres techniques. Économiser sur la qualité, ignorer les spécifications ou l'utilisateur final, alimenter votre propre ego; en outre, beaucoup font une erreur fatale: ils confondent l'art et le design.



Cette dernière erreur conduit à des bâtiments qui éblouissent les gens avec la lumière du soleil réfléchie par leurs fenêtres: quelqu'un qui s'imagine un artiste convainc les gens en costumes de dépenser des milliards pour un projet dans lequel la forme est plus importante que la fonction.

"Mais HTML ne nous donne pas les outils dont nous avons besoin pour fournir l'UX."

Il existe de nombreuses versions différentes de cette excuse, mais en général elles impliquent ce qui précède. Ceux qui disent cela se réfèrent presque toujours aux fans des "applications Web" ou des "applications à une seule page", ils essaient d'utiliser JavaScript partout, ils ne se soucient pas de l'accessibilité pour les personnes handicapées et insistent sur le fait que les "utilisateurs" "ont besoin" de tout leurs trucs fantaisistes pour améliorer "l'expérience utilisateur".



Mais pour être parfaitement honnête, ces clowns en savent autant sur l'UX que les artistes qui sont tombés dans l'illusion d'être des "web designers" en savent sur le design.



Et vous pouvez voir les résultats de leur travail MAINTENANT dans l'ensemble de notre secteur: des solutions fragiles, gonflées et lentes qui "peuvent améliorer les scripts" ralentissent tellement les systèmes de panier d'achat des magasins en ligne que beaucoup d'entre eux ne sont même pas capables de maintenir la disponibilité (bonjour Zotac) ; dans le même temps, les utilisateurs appuient férocement sur F5, espérant pouvoir toujours acheter une carte vidéo. Du fait du rechargement de la page entière et de la relance du script, toutes les fonctions de "l'application" ne conduisent qu'à une RÉDUCTION de la vitesse de chargement de la page. Et c'est encore plus prononcé si vous crachez sur le balisage en utilisant les classes de présentation.



Et comme les scripts peuvent être désactivés et que le contenu généré par script est plus difficile pour les lecteurs d'écran, les livres électroniques en braille, etc., les applications à page unique (SPA) enfreignent les directives d'accessibilité pour les personnes handicapées.



Je ne dis pas que le SPA et autres n’ont aucune utilité sensée, mais si vous ne pouvez pas créer un simple panier d’achat ou un portail bancaire à chargement rapide qui perd peu de choses en désactivant les scripts, vous ne devriez probablement pas faire de travail. c'est une entreprise. Les applications Web ne doivent PAS être utilisées pour quelque chose de ridiculement simple comme un panier sur un site Web!



Et si vous pensez que l'utilisation de scripts pour ce faire améliore vraiment l'expérience utilisateur, alors vous n'avez évidemment pas testé le système avec de vrais utilisateurs et du trafic réel! À tout le moins, ils n'ont pas effectué de comparaison réelle de la répartition des tâches en utilisant le cache dans les chargements de page normaux et sur les pages avec des scripts newfangled.

Le développeur Web est-il donc à blâmer pour tout?

Pas question . Revenons au début de l'article et aux cris de Ballmer «développeurs, développeurs, développeurs».



Quand il a joué son petit croquis, il a été conçu pour résoudre le problème qui, à la fin des années 90, n'était nullement à la base de Windows, car les développeurs n'utilisaient souvent pas les outils fournis par Microsoft. Borland a publié la meilleure documentation pour l'API Windows. Les gens utilisaient des outils non-Microsoft parce que les langages «visuels» étaient considérés comme des jouets. Ils étaient tellement en retard sur les technologies de développement Web, on peut dire qu'ils essaient toujours de les rattraper!



Le W3C et WhatWG ont des problèmes similaires avec le soi-disantLes «spécifications» ne sont tout simplement pas écrites pour les personnes qui écrivent des sites Web. Permettez-moi de répéter: la spécification de la langue utilisée pour écrire des sites Web n'est pas pour les personnes qui écrivent réellement des sites Web . Il est écrit pour les personnes qui écrivent des user-agents! Le navigateur est l'agent utilisateur, mais l'UA n'est pas toujours le navigateur.



En fait, c'est tellement absurde que la version idiote du «document dynamique» de WhatWG se réfère à MDN pour que les «simples mortels» le comprennent.



: , « » (living document), HTML- . HTML 5, , HTML 5, HTML 5 ? !



Fait simple: pour obtenir des descriptions de la signification des balises en anglais simple, vous devez vous tourner vers des sources tierces, dont beaucoup ne sont même pas d'accord les unes avec les autres. De plus, le W3C est devenu complètement édenté, acceptant aveuglément tout ce que dit WhatWG, même si WhatWG a prouvé à maintes reprises qu'il n'est pas qualifié pour créer un descendant de HTML 4 Strict. L'acceptation d'EMBED comme balise valide, la création et / ou le maintien de balises redondantes par rapport à OBJECT, ne supportaient plus (heureusement) la balise HGROUP, qui montrait qu'ils ne comprenaient même pas à quoi servaient les en-têtes numérotés et comment les utiliser. .. qui a travaillé dessus, le défi pour HTML 5 n'a jamais vraiment été de créer une spécification ou une norme qui nous indique comment créer des sites Web utiles!Il s'agissait de documenter si les gens font bien ou mal aujourd'hui et que les navigateurs peuvent soutenir, mais pas ce qu'ils devraient soutenir! Étant donné que pendant le développement de HTML 5, la plupart des développeurs martelaient encore HTML 3.2 et griffonnaient le doctype HTML 4 perverti dessus, pourquoi être surpris que tout se soit avéré être une telle collection de pratiques mauvaises, dépassées et démodées?



Si les développeurs ne prennent pas assez le HTML au sérieux, alors ceux qui l'ont développé comme "spécification" sont à blâmer; même l'appeler HTML 5 était un crime si grave contre le développement Web ... Tout comme un crime contre la musique offrait un Grammy à Billie Eilish pour ses créations médiocres.



Le W3C et WhatWG ne sont même pas pris au sérieux par les autres organismes de normalisation, et pour une bonne raison.

Quelle devrait être la solution?

Ce serait une bonne idée de commencer par amener les développeurs à ne pas percevoir le HTML comme un enfant sous-développé du monde des langages de programmation. En particulier, les amener à pratiquer le balisage sémantique, en séparant la présentation du contenu, ce qui augmentera considérablement la convivialité, l'accessibilité et l'efficacité.



De plus, nous-mêmes, en tant que développeurs, avons notre mot à dire et déconsidérons le W3C pour l' échec désastreux de son travail en tant qu'organisme de certification . Nous devons exiger une documentation linguistique plus simple et plus claire de la source officielle. Il ne peut être justifié qu'un document décrivant quelque chose d'aussi simple que HTML soit cinq à dix fois plus long que les constitutions de la plupart des pays développés.Le fait même que la spécification de la langue utilisée pour créer des sites Web ne soit pas écrite pour les personnes qui utilisent la langue pour créer des sites Web est un vote de défiance.



Mais nous avons besoin de plus qu'une documentation officielle améliorée, nous devons réduire la langue, la rendre plus axée sur les tâches. Relancez de nombreuses idées contenues dans HTML 5 avant que le W3C ne les jette à la poubelle et n'adopte la version WhatWG. Le fait que Microsoft ait passé des décennies à empêcher IE d'utiliser OBJECT n'est pas une raison non seulement pour conserver la balise IMG, mais pour ajouter inutilement de nombreuses nouvelles balises (VIDEO, AUDIO). Le simple fait que les "artistes" et les escrocs du marketing aiment ouvrir de nouvelles fenêtres pour l'utilisateur, qu'il le veuille ou non, n'est pas encore une raison pour laquelle la spécification doit inclure TARGET="_BLANK"



...



De plus, l' utilisation et la signification EXPLICITES des balises devraient être placées au centre de la spécification , et peut-être même dans un guide d'utilisation distinct pour ceux qui vivent encore en 1997.



Créer une version HTML plus simple, plus propre et plus utile qui nous guidera tous n'est pas un problème.



De plus, cela nous sera utile si les développeurs de navigateurs ont moins de poids lors de leur création. Microsoft, Mozilla, Apple et Google ont un impact énorme sur le W3C et WhatWG, ce qui est totalement contraire à l'éthique. Leur poids dans la prise de décision va à l'encontre du concept même d'un web libre et ouvert.

---

Publicité

Les serveurs Epic sont des VDS pour l'hébergement de sites d'une petite boutique en ligne sur Opencart à des projets sérieux avec un public énorme. Créez vos propres configurations de serveur en quelques clics!



Rejoignez notre chat Telegram .