Keine nutzung von Pseudo Tags und HTML 5 Semantische Tags

[MB]

moin,

warum nutzt man nicht pseudo Tags wie z.B.…

<icon>
  <svg><!-- stuff --></svg>
</icon>

…und definier sie dann mit Style Sheets…

icon {
  /* stuff */
}

…anstatt mit Block Tags zu arbeiten…

<div class="icon">
  <svg><!-- stuff --></svg>
</div>

ich hab auch auf mehreren Seiten das gesehen <div class="header>...</div> anstatt ein einfaches semantisches <header>-Tag 😕. HTML 5 will doch aus diesem <div>-Tag Chaos rauskommen habe ich das gefühl.

Warum zum Henker stellt man neue Tags zu verfügung wenn man sie nicht nutzt? Ich hab keine Beispiele. ok ein Grund könnte sein, browser kompatiblität. Schön und gut aber braucht man das in allem Umfang? Von IE 1.0, Mosaic und Netscape bis zum Google Chrom Browser. Seeehr verwunderlich.

lgmb

[Felix Riesterer]

Liebe(r) MB,

<icon>
  <svg><!-- stuff --></svg>
</icon>

dafür kann man doch <i><svg/></i> nutzen. Hast Du das noch nirgends gesehen? Das i-Element existiert schon seit Urzeiten (wenn auch für etwas anderes - na und?) und wird von allen Browsern bis runter zu Netscape unterstützt. Was Netscape allerdings mit SVG macht... keine Ahnung. Wahrscheinlich nix vernünftiges.

Liebe Grüße

Felix Riesterer

[MB]

moin,

dafür kann man doch <i><svg/></i> nutzen. Hast Du das noch nirgends gesehen?

<i>-Tag (italic) ist bekanntlich Kursivschrift. Ich will keine Hacks nutzen sonder sschön semantisch strukturiert arbeiten können.

Was Netscape allerdings mit SVG macht... keine Ahnung. Wahrscheinlich nix vernünftiges.

ich hätte auch schreiben können <icon class="foobar" />. Jacke wie Hose. Es geht mir ums Prinzip 😉

lgmb

[Gunnar Bittersmann]

@@MB

<i>-Tag (italic) ist bekanntlich Kursivschrift.

Das ist falsch. Das i-Element ist bekanntlich „a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.“ [HTML]

Per Browserstylesheet werden i-Elemente kursiv gesetzt.

Und „Element“, nicht „Tag“.

S.a. Verwendung von b- und i-Elementen

Ob nun ein Icon als „a span of text in an alternate voice or mood…“ durchgeht, darf angezweifelt werden.

LLAP 🖖

[dedlfix]

Tach!

Ob nun ein Icon als „a span of text in an alternate voice or mood…“ durchgeht, darf angezweifelt werden.

Also bei mir ändert sich jedesmal der Mood, wenn solche Icons sehe, vor allem weil es wieder eins von vielen schwarzweißen ist und keine Farbe zur Unterstütung des besseren Erkennens hinzugefügt wurde.

dedlfix.

[MB]

moin,

<i>-Tag (italic) ist bekanntlich Kursivschrift.

Das ist falsch. Das i-Element ist bekanntlich „[…]“

Ich bin mir sicher ich hab mich "falsch" ausgedrückt.

Per Browserstylesheet werden i-Elemente kursiv gesetzt.

…das wollte ich sagen.

Und „Element“, nicht „Tag“.

<x-element>-Tag. So besser?

S.a. Verwendung von b- und i-Elementen

Danke für den link…

Ob nun ein Icon als „a span of text in an alternate voice or mood…“ durchgeht, darf angezweifelt werden.

…Danke für deine Meinung

lgmb

[Auge]

Hallo

Und „Element“, nicht „Tag“.

<x-element>-Tag. So besser?

Wohl eher <x-tag>-Element. Es handelt sich um das Element x-tag (welchen Wert auch immer „tag“ haben wird) mit dem Start-Tag <x-tag> und dem End-Tag </x-tag> (so denn eines vorhanden ist).

Tschö, Auge

[MB]

moin,

Wohl eher <x-tag>-Element.

…oder so

lgmb

[Matthias Apsel]

