Umgang mit häufigen HTML- und CSS-Problemen

Einige der Probleme mit HTML und CSS liegen in der Tatsache, dass beide Sprachen relativ einfach sind und Entwickler oft nicht darauf achten, sicherzustellen, dass der Code gut gestaltet, effizient und semantisch die Funktion der Merkmale auf der Seite beschreibt. In den schlimmsten Fällen wird JavaScript verwendet, um den gesamten Webseiteninhalt und -stil zu erstellen, was Ihre Seiten unzugänglich und weniger performant macht (erzeugen von DOM-Elementen ist kostspielig). In anderen Fällen werden neue Merkmale nicht konsistent über alle Browser unterstützt, was dazu führen kann, dass einige Merkmale und Stile für einige Nutzer nicht funktionieren. Probleme mit responsivem Design sind ebenfalls häufig — eine Website, die in einem Desktop-Browser gut aussieht, kann auf einem mobilen Gerät eine schlechte Benutzererfahrung bieten, weil der Inhalt zu klein ist, um ihn zu lesen, oder weil die Website möglicherweise langsam ist aufgrund kostspieliger Animationen.

Lassen Sie uns fortfahren und schauen, wie wir plattformübergreifende Fehler, die aus HTML/CSS resultieren, reduzieren können.

Wir haben im ersten Artikel dieser Serie gesagt, dass eine gute Strategie darin besteht, mit dem Testen in ein paar modernen Browsern auf Desktop/Mobilgeräten zu beginnen, um sicherzustellen, dass Ihr Code generell funktioniert, bevor Sie sich auf die plattformübergreifenden Probleme konzentrieren.

In unseren Artikeln Debugging HTML und Debugging CSS haben wir einige grundlegende Anleitungen zur Fehlersuche in HTML/CSS gegeben — wenn Sie mit den Grundlagen nicht vertraut sind, sollten Sie diese Artikel unbedingt studieren, bevor Sie weitermachen.

Grundsätzlich liegt es daran, ob Ihr HTML- und CSS-Code gut formatiert ist und keine Syntaxfehler enthält.

Bei HTML beinhaltet die Validierung, sicherzustellen, dass alle Ihre Tags ordnungsgemäß geschlossen und verschachtelt sind, Sie einen Doctype verwenden und die Tags für ihren richtigen Zweck verwenden. Eine gute Strategie ist, Ihren Code regelmäßig zu validieren. Ein Service, der dies tun kann, ist der W3C Markup Validation Service, der Ihnen erlaubt, auf Ihren Code zu verweisen und eine Liste von Fehlern zurückgibt:

CSS hat eine ähnliche Geschichte — Sie müssen prüfen, ob Ihre Eigenschaftsnamen korrekt geschrieben sind, Eigenschaftswerte richtig geschrieben sind und für die Eigenschaften, auf denen sie verwendet werden, gültig sind, es dürfen keine geschweiften Klammern fehlen, und so weiter. Auch hierfür bietet das W3C einen CSS Validator an.

Eine andere gute Option ist eine sogenannte Linter-Anwendung, die nicht nur Fehler aufzeigt, sondern auch Warnungen vor schlechten Praktiken in Ihrem CSS hervorheben kann, und andere Punkte zusätzlich. Linter können im Allgemeinen auf strengere oder lockerere Fehlermeldungen/Warnungen angepasst werden.

Es gibt viele Online-Linter-Anwendungen wie Dirty Markup für HTML, CSS und JavaScript. Diese Anwendungen erlauben es Ihnen, Ihren Code in ein Fenster zu kopieren, und sie kennzeichnen Fehler mit Kreuzen, die dann schwebend eine Fehlermeldung anzeigen, die Ihnen mitteilt, was das Problem ist. Dirty Markup erlaubt es Ihnen auch, Ihre Markup mit der Clean-Schaltfläche zu korrigieren.

Es ist jedoch nicht sehr bequem, Ihren Code mehrmals zum Überprüfen der Gültigkeit über eine Webseite kopieren und einfügen zu müssen. Was Sie wirklich wollen, ist ein Linter, der sich mit minimalem Aufwand in Ihren normalen Arbeitsablauf einfügt.

Viele Code-Editoren haben Linter-Plugins. Zum Beispiel:

• SublimeLinter für Sublime Text
• Notepad++ Linter
• VS Code Linters

Die Entwicklerwerkzeuge, die in die meisten Browser integriert sind, bieten ebenfalls nützliche Tools zum Aufspüren von Fehlern, hauptsächlich für CSS.

