Über das Forken des Webs

 (dillo-browser.org)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Ziel einer alternativen Spezifikation ist nicht das gesamte Web, sondern vorrangig die HTML-Spezifikation, deren entpackte Größe am 6. Mai 2026 18,3 MiB beträgt, und dabei die Vorteile des Webs zu bewahren und seine Nachteile zu vermeiden
  • Die Spezifikation sollte kurz und einfach sein und die Implementierungslast senken, damit verschiedene Browser und Clients entstehen können, etwa indem ein komprimiertes tar.gz mit der vollständigen Spezifikation auf 1,44 MiB begrenzt wird
  • Statt eines sich ständig ändernden Dokuments wie der aktuellen Web specification sollte sie eine semantische Version wie 1.2.3 haben, und veröffentlichte Standardversionen dürfen niemals geändert werden
  • Die Spezifikation sollte eine leicht parsbare eindeutige formale Grammatik enthalten, und Seiten, die den Standard nicht einhalten, sollten nicht gerendert werden, um die Kosten für Parser und Content-Tools zu senken
  • Die alternative Spezifikation zielt nicht auf eine funktionsweise Replik des Webs, sondern auf Informationsaustausch rund um verfassten Text und bevorzugt statt Scripting das Öffnen standardisierter Dateien und URLs in nativen Programmen, etwa wie bei Geo-Links oder dem Standard für tiled web maps

Ziele einer alternativen Web-Spezifikation

  • Die HTML-Spezifikation hat zum 6. Mai 2026 eine entpackte Größe von 18,3 MiB; der erste Prüfgegenstand ist daher nicht das gesamte Web, sondern die HTML-Spezifikation
  • Ziel ist es, eine alternative Spezifikation zu schaffen, die möglichst viele Vorteile des Webs erhält und seine Nachteile vermeidet
  • Es handelt sich noch nicht um eine formale Spezifikation, sondern eher um informelle Notizen, die sich mit der Zeit ändern können

Einfachheit und Vielfalt bei Implementierungen

  • Die gesamte Spezifikation sollte kurz und einfach sein, sodass sich mit geringem Aufwand verschiedene Browser und Clients entwickeln lassen
  • Da es sehr schwierig ist, über Jahrzehnte hinweg Einfachheit zu bewahren, könnte eine Regel, die die Länge der Spezifikation in Byte begrenzt, ein möglicher Ansatz sein
  • Dillo verwendet denselben Ansatz, um Releases auf eine einzelne Diskette zu begrenzen; auch für die alternative Spezifikation könnte für das komprimierte tar.gz mit der vollständigen Spezifikation eine Grenze von 1,44 MiB gelten

Semantische Versionsverwaltung

  • Die aktuelle Web specification ist eine Seite, die sich ungefähr wöchentlich ändert; Clients müssen daher laufend Änderungen nachverfolgen, um der Spezifikation zu entsprechen
  • Die alternative Spezifikation sollte eine genaue semantische Version wie 1.2.3 besitzen
  • Für die Kompatibilität braucht es Kriterien wie: Ein 1.2.3-Dokument kann in Browsern korrekt gerendert werden, die 1.2.3, 1.2.0 oder 1.3.0 unterstützen, aber nicht in Browsern, die nur 1.1.0 oder 2.0.0 unterstützen
  • Ziel der Dokumenterstellung sollte nicht der Implementierungsstand einzelner Browser sein, sondern eine Standardversion; man könnte also etwa unter der Annahme schreiben, dass 90 % der Browser den Standard 1.2.0 unterstützen
  • Eine einmal veröffentlichte Standardversion darf niemals geändert werden
    • Tippfehlerkorrekturen werden über eine erhöhte Patch-Version behandelt
    • Neue abwärtskompatible Funktionen werden über eine erhöhte Minor-Version behandelt
    • Inkompatible Änderungen erfordern eine erhöhte Major-Version
  • Schon allein mit einer Druckfassung des Standards 1.2.0 sollte man in einer isolierten Umgebung einen vollständig konformen Browser bauen können, und dieser Browser müsste dauerhaft in der Lage sein, 1.2.X-Dokumente korrekt zu parsen