Hallo MB,

Wohl eher <x-tag>-Element.

…oder so

Zum Nachlesen: http://selfhtml.apsel-mv.de/tag-element/tag-element-attribut.html

Bis demnächst
Matthias

[MB]

moin,

Zum Nachlesen: http://selfhtml.apsel-mv.de/tag-element/tag-element-attribut.html

Wow, habe ich auch so gemacht aber mit einem Textverarbeitungs-Progrämmchen. Cool!!!

lgmb

[Auge]

Hallo

Zum Nachlesen: http://selfhtml.apsel-mv.de/tag-element/tag-element-attribut.html

Zum stöbern und rumpfriemeln immer wieder schön. Dennoch habe ich einen Verbesserungsvorschlag – zumindest einen halben. Bitte passe die Schriftfarbe der jeweiligen Hintergrundfarbe mit ausreichendem Kontrast an. Für mich ist das bei „Element“, „Tag“, „Starttag“ und „Atttributname“ nicht gegeben. Andere mögen das – im wortwörtlichen Sinne – anders sehen.

Denke dabei bitte auch an die Funktion, die farbliche Hervorhebung der Einzelpunkte zu entfernen.

Tschö, Auge

[Matthias Apsel]

Hallo Auge,

Verbesserungsvorschlag – zumindest einen halben. Bitte passe die Schriftfarbe der jeweiligen Hintergrundfarbe mit ausreichendem Kontrast an. Für mich ist das bei „Element“, „Tag“, „Starttag“ und „Atttributname“ nicht gegeben. Andere mögen das – im wortwörtlichen Sinne – anders sehen.

Das ist eine gute Idee, magst du vielleicht einen Vorschlag machen? Bild würde reichen.

Denke dabei bitte auch an die Funktion, die farbliche Hervorhebung der Einzelpunkte zu entfernen.

Das verstehe ich nicht.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Denke dabei bitte auch an die Funktion, die farbliche Hervorhebung der Einzelpunkte zu entfernen.

Das verstehe ich nicht.

Ich glaube, Auge bezieht sich auf die Möglichkeit, Hintergrundfarben im Browser entfernen zu lassen, so dass dann, falls du die Schriftfarbe auf Weiß geändert hättest, plötzlich weißer Text auf weißem Hintergrund läge und das dann als die ostfriesische Nationalflagge interpretiert würde…

Gruß
Kalk

[Auge]

Hallo

Denke dabei bitte auch an die Funktion, die farbliche Hervorhebung der Einzelpunkte zu entfernen.

Das verstehe ich nicht.

Ich glaube, Auge bezieht sich auf die Möglichkeit, Hintergrundfarben im Browser entfernen zu lassen, so dass dann, falls du die Schriftfarbe auf Weiß geändert hättest, plötzlich weißer Text auf weißem Hintergrund läge und das dann als die ostfriesische Nationalflagge interpretiert würde…

Jepp, genau das isses.

Tschö, Auge

[Gunnar Bittersmann]

@@MB

warum nutzt man nicht pseudo Tags wie z.B.…

<icon>
  <svg><!-- stuff --></svg>
</icon>

Custom elements haben ein - im Bezeichner, bspw. <x-icon>

Aber wozu brauchst du überhaupt ein Containerelement für <svg>?

ich hab auch auf mehreren Seiten das gesehen <div class="header>...</div> anstatt ein einfaches semantisches <header>-Tag 😕.

Unwissenheit der Entwickler.

LLAP 🖖

[MB]

moin,

warum nutzt man nicht pseudo Tags wie z.B.…

Custom elements haben ein - im Bezeichner, bspw. <x-icon>

Oh echt. Noch nie in dieser hinsicht gehört aber schon gesehen. Erkennt der Browser das <x-tag>? Ist das mit diesem "-" von HTML 5 vorschrift oder einfach nur eine Konvention der Entwickler ohne Relevanz und Konsequenz des Interpreters?

Aber wozu brauchst du überhaupt ein Containerelement für <svg>?

Ich hab es nur als Beispiel Angeführt siehe @@Felix Riesterer .

lgmb

[Gunnar Bittersmann]

@@MB

Erkennt der Browser das <x-tag>?