Zum Beispiel zeigt der CSS-Inspektor in Firefox CSS-Deklarationen, die nicht angewendet werden, durchgestrichen an, mit einem Warnsymbol. Wenn man mit der Maus über das Warnsymbol fährt, wird eine beschreibende Fehlermeldung angezeigt:

Andere Browser-Entwicklertools haben ähnliche Funktionen.

Nun wollen wir einige der häufigsten plattformübergreifenden HTML- und CSS-Probleme betrachten. Die Hauptbereiche, die wir betrachten, sind fehlende Unterstützung für moderne Funktionen und Layoutprobleme.

Dies ist ein häufiges Problem, insbesondere wenn Sie alte Browser unterstützen müssen oder Funktionen verwenden, die in einigen Browsern implementiert sind, aber noch nicht in allen. Im Allgemeinen funktionieren die meisten grundlegenden HTML- und CSS-Funktionalitäten (wie grundlegende HTML-Elemente, CSS-Grundfarben und Textstile) in allen Browsern, die Sie unterstützen möchten; mehr Probleme treten auf, wenn Sie neuere HTML-, CSS- und API-Funktionen verwenden möchten. MDN zeigt Browser-Kompatibilitätsdaten für jede dokumentierte Funktion; siehe zum Beispiel den Browser-Support-Tabelle für die :has() Pseudoklasse.

Sobald Sie eine Liste von Technologien identifiziert haben, die Sie verwenden, die nicht universell unterstützt werden, ist es eine gute Idee, zu recherchieren, in welchen Browsern sie unterstützt werden und welche verwandten Techniken nützlich sind. Siehe Hilfe finden unten.

Einige Probleme können einfach durch Ausnutzung der natürlichen Funktionsweise von HTML/CSS gelöst werden.

Nicht erkannte HTML-Elemente werden vom Browser als anonyme Inline-Elemente behandelt (effektiv Inline-Elemente ohne semantischen Wert, ähnlich zu <span> Elementen). Sie können weiterhin auf sie per Namen verweisen und sie mit CSS stylen — Sie müssen nur sicherstellen, dass sie sich so verhalten, wie Sie es wünschen. Stylen Sie sie wie jedes andere Element, einschließlich der Einstellung der display-Eigenschaft auf etwas anderes als inline, falls erforderlich.

Komplexere Elemente wie HTML <video>, <audio>, <picture>, <object> und <canvas> (und andere Features) haben natürliche Mechanismen für Fallbacks, die hinzugefügt werden können, falls die verlinkten Ressourcen nicht unterstützt werden. Sie können Fallback-Inhalte zwischen die öffnenden und schließenden Tags einfügen, und nicht unterstützende Browser ignorieren das äußere Element und führen die eingebetteten Inhalte aus.

Zum Beispiel:

<video id="video" controls preload="metadata" poster="img/poster.jpg">
  <source
    src="video/tears-of-steel-battle-clip-medium.webm"
    type="video/webm" />
  <!-- Offer download -->
  <p>
    Your browser does not support WebM video; here is a link to
    <a href="video/tears-of-steel-battle-clip-medium.mp4"
      >view the video directly</a
    >
  </p>
</video>

Dieses Beispiel enthält einen einfachen Link, der es Ihnen erlaubt, das Video herunterzuladen, falls der HTML-Videoplayer nicht funktioniert, sodass der Benutzer zumindest das Video trotzdem ansehen kann.

Ein weiteres Beispiel sind Formularelemente. Als neue <input> Typen für die Eingabe spezifischer Informationen in Formulare eingeführt wurden, wie Zeiten, Daten, Farben, Zahlen usw., wenn ein Browser das neue Merkmal nicht unterstützte, verwendete der Browser standardmäßig type="text". Es wurden Eingabetypen hinzugefügt, die insbesondere auf mobilen Plattformen sehr nützlich sind, wo es wichtig für die Benutzererfahrung ist, einen schmerzfreien Weg zur Eingabe von Daten bereitzustellen. Plattformen bieten je nach Eingabetyp unterschiedliche UI-Widgets, wie zum Beispiel ein Kalender-Widget zur Eingabe von Daten. Sollten in einem Browser ein Eingabetyp nicht unterstützt werden, kann der Benutzer dennoch die erforderlichen Daten eingeben.

Das folgende Beispiel zeigt Date- und Zeitangaben:

<form>
  <div>
    <label for="date">Enter a date:</label>
    <input id="date" type="date" />
  </div>
  <div>
    <label for="time">Enter a time:</label>
    <input id="time" type="time" />
  </div>
</form>

Die Ausgabe dieses Codes ist wie folgt:

