Hey, danke für den Link auf meine Seite!

Als Ergänzung mochte ich noch erwähnen, dass Suchmaschinen Begriffe, die mit shy versetzt sind, wahrscheinlich nicht indexieren! Aber das müsste man mal genauer untersuchen.

Dass Opera trotz shy noch suchen kann, wusste ich nicht. Und irgendwie macht das Hyphenation-Script im Firefox noch zuviele Trennstriche (z.B. nach einem Punkt!?!) Da muss ich mich wohl wieder einmal dahintersetzen...

Grüsse aus Zürich, Mathias

Der Bug-Report für das Problem mit der Suche ist Bug 294615

Eine manuelle Silbentrennung ist, selbst wenn der alte Bug mal behoben ist, trotzdem keine Lösung. Wer hat schon Bock, alle zwei bis fünf Zeichen im Text ein ­ zu notieren? HTML-Editoren können diese Arbeit vielleicht bis zu einem gewissen Grad automatisieren, aber z.B. bei user generated content fällt das alles wieder flach.

Sinnvoller fände ich es, wenn Browser mit einem Thesaurus-Set ausgerüstet wären, das auch über Silbenkennzeichnung verfügt, so wie es jede bessere Textverarbeitung heute mitbringt. In Texten, die eine Sprachidentifikation mittels lang-Attribut haben, könnte die Silbentrennung dann automatisch vom Browser durchgeführt werden. Allerdings sollte das ein Leistungsmerkmal sein, das per Default ausgeschaltet ist und auf Wunsch eingeschaltet werden kann. Idealer Ort dafür ist CSS. Ist ja auch schon vorgesehen - siehe CSS 3: Texteffekte (Artikel von Jens Meiert).

Alles andere halte ich jedenfalls für unzumutbaren Zufußmarsch, und vielleicht hat es auch deshalb so lange gedauert, bis sich jemand dieses Bugs erbarmt hat.

Hi,

die Trennung funktioniert auch im Opera nicht - zumindest in meinem. Weder über [Strg]+[F] noch über die Schnellsuche [.] kann ich getrennte Wörter finden.

Micha

Hallo zusammen!

Das ist doch wieder mal ein typisches Beispiel für die heutzutage immer häufiger auftretende Problematik im Webdesign.

Zunächsteinmal dürften wir uns ja insoweit einig darüber sein, dass eine wie auch immer geartete Silben-/ Worttrennung ja (im wesentlichen) nur für das Screen- und Printlayout von Bedeutung/ Interesse sind (k.A. wie es bei Braille ist!?).

Davon ausgehend ist also schon das zwingende Vorhandensein von extra Code im HTML Dokument ein Verstoß gegen die Trennung Inhalt und Design (als Oberbegriff). Ferner ergeben sich daraus ja auch noch weitere Probleme, wie die bereits im Artikel und den Kommentaren angesprochenen.

Die Javascript Alternative ist zwar sehr nett, nur nutzt sie dem Webdesigner im Bezug auf sein Layout ja auch nicht weiter. Haben wir doch gelernt (und predigen es an jeder Ecke), dass Javascript zwar optional als "Bonus" eingesetzt werden kann und darf, aber niemals Grundlage, bzw. Grundvoraussetzung für irgendetwas sein darf.

Ich stimme auch am ehesten mit der Meinung von Stefan Münz überein, dass es Sache des lokalisierten Browsers sein sollte, eine vom Webautor über CSS-Angaben gesteuerte Silbentrennung vorzunehmen.

Auch dieses Beispiel zeigt mir wieder, dass eine separate "Layoutsprache" (wie ich sie schon länger fordere), die die Möglichkeiten von Javascript und CSS, in einer für den Webautor zuverlässigen Art & Weise miteinander verbindet, immer sinnvoller wird.

Mein Fazit: Ein Feature, dass in der Praxis sicherlich gut einzusetzen wäre, in dieser Form der praktischen Umsetzung jedoch völlig unbrauchbar ist (wie leider zu Vieles heutzutage)!

Gruß Gunther

Gunther, aus meiner Sicht ist diese Lehre, dass Javascript nur optional funktionieren darf, in weiten Teilen nicht mehr gültig. Zwar ist noch immer anzustreben, dass vor allem die Basisfunktionalität ohne JS auskommt oder mittels Fallbacks gewährleistet wird, jedoch kann es auch hier Situationen geben, in denen es ohne JS nicht sinnvoll funktioniert und Fallbacks nicht sinnvoll nutzbar oder zu aufwendig in der Umsetzung wären. »Früher« wären solche Zustände indiskutabel gewesen, während man sie heute (zwangsläufig) akzeptiert.

Im Fall der Silbentrennung sehe ich den beschriebenen JS-Ansatz allerdings nicht als Basisfunktionalität, sondern lediglich als Maßnahme, die die Textausgabe flüssiger macht. Nicht böse also, sondern sehr nützlich. Und dabei ziemlich clever.

Ich verwende Javascript auch nur, wenn es anders nicht geht (für einen kleinen Effekt z.B.), möchte es aber nicht auf jeder Seite integrieren und das Layout letztendlich von dem User abhängig machen (Hat er Javascript aktiviert oder nicht). Da sollte das W3C einmal ansetzen, mit ihren immer neueren Webstandards.

Seit einiger Zeit verfügt Firefox doch über eine Rechtschreibprüfung. Wenn die dazu gehörigen Wörterbücher auch Informationen zur korrekten Silbentrennung der Worte enthielten, könnte der Client das Thema ganz alleine. Der Nutzer könnte ggf. noch einstellen, ob er eine Silbentrennung wünscht oder nicht. Das sieht für mich nach einem Betätigungsfeld für ein Firefox Add-on aus.