Zum Erkennen müsste man ein custom element per JavaScript bekannt machen. Sonst (in diesem Fall aber ausreichend) ist es ein unbekantes Element mit allen CSS-Eigenschaften auf ihrem Initialwert (display also auf inline).

Ist das mit diesem "-" von HTML 5 vorschrift oder einfach nur eine Konvention der Entwickler ohne Relevanz und Konsequenz des Interpreters?

valid custom element name, insb. zweite Info.

LLAP 🖖

[Auge]

Hallo

Warum zum Henker stellt man neue Tags zu verfügung wenn man sie nicht nutzt?

Falsche Frage. Die Frage lautet, warum (zum Henker) man neue Elemente (und auch Attribute) nicht nutzt, obwohl sie zur Verfügung stehen? Es gibt darauf mehrere Antworten.

1. Der Entwickler/Betreiber einer Website weiß nichts von den Entwicklungen rund um HTML, CSS und JS der letzten Jahre, weil er sich nur, als es notwendig war, ein wenig, danach aber nie wieder, damit beschäftigt hat.
2. Der Betreiber einer Website hat sich diese $irgendwann verfertigen lassen und weiß nicht, dass die Entwicklungen rund um HTML, CSS und JS der letzten Jahre eine Überarbeitung sowohl notwendig machen aus auch rechtfertigen. Ansonsten siehe 1.
3. Dem Betreiber einer Website ist diese egal, weil sie laut den Zugriffszahlen eh niemanden interessiert. Dass das (auch und oft nicht unmaßgeblich) daran liegen kann ^[1], dass die (wahrscheinlich vor Urzeiten) erstellte Website nach heutigen Maßstäben einfach nicht funktioniert und basierend auf den Entwicklungen rund um HTML, CSS und JS der letzten Jahre überarbeitet werden muss, um an den Zugriffszahlen etwas zu ändern ^[1:1], ist ihm unbekannt. Ansonsten siehe 1.
4. $irgendwelche weiteren Gründe. Und vermutlich auch hier siehe 1.

Tschö, Auge

---

1. Es gibt natürlich immer mehrere Gründe für eine schlecht laufende Website. neben technischer Unzugänglichkeit ist sehr oft auch schlechter und/oder schlecht aufbereiteter Inhalt einer der Gründe. ↩︎ ↩︎

[Matthias Scharwies]

Servus!

Warum zum Henker stellt man neue Tags zu verfügung wenn man sie nicht nutzt?

Falsche Frage. Die Frage lautet, warum (zum Henker) man neue Elemente (und auch Attribute) nicht nutzt, obwohl sie zur Verfügung stehen? Es gibt darauf mehrere Antworten.

4 $irgendwelche weiteren Gründe. Und vermutlich auch hier siehe 1.

Ich hatte jetzt grad ne Webseite in der Hand, die nur aus p und strong-Elementen bestand, also keine semantische Textauszeichnung. Da muss man mehr Elemente wie h1-hx, ul, ol und li, bzw auch address und dl verwenden.

Auf Seitenstrukturierung mit article, section, etc habe ich verzichtet - 2013 hatte ich jede Seite damit vollgepflastert. Bei längeren Seiten sind diese Elemente sinnvoll.

Allerdings hatten wir hier auch schon einmal die Debatte, ob man für Fachbegriffe /Definitionen dfn oder abbr verwendet. Weitgehender Konsens war eigentlich, dass man dafür keine eigenen Elemente benötigt.

Auch die mangelhafte Browserunterstützung von detailsund dialogzeigt, dass selbst die Brwoserhersteller nicht glauben, dass man für jeden Anwendungsfall ein eigenens Element benötigt.

Im vorliegenden Fall würde ich @Gunnar Bittersmann zustimmen und auf ein Container-Element verzichten.

#Less is more!

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

Warum zum Henker stellt man neue Tags zu verfügung wenn man sie nicht nutzt?

Falsche Frage. Die Frage lautet, warum (zum Henker) man neue Elemente (und auch Attribute) nicht nutzt, obwohl sie zur Verfügung stehen? Es gibt darauf mehrere Antworten.

