Auf HTML setzen

• Mit der Verbreitung von KI auf Basis großer Sprachmodelle wächst neben der Oberfläche für Menschen auch der Wert von maschinenlesbarem semantischem HTML
• Die Walled Gardens großer sozialer Medien verhindern Datenportabilität und Interoperabilität; auch dezentrale Ansätze wie Fediverse, Threads und Bluesky bieten normalen Nutzern oft zu wenig Anreiz
• Modernes HTML bringt mit <details>, <dialog> und verschiedenen <input>-Typen bereits viele grundlegende UI-Elemente mit, die Web-Apps benötigen
• Wer Browser-Standardstyles und den Reader Mode nutzt, kann die Abhängigkeit von übermäßigem CSS und JavaScript reduzieren; korrekte Tags verbessern die Maschinenlesbarkeit und die mobile Eingabeerfahrung
• In einer Entwicklung, in der RSS weiterhin lebt und ChatGPT-ähnliche Interfaces als Form des Datenzugriffs aufkommen, kann strukturiertes HTML eine praktikablere Grundlage sein als werbezentrierte Interfaces

---

HTML als grundlegendes Dateninterface des Webs

• Das Aufkommen von KI auf Basis großer Sprachmodelle rückt die Bedeutung von semantischem HTML wieder stärker in den Vordergrund
• Im Kern geht es im Internet darum, Daten bereitzustellen, die Menschen für die Interaktion mit der Welt brauchen; die Freiheit von HTML/CSS/JavaScript hat aber auch eine Kehrseite, weil sie den Datenzugriff einschränken kann
• Soziale Medien großer Tech-Unternehmen binden Nutzer in geschlossene Plattformen, statt auf offene, zugängliche Datenformate und APIs zu setzen
  • Interoperabilität zwischen Plattformen wird dadurch praktisch schwierig
  • Weil Unternehmen eine einfache Datenportabilität meiden, wird das Problem noch komplexer
• Die jüngste Instabilität sozialer Medien hat das Interesse an dezentralen Plattformen wie dem Fediverse wieder wachsen lassen
  • Metas Threads und das von Jack Dorsey gegründete Bluesky stellen Interoperabilität mit dem größeren Fediverse in Aussicht
  • Normale Nutzer entscheiden sich jedoch oft nicht allein aus solchen Gründen für ein neues soziales Netzwerk
• Es lohnt sich, HTML als bereits bewährte Lösung erneut zu betrachten
  • Früher musste man viel CSS einsetzen, damit HTML-Inhalte im Browser nicht schlecht aussahen
  • Heute wurden viele moderne HTML-Elemente ergänzt, die den Großteil der für moderne Webanwendungen nötigen UI-Elemente bereitstellen
  • Der Reader Mode kann die in Styling investierte Zeit aushebeln; das lässt sich auch positiv sehen
• Korrekte Tags stellen ein maschinenfreundliches Format bereit
  • Das ist ein stärkerer Grund für den Einsatz modernen HTMLs als nur eingesparte Designzeit
  • RSS lebt weiterhin
  • Interfaces wie ChatGPT könnten künftig eine Art sein, wie Menschen auf Daten zugreifen

Nützliche oder neu zu betrachtende HTML-Elemente

• Ein Blick auf die vollständige Liste der HTML-Elemente bei MDN lohnt sich
  • Die folgenden Beispiele verwenden nur die Standardstyles des Browsers, ohne zusätzliches Styling
  • Je nach Browser können sie deutlich anders aussehen oder gar nicht unterstützt werden
• <abbr>: Element zum Auszeichnen von Abkürzungen
  • Kann per Styling hervorgehoben werden
  • Vor allem für die Maschinenlesbarkeit nützlich
• <datalist>: Element, das eine Liste von Eingabevorschlägen bereitstellt
  • Damit lässt sich eine UI bauen, die wie Typeahead wirkt
  • Eine eingebaute Validierung scheint es nicht zu geben
  • In Safari müssen option-Tags geschlossen werden; ohne schließendes Tag funktioniert es nicht
• <details>: auf- und zuklappbares Offenlegungselement
  • Kann als kleines Dropdown verwendet werden
  • Lässt sich auch stark stylen
• <dialog>: Dialogelement
  • Ein eingebautes Element, das sich mit Buttons, Formularen, Attributen und JavaScript öffnen und schließen lässt
  • Es ist nicht exakt dasselbe wie ein Modal, eignet sich aber als Grundlage, wenn man ein Modal bauen will
  • Es scheint über den folgenden Elementen gerendert zu werden
