Lob und Schelte für Apples Safari-Entwickler

Apples Safari bestand als erster einen anspruchsvollen Browser-Test. Nun würden die KHTML-Entwickler die dazu notwendigen Änderungen gerne übernehmen, doch Apple mauert.

In Pocket speichern vorlesen Druckansicht 420 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Axel Kossel

Als erster Web-Browser bestand Apples Safari den anspruchsvollen Acid-2-Test auf korrekte Darstellung komplexer, aber standardkonformer Seiten. Allerdings nicht ohne Hilfe: David Hyatt, einer der Safari-Entwickler, half dem Browser mit etlichen Patches auf die Sprünge. Hyatt bietet diese Änderungen zum Download an.

Acid 2 ist ein Projekt des Web Standards Project. Er besteht aus einer Testseite, die die Möglichkeiten von HTML4, CSS1, PNG und Data URLs ausreizt. Das Web Standards Project moniert, dass die aktuellen Browser diese Seite falsch darstellen. Web-Entwickler könnten daher nützliche Techniken in der Praxis nicht einsetzen.

Hyatts Erfolg sollte also Anlass zu Freude sein. Bei KDE-Entwickler Zack Rusin sorgte er jedoch für einen zornigen Ausbruch in seinem Blog. Die Rendering Engine von Safari basiert auf KHTML, freier Software von KDE. Rusin ärgert sich nun über Nachfragen, wann die Verbesserungen an Apples Rendering Engine auch für KHTML verfügbar werden. Solange nicht jemand alles noch einmal von Grund auf nachprogrammiert, sei damit gar nicht zu rechnen, stellt Rusin frustriert fest.

Der Entwickler wirft Apple schlechte Zusammenarbeit vor. Das Unternehmen erfülle nur die allernötigsten Lizenzauflagen für die Verwendung des KHTML-Codes. Statt regelmäßig einzelne Patches zurückzuliefern, die die KHTML-Entwickler übernehmen könnten, werfe Apple regelmäßig Code-Bomben in Form einer neuen Version ab. Man habe Apple Zugriff auf das KDE-CVS gewährt, doch die KHTML-Entwickler dürften noch nicht einmal die History von Apples Versionsverwaltung einsehen, obwohl einige bereit gewesen wären, für diese Informationen eine Vertraulichkeitsvereinbarung zu unterzeichnen.

Nun ernte Apple Lorbeeren und die KHTML-Entwickler gelten als faul, ärgert sich Rusin. Dabei sei der Code in Safari so inkonsistent und Änderungen daran so verwoben, dass es ohne weitere Informationen von Apple schlicht unmöglich sei, die Änderungen in KHTML zu übernehmen. (ad)