HTML

À quoi sert un DOCTYPE ?

DOCTYPE est une abréviation de Document Type. Un DOCTYPE est toujours associé à une DTD - pour Document Type Definition.

Une DTD définit comment les documents d'un certain type doivent être structurés (par exemple, un button peut contenir un span mais pas un div), tandis qu'un DOCTYPE déclare quelle DTD un document est censé respecter (par exemple, ce document respecte la DTD HTML).

Pour les pages web, la déclaration DOCTYPE est obligatoire. Elle est utilisée pour indiquer aux agents utilisateurs quelle version des spécifications HTML votre document respecte. Une fois qu'un agent utilisateur a reconnu un DOCTYPE correct, il déclenchera le mode sans quirks correspondant à ce DOCTYPE pour la lecture du document. Si un agent utilisateur ne reconnaît pas un DOCTYPE correct, il déclenchera le mode quirks.

La déclaration DOCTYPE pour les standards HTML5 est <!DOCTYPE html>.

Comment servez-vous une page avec du contenu en plusieurs langues ?

Je vais supposer que la question porte sur le cas le plus courant, à savoir comment servir une page avec du contenu disponible en plusieurs langues, mais le contenu de la page doit être affiché dans une seule langue cohérente.

Lorsqu'une requête HTTP est faite à un serveur, l'agent utilisateur qui effectue la requête envoie généralement des informations sur les préférences linguistiques, comme dans l'en-tête Accept-Language. Le serveur peut alors utiliser ces informations pour renvoyer une version du document dans la langue appropriée si une telle alternative est disponible. Le document HTML renvoyé doit également déclarer l'attribut lang dans la balise <html>, comme <html lang="en">...</html>.

Bien sûr, cela est inutile pour informer un moteur de recherche que le même contenu est disponible dans différentes langues, et vous devez donc également utiliser l'attribut hreflang dans le <head>. Par exemple : <link rel="alternate" hreflang="de" href="http://de.example.com/page.html" />

En back-end, le balisage HTML contiendra des placeholders i18n et du contenu pour la langue spécifique stocké aux formats YML ou JSON. Le serveur générera alors dynamiquement la page HTML avec le contenu dans cette langue particulière, généralement à l'aide d'un framework back-end.

De quel genre de choses devez-vous vous méfier lorsque vous concevez ou développez des sites multilingues ?

  • Utilisez l'attribut lang dans votre HTML.
  • Diriger les utilisateurs vers leur langue maternelle - Permettre à un utilisateur de changer facilement son pays/sa langue sans tracas.
  • Le texte dans les images basées sur des pixels (par exemple, png, gif, jpg, etc.) n'est pas une approche évolutive - Placer du texte dans une image est toujours un moyen populaire d'afficher de belles polices non-système sur n'importe quel ordinateur. Cependant, pour traduire le texte d'une image, chaque chaîne de texte devra avoir une image distincte créée pour chaque langue. Plus qu'une poignée de remplacements comme celui-ci peut rapidement devenir incontrôlable.
  • Longueur de mots/phrases restrictive - Certains contenus peuvent être plus longs lorsqu'ils sont écrits dans une autre langue. Soyez attentif aux problèmes de mise en page ou de débordement dans la conception. Il est préférable d'éviter de concevoir où la quantité de texte ferait ou déferait un design. Le nombre de caractères entre en jeu avec des éléments tels que les titres, les étiquettes et les boutons. Ils sont moins problématiques avec le texte libre comme le corps du texte ou les commentaires.
  • Soyez attentif à la perception des couleurs - Les couleurs sont perçues différemment selon les langues et les cultures. Le design doit utiliser la couleur de manière appropriée.
  • Formatage des dates et des devises - Les dates de calendrier sont parfois présentées de différentes manières. Par exemple, « 31 mai 2012 » aux États-Unis contre « 31 May 2012 » dans certaines parties de l'Europe.
  • Ne concaténez pas les chaînes traduites - Ne faites rien comme "La date d'aujourd'hui est " + date. Cela ne fonctionnera pas dans les langues avec un ordre de mots différent. Utilisez plutôt une chaîne de modèle avec une substitution de paramètres pour chaque langue. Par exemple, regardez les deux phrases suivantes en anglais et en chinois respectivement : I will travel on {% date %} et {% date %} 我会出发. Notez que la position de la variable est différente en raison des règles grammaticales de la langue.
  • Sens de lecture de la langue - En anglais, nous lisons de gauche à droite, de haut en bas ; en japonais traditionnel, le texte se lit de haut en bas, de droite à gauche.
  • Utile à avoir - inclure la locale dans le chemin (par exemple en_US, zh_CN, etc).