• <i> und <em>
  • Es lohnt sich, den Unterschied zwischen beiden Elementen zu kennen
• <iframe>
  • Wurde in die Beispielliste aufgenommen, aber eher scherzhaft behandelt
• <input>: Formulareingabeelement
  • Für Eingaben sollten passende Labels und Typen verwendet werden
  • Auf Mobilgeräten ist die Angabe des Eingabetyps wichtig, weil das Betriebssystem je nach Kontext unterschiedliche Tastaturen öffnet
  • Die Vielfalt zeitbezogener Eingaben kann separate JavaScript-Date-Picker reduzieren
  • Als Beispiele werden Eingaben für color, range und datetime-local genannt
• <mark>: Element zum Hervorheben von Text
  • In Safari wird es standardmäßig als gelbe Hervorhebung angezeigt
• <meter>: Element zur Anzeige eines Messwerts
  • In Safari wird es je nach gesetzten Parametern rot, gelb oder grün angezeigt
  • Ein optimum-Wert kann gesetzt werden
  • Könnte für eine Demo zur Musikvisualisierung mit 60 fps nützlich sein
• <progress>: Element zur Anzeige von Fortschritt
  • Eine native HTML-Fortschrittsleiste, die einen festen Wert oder einen unbestimmten Zustand haben kann
  • In Safari erscheint sie blau, wenn das Fenster aktiv ist, und grau, wenn es inaktiv ist
  • Standardmäßig folgt sie der System-Akzentfarbe und kann über die CSS-Eigenschaft accent-color gesetzt werden

[GN⁺]

Hacker-News-Kommentare

• Dass HTML die Lösung für Lock-in in geschlossenen Ökosystemen sein soll, ist seltsam. Solche geschlossenen Dienste verwenden bereits HTML und nutzen auch einige der erwähnten semantischen Elemente sowie ausgefeiltere semantische ARIA-Attribute.
  Auch die Behauptung, Interfaces wie ChatGPT seien die Zukunft des menschlichen Datenzugriffs, übersieht: Der Kern von KI-Systemen ist gerade, dass sie keine speziellen „maschinenlesbaren“ Annotationen brauchen, um Eingaben zu verarbeiten. ChatGPT und nachfolgende Modelle können normale Websites wie Menschen durchsuchen und erkennen auch ohne explizites Markup, dass eine Gruppe von Absätzen eine „Liste“ ist.
  Was der Autor beschreibt, ist letztlich eher eine API über semantische HTML-Elemente. Wenn es aber eine API gibt, braucht man für automatisierten Datenzugriff kein großes Sprachmodell; ein gewöhnliches Python-Skript mit Beautiful Soup reicht aus und hat zudem den Vorteil, nur lokal zu laufen.

  • Das wirkt mir zu stark verkürzt. Es gibt „HTML“, und es gibt Websites, deren endgültiges DOM erst feststeht, nachdem der Nutzer 10 Sekunden lang versucht hat, sie zu lesen. Zwischen diesen Extremen gibt es große Unterschiede darin, wie viele Browser-Funktionen man nutzen muss.
    Am Ende trennt Implementierungskomplexität das Gute vom Schlechten. Jedes Werkzeug kann gut oder schlecht eingesetzt werden, und ein Anfänger kann mit einer Kreissäge und geladenem Akku großen Schaden anrichten. Ein Handwerker kann sich auch entscheiden, das Werkzeug gar nicht zu benutzen und stattdessen daneben zu klopfen – also gegen die geschäftlichen Anforderungen zu handeln.
    Die Websites, die ich in letzter Zeit gebaut habe, sind die kompatibelsten, die ich je erstellt habe. Ich nutze keine WebSockets mehr und verlasse mich nicht darauf, dass JavaScript stückchenweise mit dem Server spricht. Selbst wenn man JavaScript komplett deaktiviert, kann man etwa 80 % des Produkts nutzen. Ich verstehe nicht, wie solche Engineering-Entscheidungen keine Lösung gegen Lock-in in geschlossenen Ökosystemen sein sollen.
  • „ChatGPT und nachfolgende Modelle können normale Websites wie Menschen durchsuchen“ klingt für mich eher nach einer Behauptung, die noch nicht wahr ist. Wenn man annimmt, dass es geht, ist es allerdings interessant.
    Große Sprachmodelle werden auf Text, Quellcode usw. trainiert, aber ohne etwas, das man als Inferenzgerät bezeichnen könnte, frage ich mich, ob sie beim Blick auf einen DOM-Baum wirklich erkennen können, was er ist und was er tut. Das DOM ist kein Text, und wegen Bundling und Komponentenisierung ist es auch schwer als gut strukturierter Quellcode zu sehen. Es klingt fast so, als würde man sagen: „Ein großes Sprachmodell kann sich eine beliebige .exe ansehen und sie sofort integrieren.“
  • Ich habe den Punkt des Artikels eher so verstanden: Statt – oder zusätzlich zu – reinen JavaScript-div-Haufen sollte man maschinenlesbare semantische Inhalte über HTTP verwenden. So können automatische Agenten wie die neue Welle großer Sprachmodelle wichtige Details leichter extrahieren, ohne einen Headless-Browser zu starten und die Seite zu rendern.
    Ich habe ein ähnliches Interesse, allerdings mit Blick auf Crawling und neue Suchmaschinen. Wenn jede Seite erst in einem Headless-Browser ausgeführt werden muss, bevor sie indexiert werden kann, wird die Einstiegshürde für neue Suchmaschinen deutlich höher.
  • Ein berechtigter Punkt. Ironischerweise scheint der Hauptvorteil von semantischem Markup inzwischen eine Abstraktion zu sein, die es menschlichen Entwicklern leichter macht, Styling und Steuerung umzusetzen.
  • Kann ChatGPT das wirklich? Macht es das tatsächlich?