Strenge Grammatik

  • Die Spezifikation sollte eine leicht parsbare eindeutige formale Grammatik enthalten
  • Seiten sollten gegen den Standard getestet und auf Konformität geprüft werden; nicht konforme Seiten sollten nicht gerendert werden
  • Es sollte Clients ausdrücklich verboten sein, Seiten zu akzeptieren, die der Spezifikation nicht entsprechen
  • Dadurch entfällt die Notwendigkeit, komplexe standardisierte Regeln zur Korrektur defekter Seiten zu implementieren, und Fehler in der Spezifikation würden dazu zwingen, sie in späteren Versionen zu korrigieren
  • Eine strenge Grammatik könnte dazu führen, dass Menschen leichter zu einfacher zu schreibenden und toleranteren Sprachen wie Markdown wechseln; genau das ist beabsichtigt
  • Ziel ist es, Parser zu vereinfachen und die Kosten für Werkzeuge zur Bearbeitung von Inhalten zu senken
  • Änderungen an Patch-Versionen betreffen nur den Wortlaut; die Grammatik bleibt unverändert

Möglichkeit zur Wiederverwendung von HTML

  • Wünschenswert wäre es, eine Teilmenge von HTML zu schaffen, die mit minimalem Aufwand in bestehender Software funktioniert
  • Aufgrund der Komplexität des HTML-Parsings könnte das jedoch unmöglich sein
  • Da auch die Erstellung einer formalen Grammatik für XML-Dokumente nicht trivial ist, muss geprüft werden, ob HTML/XML überhaupt für einfaches Parsen geeignet ist

Widerstand gegen die Vereinnahmung von Standards

  • Eines der Probleme des Webs ist, dass Akteure mit Monopolmacht, sobald sie Mechanismen zur Gewinnabschöpfung schaffen können, einen Anreiz haben, Standards zu vereinnahmen und zu ihren Gunsten zu verändern
  • Im Web hat das nach dieser Sichtweise dazu geführt, dass die Komplexität der Standards unkontrollierbar gewachsen ist, die Einstiegshürden für neue Browser gestiegen sind und der Wettbewerb abgenommen hat
  • Es gibt erste Ideen, wie sich eine solche Situation verhindern ließe, doch aus spieltheoretischer Sicht ist eine deutlich sorgfältigere Prüfung nötig

Text-zuerst-Prinzip

  • Ziel der Spezifikation ist es, die Details abzudecken, die ausreichen, damit Menschen Informationen wie in gedruckten Büchern oder Texten austauschen können
  • Verfasster Text sollte als vielseitigstes Medium zur Kodierung von Informationen bevorzugt werden
  • Text kann übersetzt, von Computern vorgelesen und platzsparend gespeichert werden
  • Dokumente sollten entsprechend der Bildschirmgröße umbrochen werden, sodass dasselbe Dokument sowohl auf kleinen als auch auf großen Bildschirmen lesbar ist

Ausschluss von Scripting

  • Das Hinzufügen von Scripting-Funktionen war ein Fehler und kann in einer alternativen Spezifikation vermieden werden
  • Das bedeutet jedoch nicht, dass Nutzer daran gehindert werden, interaktive Programme zu verwenden
  • Derzeit wird beispielsweise eine interaktive Karte im Browser per JavaScript geladen, um Standorte von Points of Interest zu zeigen; stattdessen könnte ein Geo-Link bereitgestellt werden, der den Ort in jedem Client öffnen kann, der dieses Protokoll unterstützt
  • Ebenso könnte bei Vorliegen einer offenen Spezifikation jeder Client die Kartenkacheln eines Servers nutzen; als Beispiel wird der Standard für tiled web maps genannt
  • Das Öffnen standardisierter Dateien oder URLs in nativen Programmen kann für das jeweils verwendete Gerät optimiert werden und den uniformen Ansatz vieler interaktiver Webseiten vermeiden