À quoi servent les attributs `data-` ?

Avant que les frameworks JavaScript ne deviennent populaires, les développeurs front-end utilisaient les attributs data- pour stocker des données supplémentaires directement dans le DOM, sans autres astuces telles que des attributs non standard ou des propriétés supplémentaires sur le DOM. Ils sont destinés à stocker des données personnalisées privées à la page ou à l'application, pour lesquelles il n'existe pas d'attributs ou d'éléments plus appropriés.

De nos jours, l'utilisation des attributs data- n'est généralement pas encouragée. L'une des raisons est que les utilisateurs peuvent facilement modifier l'attribut de données en utilisant l'inspecteur d'éléments dans le navigateur. Le modèle de données est mieux stocké dans JavaScript lui-même et mis à jour avec le DOM via la liaison de données, éventuellement à l'aide d'une bibliothèque ou d'un framework.

Cependant, une utilisation parfaitement valide des attributs de données est d'ajouter un hook pour les frameworks de test de bout en bout tels que Selenium et Capybara, sans avoir à créer des classes ou des attributs d'ID dénués de sens. L'élément a besoin d'un moyen d'être trouvé par une spécification Selenium particulière, et quelque chose comme data-selector='the-thing' est un moyen valide de le faire sans compliquer le balisage sémantique autrement.

Considérez HTML5 comme une plateforme web ouverte. Quels sont les éléments constitutifs de HTML5 ?

  • Sémantique - Vous permettant de décrire plus précisément le contenu de votre site.
  • Connectivité - Vous permettant de communiquer avec le serveur de manière nouvelle et innovante.
  • Hors ligne et stockage - Permettant aux pages web de stocker des données côté client localement et de fonctionner hors ligne plus efficacement.
  • Multimédia - Faisant de la vidéo et de l'audio des citoyens de première classe sur le Web ouvert.
  • Graphiques et effets 2D/3D - Permettant une gamme beaucoup plus diversifiée d'options de présentation.
  • Performance et intégration - Offrant une plus grande optimisation de la vitesse et une meilleure utilisation du matériel informatique.
  • Accès aux appareils - Permettant l'utilisation de divers périphériques d'entrée et de sortie.
  • Stylisation - Permettant aux auteurs d'écrire des thèmes plus sophistiqués.

Décrivez la différence entre un `cookie`, `sessionStorage` et `localStorage`.

Toutes les technologies mentionnées ci-dessus sont des mécanismes de stockage clé-valeur côté client. Elles ne peuvent stocker les valeurs que sous forme de chaînes de caractères.

| | cookie | localStorage | sessionStorage | | --- | --- | --- | --- | | Initiateur | Client ou serveur. Le serveur peut utiliser l'en-tête Set-Cookie | Client | Client | | Expiration | Défini manuellement | Pour toujours | À la fermeture de l'onglet | | Persistant entre les sessions de navigation | Dépend de si une expiration est définie | Oui | Non | | Envoyé au serveur à chaque requête HTTP | Les cookies sont automatiquement envoyés via l'en-tête Cookie | Non | Non | | Capacité (par domaine) | 4 Ko | 5 Mo | 5 Mo | | Accessibilité | N'importe quelle fenêtre | N'importe quelle fenêtre | Même onglet |