• Der erste Satz des Artikels lautet: „Mit dem Aufkommen von KI auf Basis großer Sprachmodelle ist semantisches HTML wichtiger denn je geworden.“ Ich halte dagegen die Formulierung „Mit dem Aufkommen von KI auf Basis großer Sprachmodelle ist semantisches HTML weniger wichtig denn je geworden“ für deutlich besser vertretbar.
  Das Semantic Web ist gescheitert, und an seine Stelle trat Google, das enorme Summen in allerlei Heuristiken mit damals führender KI investierte. Je besser KI wird, desto besser kann sie Informationen auch aus beliebig zusammengewürfeltem Mischmasch extrahieren; und wenn dieses Mischmasch ausreicht, werden Menschen auch nur so viel Aufwand betreiben. Im Prinzip werden am Ende sowohl das Semantic Web als auch Heuristik-Haufen durch KI ersetzt.
  Wichtig ist auch, dass anfangs LLM geschrieben wird und danach auf den allgemeinen Begriff KI gewechselt wird. Große Sprachmodelle sind nicht die gesamte künstliche Intelligenz, sondern nur ein aktuell heißer Zweig – und nicht der letzte heiße Zweig. Es ist keine gute Idee, Prognosen für die kommenden Jahrzehnte auf der Annahme aufzubauen, große Sprachmodelle seien die endgültige Antwort der KI.

  • Glaubst du, KI wird auch Web Accessibility auf Basis von semantischem HTML und ARIA lösen? Wenn nicht, braucht es weiterhin Menschen, um sicherzustellen, dass Webinhalte zugänglich sind; und in diesem Fall bleibt semantisches HTML wichtig.
  • Ich frage mich, wie Suchmaschinenoptimierung nach großen Sprachmodellen aussehen wird.
    Wenn das Ziel darin bestand, dass relevante Teile von Inhalten gut genug indexiert werden, um im Ranking aufzutauchen, dann gab es wohl zu wenig Anreiz, semantisches HTML vollständig zu übernehmen.
    Wenn sich das Ziel von „im Ranking auftauchen“ zu „große Sprachmodelle sollen möglichst viel Nuance und Textur aus den Inhalten extrahieren“ verschiebt, könnte der Anreiz steigen, bestimmte Elemente besser zu nutzen. Websites, die das tun, könnten größeren Einfluss auf die Ausgaben großer Sprachmodelle haben.
    Es fühlt sich an wie der Unterschied zwischen laut genug sprechen, um gehört zu werden, und klar genug sprechen, um verstanden zu werden.
  • Stützen schema.org und Wikidata/Wikipedia nicht immer noch den Großteil von Googles Rich Results?
    Ich habe gehört, dass eine neue Ergebnisseite mit Bard angekündigt wurde, aber ich glaube, ich habe sie noch nicht gesehen – vielleicht wegen meiner Gewohnheit, Werbung zu ignorieren, oder weil sie in meiner Region noch nicht verfügbar ist. Ich sollte das nachsehen.
  • KI fühlt sich wie Magie an. Ich dachte immer, die Mustererkennung des Menschen sei ziemlich einzigartig und schwer zu replizieren. Man nutzt sie, wenn man sich durch den Mischmasch einer Website arbeitet und irgendwie Daten extrahiert.
    Im Kopf war ich eher im Lager des Semantic Web, aber wenn Maschinen dieses Mischmasch halbwegs verstehen können, stimmt die Frage schon: Warum sich die Mühe machen?
  • Projekte, die Datenressourcen erstellen und KI dazu bringen wollen, diese Ressourcen zu nutzen, verfehlen den Kern. Die KI selbst ist die Datenressource.
    Es gibt auch Projekte, die behaupten, Wissensgraphen oder andere Datenbestände könnten KI dabei helfen, „wahres“ Wissen abzurufen. Persönlich halte ich es für besser, Methoden zu entwickeln, mit denen KI ihre eigenen Datenbestände erstellen kann. Die Gewichte neuronaler Netze sind ebenfalls ein solcher Bestand.
    Das Wahrheitsproblem bleibt sehr schwierig. Wie kann man einer KI mitteilen, dass bestimmtes Wissen vertrauenswürdiger ist als anderes? Natürlich haben Menschen dasselbe Problem.