Ich hatte jetzt grad ne Webseite in der Hand die nur aus p und strong-Elementen bestand, also keine semantische Textauszeichnung. Da muss man mehr Elemente wie h1-hx, ul, ol und li, bzw auch address und dl verwenden.

Auf Seitenstrukturierung mit article, section, etc habe ich verzichtet - 2013 hatte ich jede Seite damit vollgepflastert.

Naja, es ist zwar immer von der sprichwörtlichen „Div-Suppe“ die Rede, aber natürlich kann man es – Stichwort „vollpflastern“ – auch mit jedem anderen Element übertreiben.

… die mangelhafte Browserunterstützung von detailsund dialogzeigt, dass selbst die Brwoserhersteller glauben, dass man für jeden Anwendungsfall ein eigenens Element benötigt.

Die Logik verstehe ich nicht.

Im vorliegenden Fall würde ich @Gunnar Bittersmann zustimmen und auf ein Container-Element verzichten.

Den konkreten Fall der Einfassung eines Icons hatte ich nicht betrachtet. Aber ja, ein Icon braucht per se keine solche.

#Less is more!

Herzliche Grüße

Matthias Scharwies

Apropos Semantik. Direkt vor der Verabschiedung mit der Hauptüberschrift um die Ecke zu kommen … *scnr*

Tschö, Auge

[Matthias Scharwies]

Servus!

… die mangelhafte Browserunterstützung von detailsund dialogzeigt, dass selbst die Brwoserhersteller glauben, dass man für jeden Anwendungsfall ein eigenens Element benötigt.

Ich hab' dann noch ein "nicht" reinverbessert. Während bei deteils nur der Edge nicht mitspielt, verweigert sich auch Mozilla dem dialog-Element.

Herzliche Grüße

Matthias Scharwies

[Auge]

Hallo

… die mangelhafte Browserunterstützung von detailsund dialogzeigt, dass selbst die Brwoserhersteller glauben, dass man für jeden Anwendungsfall ein eigenens Element benötigt.

Ich hab' dann noch ein "nicht" reinverbessert.

Aj ja, jetzt erschließt sich mir der Satz. 😀

Während bei deteils nur der Edge nicht mitspielt …

Abseits der Semantik ist das nun aber auch kein Beinbruch. Der Inhalt wird in einem Blockelement offen angezeigt und gut ist.

… verweigert sich auch Mozilla dem dialog-Element.

Naja, es funktioniert so fast halb. Man kann dialog im Firefox seit Version 53 ja per about:config aktivieren (dom.dialog_element.enabled = true), allerdings wird das Pseudoelement dialog::backdrop nicht unterstützt. Es geht mit einigem Gefrickel (händisch eingebautes Backdrop-Element) zumindest in einer kontrollierbaren Umgebung wie einem Intranet. Allerdings sieht es für mich laut dem Mozilla-Bugtracker-Eintrag für Dialog nicht danach aus, dass die Implementierung zeitnah zuende gebracht wird ^[1]. Wünschenswert wäre es.

Tschö, Auge

---

1. Die Politik der Mozilla-Stiftung scheint mehr an fragwürdigen Features wie eigenem Nutzertracking interessiert zu sein, als an der geradlinigen Umsetzung von Web-Standards. Schade auch. ↩︎

[marctrix]

Hej Matthias,

… die mangelhafte Browserunterstützung von detailsund dialogzeigt, dass selbst die Brwoserhersteller glauben, dass man für jeden Anwendungsfall ein eigenes Element benötigt.

Mangelhaft ist für meinen Geschmack stark übertrieben angesichts der Tatsache, dass genau ein Browser Details nicht unterstützt - zumal es seit Jahren ein winziges Polyfill gibt, das den Job erledigt und die Darstellung bei fehlender Unterstützung wenig problematisch ist (alle Details sind dauerhaft sichtbar).

Außerdem wird der Edge es in der nächsten Version dank der Chrome-Rendering Engine Blink ebenfalls nativ unterstützen.

Ich hab' dann noch ein "nicht" reinverbessert. Während bei deteils nur der Edge nicht mitspielt, verweigert sich auch Mozilla dem dialog-Element.

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Hier gilt wie so oft, dass progressive enhancement die beste Herangehensweise ist, wenn man Elemente verwendet, die noch nicht von jedem UA (vollständig) unterstützt werden. In keinem Fall sollte man die unvollständige Unterstützung als Ausrede nutzen, um sie zu ignorieren. Einer muss ja anfangen, sonst bleibt man immer keine Henne ohne Ei. 😉