Wenn Sie sich das Beispiel ansehen, werden Sie die UI-Funktionen in Aktion sehen, wenn Sie versuchen, Daten einzugeben. Auf Geräten mit dynamischen Tastaturen werden typenspezifische Keypads angezeigt. In einem nicht unterstützenden Browser werden die Eingaben einfach auf normale Texteingaben zurückgesetzt, was bedeutet, dass der Benutzer dennoch die richtigen Informationen eingeben kann.

CSS kann besser mit Fallbacks umgehen als HTML. Wenn ein Browser auf eine Erklärung oder Regel stößt, die er nicht versteht, überspringt er sie einfach vollständig, ohne sie anzuwenden oder einen Fehler anzuzeigen. Dies kann für Sie und Ihre Benutzer frustrierend sein, wenn ein solcher Fehler bis in den Produktionscode durchrutscht, aber es bedeutet zumindest, dass die gesamte Seite nicht wegen eines Fehlers abstürzt, und wenn es clever eingesetzt wird, können Sie es zu Ihrem Vorteil nutzen.

Betrachten wir ein Beispiel — ein einfacher Kasten, der mit CSS gestylt ist und mehrere CSS-Eigenschaften hat:

Der Button hat eine Reihe von Deklarationen, die das Styling abdecken, aber die zwei, die uns am meisten interessieren, sind folgende:

button {
  /* … */

  background-color: #ff0000;
  background-color: rgb(255 0 0 / 100%);
  box-shadow:
    inset 1px 1px 3px rgb(255 255 255 / 40%),
    inset -1px -1px 3px rgb(0 0 0 / 40%);
}

button:hover {
  background-color: rgb(255 0 0 / 50%);
}

button:active {
  box-shadow:
    inset 1px 1px 3px rgb(0 0 0 / 40%),
    inset -1px -1px 3px rgb(255 255 255 / 40%);
}

Hier bieten wir eine RGB background-color, die bei Hover die Opazität ändert, um dem Benutzer einen Hinweis zu geben, dass der Button interaktiv ist, und einige halbtransparente eingesetzte box-shadow Schatten, um dem Button etwas Textur und Tiefe zu verleihen. Während sie mittlerweile vollständig unterstützt werden, haben RGB-Farben und Box-Schatten nicht von Anfang an existiert; sie begannen ab IE9. Browser, die RGB-Farben nicht unterstützten, würden die Deklaration ignorieren, was bedeutet, dass in alten Browsern der Hintergrund überhaupt nicht angezeigt würde, sodass der Text nicht lesbar wäre, was gar nicht gut ist!

Um dies zu beheben, haben wir eine zweite background-color-Deklaration hinzugefügt, die einfach eine Hex-Farbe angibt — dies wird in sehr alten Browsern weit zurück unterstützt und fungiert als Fallback, wenn die modernen glänzenden Funktionen nicht funktionieren. Was passiert, ist, dass ein Browser, der diese Seite besucht, zunächst den ersten background-color-Wert anwendet; wenn er zur zweiten background-color-Deklaration gelangt, überschreibt er den ersten Wert mit diesem, wenn er RGB-Farben unterstützt. Wenn nicht, ignoriert er einfach die gesamte Deklaration und fährt fort.

Natürlich werden keine CSS-Funktionen überhaupt angewendet, wenn Sie nicht die richtigen Selektoren verwenden, um das Element auszuwählen, das Sie stylen möchten!

In einer durch Kommata getrennten Liste von Selektoren, wenn Sie einfach einen Selektor falsch schreiben, kann es sein, dass er kein Element auswählt. Wenn jedoch ein Selektor ungültig ist, wird die gesamte Liste der Selektoren ignoriert, zusammen mit dem gesamten Stilblock. Aus diesem Grund sollten Sie ein :-moz--präfixiertes Pseudoklasse oder Pseudo-Element nur in einer nachsichtigen Selektorliste wie :where(::-moz-thumb) einschließen. Fügen Sie kein :-moz--präfixiertes Pseudoklasse oder Pseudo-Element in eine durch Kommas getrennte Gruppe von Selektoren außerhalb einer :is() oder :where() nachsichtigen Selektorliste ein, da alle Browser außer Firefox den gesamten Block ignorieren. Beachten Sie, dass sowohl :is() als auch :where() als Parameter in anderen Selektorlisten verwendet werden können, einschließlich :has() und :not().

Wir finden, dass es hilfreich ist, das Element, das Sie stylen möchten, mit den Entwicklerwerkzeugen Ihres Browsers zu inspizieren und dann die DOM-Baum-Breadcrumbs zu betrachten, die DOM-Inspektoren normalerweise bereitstellen, um zu sehen, ob Ihr Selektor im Vergleich dazu Sinn macht.