• Von den meisten dieser HTML-Elemente hatte ich kaum je gehört, und das ist ziemlich schade. Denn solche Dinge könnten erheblich dazu beitragen, das Ökosystem zu beenden, in dem „alles JavaScript braucht“
  Zumindest könnten sie JavaScript wieder näher an den Platz zurückbringen, für den es ursprünglich gedacht war: als Mittel, um etwas Dekoration oder Interaktion hinzuzufügen. Es muss kein Ersatz für sämtliches Markup und kein kompletter DOM-Manager sein
  Der Browser, von dem ich träume, könnte vielleicht so etwas wie visurf https://sr.ht/~sircmpwn/visurf/ sein, bei dem die interne Netsurf-Engine so aktualisiert ist, dass sie modernes HTML+CSS einschließlich dieser Elemente unterstützt. Mit so einem Browser ließe sich vermutlich ein kleines Web mit fast keinem JavaScript bauen. Die Barrierefreiheit würde besser, weil Screenreader, System-Themes, Tastenkürzel usw. weniger kaputtgemacht würden; es würde viel weniger Ressourcen verbrauchen als schwere JavaScript-Apparate, die sich ersetzen lassen; und das meiste, was man heute von mittelgroßen Web-Apps erwartet, scheint ebenfalls möglich. Für Dinge wie WebGL kann man Firefox starten, aber zum Beispiel könnte auch ein Matrix-Client mit Websockets und Ende-zu-Ende-Verschlüsselung auskommen, wenn nur ein wenig JavaScript dazukommt

  • Das allgemeine Problem mit solchen eingebauten Komponenten ist, dass Theming schwierig ist. Wenn mitten in einer modernen App plötzlich Komponenten im Windows-7-Stil auftauchen, ist das extrem störend
    Erweiterbarkeit gibt es auch kaum; sobald man etwas auch nur ein wenig Komplexes machen muss, wirft man es am Ende weg und fängt wieder mit JavaScript an. Dann ist es besser, gleich mit JavaScript zu beginnen: Das funktioniert gut, gibt einem volle Kontrolle und verhält sich auf allen Systemen gleich
    Am Ende bleiben solche zusätzlichen Komponenten als Bloat übrig, den alle Browser implementieren müssen, den aber niemand nutzt
  • Als ich datalist zum ersten Mal sah, dachte ich: „Wow, das ist ein Game Changer.“ Das Verhalten ist in allen Browsern gleich, aber das Aussehen ist völlig browserspezifisch und lässt sich nicht per CSS stylen
    Manchmal sieht man nur den Text der Daten, manchmal sowohl den Text als auch das value-Attribut. Dadurch wählt man nicht „Atlanta“ aus, sondern „234290780 Atlanta“, also ID und Wert zusammen
    Auch beim Klickverhalten bekommt man nicht einfach direkt die ID, sondern muss den gesamten Wert nehmen und die ID herausparsen. Es fühlt sich einfach wie ein vernachlässigtes Element an
  • Das könnte dir gefallen: http://youmightnotneedjs.com/
  • Ich bin nicht grundsätzlich gegen die Stoßrichtung, aber diese Elemente gibt es schon seit langer Zeit. Wenn Kritik an HTML ernst genommen werden soll, sollte man meiner Meinung nach die Grundlagen kennen
    Der Artikel verlinkt auf MDN, und MDN ist als kurze Referenz eine der nützlichsten Quellen. Natürlich gibt es auch die WHATWG-HTML-Spezifikation; falls die zu umfangreich ist, gibt es außerdem die SGML-DTD-Form-Grammatik für die WHATWG-HTML-Snapshots 2021 und 2023 sowie die älteren Grammatiken der HTML-5.x-Reihe
    [1]: https://sgmljs.net/docs/html200129.html
  • https://qutebrowser.org

