mirror
/
front-end-interview-handbook
mirror of https://github.com/yangshun/front-end-interview-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
front-end-interview-handbook/website/i18n/de/docusaurus-plugin-content-docs/current/html-questions.md

17 KiB
Raw Blame History

title
Fragen zu HTML

Antworten auf Front-end Job Interview Questions - HTML Questions. Pull requests for suggestions and corrections are welcome!

import TOCInline from '@theme/TOCInline';

Was tut ein doctype?

DOCTYPE ist eine Abkürzung für DOCument TYPE. Jeder DOCTYPE ist immer mit einer DTD - verbunden, einer Document Type Definition.

Eine DTD legt fest, wie ein Dokument eines bestimmten Typs strukturiert ist (d.h. ein button kann ein span enthalten, aber keindiv), ein DOCTYPE hingegen erklärt, welche DTD ein Dokument vermutlich akzeptiert (d.h. dieses Dokument akzeptiert eine HTML DTD).

Webseiten benötigen die Ausweisung im jeweiligen DOCTYPE. User Agents erkennen so, welche Version der HTML-Spezifikationen das Dokument akzeptiert. Sobald ein User Agent ein korrektes DOCTYPE erkannt hat, löst es den no-quirks mode aus, das dem jeweiligen DOCTYPE entspricht. Wenn der User Agent kein korrektes DOCTYPE erkennt, löst er den quirks mode aus.

Die DOCTYPE Spezifikation für den HTML5 Standard ist <!DOCTYPE html>.

Referenzen

Wie lieferst du eine Seite mit Inhalten in verschiedenen Sprachen aus?

Ich gehe davon aus, dass es sich um den häufigsten Fall handelt: Wie kann eine Seite mit Inhalten bedient werden, die in mehreren Sprachen verfügbar ist. Dabei soll der Inhalt innerhalb der Seite nur in einer konsistenten Sprache angezeigt werden.

Wenn ein Server eine HTTP-Anforderung erhält, sendet der anfordernde User Agent normalerweise Informationen über Sprachpräferenzen, die z.B. im Accept-Language-Header definiert sind. Der Server kann dann diese Informationen verwenden, um eine Version des Dokuments in der entsprechenden Sprache zurückzugeben, wenn eine solche Alternative verfügbar ist. Das zurückgegebene HTML-Dokument sollte auch das lang-Attribut im <html>-Tag deklarieren, wie z.B. <html lang="en">...</html>.

Da es keinen Sinn ergibt, eine Suchmaschine wissen zu lassen, dass der gleiche Inhalt in verschiedenen Sprachen erhältlich ist, solltest du das hreflang Attribute im <head> setzen. D.h <link rel="alternate" hreflang="de" href="http://de.example.com/page.html" />

