Le module de communications

Il doit permettre au navigateur Web implanté dans l'appareil de l'utilisateur d'accéder aux ressources extérieures et doit le faire en respectant tous les standards de communication et rien que les standards.

  Le moteur de rendu

Le « moteur de rendu » produit ce que vous voyez à l'écran, une page Web, juste la page Web, indépendamment de tout le reste (tout ce qui est affiché en haut, en bas, à gauche, à droite). Il doit être possible de conserver en mémoire plusieurs pages Web déjà affichées et sur lesquelles l'utilisateur souhaite revenir rapidement, sans retourner sur le Web et sans repasser par la phase du « moteur de rendu » (gagner du temps et économiser de la bande passante). Cela se fait avec des « onglets » dont le nombre n'est, en théorie, pas limité, mais la taille de la mémoire centrale de l'appareil peut pousser certaines pages dans une mémoire externe (disque...) pour les rappeler plus tard en cas de besoin (une forme de « Swap-in - Swap-out »).

Le navigateur Web peut demander au « moteur de rendu » d'afficher certains objets graphiques qui n'appartiennent pas à la page Web, comme les ascenseurs, des barres d'outils et des menus.

Le « moteur de rendu » :

• Interprète et affiche plus ou moins bien le code HTML selon les standards du W3C (y compris les formulaires et la prise en charge de l'interaction avec l'internaute)

• En respectant plus ou moins bien les styles et formats décrits dans les feuilles de style en cascade (CSS) selon les standards du W3C

• En interprétant plus ou moins bien, et plus ou moins rapidement, les codes JavaScript (les scripts) de la page Web (il y a divers « moteurs JavaScript » (« interpréteur JavaScript ») dans les navigateurs Web dont les tests comparatifs de vitesse font l'objet de combats homériques : SpiderMonkey, TraceMonkey, JägerMonkey, IonMonkey, V8, JavaScriptCore, Chakra, Rhino, Tamarin, Carakan, Futhark, etc.

• Avec un comportement dit « à tolérance de panne » (« fault tolerant ») qui passe son temps à tenter de rendre visible et cohérente une page bourrée de fautes de syntaxe HTML et CSS, comportement hautement et admirablement abracadabrantesque (une véritable gymnastique les pieds au mur) qui fait des merveilles, mais permet aussi beaucoup de laxisme de la part des webmasteurs.

Il existe désormais (normalisation forte) très peu de « moteur de rendu » (Quantum, Webkit, Blink, Gecko, WebCore (dérivé de KHTML), Trident, EdgeHTML et c'est presque tout). Ils sont tous open source (sauf Khtml et Trident, tous deux en voie de disparition).

Les critères de choix vont donc être :

• Respect des standards du W3C

• Vitesse

Aucun souci du côté des « moteurs de rendu » en termes de sécurité et de protection ou violation de la vie privée - Les « moteurs de rendu » n'interviennent absolument pas dans ce domaine et ne communiquent pas avec l'ordinateur (sauf les routines appelant les APIs du processeur graphique et les requêtes en ressources matérielles).

ATTENTION : LE MOTEUR DE RENDU N'EST PAS LE NAVIGATEUR WEB.

Qui utilise quoi ? Quels navigateurs Web (et autres applications) utilisent Webkit ou Gecko ou Quantum ou Blink ?

• Gecko puis Quantum :
  Un des objectifs de Gecko a été, dès le départ, le strict respect des standards du Web et des recommandations du W3C. Les standards reconnus par Gecko sont notamment HTTP, HTTPS, FTP, FTPS, SSL, Unicode, JPEG, GIF, HTML, XHTML, XML, CSS, JavaScript, ECMAScript, DOM, MathML, RDF, XSLT, SVG, PNG, RSS, Atom, Ajax et XUL. Gecko est remplacé par Quantum dans Firefox (mais continue d'exister dans des dizaines de navigateurs Web dérivés de Firefox.

• Trident :
  L'un des objectifs de Microsoft, avec Trident, est de ne respecter aucun standard si ce ne sont pas des « standards » de Microsoft. À ce petit jeu, face au W3C et face à tous les autres « moteurs de rendu », Microsoft a perdu.