• Ich möchte an das Semantic Web glauben und daran, dass Browser gute Basismodule und ordentliche Standard-Styles bereitstellen können, aber im Moment muss man wohl akzeptieren, dass es nicht so ist
  Schon beim Beschriften eines input muss man sich fragen, warum das kein Attribut ist, und man kann sich schwer sicher sein, ob man es als Wrapper verwenden oder als Geschwisterelement mit for=-Attribut danebenstellen soll. Das ist nur die Spitze des Eisbergs. Für jedes Tag muss man die gesamte Entwicklungsgeschichte lernen und neu recherchieren, was heute die richtige Vorgehensweise ist
  Wir hätten etwas Gutes haben können, aber inzwischen sollten wir uns wohl beruhigen und loslassen

  • Ich weiß nicht, welche Tools du verwendest, also ist das nicht auf eine bestimmte Person gemünzt, aber wenn Webentwickler nur einen Teil der Zeit, die sie in React, Tailwind usw. stecken, in das Lernen von HTML investiert hätten, wäre das Web in einem deutlich besseren Zustand
    Es gibt sicher merkwürdige Stellen und raue Kanten, aber wenn alle Webentwickler semantisches HTML möglichst gut nutzen könnten, gäbe es im Browser viel weniger JavaScript, weniger Accessibility-Bugs, und vermutlich hätten mehr Augen darauf geschaut, wenn die Spezifikation solche Merkwürdigkeiten beheben oder ersetzen müsste
  • Wenn Eingabe-Labels ein HTML-Attribut wären, wären Formulare viel weniger flexibel. Man würde zwei visuelle Elemente zu einem zusammenführen, was die Darstellung schwer anpassbar macht. Man denke etwa an ein Eingabefeld mit rechtsbündigem Label links daneben oder an eine Checkbox mit Label rechts daneben
    Ein label-Attribut würde wohl reinen Textinhalt bedeuten, was zu eingeschränkt wirkt
    HTML hat, wie man es nach Jahrzehnten der Nutzung erwarten würde, eine komplizierte Geschichte und viele Schichten. Trotzdem hat es sich in letzter Zeit nicht stark verändert, und dank MDN ist es recht einfach, genug darüber zu lernen, was mit HTML5 möglich ist, und bei Bedarf tiefer einzusteigen
  • In meinem Fall möchte ich das label-Tag fast immer hinter das input-Tag setzen. So kann man mit CSS-Pseudoklassen das Label abhängig vom Eingabestatus auswählen und stylen
  • Dass man die Bedeutung der einzelnen Tags lernen muss, ist ein wesentlicher Bestandteil jedes semantischen Tagging-Systems. Wenn dir diese Vorstellung nicht gefällt, passt das grundsätzlich nicht zur Idee des Semantic Web
    Natürlich muss man bei jedem Publishing-System, ja eigentlich bei jedem System, lernen, wie man die bereitgestellten Grundelemente effektiv verwendet. Das ist also kein Problem, das nur das Semantic Web hat

• Ich verwende details häufig zum Debuggen von Go-HTML-Templates
  Wenn ich im Entwicklungsmodus mit {{if .DevMode}} Daten hineinlege, zerstört es die Seite eingeklappt nicht groß und fällt kaum auf; wenn ich es brauche, klappe ich es auf und sehe den gesamten Inhalt

  • Wenn möglich, missbrauche ich das details-Element ein wenig. Es ist sehr sauber; ich weiß nicht, warum es nicht häufiger genutzt wird
  • Man kann es auf Webseiten für viele Zwecke verwenden, etwa für einklappbare Menüs
    Auch in GitHub Markdown funktioniert es, und manche nutzen es für Beispiele oder Inline-Erklärungen

