- Servo erhielt im Juli 2023 eine NLnet-Förderung, um zentrale Layout-Funktionen als leichtgewichtige, leistungsstarke Alternative für das Einbetten von Web-Technologien in Anwendungen zu stärken
- Der Verbesserungsumfang konzentriert sich auf die Vervollständigung von CSS floats, erweiterte Mehrsprachen-Unterstützung im Inline-Layout und die Ergänzung erster
<table>-Unterstützung - An CSS floats wird seit Mitte 2023 gearbeitet; Ziel ist es, die durchschnittliche Bestehensquote der zugehörigen WPT-Tests auf über 80 % zu erhöhen
- Dem Inline-Layout fehlen Funktionen, die für das Rendering nichtlateinischer Schriften nötig sind, darunter Font-Auswahl, von rechts nach links geschriebene Schriften und Unterstützung für logische Eigenschaften
- Da die fehlende table-Unterstützung in der neuen Layout-Engine die Darstellung vieler Webseiten beeinträchtigt, wird zunächst das Rendering von Wikipedia-Tabellen als praktisches Ziel verfolgt
Servo-Bereiche, die mit der NLnet-Förderung verbessert werden
- Servo erhielt im Juli 2023 eine NLnet-Förderung, um mehrere Layout-bezogene Funktionen zu verbessern
- Die Hauptziele lassen sich in drei Punkte zusammenfassen
- Vervollständigung der float-Unterstützung in Servo
- Unterstützung weiterer Sprachen im Inline-Layout
- Ergänzung erster
<table>-Unterstützung
Ziele und Fortschritt nach Layout-Funktion
-
Floats
- Servos float-Unterstützung ist seit Mitte 2023 in Arbeit
- Für eine vollständig CSS-float-konforme Implementierung bleiben noch Probleme zu lösen
- Ziel ist eine durchschnittliche WPT-Bestehensquote von über 80 % in
/css/CSS2/floats/und/css/CSS2/floats-clear/ - Die Ergebnisse sind im WPT dashboard nachverfolgbar
- In der vergangenen Woche überschritten die Tests unter
/css/CSS2/floats/mit einer Bestehensquote von 82,2 % das Ziel /css/CSS2/floats-clear/liegt derzeit bei 73,3 % und nähert sich dem Ziel
-
Mehr Sprachen im Inline-Layout
- Der Layout-Engine von Servo fehlen zentrale Funktionen, die für das Rendering von Sprachen ohne lateinisches Alphabet erforderlich sind
- Zu den auszubauenden Bereichen gehören die korrekte Font-Auswahl, Unterstützung für von rechts nach links geschriebene Schriften und logische Eigenschaften
- Ziel ist es, den Unterstützungsumfang des Inline-Layouts zu erweitern, damit Servo vielfältigere Inhalte darstellen kann
-
Erste
<table>-Unterstützung- HTML-Tabellen sind eine wichtige und weit verbreitete Web-Funktion
- Servos neue Layout-Engine unterstützt tables noch nicht, weshalb Layouts vieler Webseiten nicht korrekt dargestellt werden
- Das vorrangige Ziel der ersten table-Unterstützung ist es, auf Wikipedia verwendete Tabellen rendern zu können
- Sobald die einzelnen Meilensteine voranschreiten und erreicht werden, sollen sie in späteren Blogbeiträgen ausführlicher behandelt werden
1 Kommentare
Hacker-News-Kommentare
Ich setze große Hoffnungen in Servo und kann kaum glauben, dass Mozilla kein Interesse daran hatte.
Die Idee eines Engines mit hoher Sicherheit und Performance ist schon gut, aber besonders gefällt mir, dass man eine Web-Engine als Komponente verwenden kann.
Zu Zeiten von Windows 9x hatte der IE ActiveX-Controls, sodass man die Web-Engine überall einbetten konnte, und bei KHTML war es ähnlich. Heute scheinen weder Firefox noch Chrome an solchen Einsatzzwecken interessiert zu sein.
Zum Glück gibt es Qt WebEngine, aber meines Wissens ist das Verhältnis etwas angespannt, weil sich die Chrome-Seite nicht um solche Use Cases kümmert.
Außerdem ist Chrome ein Google-Produkt, und meiner Erfahrung nach leben Google-Produkte in ihrer eigenen Welt, wodurch Build und Integration mühsam sind.
Deshalb hoffe ich sehr auf eine praktikable Alternative, die man in den Code einbinden kann, die Sicherheitsbedenken ausräumt und zugleich die Integrationsschmerzen reduziert.
Mozilla hat es als Forschungsprojekt finanziert und wohl eher erkannt, dass es viel mehr Geld und Zeit kosten würde, es vollständig marktreif zu machen, und sich dann entschieden, Kosten zu sparen.
Allerdings gibt es das Problem, dass dieses Geld auf eine Weise an Führungskräfte und andere verteilt wurde, die nicht zu der von Mozilla vertretenen Moral passte.
Den Blogposts zufolge hat Mozilla Dinge aus Servo in Firefox integriert, die sich übernehmen ließen, und damit gewissermaßen einen gewissen Wert aus dem Projekt gezogen.
Ich denke, wenn jemand Mozilla viel Geld und einen unbegrenzten Zeitplan gegeben hätte, hätten sie Servo fertiggestellt.
Doch sobald CEF populär wurde, investierte Google viele Ressourcen darin, Google-Logins in CEF und anderen eingebetteten Browsern zu blockieren[0].
Deshalb musste ich einen CEF-basierten Browser aufgeben; solche Geschäftspraktiken finde ich verabscheuungswürdig, aber ich konnte nichts dagegen tun.
Wenn mein Browser sich nicht bei Google-Produkten anmelden kann, wird er sich kaum breit durchsetzen, und ich habe auch keine Zeit, mit Googles Erkennung ein Katz-und-Maus-Spiel zu spielen.
Damit eingebettete Browser-Komponenten so verbreitet werden, dass jeder einen Browser bauen kann, muss zuerst das Problem angegangen werden, dass große Unternehmen populär gewordene eingebettete Browser blockieren.
Idealerweise gäbe es ein einbettbares Gecko, das nicht Android ist, denn Firefox ist zu groß, um blockiert zu werden.
Früher wurde darüber schon viel gesprochen, und ich habe auch einen Proof of Concept gebaut, der sich ein Window-Handle schnappt[1], aber damit lässt sich kein Geld verdienen.
0 - https://developers.googleblog.com/2016/08/modernizing-oauth-...
1 - https://github.com/cretz/ffembedpoc
Ich weiß nicht, was damit gemeint ist, aber sie haben mehrere Komponenten, darunter WebRender und Stylo, in Gecko übernommen.
Ich erinnere mich, dass, wenn der Desktop-Hintergrund fehlschlug, auf dem Desktop eine ActiveX-Fehlerseite mit anklickbaren Links angezeigt wurde; das war wirklich verwirrend.
Unter macOS und Linux funktioniert es sehr gut.
Trotzdem brauchen wir mehr einbettbare Web-Engines.
Gecko ist gut, aber dass es dauerhaft wie fest mit XULRunner verbunden ist, bremst es aus.
Es ist schön zu sehen, dass die Arbeit an Servo weitergeht, seit Igalia sie übernommen hat.
Durch die jahrelange Minimalwartung hat sich viel technische Schuld angesammelt, aber es scheint echte Fortschritte zu geben.
Persönlich würde ich mir wünschen, dass Modularität stark vorangetrieben wird.
Ich glaube, es gibt eine Nische für eine Open-Source-Browser-Engine mit Fokus auf Einbettbarkeit, und eine „Bau dir deinen eigenen Browser“-Bibliothek, mit der Menschen wie mit Lego-Steinen neue Engines zusammenstecken können, könnte auch der langfristigen Gesundheit der Webplattform sehr helfen.
Ein Electron mit eingebettetem Servo oder etwas Electron-Ähnliches könnte ein gutes Ergebnis sein.
Tauri füllt diese Nische bereits teilweise, verwendet aber eher das, was das Betriebssystem bereitstellt, statt etwas einzubetten.
Eine Option irgendwo dazwischen wäre schön.
Sciter [1] zum Beispiel hat nur eine sinnvolle Teilmenge der DOM-API implementiert und war dennoch einigermaßen erfolgreich.
Für normales Surfen im Internet passt es nicht gut, aber wenn man es als UI-Bibliothek nutzt, kann man die Teile meiden, die nicht funktionieren.
1: https://sciter.com/
Das Komponentenmodell und die Einbettungsschicht sind genau so strukturiert.
Die Mittel für diesen Zuschuss stammen teilweise von der European Commission und werden über das NGI-Programm bereitgestellt.
Wirklich gute Nachrichten für Servo.
Die NLNet Foundation unterstützt in letzter Zeit viele hervorragende Projekte, und ihr Name taucht häufig auf.
Wir brauchten Unterstützung, um einige Probleme voranzutreiben, und genau das ist passiert.
Dass wir hauptsächlich in Nordamerika sitzen, die Finanzierung aber aus der EU kommt, ist eine sehr vorausschauende Form der Unterstützung.
Als ein weiterer Browser, der von Grund auf neu gebaut wird, ist auch Ladybird sehenswert
Entsteht durch eine eher bunt zusammengewürfelte Indie-Gruppe: https://ladybird.dev/
Ehrlich gesagt ein wirklich ziemlich kompromissloses Projekt
Wenn man bedenkt, dass das Projekt noch sehr jung ist, ist es bereits ziemlich beeindruckend
Schon anhand von Screenshots wirkt Servos Renderer sehr rudimentär, langsam und voller Bugs
Es ist schnell, und weil alles öffentlich entwickelt wird, ist sehr beeindruckend, was das Ladybird-Team leistet
Irgendwie dachte ich, Servo sei bereits in Firefox integriert
Gibt es eine Möglichkeit, in Rust HTML zu einem Bild zu rendern, ohne einen ganzen Browser zu starten?
Es muss nicht viel HTML oder CSS unterstützen
https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
Vermutlich gibt es auch noch anderes
Allerdings gibt es zwei Unterschiede: Es unterstützt nur Markdown statt beliebigem HTML und rendert auf den Bildschirm statt in ein Bild
Trotzdem ein guter Ausgangspunkt
Das größte Hindernis für Web-Rendering in Rust ist meiner Ansicht nach derzeit ein besseres Text-Layout, insbesondere die Unterstützung dafür, nicht-textuelle Inhalte wie bei
display: inline-blockin Text einzubettenWenn das implementiert ist, sollte sich grundlegendes Rendering von Webseiten ziemlich ordentlich umsetzen lassen
Das sind jeweils ein GPU-basierter Compositor und eine CSS-Engine
Servo ist eine in Rust geschriebene Web-Rendering-Engine, unterstützt WebGL und WebGPU und lässt sich für Desktop-, Mobile- und Embedded-Anwendungen anpassen
Es ist eine einbettbare und eigenständige Web-Rendering-Engine mit Speichersicherheit, Modularität und Parallelität
Was ist das als Vergleich herangezogene Legacy Layout?
Eine frühere Iteration von Servo?
Ein Teil des Codes scheint in beiden weiterhin genutzt zu werden, und die Kurven steigen und fallen gelegentlich gleichzeitig, aber nicht immer
Später wurde mit Layout 2020 ein zweites System begonnen, um Probleme zu lösen, bei denen die Implementierung bestimmter Teile der CSS-Spezifikation nicht sauber in die Architektur von Layout 2013 passte
Im Servo-Wiki gibt es aus diesem Jahr einen guten Bericht von den Leuten bei Igalia, der die Unterschiede zwischen den beiden Systemen zusammenfasst und erklärt, warum man beschlossen hat, in Richtung Layout 2020 weiterzugehen
https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...