|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
|
Nach kurzem Studium des Artikels und der Hintergründe kann ich mal folgendes zusammentragen:
- Das betreffende Feature ist optional. Der Parser muss es nicht unterstützen, um als standardkonform zu gelten.
- Die Implementation dieses Features ist aufwändig, und verlangsamt die (ohnehin schon langsame) XSLT-Engine zusätzlich.
- Bei einer Transformation von XML in anderes XML ist dieses Feature unnötig.
- Bei der Transformation von XML in nicht-XML kann dieses Feature notwendig sein.
Zu Punkt 4 zitiere ich von der W3C Homepage:
This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents.
Und damit ist der Fall für mich abgeschlossen.
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 07. March 2006, 20:09 MEW (#2)
|
|
|
|
|
Sicherlich nicht relevant für die Engine in Mozilla, aber nur weil die im W3C nicht wussten, dass man XSLT auch woanders einsetzen kann, ist dein Punkt 4 nicht etwas, was man einfach so per Schlußregel ignorieren sollte: ich bastel Makefiles mittels XSLT - ohne "disable-output-escaping" (fast) unmöglich.
Zurück zum Thema: Die seuchenartige WONTFIX-Attitüde bei Mozilla ist Mist. Betrifft ja inzwischen so einiges. Und ständig wird mit der "reinen Lehre" argumentiert (beim Referrer-"Bug" hat man jedoch irgendwann einen Rückzieher gemacht ...) Die Mozilla-Leute scheitern (möglicherweise?) immer wieder daran, dass sie den Entwicklern von Websites nichts zutrauen. Aber selbst wenn dieses Mißtrauen berechtigt ist, plädiere ich für mehr Freheit+Eigenverantwortung. Denn WONTFIX führt dazu, dass niemand mehr den Mozilla (samt Derivaten) benutzen wird. In diesem Sinne ist es definitiv besser, strittige Features einfach zu implementieren, sofern der Mozilla dadurch kompatibler zu anderen Browsern wird. Von mir aus auch konfiggerbar per "hidden option".
Sonst wird es wirklich nichts mit der (FF-)Weltherrschaft.
|
|
|
|
|
|
|
|
|
|
|
|
|
" In diesem Sinne ist es definitiv besser, strittige Features einfach zu implementieren, sofern der Mozilla dadurch kompatibler zu anderen Browsern wird."
Ich bin auch fuer schwerfaellige Monster mit Verhaltensstoerungen. Fuer die Weltherrschaft geht's nicht anders.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 08. March 2006, 14:40 MEW (#6)
|
|
|
|
|
Wenn die Firefox Weltherrschaft auf kosten von Standardkonformität geht, dann bin ich gerne bereit dieses Risiko einzugehen. Allerdings denke ich nicht, dass diese Entscheidung merklichnen Einfluss auf den Marktanteil von Firefox haben wird. Die meisten Benutzer welche vom IE zu Firefox wechseln tun dies eher, weil der Firefox von der Presse als "viel sicherer" angepriesen wird, und nicht weil er jede erdenkliche und mit noch so vielen Fehlern behaftete Seite darstellt.
|
|
|
|
|
|
|
|
|
|
|
|
|
Auch wenn ein Feature optional ist, finde ich, wenn es standardisiert ist, sollte es implementiert werden, es sei denn es ist wirklich unmöglich und schafft enorme Probleme...
Ich habe mir nicht die gesamte Diskussion durchgelesen, aber irgendwie wirkt es für mich etwas so, als dass es einem am Anfang einfach zu viel Aufwand für ein nicht sonderlich wichtiges Feature schien, und man jetz irgendwie nicht die Kraft zusammenbringt zu sagen: "Ok, stimmt wir sollten das impementieren, ihr habt ja recht", als man auch sah, dass die User das wollen...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unmöglich zu implementieren wärs nicht, aber es würde tatsächlich enorme Probleme bereiten.
Die Idee hinter client side XSLT ist, dass man dem Browser ein valides XML und ein valides XSLT gibt, und dieser daraus ein valides XHTML erzeugt, das er rendern kann. Ausserhalb des Browser gibt es aber natürlich noch andere Anwendungen, und theoretisch ist es auch möglich, nicht-XML zu erzeugen. Dies ist eigentlich gar nicht im Sinne von XSLT, aber trotzdem wurde beschlossen es zu ermöglichen. Zu diesem Zweck wurde ein optionales Feature eingeführt, das Escaping abzuschalten, und so die Regeln von XML/XSLT gezielt zu brechen. Es wird aber auch ausdrücklich davor gewarnt, dieses Feature dort aufzunehmen, wo es keinen Sinn macht.
Macht es also in einem Browser Sinn? Nicht wirklich. Ausser der Faulheit von Webprogrammierern, die unsauberes XML irgendwie durchmogeln wollen, gibt es keinen Grund, dieses Feature zu implementieren. Könnte das Feature schaden? Ja, könnte es: Das Feature ermöglicht es, Code ungeparst an der XSLT Engine vorbei zu schmuggeln, so dass er 1:1 in das zu rendernde Resultat übernommen wird. Damit haben wir nicht nur ein potentielle Quelle für schwer nachvollziehbare Fehler, sondern auch ein potentielles Sicherheitsloch. Denn der primäre Einsatzzweck einer sochlen Technik ist es, fremden (X)HTML Code ungeprüft und unbearbeitet in die eigene Webseite einfliessen zu lassen.
Frage: Wer sind die primären Nutzer von Firefox?
Antwort: Die Webseitenbetrachter.
Frage: Wollen diese Nutzer ein Feature, dass ihnen nichst bringt, möglicherweise aber schadet?
Antwort: Ganz sicher nicht.
Ergo wurde wurde der Bugreport abgelehnt (er steht jetzt auf VERIFIED WONTFIX), und zwar aus rein pragmatischen Gründen: Warum viel Zeit und Arbeit in ein Feature investieren, dass völlig unnötig ist, und von den primären Nutzern gar nicht gewünscht wird?
--
GPL ist der Versuch, den Ring gegen Sauron einzusetzen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Hört sich korrekt an.
Ich kann mir keinen Einsatzzweck vorstellen, wo ich einem Browser per XSLT nicht-XML Daten geben wollen würde.
|
|
|
|
|
|
|
|
|
|
|
|
|
Einverstanden. Bis auf:
Der Browser muss den generierten XHTML-Code trotzdem nochmals checken.
|
|
|
|
|
|