Zum Beispiel erhalten Sie in den Firefox-Entwicklertools diese Art von Ausgabe am unteren Rand des DOM-Inspektors:

Wenn Sie versuchen würden, diesen Selektor zu verwenden, würden Sie sehen, dass er nicht das gewünschte Eingabeelement auswählt:

form > #date

(Das date Formularfeld ist kein direktes Kind des <form>; Sie wären besser dran, einen allgemeinen Nachfahren-Selektor anstelle eines Kindselektors zu verwenden).

Ein weiteres Problem entsteht mit CSS-Präfixen — dies sind Mechanismen, die ursprünglich verwendet wurden, um Browseranbietern die Implementierung ihrer eigenen Version einer CSS- (oder JavaScript-) Funktion zu ermöglichen, während die Technologie sich in einem experimentellen Zustand befindet, sodass sie damit spielen und sie richtig machen können, ohne mit Implementierungen anderer Browser zu kollidieren oder mit der endgültigen nicht präfixierten Implementierung.

Zum Beispiel verwendet Firefox -moz- und Chrome/Edge/Opera/Safari verwenden -webkit-. Andere Präfixe, die Sie in altem Code finden können und die sicher entfernt werden können, sind -ms-, das von Internet Explorer und frühen Versionen von Edge verwendet wurde, sowie -o, das in den ursprünglichen Versionen von Opera verwendet wurde.

Präfixierte Funktionen sollten nie in Produktionswebsites verwendet werden — sie können sich ohne Vorwarnung ändern oder entfernt werden, können in alten Browserversionen, die sie benötigen, Leistungsprobleme verursachen und haben plattformübergreifende Probleme verursacht. Dies ist besonders problematisch, wenn Entwickler sich entscheiden, nur die -webkit- Version einer Eigenschaft zu verwenden, was implizierte, dass die Website in anderen Browsern nicht funktioniert. Dies ist tatsächlich so häufig passiert, dass andere Browseranbieter -webkit--präfixierte Versionen mehrerer CSS-Eigenschaften implementierten. Während Browser immer noch einige präfixierte Eigenschaftsnamen, Eigenschaftswerte und Pseudoklassen unterstützen, werden jetzt experimentelle Funktionen hinter Flags gesetzt, damit Webentwickler sie während der Entwicklung testen können.

Wenn Sie ein Präfix verwenden, stellen Sie sicher, dass es benötigt wird; dass die Eigenschaft eine der wenigen verbleibenden präfixierten Funktionen ist. Sie können nachsehen, welche Browser Präfixe auf den MDN-Referenzseiten erfordern, und auf Websites wie caniuse.com. Wenn Sie sich unsicher sind, können Sie es auch herausfinden, indem Sie einige Tests direkt in den Browsern durchführen. Fügen Sie die standardmäßige nicht-präfixierte Version nach der präfixierten Stil-Deklaration hinzu; sie wird ignoriert, wenn sie nicht unterstützt wird und verwendet, wenn sie unterstützt wird.

.masked {
  -webkit-mask-image: url(MDN.svg);
  mask-image: url(MDN.svg);
  -webkit-mask-size: 50%;
  mask-size: 50%;
}

Probieren Sie dieses einfache Beispiel aus:

1. Verwenden Sie diese Seite oder eine andere Website, die eine prominente Überschrift oder ein anderes Blockelement hat.

2. Klicken Sie mit der rechten Taste/Befehlstaste auf das betreffende Element und wählen Sie "Inspect/Element inspizieren" (oder die entsprechende Option in Ihrem Browser) — dies sollte die Entwicklertools in Ihrem Browser öffnen, wobei das Element im DOM-Inspektor hervorgehoben ist.

3. Suchen Sie nach einer Funktion, die Sie verwenden können, um dieses Element auszuwählen. Zum Beispiel hat diese Seite auf MDN aktuell ein Logo mit einer ID mdn-docs-logo.

4. Speichern Sie einen Verweis auf dieses Element in einer Variablen, zum Beispiel:

   js

   const test = document.getElementById("mdn-docs-logo");
   

5. Versuchen Sie nun, einen neuen Wert für die CSS-Eigenschaft, an der Sie interessiert sind, auf diesem Element festzulegen; dies können Sie mit der style Eigenschaft des Elements tun, versuchen Sie zum Beispiel, diese in die JavaScript-Konsole einzugeben:

   js

   test.style.transform = "rotate(90deg)";
   

