Servo améliore ses fonctionnalités de mise en page grâce à une subvention de la fondation NLnet

 (servo.org)
1 points par GN⁺ 2023-11-11 | 1 commentaires | Partager sur WhatsApp
  • En juillet 2023, Servo a reçu une subvention de NLnet afin de renforcer des fonctionnalités clés de mise en page, en tant qu’alternative légère et performante pour intégrer les technologies web dans des applications
  • Les améliorations se concentrent sur la finalisation de la prise en charge de CSS float, l’élargissement du support multilingue dans la mise en page inline, et l’ajout d’un support initial de <table>
  • Le travail sur CSS float se poursuit depuis la mi-2023, avec pour objectif de porter le taux moyen de réussite aux tests WPT associés à plus de 80 %
  • La mise en page inline manque encore de prise en charge pour la sélection de polices nécessaire au rendu des caractères non latins, des écritures de droite à gauche et des propriétés logiques
  • L’absence de prise en charge des tables dans le nouveau moteur de mise en page casse l’affichage de nombreuses pages web, si bien que le rendu des tables de Wikipedia est devenu un objectif pratique prioritaire

Domaines de Servo renforcés grâce à la subvention NLnet

  • En juillet 2023, Servo a reçu une subvention de NLnet pour améliorer plusieurs fonctionnalités liées à la mise en page
  • Les principaux objectifs se résument en trois points
    • finaliser la prise en charge des floats dans Servo
    • prendre en charge davantage de langues dans la mise en page inline
    • ajouter un support initial de <table>

Objectifs et état d’avancement par fonctionnalité de mise en page

  • Floats

    • La prise en charge des floats dans Servo est en cours depuis la mi-2023
    • Il reste encore des problèmes à résoudre avant de pouvoir considérer l’implémentation comme pleinement conforme à CSS float
    • L’objectif est de dépasser en moyenne 80 % de réussite aux tests WPT pour /css/CSS2/floats/ et /css/CSS2/floats-clear/
    • Les résultats peuvent être suivis sur le tableau de bord WPT
    • La semaine dernière, les tests /css/CSS2/floats/ ont dépassé l’objectif avec un taux de réussite de 82,2 %
    • /css/CSS2/floats-clear/ affiche actuellement un taux de réussite de 73,3 % et se rapproche de l’objectif

  • More languages in inline layout

    • Le moteur de mise en page de Servo ne dispose pas encore de certaines fonctionnalités essentielles au rendu des langues qui n’utilisent pas l’alphabet latin
    • Les améliorations visées incluent la sélection correcte des polices, la prise en charge des écritures de droite à gauche et des propriétés logiques
    • L’objectif est d’élargir le périmètre de prise en charge de la mise en page inline afin que Servo puisse afficher une plus grande diversité de contenus

  • Initial <table> support

    • Les tables HTML sont une fonctionnalité web importante et largement utilisée
    • Le nouveau moteur de mise en page de Servo ne prend pas encore en charge les tables, ce qui empêche l’affichage correct de la mise en page de nombreuses pages web
    • L’objectif prioritaire de ce support initial des tables est de pouvoir rendre les tables utilisées sur Wikipedia
    • À mesure que chaque jalon avancera et sera atteint, des articles de blog ultérieurs en détailleront davantage le contenu

À lire aussi