Im Backend enthält das HTML-Markup `i18n'-Platzhalter und Inhalte für die jeweilige Sprache, die im YML- oder JSON-Format gespeichert sind. Der Server generiert dann dynamisch die HTML-Seite mit Inhalt in dieser speziellen Sprache, normalerweise mit Hilfe eines Backend-Frameworks.

Referenzen

Vor welchen Dingen solltest du dich hüten, wenn du mehrsprachige Websites designst oder entwickelst?

  • Setze im HTML das lang Attribut.

  • Erlauben Sie einem Benutzer, sein Land/seine Sprache einfach und problemlos zu ändern.

  • Text in rasterbasierten Bildern (z.B. png, gif, jpg, etc.) auszuliefern, ist kein skalierbarer Ansatz. Dabei ist das Platzieren von Texten in Bildern immer noch eine beliebte Methode, um gut aussehende, nicht systemgebundene Schriftarten auf jedem Computer anzuzeigen. In diesem Fall muss aber für jeder auszuliefernde Sprache ein eigenes mit der entsprechenden Textzeichenfolge erstellt werden. Alles, was über eine Handvoll solcher Ersetzungen hinausgeht, kann schnell außer Kontrolle geraten.

  • Restriktive Wort-/Satzlänge - Manche Inhalte können länger sein, wenn sie in einer anderen Sprache geschrieben sind. Sei vorsichtig bei Layout- oder Überlaufproblemen im Design. Besondere Aufemerksamkeit ist prominenten Elementen wie Überschriften, Beschriftungen und Schaltflächen zu widmen, das hier sich ändernde Zeilenlängen schnell Überläufe bilden können. Frei fließender Text wie Fließtext oder Kommentartext ist weniger problematisch.

  • Achte darauf, wie Farben wahrgenommen werden - Farben werden je nach Sprache und Kultur unterschiedlich wahrgenommen. Das Design sollte das berücksichtigen.

  • Formatierung von Daten und Währungen - Kalenderdaten werden unterschiedlich dargestellt. Z.B. "31. Mai 2012" in den USA vs. "31. Mai 2012" in Teilen Europas.

  • Verketten Sie keine übersetzten Zeichenketten - Machen Sie nichts wie "Das heutige Datum ist " + date. So ein Konstrukt funktioniert in einer Sprache mit einer anderen Wortstellung nicht. Verwende stattdessen Template-Strings mit sprachspezifischen Parameter-Substitution. Dazu ein Beispiel: I will travel on {% date %} sieht auf Chinesisch so aus: {% date %} 我会出发. Beachte, dass die Position der Variable Grammatikbedingt unterschiedlich ist.

  • Sprachleserichtung - Im Englischen lesen wir von links nach rechts, von oben nach unten, im traditionellen Japanisch wird der Text von oben nach unten, von rechts nach links gelesen.

Referenzen

Wofür sind data- Attribute nützlich?

Bevor JavaScript-Frameworks populär wurden, benutzten Front-End-Entwickler data- Attribute, um zusätzliche Daten innerhalb des DOM selbst zu speichern. Sie dienen zum Speichern benutzerdefinierter Daten, für die es keine passenderen Attribute oder Elemente gibt.

Heute wird die Verwendung von Daten- Attributen nicht empfohlen. Zum Beispiel weil Benutzer das Datenattribut leicht modifizieren können, indem sie das inspect-Element im Browser verwenden. Das Datenmodell ist besser im JavaScript gespeichert und bleibt mit dem DOM durch Datenbindung, bspw. eine Library oder ein Framework, auf dem neuesten Stand.

Das Hinzufügen eines Hooks für end to end Testframeworks wie Selenium und Capybara ist ein Beispiel für die gültige Verwendung von Datenattributen. Denn so ist es nicht nötig, sinnlose Klassen oder ID-Attribute erstellen zu müssen. Da das Element einen Weg benötigt , um von einer bestimmten Selenium-Spezifikation gefunden zu werden, und etwas wie data-selector='the-thing' ist ein gültiger Weg.

Referenzen

Stelle dir HTML5 als eine offene Internetplattform vor. Was sind die Basiskomponenten von HTML5?

  • Semantik - Ermöglicht, Inhalte genauer zu beschreiben.
  • Konnektivität - Ermöglicht, auf (innovative) neue Weise mit dem Server zu kommunizieren.
  • Offline und Speicherung - Ermöglicht Webseiten, Daten auf der Client-Seite lokal zu speichern und offline effizienter zu arbeiten.
  • Multimedia - Video und Audio lassen sich besser im Open Web nutzen.
  • 2D/3D-Grafiken und -Effekte - Ermöglicht eine vielfältigere Palette von Präsentationsmöglichkeiten.
  • Leistung und Integration - Geschwindigkeitsoptimierung und bessere Nutzung der Computerhardware.
  • Gerätezugriff - Ermöglicht die Verwendung verschiedener Ein- und Ausgabegeräte.
  • Styling - Macht anspruchsvollere Themes möglich.
Referenzen

Beschreibe die Unterschiede zwischen Cookies, sessionStorage und localStorage.

Alle oben genannten Technologien sind Schlüsselspeichermechanismen auf der Client-Seite. Sie sind nur in der Lage, Werte als Strings zu speichern.

cookie localStorage sessionStorage
Initiator Client bzw. Server. Server nutzt Set-Cookie Header Client Client
Ablauf Manuell gesetzt Für immer Wenn Tab geschlossen
Persistenz über Browser-Sessions Hängt davon ab, welcher Ablauf gesetzt ist Ja Nein
Wird mit jeder HTTP-Anfrage an den Server gesendet Cookies werden automatisch über den Cookie-Header gesendet Nein Nein
Kapazität (pro Domain) 4kb 5MB 5MB
Zugänglichkeit Jedes Fenster Jedes Fenster Selbes Tab

Hinweis: Löscht der Nutzer seine Browser-Daten s zu löschen, löscht dies auch jeden gespeicherten Cookie, LocalStorage oder SessionStorage. Es ist wichtig, dies beim Design für lokale Persistenz zu bedenken. Eventuell sollte eine serverseitige Speicherung in einer Datenbank in Erwägung gezogen werden.

Referenzen

Beschreibe die Unterschiedie zwischen <script>, <script async> und <script defer>.

  • <script> - Das HTML-Parsing wird blockiert, das Skript wird geholt (gefetcht) und sofort ausgeführt, das HTML-Parsing wird nach Ausführung des Scripts fortgesetzt.
  • <script async> - Das Skript wird parallel zum HTML-Parsing geholt (gefetcht) und ausgeführt, sobald es verfügbar ist (möglicherweise bevor das HTML-Parsing abgeschlossen ist). Verwende async, wenn das Skript unabhängig von anderen Skripten auf der Seite ist, z.B. bei Analysen. (im Original "Analytics")
  • <script defer> - Das Skript wird parallel zum HTML-Parsing geholt (gefetcht) aber erst dann ausgeführt, wenn das Parsen der Seite beendet ist. Sind mehrere Scripts vorhanden, werden sie in der Reihenfolge ausgeführt, in der sie im Dokument angetroffen wurden. Wenn sich ein Script auf ein vollständig geparstes DOM stützt, ist das defer-Attribut nützlich, um sicherzustellen, dass das HTML vor der Ausführung vollständig geparst wird. Es macht keinen großen Unterschied, ein normales <script> an das Ende von <body> zu setzen. Ein verzögertes Skript darf kein document.write enthalten.

Hinweis: Die Attribute async und defer werden für Skripte ignoriert, die kein `src'-Attribut haben.