Marc

[Matthias Scharwies]

Servus!

Ich hab' dann noch ein "nicht" reinverbessert. Während bei deteils nur der Edge nicht mitspielt, verweigert sich auch Mozilla dem dialog-Element.

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Das hatte @Auge schon erwähnt. Problem ist aber, dass ich keine Seiten für Euch mache, die in der about:config rumhacken, sondern für Otto-Normalverbraucher.

<p role="browser-note">Diese Webseite ist optimiert für alle modernen Browser.</p>

<p>Im Firefox ändern Sie bitte in der <code>about:config</code> folgende Einstellungen:
  …
  …
</p>

Herzliche Grüße

Matthias Scharwies

[marctrix]

Hej Matthias,

Ich hab' dann noch ein "nicht" reinverbessert. Während bei deteils nur der Edge nicht mitspielt, verweigert sich auch Mozilla dem dialog-Element.

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Das hatte @Auge schon erwähnt.

Ja, habe ich später erst gesehen und mit einem Plus "belohnt". 😉

Problem ist aber, dass ich keine Seiten für Euch mache, die in der about:config rumhacken, sondern für Otto-Normalverbraucher.

Das ist ein Problem. Du hast Mozilla aber Verweigerung unterstellt. Darum habe ich entgegnet, dass ich keine Verweigerung sehe, wenn jemand offenbar schon an der Umsetzung werkelt.

Allerdings stimmt mich auch hier der spät gelesene Einwurf von Auge skeptisch, der gesagt hat, dass sich da seit langem kein Fortschritt zeigt.

Ich hoffe, das hat Gründe, die nichts mit Verweigerung zu tun haben.

Marc

[Auge]

Hallo

Allerdings stimmt mich […] der spät gelesene Einwurf von Auge skeptisch, der gesagt hat, dass sich da seit langem kein Fortschritt zeigt.

Ich hoffe, das hat Gründe, die nichts mit Verweigerung zu tun haben.

Ich hatte ja schon in meinem Posting von 11:17 Uhr den zugehörigen Bugtracker-Eintrag verlinkt. Der ist bereits 6 Jahre alt und es scheint da immer nur stoßweise etwas zu passieren. Bei „depends on“ sind noch sechs offene Tickets eingetragen. Bevor die nicht erledigt werden, bleibt die Implementierung von Dialog unfertig. Vor fünf Monaten hat ein Beteiligter ^[1] einen Kommentar hinterlassen, der den Wunsch das fertig zu bekommen, bestätigt. Das lässt Raum für Hoffnung.

Tschö, Auge

---

1. Die Art, wie er (?) sich äußert, lässt mich vermuten, dass er an der Firefox-Entwicklung beteiligt ist. ↩︎

[Matthias Scharwies]

Servus!

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Das hatte @Auge schon erwähnt.

Ja, habe ich später erst gesehen und mit einem Plus "belohnt". 😉

Problem ist aber, dass ich keine Seiten für Euch mache, die in der about:config rumhacken, sondern für Otto-Normalverbraucher.

Das ist ein Problem. Du hast Mozilla aber Verweigerung unterstellt. Darum habe ich entgegnet, dass ich keine Verweigerung sehe, wenn jemand offenbar schon an der Umsetzung werkelt.

Allerdings stimmt mich auch hier der spät gelesene Einwurf von Auge skeptisch, der gesagt hat, dass sich da seit langem kein Fortschritt zeigt.

Ich hoffe, das hat Gründe, die nichts mit Verweigerung zu tun haben.

Na ja, ich habe die Wiki-Artikel zu article und aside im April 2014 veröffentlicht. Die mehrteilige HTML5-Serie im Blog ist vom April 2013.

@Camping_RIDER hatte beim menu-Element mal ein ToDo reingesetzt, dass man da mal ein Live-Beispiel anfertigen sollte. Seitdem ist bei Firefox nicht mehr viel passiert.