1 commentaires

 
GN⁺ 2023-11-11
Avis de Hacker News

  • J’ai de très grandes attentes pour Servo, et j’ai du mal à croire que Mozilla ne s’y soit pas intéressé
    L’idée d’un moteur excellent en sécurité et en performances est déjà séduisante, mais ce qui me plaît surtout, c’est de pouvoir utiliser un moteur web comme composant
    À l’époque de Windows 9x, IE avait des contrôles ActiveX qui permettaient d’embarquer un moteur web partout, et KHTML faisait quelque chose de similaire ; aujourd’hui, Firefox comme Chrome semblent ne plus s’intéresser à cet usage
    Heureusement qu’il existe Qt WebEngine, mais si j’ai bien compris, les relations sont un peu compliquées parce que Chrome ne se soucie pas vraiment de ce cas d’usage
    En plus, Chrome est un produit Google, et d’après mon expérience les produits Google ont leur propre univers, ce qui les rend pénibles à compiler et à intégrer
    J’attends donc avec beaucoup d’intérêt une alternative pratique, intégrable dans du code, qui réponde aux préoccupations de sécurité tout en réduisant la douleur de l’intégration

    • Dire que « Mozilla ne s’intéressait pas à Servo » ne me semble pas exact
      Mozilla l’a financé comme projet de recherche, puis a plutôt réalisé qu’il faudrait beaucoup plus d’argent et de temps pour en faire un vrai produit commercialisable, et a décidé de réduire les coûts
      Le problème, c’est qu’ils ont ensuite réparti cet argent entre des dirigeants et autres d’une manière qui ne correspondait pas vraiment à la moralité qu’ils mettaient en avant
      D’après les billets de blog, Mozilla a intégré dans Firefox ce qu’il pouvait récupérer de Servo, et a donc tiré une certaine valeur du projet
      Je pense que si quelqu’un avait donné à Mozilla beaucoup d’argent et un calendrier illimité, ils auraient terminé Servo
    • J’ai utilisé CEF, WebKit et WebView2, et parmi eux, CEF était le seul choix multiplateforme facilement intégrable
      Mais dès que CEF a gagné en popularité, Google a consacré beaucoup de ressources à bloquer la connexion Google dans CEF et d’autres navigateurs embarqués[0]
      À cause de cela, j’ai dû abandonner mon navigateur basé sur CEF ; ces pratiques commerciales sont détestables, mais je ne pouvais rien y faire
      Si mon navigateur ne peut pas se connecter aux produits Google, il a peu de chances d’être largement utilisé, et je n’ai pas le temps de jouer au chat et à la souris avec les méthodes de détection de Google
      Pour que les composants de navigateur embarqué deviennent assez courants pour que n’importe qui puisse créer un navigateur, il faut d’abord traiter le problème des grandes entreprises qui bloquent les navigateurs embarqués dès qu’ils deviennent populaires
      Idéalement, il faudrait un Gecko intégrable qui ne soit pas Android, parce que Firefox est trop gros pour être bloqué
      Il y a déjà eu beaucoup de discussions à ce sujet, et j’ai même fait une preuve de concept qui réutilisait de force un handle de fenêtre[1], mais ça ne rapporte pas d’argent
      0 - https://developers.googleblog.com/2016/08/modernizing-oauth-...
      1 - https://github.com/cretz/ffembedpoc
    • Mozilla s’intéressait à Servo
      Je ne sais pas ce que tu veux dire, mais ils ont transféré plusieurs composants dans Gecko, dont WebRender et Stylo
    • La mention d’ActiveX me rappelle beaucoup de choses
      Je me souviens que lorsque le fond d’écran du bureau échouait, une page d’erreur ActiveX avec des liens cliquables s’affichait sur le bureau ; c’était vraiment déroutant
    • WebKit reste très agréable à embarquer, mais le compiler sous Windows est assez sale
      Sur macOS et Linux, il fonctionne très bien
      Cela dit, il faut davantage de moteurs web intégrables
      Gecko est très bien, mais le fait qu’il soit lié de façon permanente à XULRunner comme s’ils ne faisaient qu’un le freine

  • C’est agréable de voir le travail sur Servo se poursuivre depuis qu’Igalia l’a repris
    Il y avait beaucoup de dette technique accumulée pendant des années de maintenance minimale, mais on dirait qu’il y a de vrais progrès
    Personnellement, j’aimerais qu’ils poussent fortement la modularité
    Il me semble qu’il y a une niche à combler pour un moteur de navigateur open source axé sur l’intégrabilité, et qu’une bibliothèque de « navigateur à composer soi-même », où les gens pourraient assembler des blocs comme des Lego pour créer de nouveaux moteurs, pourrait aussi beaucoup aider la santé à long terme de la plateforme web

    • Oui
      Un Electron avec Servo embarqué, ou quelque chose de similaire à Electron, pourrait donner de bons résultats
      Tauri occupe déjà en partie cette niche, mais il utilise ce que fournit le système d’exploitation plutôt que d’embarquer quelque chose
      Ce serait bien d’avoir une option à mi-chemin
    • Un moteur embarqué est aussi une voie beaucoup plus rapide vers des cas d’usage pratiques
      Par exemple, Sciter [1] a eu un certain succès alors qu’il n’implémentait qu’un sous-ensemble raisonnable de l’API DOM
      Ce n’est pas très adapté à la navigation générale sur Internet, mais utilisé comme bibliothèque d’interface, il suffit d’éviter les parties qui ne fonctionnent pas
      1: https://sciter.com/
    • Pure spéculation, mais avec l’iPhone contraint d’ouvrir les moteurs web, il pourrait apparaître des apps voulant embarquer leur propre moteur sur l’ensemble des appareils mobiles
    • C’est fortement conçu dans ce sens
      Le modèle de composants et la couche d’intégration ont cette architecture

  • Le financement de cette subvention provient en partie de la European Commission, via le programme NGI

  • C’est une excellente nouvelle pour Servo
    La NLNet Foundation soutient beaucoup de très bons projets récemment, et son nom revient souvent

    • Mon projet https://www.oilshell.org/ est lui aussi soutenu par NLnet depuis 2022, et cela nous a beaucoup aidés
      Nous avions besoin d’aide pour faire avancer quelques problèmes, et c’est effectivement ce qui s’est passé
      Nous sommes principalement basés en Amérique du Nord, tandis que le financement vient de l’UE : c’est un soutien vraiment tourné vers l’avenir

  • Parmi les autres navigateurs repartis de zéro, Ladybird vaut aussi le détour
    Il est développé par un groupe indie un peu plus hétéroclite : https://ladybird.dev/
    Franchement, c’est un projet vraiment très couillu

    • Honnêtement, j’ai encore plus d’attentes pour Ladybird que pour Servo
      Si l’on considère que le projet est encore très jeune, il est déjà assez impressionnant
      Rien qu’en prenant des captures d’écran, le moteur de rendu de Servo paraît très basique, lent et plein de bugs
    • Ladybird est étonnant
      Il est rapide et tout est développé au grand jour ; ce que fait l’équipe de Ladybird est très impressionnant
    • Ladybird est-il réellement utilisable en dehors de Serenity OS ?
    • Pourquoi a-t-on besoin d’un autre moteur de navigateur écrit en C++ ?

  • Pour une raison quelconque, je pensais que Servo avait déjà été intégré à Firefox
    Existe-t-il un moyen, en Rust, de rendre du HTML en image sans lancer un navigateur complet ?
    Pas besoin de prendre en charge beaucoup de HTML ou de CSS

    • Stylo, le système de styles CSS, a commencé dans Servo et se trouve maintenant dans Firefox, mais d’après ce que je comprends, les deux ont pas mal divergé
      https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
    • WebRender et Stylo viennent de Servo et ont été intégrés sous les noms Quantum Render et Quantum CSS
      Il y en a peut-être d’autres aussi
    • Ce qui s’en rapproche le plus aujourd’hui est probablement https://github.com/trimental/inlyne
      Mais il y a deux différences : il ne prend en charge que Markdown, pas du HTML arbitraire, et il rend à l’écran, pas dans une image
      Cela dit, c’est un bon point de départ
      À mon avis, le principal obstacle au rendu web en Rust aujourd’hui est une meilleure mise en page du texte, en particulier la prise en charge de contenu non textuel au sein du texte, comme avec display: inline-block
      Une fois cela implémenté, le rendu de pages web basiques devrait pouvoir devenir plutôt correct
    • Ce ne sont pas des moteurs complets, mais WebRender et Stylo sont dans Firefox depuis quelques années
      Ce sont respectivement un compositeur basé sur le GPU et un moteur CSS

  • Servo est un moteur de rendu web écrit en Rust qui prend en charge WebGL et WebGPU, et peut être adapté aux applications desktop, mobiles et embarquées
    C’est un moteur de rendu web intégrable et indépendant, avec sûreté mémoire, modularité et parallélisme

  • Qu’est-ce que le Legacy Layout utilisé comme point de comparaison ?
    Une itération précédente de Servo ?
    Une partie du code semble encore utilisée des deux côtés, et les courbes montent et descendent parfois en même temps, mais pas toujours

    • Legacy Layout désigne le système d’origine, Layout 2013
      Par la suite, un second système, Layout 2020, a été lancé pour résoudre les problèmes rencontrés lors de l’implémentation de certaines parties des spécifications CSS qui ne s’intégraient pas proprement dans l’architecture de Layout 2013
      Il y a cette année sur le wiki de Servo un bon rapport rédigé par des gens d’Igalia, qui résume les différences entre les deux systèmes et pourquoi il a été décidé d’aller vers Layout 2020
      https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...