• Die Lektüre und die interaktiven Demos waren gut
  Nachdem ich ein paar Jahre mit Flutter gearbeitet habe, bin ich wieder zum selben Schluss gekommen: Man sollte auf HTML setzen
  Die Kombination aus Astro / Tailwind / Daisy UI / Alpine.js eignet sich gut, um HTML-Sites zu bauen, die viel schlichtes Server-Side Rendering nutzen und clientseitig ein wenig Reaktivität darüberstreuen
  Das Ergebnis sind einfache, ordentliche HTML-Dateien, die in Desktop-Webbrowsern und in mobil umschlossenen WebViews gut aussehen und funktionieren. Meine App ist im Grunde statisch, wird also im CDN gecacht, funktioniert auch offline, und „Quelltext anzeigen“ macht das Debugging einfacher

  • Nachdem ich mehrere schicke Frameworks und Plattformen ausprobiert hatte, bin ich am Ende ebenfalls bei einer statischen Site mit Alpine.js und Tailwind gelandet. Das war mit Abstand die beste Entscheidung, die ich bisher getroffen habe
    Das Beste daran ist, dass ich sicher sein kann: Ein neuer Entwickler, egal ob er aus React, Angular, PHP oder Python kommt, versteht eine 100-Zeilen-Build-Datei nach etwa drei Minuten. Es ist wirklich schön, weil es so einfach ist
  • Web-Export mit Flutter halte ich für nahezu einen Albtraum. Als ich zuletzt nachgesehen habe, passierte das Rendering auf einem Canvas, und es gab überhaupt kein Markup
  • Kann mir jemand helfen, den Nutzen von Daisy UI zu verstehen? Es wirkt so, als würde man altmodische Klassen plus Stylesheets über den zusätzlichen Zwischenschritt Tailwind verwenden
  • Genau, Astro und die Islands Architecture machen wirklich Spaß beim Arbeiten

• Das Problem des Semantic Web liegt meiner Meinung nach darin, dass Entwickler sich weigern, es richtig zu verwenden, egal wie einfach es gemacht wird. Meine Browser-Erweiterung nutzt das main-Tag, deshalb habe ich besonders darauf geachtet; in der MDN-Dokumentation ist sehr klar beschrieben, was man tun soll, und die Dokumentation selbst zeigt gute Anwendungsbeispiele. Trotzdem verwenden es nur sehr wenige Sites richtig
  Selbst auf aufwendig gemachten professionellen Sites wird oft der gesamte Seiteninhalt einschließlich Navigation, Footer und Ähnlichem in das main-Tag gepackt. Dieses Tag sollte nur für den Hauptinhalt der Seite verwendet werden
  Wenn nicht einmal ein so einfaches Element korrekt genutzt wird, erwarte ich bei den anderen Elementen nicht viel

  • Das ist dieselbe Sorte Entwickler, die HTTP-Verben falsch verwendet
    Solche Dinge sollten nicht so tun, als wären sie Verträge
  • Jeder Entwickler, der ein p-Tag für einen Absatz verwendet, hat es buchstäblich richtig gemacht. Das ist etwas anderes als so etwas wie class="card"
    Ich verstehe nicht, warum so viele technisch versierte Leute so sehr über die Nutzlosigkeit des Semantic Web oder sein Scheitern klagen. Das klingt für mich, als würde man sagen: „Ich hoffe, das Auto setzt sich durch, dann wäre Reisen über lange Strecken bequemer“
  • Die erste naheliegende Lösung wäre strengere Validierung: Wenn die Struktur nicht korrekt ist, verweigert der Browser das Rendering
    Aber solche Zeiten gab es schon. Vor HTML4 war das im Großen und Ganzen so, und das war noch schlechter
    Vielleicht wäre es daher besser, wenn die Entwicklertools bei falscher Verwendung Warnungen oder Fehler ausgeben würden
  • Es gibt keinerlei Anreiz, es richtig zu machen. Ich versuche es selbst richtig zu machen, aber außer der Zeit, die ich damit verbracht habe zu entscheiden, welches Element was sein sollte, hat es überhaupt keinen Unterschied gemacht

