HTML: Warum die Entity ­ nicht nur für Donaudampfschifffahrtsgesellschaftskapitäne gut ist
Die Existenz der HTML-Entity ­ (bzw. siehe auch Beschreibung auf quirksmode.org) war mir lange nicht bewusst. Ich kannte zwar das mittlerweile veraltete Tag <wbr />, das bei einem langen Wort einen optionalen Zeilenumbruch ermöglicht. Das Tag führt aber zu einer typografisch eher unbrauchbaren Teilung ohne Trennzeichen.
Da in meinem aktuellen Design in Überschriften sehr große Schriftgrößen zum Einsatz kommen, stand ich schon des Öfteren vor dem Problem, dass lange Wörter, vor allem auf Mobilgeräten, die Seite sprengten und man dadurch beim Scrollen oft seitwärts abdriftete.
Auf der Suche nach einer Lösung versuchte ich zunächst das wbr-Tag mittles CSS-»:before«- und -»content«-Anweisungen zur Ausgabe eines Trennstrichs zu bewegen, allerdings ohne Erfolg.
Auf das mittlerweile von Browsern gut unterstützte HTML-Sonderzeichen ­, welches im Falle eines Umbruchs automatisch den Trennstrich anzeigt, bin ich eher durch Zufall gestoßen. Es lässt sich wie folgt anwenden:
Donau­dampf­schiff­fahrts­gesell­schafts­kapitän
Damit sind alle Probleme mit Wortlängen, die in der deutschen Sprache ja relativ oft anzutreffen sind, gelöst. Besser wäre natürlich eine gute, automatische Silbentrennung. Das manuelle Setzen von ­ stellt zwar einen Mehraufwand dar, dafür behält man aber volle Kontrolle über die Silbentrennung.
Neueste Artikel
Teilen & Favorisieren
Twitter (0 & 1) · Facebook (0 & 0)
4 Kommentare
Hier (4) · Twitter (0) · Facebook (0)
Kommentieren
Dieser Eintrag kann nicht mehr kommentiert werden.
Danke für die Erklärung – Bei mir scheitert ein sinnvoller Einsatz von und dergleichen aber daran, dass der Code-Editor von WordPress den Html-Code für das soft Hyphen immer wieder durch ein soft Hyphen ersetzt. Sprich nach dem Speichern ist im Code-Editor der Html-Code für das soft Hyphen verschwunden und durch das Zeichen ersetzt, das ich nicht im Code-Editor will, sondern in der erzeugten html-Seite.
Das ist extrem störend. Kennen Sie eine Lösung die mit WordPress Bordmitteln auskommt (also ohne zusätzliches Plugin)?
Bitte, gern!
Ihre Problembeschreibung ist interessant, denn bei mir funktioniert das Setzen eines ­ im WordPress Classic-Editor (den ich mittlerweile als Plugin verwende), ebenso wie in der Code-Ansicht in Gutenberg. Sprich, das sollte bereits ohne weiteres Zutun mit Bordmitteln funktionieren.
Welche WordPress-Version verwenden Sie bzw. haben Sie eventuell irgendwelche Plugins im Einsatz, die für das Ersetzen verantwortlich sein könnten? Und: Funktionieren andere HTML-Entities, z.B.: · oder –?
Vielen Dank für die schnelle Antwort!
die beiden Beispiele wurden sofort umgebaut zu: A·oder–C
Das Problem betrifft zwei verschiedene Sites, mit unterschiedlichen Plugins.
Jeweils aktuellste WordPress Version – wobei ich das Problem schon lange (oder schon immer?) habe – bisher habe ich es nur ignoriert, und auf die Funktionalität verzichtet.
Csv-Tabelle der Plugins:
Site 1;Site 2
404page;%
Broken Link Checker;%
Duplicator;Duplicator
Health Check & Troubleshooting;%
iframe;%
Last Updated Shortcode;Last Updated Shortcode
Print PDF & Email by PrintFriendly;Print PDF & Email by PrintFriendly
Redirection;%
Shariff for WordPress;%
Shashin;%
Simple Yearly Archive;%
TablePress;%
Twitter;%
%;Polylang
Ich würde als ersten Schritt versuchen alle Plugins zu deaktivieren und testen, ob das Problem weiterhin besteht.
Wenn nein, ein Plugin nach dem anderen aktivieren und prüfen, welches Plugin den Fehler verursacht.
Wenn ja, dann muss ein anderes Problem vorliegen. Ich habe ein wenig gegoogelt und Hinweise darauf gefunden, dass das unter Umständen mit der Zeichenkodierung in MySQL bzw. der PHP-Konfiguration Ihres Webservers zusammenhängen könnte (leider finde ich den Link nicht mehr, ich glaube, es war Stack Overflow – ich aktualisiere den Post, wenn ich diesen wiederfinde). Wenn das Problem auch bei einer komplett neuen Installation von WordPress auftritt, wäre das ein Indiz dafür. Zunächst könnten Sie prüfen, ob Ihre MySQL-Tabellen für WordPress auch entsprechend mit UTF-8-Encoding angelegt sind – den dies können Sie bei Bedarf selber ändern. Bezüglich PHP-Konfiguration müssten Sie sich an Ihren Hoster wenden. Apropos, wenn dieser WordPress-Support anbietet, könnten Sie sich auch den diesen wenden, vielleicht ist ihm das Problem bekannt.