Referenzen

Warum ist es eine gute Idee, die <link>s zum CSS-Stylesheet inneralb der <head></head> Tags zu platzieren und die JS <script>s direkt vorm </body> einzubinden? Würdest du Ausnahmen machen?

Platzieren von <link>s im <head>

Eine optimierten Website setzt voraus, dass das <link> Attribut im <head> platziert ist. Wird eine Seite erstmalig geladen, werden HTML und CSS gleichzeitig geparst; HTML erzeugt das DOM (Document Object Model) und CSS erzeugt das CSSOM (CSS Object Model). Beide sind für die Erstellung einer Website erforderlich. Je schneller geparsed wird, desto besser, denn "first meaningful paint" ist ein wichtiger Performance-Indikator. Die Platzierung von Stylesheets am unteren Rand des Dokuments würde das progressessive Rendering in vielen Browsern verhindern. Einige Browser blockieren das Rendering, um zu vermeiden, dass Elemente der Seite neu gezeichnet werden müssen, wenn sich ihre Stile ändern. Der Benutzer bleibt dann bei der Anzeige einer leeren weißen Seite hängen. Zu anderen Zeiten kann es Flashs mit unstyled content (FOUC) geben, die eine Webseite ohne angewandtes Styling zeigen.

Platzieren von <script>s direkt vor </body>

<script> Tags blockieren das Parsen von HTML, während sie heruntergeladen und ausgeführt werden. Das kann die Seite verlangsamen. Durch die Platzierung der Skripte am unteren Rand wird das HTML zuerst geparsed und dem Benutzer angezeigt.

Es gibt eine Ausnahme für die Positionierung von <script>s am unteren Rand: Dein Script enthält document.write(). Das ist aber heutzutage eine schlechte Praxis. Außerdem bedeutet die Platzierung von <script>s am unteren Rand, dass der Browser erst dann mit dem Herunterladen der Skripte beginnen kann, wenn das gesamte Dokument geparst wurde. Dies stellt sicher, dass Code, der DOM-Elemente manipulieren muss, das gesamte Skript nicht verwirft, Fehler macht und anhält. Muss <script> in's <head> gesetzt werden, sollte man dasdefer-Attribut nutzen, das den gleichen Effekt erzielt wie das Herunterladen und Ausführen des Skripts nach dem Parsen des HTML-Dokuments.