• Interessant, dass viele Kommentare hier diesen Beitrag als Anti-JavaScript-Artikel lesen. Für mich wirken das eher wie Tools, die zusammen mit den TypeScript-zentrierten Frameworks, die wir in modernen Enterprise-App-Frontends verwenden, enorm nützlich wären. Weil es HTML-native Werkzeuge sind, verlangen sie nicht viel Drumherum
  Zum Beispiel dürfte das meter-Tag, wenn ich heute ins Büro komme, alle Lademodule ersetzen, die wir in React verwenden. Es ist nämlich viel besser als das, was wir derzeit nutzen
  Vielleicht habe ich die Leute missverstanden oder den Artikel falsch gelesen, aber selbst wenn das gesamte Frontend – wie bei großen Anwendungen heute – fast vollständig aus TypeScript besteht, ist das sehr interessant

  • Meine Hoffnung ist, dass solche Dinge riesige JavaScript-Codeklumpen ersetzen. Ich weiß, dass ein Web ohne JavaScript leider eine Illusion ist, aber zumindest kann man große Brocken entfernen und eine stärker standardisierte User Experience schaffen, die vom System geführt und geprägt werden kann
    Es entstehen neue Anwendungen, die mit viel weniger JavaScript auskommen als früher. In bestehenden Enterprise-TypeScript-Apps kann das ein In-place-Upgrade sein, aber die Hoffnung ist, dass man bei der Entwicklung neuer Apps solche Enterprise-Frameworks selbst vermeiden kann. Träumen darf man ja wohl?

• Ich will Webentwicklung nicht komplett schlechtreden, aber sie ist wirklich furchtbar. Ich habe über die Jahre alles gemacht, von rohem HTML über Skriptsprachen bis hin zu Frameworks, und die Zeit, die man für Kleinigkeiten braucht, fühlt sich wie eine enorme Verschwendung von Denkleistung an.
  Als ich im Urlaub war, wollte ich einfach nur herausfinden, wo man essen und trinken kann oder wohin man für einen Tag gehen könnte, aber die meisten Websites waren chaotisch, veraltet oder nicht aktualisiert. Es gibt immer noch viele Websites, die einmal erstellt und dann vergessen wurden. Vermutlich, weil das Budget knapp ist und man sich Updates nicht leisten kann, oder weil Updates technisch zu schwierig sind.
  Die Komplexität der Websites führt zur Lähmung. Was ein paar einfache Seiten mit Text und Bildern sein könnte, ist unnötig überentwickelt und verbrennt Unmengen an CPU-Zyklen. Gut möglich, dass dafür ein fertiges CMS verbogen wurde, das Sicherheitsupdates braucht.
  Kürzlich habe ich mir die Website eines Kinos angesehen, und selbst ein Überblick über die wenigen Filme, die in dieser Woche liefen, war fast unmöglich. Ich hatte das Gefühl, dass es in einer Tabellenkalkulation besser lesbar wäre, und als ich tatsächlich JSON aus der API heruntergeladen habe, war das besser lesbar.
  Meist ist es nur ermüdende Verpackung, wie Lippenstift auf einem Schwein. Einer der Gründe für den Erfolg von Facebook war das einfache Onboarding, ein anderer, dass das Teilen von Fotos einfach war. Bei WhatsApp und Instagram genauso. Publizieren muss einfach sein. Einfaches FTP ist zwar auch einfach, hat für normale Leute aber einen merkwürdigen Bruch im Bedienablauf. Menschen wollen Drag-and-drop, Upload, ablegen und vergessen, einfache Bearbeitung. Wer Daten konsumieren will, will am Ende nur den Kern. Nämlich die Daten.

  • Ich glaube nicht, dass Menschen, die Daten konsumieren wollen, nur die Kerndaten wollen. Der durchschnittliche HN-Leser vielleicht, aber nicht der durchschnittliche Mensch.
    Was Menschen wollen, ist eine gut gestaltete und benutzbare Webseite. Das Problem ist, dass es nicht genug effektive und talentierte User-Experience-Designer gibt und auch den Stakeholdern in Unternehmen ein brauchbares Gespür für UX fehlt.
    Deshalb ist es für durchschnittliche Nutzer besser, nur die Kerndaten zu liefern, als die halbgarer UX, die sich ein durchschnittliches Unternehmen leisten kann. Nicht, weil sie das bevorzugen, sondern weil es besser ist.
    {schlechte UX} << {Rohdaten} < {gute UX}
    Der Umweg, den WordPress gefunden hat, bestand darin, professionelle Styles und Themes zu erstellen, die Nutzer kaufen und anwenden können. Den schlechten Geschmack der Stakeholder kann es damit aber nicht beheben.
    Ich denke, Facebook war erfolgreich, weil es eine professionelle, standardisierte UX erzwungen hat. {Daten der Menschen} + {professionelle und standardisierte UX} = {Sieg}. Man kann die frühe Facebook-UX nicht mögen, aber es ist schwer zu behaupten, sie sei Amateurarbeit gewesen. Die allgemeine Wahrnehmung von MySpace oder Geocities und Ähnlichem war das Gegenteil.
  • Der Hinweis auf WhatsApp trifft den Kern. In dem afrikanischen Land, in dem ich bin, ist WhatsApp so populär, dass Mobilfunkanbieter sogar WhatsApp-Datenpakete verkaufen.
    Wenn ich so etwas wie Drahtgeflecht suche, frage ich zuerst in meinen WhatsApp-Gruppen, in Familien-, Nachbarschafts- und Schulfreundesgruppen. Meist bekomme ich ein paar Nummern und kontaktiere die Anbieter per WhatsApp, um aktuelle Informationen zu bekommen.
    Diese Anbieter können sich keine aktuelle Website leisten. WhatsApp hat sogar eine Funktion, mit der man einen Katalog ins Profil stellen kann, und zwar für kostenlose Business-Accounts.
  • Deshalb empfehle ich den meisten kleinen Gewerbetreibenden Wix. Sehen die Websites alle ähnlich aus? Ja, und das ist nicht unbedingt schlecht. Sie sind leicht zu benutzen und zu aktualisieren, und Kunden sind dankbar, wenn sie die aktuellen Informationen bekommen, die sie brauchen.
    Was ich gern sehen würde, wäre so etwas wie „Wix Widgets“: datenverbundene Widgets, bei denen man REST-Service-Aufrufe anbinden und Datenpunkte auf Widget-Anzeigen mappen kann. Das würde ziemlich helfen, die Anforderungen an interne Websites zu bedienen, die heute jedes Unternehmen hat.
    90 bis 95 % der Webseiten brauchen wirklich einfache Lösungen.
  • Es ist schon komisch, dass man ständig hört, die Webplattform sei das beste und konsistenteste plattformübergreifende GUI-System, und zugleich ist es furchtbar, darauf etwas zu bauen.
    Vielleicht frage ich mich, ob das einfach in der Natur von GUIs liegt. Vielleicht ist die Struktur so, dass man jede Anweisung einzeln geben muss, dass sie viele Zyklen verbraucht und sonst nicht plattformübergreifend funktioniert.
  • Ein Teil des Problems liegt darin, dass die Tags und Elemente in HTML-Dateien immer weiter zunehmen. Aus Dokument-Markup ist Seiten-Markup geworden, und es ist schwer zu erkennen, wo das eine endet und das andere beginnt. Auch wenn das W3C mit den Elementen article und section einen Versuch unternommen hat.
    Natürlich war roher HTML-Code vermutlich ohnehin nie dafür gedacht, von jemand anderem als Entwicklern gelesen zu werden, insofern spielt das auch eine Rolle.