Note : Si l'utilisateur décide d'effacer les données de navigation via n'importe quel mécanisme fourni par le navigateur, cela effacera tous les cookie, localStorage ou sessionStorage stockés. Il est important de garder cela à l'esprit lors de la conception de la persistance locale, surtout en comparaison avec des alternatives telles que le stockage côté serveur dans une base de données ou similaire (qui bien sûr persistera malgré les actions de l'utilisateur).

Décrivez la différence entre `<script>`, `<script async>` et `<script defer>`.

  • <script> - L'analyse HTML est bloquée, le script est récupéré et exécuté immédiatement, l'analyse HTML reprend après l'exécution du script.
  • <script async> - Le script sera récupéré en parallèle de l'analyse HTML et exécuté dès qu'il est disponible (potentiellement avant la fin de l'analyse HTML). Utilisez async lorsque le script est indépendant de tout autre script sur la page, par exemple, les analyses.
  • <script defer> - Le script sera récupéré en parallèle de l'analyse HTML et exécuté une fois que la page a terminé son analyse. S'il y en a plusieurs, chaque script différé est exécuté dans l'ordre où il a été rencontré dans le document. Si un script dépend d'un DOM entièrement analysé, l'attribut defer sera utile pour s'assurer que le HTML est entièrement analysé avant l'exécution. Un script différé ne doit pas contenir document.write.

Note : Les attributs async et defer sont ignorés pour les scripts qui n'ont pas d'attribut src.

Pourquoi est-il généralement judicieux de placer les balises CSS `<link>` entre `<head></head>` et les balises JS `<script>` juste avant `</body>` ? Connaissez-vous des exceptions ?

Placer les balises <link> dans le <head>

Placer les balises <link> dans le <head> fait partie des spécifications appropriées pour la construction d'un site web optimisé. Lorsqu'une page se charge pour la première fois, le HTML et le CSS sont analysés simultanément ; le HTML crée le DOM (Document Object Model) et le CSS crée le CSSOM (CSS Object Model). Les deux sont nécessaires pour créer les visuels d'un site web, permettant un temps rapide de « premier affichage significatif ». Ce rendu progressif est une catégorie d'optimisation selon laquelle les sites sont mesurés dans leurs scores de performance. Placer les feuilles de style près du bas du document est ce qui empêche le rendu progressif dans de nombreux navigateurs. Certains navigateurs bloquent le rendu pour éviter d'avoir à repeindre des éléments de la page si leurs styles changent. L'utilisateur est alors bloqué en train de voir une page blanche vide. D'autres fois, il peut y avoir des flashs de contenu non stylisé (FOUC), qui affichent une page web sans aucun style appliqué.

Placer les balises <script> juste avant </body>

Les balises <script> bloquent l'analyse HTML pendant qu'elles sont téléchargées et exécutées, ce qui peut ralentir votre page. Placer les scripts en bas permettra au HTML d'être analysé et affiché à l'utilisateur en premier.

Une exception pour le positionnement des balises <script> en bas est lorsque votre script contient document.write(), mais de nos jours, ce n'est pas une bonne pratique d'utiliser document.write(). De plus, placer les balises <script> en bas signifie que le navigateur ne peut pas commencer à télécharger les scripts tant que le document entier n'est pas analysé. Cela garantit que votre code qui a besoin de manipuler les éléments du DOM ne provoquera pas d'erreur et n'arrêtera pas l'ensemble du script. Si vous avez besoin de placer des balises <script> dans le <head>, utilisez l'attribut defer, qui aura le même effet d'exécuter le script seulement après que le HTML a été analysé, mais le navigateur peut télécharger le script plus tôt.

Gardez à l'esprit que placer les scripts juste avant la balise </body> fermante créera l'illusion que la page se charge plus rapidement sur un cache vide (puisque les scripts ne bloqueront pas le téléchargement du reste du document). Cependant, si vous avez du code que vous voulez exécuter pendant le chargement de la page, il ne commencera à s'exécuter qu'après que la page entière ait été chargée. Si vous mettez ces scripts dans la balise <head>, ils commenceraient à s'exécuter avant - donc sur un cache amorcé, la page semblerait en fait se charger plus rapidement.

Les balises <head> et <body> sont désormais facultatives

Selon la spécification HTML5, certaines balises HTML comme <head> et <body> sont facultatives. Le guide de style de Google recommande même de les supprimer pour économiser des octets. Cependant, cette pratique n'est pas encore largement adoptée et le gain de performance est susceptible d'être minime et pour la plupart des sites, cela ne devrait probablement pas avoir d'importance.

Qu'est-ce que le rendu progressif ?

Le rendu progressif est le nom donné aux techniques utilisées pour améliorer les performances d'une page web (en particulier, améliorer le temps de chargement perçu) afin de rendre le contenu pour l'affichage le plus rapidement possible.

Il était beaucoup plus répandu à l'époque de l'internet à haut débit, mais il est toujours utilisé dans le développement moderne car les connexions de données mobiles deviennent de plus en plus populaires (et peu fiables) !

Exemples de ces techniques :

  • Chargement paresseux des images (Lazy loading of images) - Les images de la page ne sont pas toutes chargées en même temps. JavaScript sera utilisé pour charger une image lorsque l'utilisateur fait défiler la partie de la page qui affiche l'image.
  • Priorisation du contenu visible (ou rendu au-dessus de la ligne de flottaison) - N'incluez que le minimum de CSS/contenu/scripts nécessaire pour la quantité de page qui serait rendue dans le navigateur de l'utilisateur en premier pour s'afficher le plus rapidement possible, vous pouvez ensuite utiliser des scripts différés ou écouter l'événement DOMContentLoaded/load pour charger d'autres ressources et contenus.
  • Fragments HTML asynchrones - Vider des parties du HTML vers le navigateur au fur et à mesure que la page est construite en back-end. Plus de détails sur la technique peuvent être trouvés.

Pourquoi utiliseriez-vous un attribut `srcset` dans une balise image ? Expliquez le processus utilisé par le navigateur lors de l'évaluation du contenu de cet attribut.

Vous utiliseriez l'attribut srcset lorsque vous souhaitez servir différentes images aux utilisateurs en fonction de la largeur de l'affichage de leur appareil - servir des images de meilleure qualité aux appareils dotés d'un écran Retina améliore l'expérience utilisateur, tandis que servir des images de résolution inférieure aux appareils bas de gamme augmente les performances et diminue le gaspillage de données (car servir une image plus grande n'aura aucune différence visible). Par exemple : <img srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" src="..." alt=""> indique au navigateur d'afficher le graphique .jpg petit, moyen ou grand en fonction de la résolution du client. La première valeur est le nom de l'image et la seconde est la largeur de l'image en pixels. Pour une largeur d'appareil de 320px, les calculs suivants sont effectués :

  • 500 / 320 = 1.5625
  • 1000 / 320 = 3.125
  • 2000 / 320 = 6.25

Si la résolution du client est de 1x, 1.5625 est le plus proche, et 500w correspondant à small.jpg sera sélectionné par le navigateur.

Si la résolution est Retina (2x), le navigateur utilisera la résolution la plus proche au-dessus du minimum. Cela signifie qu'il ne choisira pas le 500w (1.5625) car il est supérieur à 1 et l'image pourrait être de mauvaise qualité. Le navigateur choisirait alors l'image avec un rapport résultant plus proche de 2, qui est 1000w (3.125).

Les srcsets résolvent le problème où vous voulez servir des fichiers image plus petits aux appareils à écran étroit, car ils n'ont pas besoin d'images aussi grandes que les écrans de bureau - et aussi, facultativement, que vous voulez servir des images de résolutions différentes aux écrans haute densité/basse densité.

Avez-vous déjà utilisé différents langages de templating HTML ?

Oui, Pug (anciennement Jade), ERB, Slim, Handlebars, Jinja, Liquid et EJS pour n'en nommer que quelques-uns. À mon avis, ils sont plus ou moins similaires et offrent des fonctionnalités similaires d'échappement de contenu et des filtres utiles pour manipuler les données à afficher. La plupart des moteurs de templating vous permettront également d'injecter vos propres filtres au cas où vous auriez besoin d'un traitement personnalisé avant l'affichage.

Quelle est la différence entre canvas et SVG ?

Canvas est basé sur les pixels, travaillant avec des pixels, tandis que SVG est basé sur les vecteurs, employant des descriptions mathématiques de formes. Canvas utilise le dessin impératif, où chaque étape est spécifiée avec JavaScript, idéal pour les graphiques dynamiques et interactifs comme les animations et les jeux.

Inversement, SVG utilise le dessin déclaratif, avec des formes et des chemins définis directement en HTML, ce qui le rend plus accessible et SEO-friendly. Canvas est optimal pour les scènes complexes en raison de sa surcharge plus faible, mais la mise à l'échelle peut entraîner une perte de qualité d'image. SVG, étant indépendant de la résolution, s'adapte à diverses tailles d'écran sans sacrifier la qualité.

En fin de compte, canvas convient aux graphiques dynamiques et gourmands en performances, tandis que SVG excelle dans les graphiques évolutifs et indépendants de la résolution, avec des avantages inhérents en matière d'accessibilité et de SEO.

Que sont les éléments vides en HTML ?

Les éléments vides en HTML sont des éléments qui ne contiennent aucun contenu entre leurs balises ouvrantes et fermantes. Au lieu de cela, ce sont des balises auto-fermantes, ce qui signifie qu'elles ont une barre oblique (/) avant le crochet angulaire fermant (>). Voici quelques exemples courants d'éléments vides :

  • <img> : Utilisé pour intégrer des images dans le document.
  • <input> : Utilisé pour accepter la saisie de l'utilisateur.
  • <br> : Utilisé pour insérer des sauts de ligne ou des retours à la ligne forcés.
  • <hr> : Utilisé pour créer des règles horizontales ou des séparateurs.