Auch bei SVG2 (siehe Blog-Artikel "was lange währt..." vom November 2016) zeigt sich, dass die Browser-Hersteller nicht immer die Guten sind.

Herzliche Grüße

Matthias Scharwies

[marctrix]

Hej Matthias,

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Das hatte @Auge schon erwähnt.

Ja, habe ich später erst gesehen und mit einem Plus "belohnt". 😉

Problem ist aber, dass ich keine Seiten für Euch mache, die in der about:config rumhacken, sondern für Otto-Normalverbraucher.

Das ist ein Problem. Du hast Mozilla aber Verweigerung unterstellt. Darum habe ich entgegnet, dass ich keine Verweigerung sehe, wenn jemand offenbar schon an der Umsetzung werkelt.

Allerdings stimmt mich auch hier der spät gelesene Einwurf von Auge skeptisch, der gesagt hat, dass sich da seit langem kein Fortschritt zeigt.

Ich hoffe, das hat Gründe, die nichts mit Verweigerung zu tun haben.

Na ja, ich habe die Wiki-Artikel zu article und aside im April 2014 veröffentlicht. Die mehrteilige HTML5-Serie im Blog ist vom April 2013.

@Camping_RIDER hatte beim menu-Element mal ein ToDo reingesetzt, dass man da mal ein Live-Beispiel anfertigen sollte. Seitdem ist bei Firefox nicht mehr viel passiert.

Auch bei SVG2 (siehe Blog-Artikel "was lange währt..." vom November 2016) zeigt sich, dass die Browser-Hersteller nicht immer die Guten sind.

Noch mal: ich bezog mich hier (ist wichtig, das zu sagen, weil ich mich manchmal allgemeiner äußere) konkret auf den Fall dialog und den Vorwurf der Verweigerung.

Generell gebe ich dir Recht. HTML outline ist übrigens praktisch als tot anzusehen. Finde ich persönlich schade, weil es gerade in Modulen einfacher ist, jede in einer section zu kapseln und die dann mit einer h1 zu beginnen. Aber jammern hilft nichts.

XHTML2 ist ja letztendlich auch wegen den Browser-Herstellern nicht gekommen. Ich will neimanden von seiner Schuld freisprechen schon gar nicht generell oder gleich für die ganze Zukunft.

Wobei Schuld auch eine Unterstellung ist, so lange man keinen Einblick in die Interna hat…

Marc

[Auge]

Hallo

Ich hab' dann noch ein "nicht" reinverbessert. Während bei deteils nur der Edge nicht mitspielt, verweigert sich auch Mozilla dem dialog-Element.

Das ist nicht korrekt. Sie arbeiten dran und wer will kann sich die Unterstützung bereits seit einer Weile freischalten.

Das hatte @Auge schon erwähnt. Problem ist aber, dass ich keine Seiten für Euch mache, die in der about:config rumhacken, sondern für Otto-Normalverbraucher.

Natürlich nicht. Deshalb habe ich ja von der (aktuell einzigen) Möglichkeit des Einsatzes in einer kontrollierten Umgebung geschrieben. Ich hoffe, dass Mozilla trotz meiner geäußerten Zweifel baldmöglichst zu Potte kommt.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

1. Der Entwickler/Betreiber einer Website weiß nichts von den Entwicklungen rund um HTML, CSS und JS der letzten Jahre, weil er sich nur, als es notwendig war, ein wenig, danach aber nie wieder, damit beschäftigt hat.

Vermutlich häufiger anzutreffender Fall: Der Entwickler/Betreiber einer Website weiß um die Entwicklungen rund um JS der letzten Jahre; aber nichts von den Entwicklungen rund um HTML und CSS.

LLAP 🖖

[marctrix]

Hej Gunnar,

Vermutlich häufiger anzutreffender Fall: Der Entwickler/Betreiber einer Website weiß um die Entwicklungen rund JS der letzten Jahre; aber nichts von den Entwicklungen rund um HTML und CSS.

Wenn man nur einen Hammer hat, sieht jede h1 aus, wie ein div, dem man per JS eine Rolle hinzufügen kann - wenn man mal nichts anderes mehr zu tun hat… - und dazu kommt es irgendwie einfach nie 😉

Marc