Was nicht das Ziel ist

  • Ziel ist nicht, das Web Funktion für Funktion zu replizieren
  • Ziel ist es, eine Spezifikation zu schaffen, mit der Menschen Wissen, Notizen und andere Informationen austauschen können, ohne dafür zum Lesen eine vollständige VM ausführen zu müssen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Lobste.rs-Kommentare

  • Heißt das also wieder, dass wir für alles Apps brauchen? Ich stimme nicht zu, dass die Skript-Funktionalität selbst ein Fehler war.
    Ich halte es für gut, dass das Web eine universelle Plattform über Betriebssystemgrenzen hinweg ist.

    • Sehe ich genauso. Es heißt zwar, ein Vorteil standardisierter Dateien oder URLs, die man mit nativen Programmen öffnet, sei die gerätespezifische Optimierung und dass man den „eine Lösung für alle“-Ansatz von Webseiten vermeidet, aber ich möchte nicht in die Zeit zurück, in der Linux-Nutzer Bürger zweiter Klasse waren.
      In die Zeit also, als nur Windows unterstützt wurde und manchmal noch Mac dazukam.
    • Man kann sich viel über Web-Apps beschweren, aber sie sind auch fast die einzige Möglichkeit, bei der Verteilung von Apps auf mobilen Plattformen die Apple-Steuer und die künftige Google-Steuer zu vermeiden.
      Und weil auch die Lage der nativen Desktop-Entwicklung nicht einfach ist, kann ich gut nachvollziehen, warum sich Leute auf dem Desktop für Web-Apps oder Electron entscheiden.
    • Warum sollte man für alles eine App brauchen? Diese Spezifikation verhindert doch nicht, dass normale Webbrowser laufen, und das heutige Web verschwindet auch nicht.
    • Der eigentliche Knackpunkt ist meiner Meinung nach, herauszufinden, wie weit man allein mit standardisiertem Markup kommt.
      Das Problem des modernen Webs ist, dass es Konzepte endlos neu erfindet, und vieles davon sollte deklaratives Markup sein. JavaScript sollte sich nicht in den Rendering-Pfad von Websites drängen müssen. Scripting sollte für bestimmte clientseitige Programmierung genutzt werden, bei der man Dinge auf dem Client erledigt, die früher auf dem Server liefen, zum Beispiel einen vom Server zurückgegebenen Datensatz weiterverarbeiten.
    • Tatsächlich gibt es schon für alles eine App. Nur nennt man sie statt App URL oder Domainname.
      Es fühlt sich so an, als hätte die IT-Branche den Webbrowser als faktische virtuelle Maschine durchgedrückt, als klar wurde, dass Sandbox-Alternativen wie Java und Swing oder Flash schmerzhaft unterlegen waren. Inzwischen dient die einzelne Anwendung Google Chrome als virtuelle Maschine für den Großteil des allgemeinen Computings der Nutzer, und sie gehört einem Monopolisten des Überwachungskapitalismus und wird von ihm entwickelt. Ob das wirklich sicherer ist oder ob echte Zero-Days einfach nur zu teuer geworden sind, um publik zu werden, weiß ich nicht.
      Ich halte das Hinzufügen von Skripting für einen Fehler. Zumindest war es eine spätere Ergänzung, und ich stimme Dillo zu, wenn es den Umfang eines Hypertext-Dokumentenlesers auf das Lesen von Dokumenten beschränkt und nicht auch noch das Schreiben und Bearbeiten innerhalb des Lesers ermöglichen will.
      Das Ziel ist nicht, das Web funktional zu duplizieren, sondern eine Spezifikation zu schaffen, die man lesen kann, ohne zum Austausch von Wissen, Notizen und Informationen eine vollwertige virtuelle Maschine laufen lassen zu müssen.
      Ich würde gern eine abgespeckte universelle Anwendung sehen, die die meisten Anforderungen an „Interaktivität“ in einer besseren Sandbox abdeckt. Braucht man wirklich eine komplette virtuelle Maschine, um Hypertext in einem Social-Media-Feed wie Reddit auszutauschen? Oder um Einkaufswagen und Zahlungsinformationen zu verarbeiten?
      Allerdings besteht eine hohe Wahrscheinlichkeit, dass „universell“ am Ende doch wieder „Anwendungen“ verschlingt und man an genau diesem Punkt das Web neu erfindet. Trotzdem wäre es vielleicht besser, wenn es eine Chance auf eine Basis gäbe, die nicht von Google stammt und nicht auf C++ aufbaut. Dillo scheint in C und C++ geschrieben zu sein, also wäre zumindest eine der beiden Hürden schon etwas besser.

  • Was man zusätzlich verbessern könnte, wäre eine abgespeckte Version von HTTP, die Cookies nur als vom Client kontrollierte Session-Cookies unterstützt, Drittanbieter-Ressourcen verbietet und verlangt, dass alle Ressourcen auf demselben Webserver wie das Dokument liegen, sowie eingebaute Browser-Konverter für Formate wie text/markdown.

    • Schon ein Verbot von Drittanbieter-Ressourcen würde viele gravierende Probleme verhindern.
    • Im Idealfall würde ich es transportunabhängig machen wollen. Wahrscheinlich würde ich zuerst lokal anfangen, damit es auch an jedem Mountpunkt eines entfernten Dateisystems funktioniert.
      Diesmal wäre der Ansatz, erst einmal die „Diät“ zu verbessern und zu sehen, ob man dadurch Cookies vermeiden kann. Das hier ist eine maschinenlesbare Darstellung von Dokumenten, zwar so entworfen, dass Menschen sie lesen können, aber nicht dafür, dass Menschen sie direkt schreiben. Stattdessen sollte man lieber eine Frontend-Sprache wie Markdown verwenden und diese in portable, strikte Dokumente kompilieren.
    • Mein Vorschlag wäre: Wenn Cookies unbedingt nötig sind, dann nur für genau diese Site-Domain. Ein Cookie von example.net sollte nicht an sub.example.net gesendet werden, und sub.example.net sollte auch keine Cookies für example.net setzen dürfen.
      HTTP/2 und HTTP/3 sollte man dem Anwendungs-Web überlassen und HTTP/1 dem Dokumenten-Web. Wie man JavaScript einschränken müsste, um das Problem „Du brauchst einen Spezialbrowser, um meinen Inhalt zu sehen“ zu vermeiden, weiß ich nicht, also sollte es besser gar kein JavaScript geben.
      Wenn man text/markdown-Rendering verlangt, stellt sich außerdem die Frage, welche Version gemeint ist. Es gibt ungefähr ein halbes Dutzend Varianten, die man unterstützen müsste.

  • Eine strikte Grammatik wird wahrscheinlich nicht gut funktionieren. Daran ist XHTML gescheitert, und deshalb hat HTML5 Regeln hinzugefügt, um häufig kaputte Eingaben zu behandeln.
    Man könnte HTML5, wie es der Autor will, zwar mit einer formelleren Grammatik neu spezifizieren, aber Seiten strikt abzulehnen, scheint keine gute Nutzung eines Forks zu sein. Die andere Alternative wäre, noch ein weiterer Gopher-/Gemini-Ersatz zu werden, und dass solche Dinge trotz enthusiastischer Fans nicht populär werden, hat seinen Grund. Die Macht der Abwärtskompatibilität ist einfach zu groß.

    • Ich stimme nicht zu, dass XHTML wegen seiner Strenge gescheitert ist. Es lag daran, dass IE XHTML bis 2011 nicht unterstützt hat — viel zu spät — und die Leute deshalb kein echtes XHTML verwendet haben und seine Vorteile nicht nutzen konnten.
      Strenge kann sehr gut sein, aber sie funktioniert nur mit Unterstützung.

  • Die Vorstellung „Das Hinzufügen von Skripting war ein Fehler“ ist zwar ein altes Meme unter depressiven Programmierer-Typen, die keinen Spaß zulassen, aber ich halte das eher für mangelnde Vorstellungskraft.
    Sorgfältig eingesetzte interaktive Multimedia können Kommunikation und Erklärung massiv verbessern. Man muss sich nur die interaktiven Diagramme im Red Blob Games Hex-Grid tutorial oder Bartosz Ciechanowskis fantastische Erklärung eines mechanischen Uhrwerks ansehen. Dank interaktiver Medien im Web kann man sogar historisch wichtige seltene Computer wie den Canon Cat nach wenigen Sekunden per Linkklick ausprobieren, ohne den Albtraum zu durchlaufen, einen nativen Emulator zu kompilieren und auszuführen. Formulareinsendung und Image-Maps sind nur ein sehr blasser Schatten von Multimedia und verlagern die Last interaktiver Unterstützung auf ein im Kern serverzentriertes und potenziell bandbreitenintensives Modell.
    Das Problem ist nicht das Skripting selbst, sondern was Skripte in heutigen Browsern tun dürfen. So wie man HTTP und HTML auf ein kleineres, einfacheres und die Nutzerautonomie respektierendes System reduzieren kann, könnte man auch den Großteil der positiven Seiten von Web-JavaScript erhalten und gleichzeitig die API-Oberfläche und das Missbrauchspotenzial massiv verkleinern. Man könnte sich zum Beispiel ein Web vorstellen, in dem es auf der Seite ein interaktives Rechteck wie Flash gibt und diese Interaktivität über für den Nutzer zugängliche und inspizierbare Lua-Skripte mit Grafik- und Eingabefunktionen wie Love2D bereitgestellt wird, während datenschutzverletzende Dinge wie der Kontakt zu entfernten Servern oder der Zugriff auf die Webcam hinter einer starken Sandbox und einer ausdrücklichen vorherigen Zustimmung des Nutzers liegen.
    Solch respektvolle Web-Anwendungen kann man auch heute bauen, aber das Fundament ist holprig und inkonsistent, mit offensichtlichen Lücken bei nützlichen Funktionen und unnötigen Risiken für Sicherheit und Privatsphäre der Nutzer an allen Ecken.
    Aus Sicht der Barrierefreiheit könnte man sich clientseitige Formulare vorstellen, die deklarative UI-Eingaben wie Buttons, Felder, Checkboxen und Slider strikt behandeln und Bilder und Markup wie auf statischen Seiten innerhalb eines <iframe> rendern, aber ohne Roundtrips zu entfernten Servern funktionieren. Viele Rechner, Tools und interaktive Visualisierungen würden in dieses Modell passen und hätten gegenüber einem backendgetriebenen Modell Vorteile bei Latenz und Nutzersicherheit.

  • Wenn es um „Text zuerst“ geht, dann muss auch CSS weg. CSS existiert größtenteils für Unternehmen, nicht für Nutzer. Das Styling sollte vom Browser kontrolliert werden, nicht von der Seite.
    Wenn Nutzer den rohen Payload einer Seite lesen wollen, sollte der Großteil davon mit den Informationen übereinstimmen, die der Browser ihnen zum Lesen anzeigt. Heute ist der lesbare Inhalt nur die Spitze des Eisbergs.
    Was „kein Scripting“ angeht, vermute ich, dass der Bedarf an Skripting, das die Darstellung beeinflusst, stark sinken könnte, wenn man Styling und aufgeblähte Seiten entfernt. Scripting, das die Darstellung nicht beeinflusst, wurde meist gegen die Interessen der Nutzer eingesetzt.

    • Das war ursprünglich der Kern der CSS-Kaskade. Es gab ein vernünftiges CSS-Subset für Bücher und wissenschaftliche Arbeiten, und es war darauf ausgelegt, mit Benutzerstilen zusammengeführt zu werden.
      Aber CSS und Layout sind viel zu komplex geworden, und Benutzerstile müssen heute entweder mit einem kompletten CSS-Reset beginnen oder für jede Seite extrem spezifisch sein.
    • Wenn man Zeitstempel in der Zeitzone des Lesers anzeigen will, geht das derzeit ohne clientseitiges Scripting nicht.
      Ich bin auf dieses Problem gestoßen, als ich persönliche Tools ohne JS auf dem Client gebaut habe, und musste feststellen, dass man entweder auf dem Server eine Einstellung „meine Zeitzone“ braucht oder ein kleines Hilfsskript hinzufügen muss.
      Wenn der Browser das Styling kontrolliert, könnte das Problem „Meine Seite ist in Browser X und Y lesbar, in Z aber nicht“ sogar noch schlimmer werden als heute.
    • Ich lebe lieber glücklich in einer Welt voller CSS, mit Farben und auffälligen Hintergründen, guten Schriftarten sowie flexbox- und grid-basierten Layouts.
      Das ist mir lieber, als nur fade Dokumente zu sehen, bei denen die Stimme des Autors auf schwarzen Text auf weißem Hintergrund heruntergewaschen wurde. CSS ist die Ausdrucksform des Autors im Web, und ich möchte es wirklich nicht loswerden. Es ist zwar komplex, aber gerade deshalb aus meiner Sicht gut, weil es mehr Einzelnen ermöglicht, auf ihren eigenen Websites interessante Dinge zu tun.
    • Stimme zu. Bevor man optionales Author-Styling verbietet, sollte man das gründlicher untersuchen.
      Ich teile auch das Gefühl, dass der Bedarf an darstellungsveränderndem Skripting sinken würde, wenn man Styles und aufgeblähte Seiten reduziert. Mit einer einfachen Grammatik könnte man vielleicht „Dokumente“ in interaktive native Programme einbetten, statt umgekehrt.

  • Wie andere schon sagen, ist Gemini ein gutes Beispiel, auf das man schauen sollte. Noch einmal: Gemini wirkt wie Performance-Kunst, aber man kann wirklich viel daraus lernen.
    Eine bemerkenswerte, zu wenig bekannte Funktion von Gemini sind abonnierbare Seiten. Innerhalb einer Seite bilden Links, deren Text mit YYYY-MM-DD beginnt, einen impliziten Feed. Das wirkt sehr eingeschränkt und dumm, ist aber meiner Meinung nach eine der beeindruckendsten Funktionen von Gemini. Spec here
    Im traditionellen HTML ist es möglich, einen Blog von Hand zu schreiben. Es ist mühsam, aber absolut machbar. Um jedoch einen RSS-/ATOM-Feed zu pflegen, braucht man fast zwangsläufig ein Tool zur Feed-Erzeugung.
    Für ein HTML der nächsten Generation, das stärker auf Inhalte ausgerichtet ist, wäre eine ähnliche Funktion gut. Vielleicht ist h-feed in microformats der richtige Weg, aber ich mag die Einfachheit abonnierbarer Seiten in Gemini wirklich sehr. Und allgegenwärtige Feeds sind etwas Gutes.
    Dass Gemini zeilenbasiert und leicht zu parsen ist, ist ein großer Vorteil, aber ich habe das Gefühl, dass es zu eingeschränkt ist und sich negativ auf die Barrierefreiheit auswirken könnte. Trotzdem wäre ein HTML-lite im Stil von Gemini wohl in Ordnung.
    Ein weiterer Vorteil eines Web-Forks wäre es, den ganzen Ballast aufzuräumen, der HTML angehängt wurde. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> ist ziemlich nervig. Wenn man mit dem Wissen von heute eine neue Version machen würde, könnte das ziemlich gut werden.
    Bei anderen Punkten bin ich weniger sicher. Grundsätzlich bin ich vollkommen für kein JS. Gleichzeitig ist eine der besten Nutzungen des Webs der universelle Zugang zu essenziellen Diensten wie Behörden und Banken. Ich bin noch nicht völlig überzeugt, dass man wirklich alles ohne JS gut benutzbar hinbekommt, aber vielleicht geht es.
    Ich möchte auch den Teil aus another comment hervorheben: „Diese Spezifikation verhindert nicht, dass normale Webbrowser laufen, und das heutige Web verschwindet auch nicht.“
    Es wäre schön, einen „Content-Webbrowser“ und einen „App-Browser“ getrennt ausführen zu können. Für viele Zwecke gibt es nicht viele Alternativen, die als App-Plattform so gut sind wie das Web, und das Web hat sich stark weiterentwickelt; Entwickler scheinen es anderen Dingen klar vorzuziehen.
    In so einer Welt würde Google Maps in meinem Content-Webbrowser nicht laufen, sondern im App-Browser geöffnet werden. Wenn ich GMail im App-Browser ausführe, würden Links in E-Mails dann im Content-Webbrowser geöffnet.
    Der Content-Webbrowser sollte idealerweise viel einfacher zu implementieren sein, was Wettbewerb und Innovation fördern würde. Schade ist nur, dass ich keinen klaren Weg sehe, wie man dahin kommen soll. Ich wäre viel glücklicher, wenn ich all meine Inhaltsnavigation mit so einem Content-Browser erledigen könnte. Die Angriffsfläche wäre viel kleiner, und ich würde mich in Sachen Sicherheit wohler fühlen. Aber offenbar kümmert das inzwischen niemanden mehr.

    • Fast alle legitimen Anwendungsfälle für JS auf Webseiten entstehen nur deshalb, weil dem Browser wichtige Funktionen fehlen. Wir haben jahrzehntelang dazugelernt, und dank Skripten mussten Browser diese Funktionen gar nicht erst einbauen.
      Also sollte man sie einfach als Browserfunktion hinzufügen.

  • Das klingt ein bisschen ähnlich wie Gemini, aber dieser Fork würde wohl etwas mehr erlauben.
    Ich denke, Websites könnten in einer Markdown-Variante oder etwas Ähnlichem geschrieben werden. Es sollten Dokumente sein, die sich auch in Rohform leicht lesen lassen. So etwas wie Gemtext mit ein wenig zusätzlicher Funktionalität wie Inline-Medien.
    Und ein bisschen Styling sollte ebenfalls erlaubt sein. Das Web war ein großartiger Ort für Kreativität und ist es immer noch. Wenn man ein einfaches und konsistentes Set an Styles beibehält, können kreative Leute noch ausgefallenere Sites bauen.

  • Es wäre auch gut, die Grundelemente von HTMX abzudecken.

    • Persönlich würde ich es begrüßen, wenn einfach nur die Rohfunktionen von Triptych eingebaut würden. Das bietet genug, um auf dem Server etwas aufzubauen, ohne den Client unnötig komplex zu machen.

  • Diese Idee würde besser funktionieren, wenn es eine klare Motivation gäbe. „Lasst es einfacher machen“ ist zu abstrakt. Menschen haben sehr unterschiedliche Vorstellungen davon, was einfach ist, deshalb braucht es explizitere Ziele dafür, warum das Web einfacher werden soll und welche konkreten Bedürfnisse es erfüllen soll.
    Das Gemini-Projekt konzentriert sich zum Beispiel darauf, eine Community aufzubauen, die eine bestimmte Form von Kommunikation schätzt. Weil das zu den Zielen dieser Community passt, wurde das Web vereinfacht, indem es auf diese Kommunikationsform beschränkt wurde; soweit ich mich erinnere, werden nicht einmal Bilder technisch unterstützt.
    Werkzeuge wie Sciter oder Blitz verfolgen dagegen ein anderes Ziel: einen browserähnlichen Renderer leichter in andere Anwendungen einzubetten. Sie vereinfachen das, indem sie unnötige Sonderfälle entfernen oder HTML-Parsing und JS-Ausführung optional machen. Dadurch gibt es weniger zu implementieren und auch weniger, das Nutzer einbetten müssen.
    Beide zielen auf Einfachheit, aber weil ihre grundlegenden Ziele sehr unterschiedlich sind, fallen auch die Ergebnisse sehr unterschiedlich aus. Was ist hier das grundlegende Ziel?