Ich frage mich warum die Mozilla-Entwickler nicht endlich mal das Soft-Hyphen () bzw. den weichen Trennstrich in Gecko implementieren. Dieses Feature wird seit Firefox 0.7 gefordert, nur bisher scheinen andere Dinge höhere Prioritäten zu genießen. Andere Browser (Opera, IE, Konqueror) werten dieses Hyphen schon seit mehreren Versionen korrekt aus. Dabei ist dieses Hyphen für Texte in Sprachen die zur Bildung längerer Wörter neigen extrem wichtig, da Texte im Blocksatz sonst sehr zerrissen ausschauen.
Dafür haben Browser wie der IE oder Konqueror andere Probleme. Stichwort CSS, da hinkte der IE lange zurück. Klar mit dem 7ner ist es besser geworden, aber deswegen entwickeln ja auch Leute daran.
Kannst ja ein Plugin schreiben, oder? soweit ich mich erinnere ist der Firefox OpenSource.
Irgendwo auch schwach, dass Firefox erst mit der 3.0 pango und cairo unterstützt, das bescheidene Rendering auch noch der 2.0.x unter Linux ist wirklich schon hinlänglich bekannt. Man kann nurmal hoffen, dass kazekahase die gtk-webcore-unterstützung bald vernünftig fertig hat
Das hat nicht mit rumtrollen zu tun. Was nicht passt wird passend gemacht. Außerdem war meine Kernaussage, das Leute dran arbeiten. Außerdem, schon mal dran gedacht das es ne "Alpha" Version ist; da kann ja noch was an Features kommen.
Wieso darf man keine Kritik üben ohne wieder mal überflüssigerweise auf die Opensource-Entwicklungsprinzipien hingewiesen zu werden? Darüber hinaus ist solch eine Kritik unabhängig davon welche anderen Browser dieses oder andere Probleme mehr oder weniger haben.
Ganz einfach: Worte-mit-Bindestrich werden bei Firefox nicht an den Strichen umgebrochen, obwohl sie das ja eigentlich dürften. Dadurch passiert es daß in schmalen Layoutboxen Text über die Box hinausragt (oder bei Tabellen die Zelle vergrössert) obwohl das gar nicht nötig wäre. Hab ich leider schon oft erlebt.
Ich finde es ebenfalls traurig, daß Firefox das nicht ändern, denn ich wüsste nicht was da so schwer dran sein soll.
Von Anonymous Coward am Di, 1. Mai 2007 um 14:28 #
Nein, ein soft hyphen ist etwas anderes. Ein soft hyphen kann man in HTML durch das Entity erzeugen. In der Regel wird ein Soft Hyphen _gar nicht_ dargestelllt. Wenn sich das Wort mit dem Soft Hyphen aber am Ende einer Zeile befindet, wird ein Bindestrich und ein Umbruch eingefügt. Ein Beispiel wäre z. B. das Wort Zeilenumbruch. Normalerweise schreibt man es zusammen, aber wenn es mit dem Ende einer Zeile koinzidiert, schreibt man sinnvollerweise Zeilen-⏎umbruch. Im Code schreibt man dann einfach Zeilenumbruch und der Browser wählt automatisch die richtige Schreibweise aus.
Neben (unbestreitbaren) Rendering-Verbesserungen sind also inzwischen möglich:
- clientseitige Speicherung von Daten durch normale Webseiten in erheblichem Umfang, *ohne* Cookies und komfortabel via JavaScript zu erreichen (für XUL-AddOns sogar mit der kompletten SQLite-Engine...)
- eine direkte JavaScript-Funktion "getLoginPwd()" für XUL-Addon-Autoren, zum Auslesen gespeicherter Formular-Passwörter. War bisher auch schon möglich, aber jetzt gibt's mit FUEL dafür eine "einfach zu benutzende" JavaScript-Funktion. Wozu auch immer... :-(
WETTEN, dass beide Dinge in Zukunft noch Ärger machen werden? (Spätestens dann, wenn ein "automatisches Update" eines populärenAdd-Ons mal heimlich allen Usern ein Osterei unterschiebt.) Extensions dürfen ja alles - so eine Art "plattformübergreifendes ActiveX" für Mozilla...
Statt Komplexität zu reduzieren, wird Mozilla immer komplexer. Wenn man sich anschaut, was alles sonst noch für die 3.0 geplant ist, fragt man sich, ob *überhaupt* jemand mal an die Sicherheit gedacht hat, *bevor* mit der Implementierung der Unmenge neuer "Convenience"-Features begonnen wurde...
IMHO sollten die Prioritäten bei der Verschlankung und Beschleunigung liegen, und definitiv nicht bei neuen Features. Das neue "Reflow"-Framework wird das Rendering wohl beschleunigen, aber der riesige XPCOM-Overhead bleibt bestehen? (Mit den vielen aus der unnötig flexiblen Architektur resultierenden Problemen bei Garbage Collection, Speicherverbrauch und Performance; so haben z.B. sogar DOM-*Attribute* teilweise eine 1:1-Umsetzung in ein separates per XPCOM gekapseltes, separat per dynamischer Speicherverwaltung verwaltetes C++-Objekt; ein einziges HTML-Element hat im Speicher bis zu mehreren *Kilobytes* an Verwaltung-Overhead!)
Werden zur 3.0 wenigstens Firefox (und später Thunderbird und Seamonkey) endlich auf XULRunner-Basis laufen können?
Imho werden plugins doch nur geupdatet wenn sie auf den mozilla servern liegen? Das heißt doch das mozilla neue plugins erst überprüft?
Deine Kritik Punkte sind imho in einem w3c standard definitiv und den standard zu erfüllen gehört genauso zu den gesetzten aufgaben von mozilla als aktuell auch die geschwindigkeit.
Zu 1.: Wenn eine Website für ein Add-On einmal als "vertrauenswürdig" deklariert ist (und das ist bei den Add-Ons auf einigen mozilla-nahen Seiten automatisch der Fall), hängt die "Sicherheit" des Add-Ons nur noch am Maintainer. (Wie bei ActiveX eben, nur dass es bei ActiveX i.d.R. keine automatischen Updates gibt, für die man bestimmte Source-Hosts komplett als "vertrauenswürdig" freigeben *muss.*) Eine inhaltliche Überprüfung von Add-Ons findet meines Wissens bei Add-On-Updates nicht statt. (Insofern meine Vermutung, dass früher oder später jemand mal "einfach so" ein Osterei oder gar einen Wurm in ein populäres Add-On einbauen wird.) (BTW: wer ist eigentlich für die sehr seltsame Umbenennung von "Erweiterungen" in "Add-Ons" verantwortlich? Im Firefox-Menü steht sogar: "Add-ons", d.h. auch noch mit einem kleinem "o" ?!)
Zu 2.: Client-seitige Speicherung ist kein W3C-Standard, sondern eine Idee der informellen WHATWG-Gruppe (http://www.whatwg.org). Und (leider) einer der weniger gut durchdachten Ideen der WHATWG (die ansonsten einige äußerst interessante experimentelle Ideen hat, deren unmittelbarer Reifegrad aber sehr kontrovers gesehen wird, wie z.B. HTML5).
Andere Browser (Opera, IE, Konqueror) werten dieses Hyphen schon seit mehreren Versionen korrekt aus.
Dabei ist dieses Hyphen für Texte in Sprachen die zur Bildung längerer Wörter neigen extrem wichtig, da Texte im Blocksatz sonst sehr zerrissen ausschauen.
Kannst ja ein Plugin schreiben, oder? soweit ich mich erinnere ist der Firefox OpenSource.
Da braucht aber auch der Firefox bei einigen Dingen eine Extraeinladung...
lg
Erik
> Kannst ja ein Plugin schreiben, oder?
ach, troll dich
Aua, was isn heute los hier, hat's das Gehirn überhitzt?
Noch nie gehört und noch nie gebraucht!
Ich finde es ebenfalls traurig, daß Firefox das nicht ändern, denn ich wüsste nicht was da so schwer dran sein soll.
also ich hab in der Druck-Vorschau eine Drucken-Button, welcher auch den Druck-Dialog aufruft
Neben (unbestreitbaren) Rendering-Verbesserungen sind also inzwischen möglich:
- clientseitige Speicherung von Daten durch normale Webseiten in erheblichem Umfang, *ohne* Cookies und komfortabel via JavaScript zu erreichen (für XUL-AddOns sogar mit der kompletten SQLite-Engine...)
- eine direkte JavaScript-Funktion "getLoginPwd()" für XUL-Addon-Autoren, zum Auslesen gespeicherter Formular-Passwörter. War bisher auch schon möglich, aber jetzt gibt's mit FUEL dafür eine "einfach zu benutzende" JavaScript-Funktion. Wozu auch immer... :-(
WETTEN, dass beide Dinge in Zukunft noch Ärger machen werden? (Spätestens dann, wenn ein "automatisches Update" eines populärenAdd-Ons mal heimlich allen Usern ein Osterei unterschiebt.) Extensions dürfen ja alles - so eine Art "plattformübergreifendes ActiveX" für Mozilla...
Statt Komplexität zu reduzieren, wird Mozilla immer komplexer. Wenn man sich anschaut, was alles sonst noch für die 3.0 geplant ist, fragt man sich, ob *überhaupt* jemand mal an die Sicherheit gedacht hat, *bevor* mit der Implementierung der Unmenge neuer "Convenience"-Features begonnen wurde...
IMHO sollten die Prioritäten bei der Verschlankung und Beschleunigung liegen, und definitiv nicht bei neuen Features. Das neue "Reflow"-Framework wird das Rendering wohl beschleunigen, aber der riesige XPCOM-Overhead bleibt bestehen? (Mit den vielen aus der unnötig flexiblen Architektur resultierenden Problemen bei Garbage Collection, Speicherverbrauch und Performance; so haben z.B. sogar DOM-*Attribute* teilweise eine 1:1-Umsetzung in ein separates per XPCOM gekapseltes, separat per dynamischer Speicherverwaltung verwaltetes C++-Objekt; ein einziges HTML-Element hat im Speicher bis zu mehreren *Kilobytes* an Verwaltung-Overhead!)
Werden zur 3.0 wenigstens Firefox (und später Thunderbird und Seamonkey) endlich auf XULRunner-Basis laufen können?
Das heißt doch das mozilla neue plugins erst überprüft?
Deine Kritik Punkte sind imho in einem w3c standard definitiv und den standard zu erfüllen gehört genauso zu den gesetzten aufgaben von mozilla als aktuell auch die geschwindigkeit.
Zu 2.: Client-seitige Speicherung ist kein W3C-Standard, sondern eine Idee der informellen WHATWG-Gruppe (http://www.whatwg.org). Und (leider) einer der weniger gut durchdachten Ideen der WHATWG (die ansonsten einige äußerst interessante experimentelle Ideen hat, deren unmittelbarer Reifegrad aber sehr kontrovers gesehen wird, wie z.B. HTML5).