Die Vorteile sind klar: Keine Tags oder Entities im Code nötig, keine Nachbereitung (manuell oder per Skript) von user-generated Content, Wahlfreiheit des Nutzers.

Die Nachteile: keine Beeinflussung durch den Autor, fragliche Verfügbarkeit des Add-ons auf Nutzerseite.

Heute wurde auch Fehler #294615 behoben. Das bedeutet die Suchfunktion des Firefox wird nun nicht mehr von Soft Hyphens beeinträchtigt.

Oh weh, weh, weh ...

Selbst wenn endlich mal ein nagelneuer Webbrowser dieses »soft hyphen« korrekt darstellt, werden die meisten WWW-Surfer noch viele Jahre lang ältere Browser benutzen, in denen sowas nicht funktioniert oder sogar zu peinlichsten, sprachlich fehlerhaften Textzeichen führt.

Für eine gesunde HTML-Evolution müsste daher wenigstens ein völlig neues (!) Sonderzeichen-Kürzel für dieses »soft hyphen« eingeführt werden. Denn jenes Kürzel »Et-S-H-Y-Semikolon« wird ja längst von diversen bisherigen Webbrowsern mitinterpretiert, und diese werden künftig noch viele Jahre von den meisten Menschen weiterverwendet werden!

Mein Fazit für die nächsten Jahre also:

Mit HTML/CSS publiziere ich Lesetexte nur in Flattersatz, und unvermeidbare Bandwurm-Wörter gliedere ich dudengemäß mit Bindestrichen — z.B. kann man »Bandwurm-Wortbildungs-Unvermeidbarkeit« statt »Bandwurmwortbildungsunvermeidbarkeit« schreiben.* Viele Webbrowser, auch einige ältere, umbrechen solche längeren Worte dann wenigstens an diesen »harten« Bindestrichen. Und für die Webbrowser, die das nicht tun, setzt man nach solchen Bindestrichen eben ein ‹wbr›-tag — was zwar W3C-unkonform sein mag, aber in keinem Webbrowser Fehlzeichen erzeugt und daher immer noch menschengerechter ist als jeder leserunfreundlich zerschossene Schriftsatz.

*) Vgl. »Getrennt- und Zusammenschreibung«, in: »Duden — Die deutsche Rechtschreibung«, Bibliografisches Institut & F.A. Brockhaus AG, Mannheim 2006 (24).

@IT-Kritikerin: Internet Explorer ab v5.0 (!), Opera ab v7.1, Safari seit v2 (und damit wohl auch KDE 4, eventuell schon frühere) und Firefox ab v3 (nicht zu vergessen alle Gecko-1.9-Forks) unterstützen Soft Hyphens, damit ist es wohl die beste und zuverlässigste Möglichkeit den bedingten Bindestrich zu setzen.

Firefox-Benutzer sind darüberhinaus sehr zuverlässig beim Aktualisieren ihrer Software. Das selbe gilt, denke ich, für viele Linux-Benutzer.

Davon abgesehen kann ein Umbruch ohne Bindestrich (mit dem wbr-Element) dazu führen, dass ein Satz eine ganz andere Bedeutung erhält, das ist eher nicht zu gebrauchen. Shy ist zwar nicht die ideale Lösung, aber das beste, was momentan verfügbar ist.

@Daniel: Von einem »Umbruch ohne Bindestrich (mit dem wbr-Element)« sollte auch gar nicht die Rede sein. Ich würde nur mit (!) Bindestrichen zusammengesetzte Worte mit einem ‹wbr› nach jedem Bindestrich versehen (siehe oben) — und dies führt zu keinerlei Problemen (im Gegensatz zum »shy«). Ein »Umbruch ohne Bindestrich« wäre nicht nur »eher nicht zu gebrauchen«, sondern orthografisch völlig unzulässig.

@IT-Kritikerin: Dass du das wbr-Element mit eigenem bindestrichverwenden würdest habe ich zugegeben überlesen.

Dennoch ist die Meinung, das Soft Hyphen wäre erst in Jahren verwendbar nicht belegt. Der letzte weit verbreitete Browser, der es mit einem Fehler angezeigt hat war Konqueror unter KDE 3.4 ([gerade festgestellt ;)] eine Version, die langsam aber sicher verschwindet). Damit ist der Markt nun von zwei Arten von Browsern bevölkert. Einerseits von denen, die mit ­ umgehen können. Und andererseits mit Browsern, die zwar mit ­ nicht umgehen können, das aber keinen Einfluss auf die Darstellungsqualität hat.

Die neue Alpha-Vorabversion von Opera 9.5 findet jetzt doch auch umgebrochene Wörter (hab' ich grade getestet).

Sagt mal, nutzt wirklich jemand von euch Opera im Alltag?

Willi, ja. 6 bis 7 Prozent der Besucher dieses Blogs tun das ebenfalls.

Die Mehrheit der "Einsteiger" wird aber in Zukunft auch den IE benutzen, denn viele wissen garnicht das es noch was anderes gibt.

@ichlach: Das kann ich bestätigen. Aus meiner sporadischen Telefonsupport-Tätigkeit weiß ich, dass viele Benutzer auf die Frage nach ihrem Browser mit "Sie meinen mein Internet?" antworten.

Ich optimiere schon seit Jahren nicht mehr für Opera. Firefox und IE 6.5 und IE 7 sollten in der Regel ausreichen.

Hy, ist mir bei meinen Kunden auch aufgefallen. Die meisten wissen wirklich gar nicht das es mehrere Browser gibt. Ich optimiere ebenfalls auf I.E und Firefox. Selber benutze ich aber den Avant da der Firefox noch zu lahm ist. Netten Gruss