Denke daran, dass das Einfügen von Scripten vor dem schließenden </body>-Tag die Illusion erzeugt, dass die Seite in einem leeren Cache schneller geladen wird (da die Scripte den Download des restlichen Dokuments nicht blockieren). Der Code wird erst dann ausgeführt, wenn die gesamte Seite geladen ist. Sind diese Scripte in das <head>-Tag gesetzt, beginnen sie vorher mit der Ausführung - auf einem vorbereiteten Cache würde die Seite also tatsächlich schneller geladen werden.

References

Was ist progressives Rendern?

"Progressive rendering" (progressive Wiedergabe) bezeichnet Techniken zur Verbesserung der Leistung einer Webseite (insbesondere zur Verbesserung der wahrgenommenen Ladezeit), da Inhalte so schnell wie möglich dargestellt werden können.

Vor der Einführung des Breitband-Internets war es viel weiter verbreitet, aber es wird in der modernen Web-Entwicklung immer noch verwendet, da mobile Datenverbindungen immer populärer (und unzuverlässiger) werden!

Beispiele für diese Technologie:

  • Langsames Laden von Bildern (Lazy loading of images) - Bilder werden nicht alle auf einmal geladen. JavaScript lädtt Bilder erst, wenn der Benutzer in den Teil der Seite scrollt, der das Bild anzeigt.
  • Priorisierung von sichtbarem Inhalt (oder Rendering über dem Falz "above-the-fold rendering" ) - Berücksichtige nur das für das erste Erscheinen der Seite nötige Minimum an CSS/Inhalten/Scripten. Durch verzögerte Scripte bzw. durch DOMContentLoaded/load können andere Ressourcen nachgeladen werden.
  • Asynchrone HTML-Fragmente - Flushen von Teilen des HTML in den Browser, während die Seite im Backend aufgebaut wird.Mehr Details findest du hier.
Referenzen

Warum würdest du ein srcset Attribute in ein image tag einsetzen? Erkläre wie der Browser bei der Auswertung des Inhalts dieses Attributs vorgeht.

Dassrcset-Attribut wird verwendet, um Benutzern abhängig von der Anzeigebreite ihrer Geräte unterschiedliche Bilder zur Verfügung zu stellen. Die Bereitstellung von Bildern höherer Qualität für Geräte mit Retina-Display verbessert das Nutzererlebnis, während die Bereitstellung von Bildern niedrigerer Auflösung für Geräte des unteren Marktsegments die Leistung erhöht und das Datenvolumen verringert (da die Bereitstellung eines größeren Bildes keinen sichtbaren Unterschied aufweist). Zum Beispiel: <img srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" src="..." alt=""> weist den Browser an, die kleine, mittlere oder große .jpg Grafik abhängig von der Auflösung des Kunden anzuzeigen. Der erste Wert ist der Bildname und der zweite ist die Breite des Bildes in Pixeln. Für eine Gerätebreite von 320px werden die folgenden Berechnungen durchgeführt:

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

Wenn die Auflösung des Clients 1x ist, ist 1.5625 die nächstliegende Auflösung. Damit entspricht 500w small.jpg und wird vom Browser ausgewählt.

Handelt es sich um ein Retina-Display (Auflösung: 2x), verwendet der Browser die nächstliegende Auflösung, die über dem Minimum liegt. Das heißt, er wird nicht die 500w (1,5625) wählen, nur weil sie größer als 1. Der Browser würde stattdessen das Bild mit einem resultierenden Verhältnis wählen, das näher an 2 liegt, d.h. 1000w (3,125). (Dessen Qualität der einer Retina-Auflösung entspricht)

Durch srcsets lassen sich Bilddateien Geräte- und Auflösungsspezifisch ausliefern: Kleine Bilder an Geräte mit schmalem Bildschirm, große, an Geräte mit großen Monitoren - und optional auch, Bilder unterschiedlicher Auflösung je nach Pixeldichte.

Referenzen

Hast du Erfahrungen mit unterschiedlichen HTML templating languages gemacht?

Ja, Pug (früher Jade), ERB, Slim, Handlebars, Jinja, Liquid und EJS, um nur einige zu nennen. Meiner Meinung nach sind sie mehr oder weniger gleich und bieten eine ähnliche Funktionalität: Inhalte zu "escapen" und die anzuzeigenden Daten zu Filter um beispielsweise ihre Darstellung zu manipulieren. Die meisten Template-Engines erlauben es, eigene Filter einzufügen, falls eine benutzerdefinierte Verarbeitung benötigt wird.

Andere Antworten