• Ich war wirklich gespannt, als ich hörte, dass es reine HTML-Modals gibt, und war dann enttäuscht, als ich merkte, dass es keine Möglichkeit gibt, sie ohne JavaScript auszulösen. Mit reinem HTML kann man sie nur schließen, nicht öffnen.
  https://github.com/whatwg/html/issues/3567
  Das dialog-Element ist eine großartige Ergänzung, und ich freue mich, dass es implementiert wird, aber ein Teil der Kernfunktionalität hängt von JavaScript ab. Um ein dialog zu öffnen, muss man per JavaScript das Attribut open setzen.
  Es wäre schön, wenn es eine Möglichkeit gäbe, dass ein button- oder a-Element einen Dialog öffnet. Es gibt bereits Präzedenzfälle für in HTML eingebaute Seiteninteraktion. Links können zum Beispiel die Seite scrollen, und das details-Element kann Elemente nach einer Interaktion verbergen; daher wirkt es naheliegend, dass auch ein anderes Seitenelement ein dialog öffnen kann.

  • Wenn das hohe Ziel „nur HTML“ bedeutet, dass HTML um Scripting-Fähigkeiten erweitert werden müsste, bin ich mir nicht sicher. In so einem Fall wäre es meiner Meinung nach besser, einfach JavaScript zu verwenden.
  • Man kann ein Modal auch ohne JavaScript nur mit HTML und CSS umsetzen.
    Klick zum Beispiel oben rechts hier auf das ?: https://aavi.xyz/proj/colors/
  • Es wäre schön, wenn es direkt in HTML eingebaut wäre, aber immerhin ist das nötige JavaScript nicht kompliziert und kann auch in ein onclick-Attribut geschrieben werden.
  • Man kann es je nach aktuellem Hash ein- oder ausblenden. Natürlich braucht diese Methode CSS.