Wenn Sie anfangen, den Eigenschaftsnamen nach dem zweiten Punkt zu tippen (beachten Sie, dass in JavaScript CSS-Eigenschaftsnamen in lower camel case, nicht in kebab-case geschrieben werden), sollte die JavaScript-Konsole beginnen, die Namen der Eigenschaften, die im Browser existieren und mit dem, was Sie bisher geschrieben haben, übereinstimmen, automatisch zu vervollständigen. Dies ist nützlich, um herauszufinden, welche Eigenschaften in diesem Browser implementiert sind.

Wenn Sie moderne Funktionen einbinden müssen, testen Sie die Unterstützung der Funktionen mit @supports, das Ihnen ermöglicht, native Feature Detection Tests zu implementieren, und die präfixierte oder neue Funktion in den @supports Block zu verschachteln.

Responsives Design ist die Praxis, Weblayouts zu erstellen, die sich an unterschiedliche Geräte-Formfaktoren anpassen — zum Beispiel unterschiedliche Bildschirmbreiten, Ausrichtungen (Hoch- oder Querformat) oder Auflösungen. Ein Desktop-Layout wird zum Beispiel auf einem mobilen Gerät schrecklich aussehen, daher müssen Sie ein geeignetes mobiles Layout mit media queries bereitstellen und sicherstellen, dass es korrekt mit viewport angewandt wird. Eine ausführliche Darstellung solcher Praktiken finden Sie in unserem Tutorial zum Responsiven Design.

Auch die Auflösung ist ein großes Problem — mobilgeräte benötigen beispielsweise weniger große und schwere Bilder als Desktop-Computer und haben eher langsamere Internetverbindungen, möglicherweise sogar teure Datentarife, die verschwendete Bandbreite zu einem Problem machen. Darüber hinaus können unterschiedliche Geräte eine Vielzahl von Auflösungen haben, was bedeutet, dass kleinere Bilder pixelig erscheinen könnten. Es gibt eine Reihe von Techniken, die Ihnen ermöglichen, solche Probleme zu umgehen, von media queries bis zu komplexeren responsiven Bildtechniken, einschließlich <picture> und den srcset und sizes Attributen des <img> Elements.

Es gibt viele andere Probleme, auf die Sie mit HTML und CSS stoßen werden, sodass Kenntnisse darüber, wie man online Antworten findet, von unschätzbarem Wert sind.

Zu den besten Informationsquellen gehören das Mozilla Developer Network (wo Sie sich gerade befinden!), stackoverflow.com und caniuse.com.

Um das Mozilla Developer Network (MDN) zu nutzen, führen die meisten Leute eine Suchmaschine nach der Technologie aus, über die sie Informationen suchen möchten, plus den Begriff "mdn", zum Beispiel "mdn HTML video". MDN enthält mehrere nützliche Arten von Inhalten:

• Referenzmaterial mit Browserunterstützungsinformationen für clientseitige Webtechnologien, z.B. die <video> Referenzseite.
• Weitere unterstützende Referenzmaterialien, zum Beispiel unser Leitfaden zu Medientypen und Formaten im Web,
• Nützliche Tutorials, die spezifische Probleme lösen, zum Beispiel Erstellung eines plattformübergreifenden Videoplayers.

caniuse.com bietet Unterstützungsinformationen zusammen mit einigen nützlichen externen Ressourcenlinks. Zum Beispiel, siehe https://caniuse.com/#search=video (Sie müssen nur das Feature, nach dem Sie suchen, in das Textfeld eingeben).

stackoverflow.com (SO) ist eine Forenseite, auf der Sie Fragen stellen können und anderen Entwicklern Ihre Lösungen teilen können, vorherige Beiträge durchsuchen und anderen Entwicklern helfen können. Es wird empfohlen, zu schauen, ob es bereits eine Antwort auf Ihre Frage gibt, bevor Sie eine neue Frage stellen. Zum Beispiel haben wir nach "disabling autofocus on HTML dialog" auf SO gesucht und sehr schnell Disable showModal auto-focusing using HTML attributes gefunden.

Abgesehen davon, versuchen Sie, in Ihrer bevorzugten Suchmaschine nach einer Antwort auf Ihr Problem zu suchen. Es ist oft nützlich, nach spezifischen Fehlermeldungen zu suchen, wenn Sie welche haben — andere Entwickler werden wahrscheinlich die gleichen Probleme gehabt haben wie Sie.

Jetzt sollten Sie mit den Haupttypen von plattformübergreifenden HTML- und CSS-Problemen vertraut sein, die Sie in der Webentwicklung treffen werden, und wissen, wie Sie sie angehen können.

• Zurück
• Übersicht: Testen
• Weiter