Die Autobreak-Funktion <we:textarea wysiwyg="false" autobr="true" /> bei nicht-wysiwyg Texteingabefeldern entfällt ganz. Laut WE-Tag-Referenz "deprecated ab Version 7.1.0."
Also ist nicht nur der Button zum de/aktivieren weg, sondern auch die ganze Funktion.
Bei aktivierten Autobreak wurden alle erzwungenen Zeilenumbrüche (RETURN-Taste) als <br> übersetzt. Mir hat das 10 Jahre lang als "wysiwyg" Eingabe gereicht!
Das diese unscheinbare, aber sehr wirkungsvolle Autobreak-Funktion entfernt wurde, ist schade, da jetzt alle meine wysiwyg false Texteingabefelder wie eine <br>-Wüste aussehen.
Also ich hätte schon ganz gern die Autobreak-Funktion wieder …
Oder weiß jemand einen Trick?
WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Ich glaube darüber das die Checkbox für autobr unsinnig war, sind wir uns einig, oder?
Die Funktion selbst könnten wir durchaus wieder einführen, wenn sie wirklich gebraucht wird - dann bitte dazu einen Bugreport dazu anlegen. Aber zugegeben ist uns kein Anwendungsfall dafür eingefallen.
Die Funktion selbst könnten wir durchaus wieder einführen, wenn sie wirklich gebraucht wird - dann bitte dazu einen Bugreport dazu anlegen. Aber zugegeben ist uns kein Anwendungsfall dafür eingefallen.
webEdition-Kern-Entwickler
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Mein klassischer Anwendungsfall für typische Artikel mit nicht-wysiwyg Texteingabefeldern ist der folgende Aufbau einer Artikel-Eingabemaske:
-- einzeilige Headline per input
-- Intro per nicht-wysiwyg Texteingabefeld
-- Haupt-Text per nicht-wysiwyg Texteingabefeld
-- einzeilige Sub-Headline per input
-- 2ter Haupt-Text per nicht-wysiwyg Texteingabefeld
-- dann kommen Links, Bilder, Uploads, Galerien, etc. - nach Bedarf weiteres, genau an die Stelle wo es hinsoll. Alles hübsch strukturiert und semantisch korrekt.
Dieser Aufbau ist einfach und für einen Redakteur recht komplikationslos zu bedienen.
Links, PDFs kommen an die definierte Stelle und nicht wahllos per wysiwyg im Haupt-Text.
Bisher hatte ich recht gute Erfahrungen damit gemacht.
Die Autobreak-Funktion, als rudimentäres wysiwyg, ist für diesen Anwendungsfall natürlich nötig. Vom Redakteur zu verlangen einzelne <br> einzugeben, ist schwer zu vermitteln.
Also bitte Autobreak-Funktion wieder reaktivieren. Gerne auch ohne Checkbox.
Bugreport ID 0011678
-- einzeilige Headline per input
-- Intro per nicht-wysiwyg Texteingabefeld
-- Haupt-Text per nicht-wysiwyg Texteingabefeld
-- einzeilige Sub-Headline per input
-- 2ter Haupt-Text per nicht-wysiwyg Texteingabefeld
-- dann kommen Links, Bilder, Uploads, Galerien, etc. - nach Bedarf weiteres, genau an die Stelle wo es hinsoll. Alles hübsch strukturiert und semantisch korrekt.
Dieser Aufbau ist einfach und für einen Redakteur recht komplikationslos zu bedienen.
Links, PDFs kommen an die definierte Stelle und nicht wahllos per wysiwyg im Haupt-Text.
Bisher hatte ich recht gute Erfahrungen damit gemacht.
Die Autobreak-Funktion, als rudimentäres wysiwyg, ist für diesen Anwendungsfall natürlich nötig. Vom Redakteur zu verlangen einzelne <br> einzugeben, ist schwer zu vermitteln.
Also bitte Autobreak-Funktion wieder reaktivieren. Gerne auch ohne Checkbox.
Bugreport ID 0011678
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
#Ich glaube darüber das die Checkbox für autobr unsinnig war, sind wir uns einig, oder?
Die checkbox ist durchaus sinnvoll, nämlich dann, wenn man in das Texteingabefeld auch andere tags als <br> eingeben muss. In solchen Fällen ist es sinnvoll, die checkbox zu deaktivieren.
Die checkbox ist durchaus sinnvoll, nämlich dann, wenn man in das Texteingabefeld auch andere tags als <br> eingeben muss. In solchen Fällen ist es sinnvoll, die checkbox zu deaktivieren.
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Ein Redakteur gibt zum einen keine anderen Tags ein und ist eher über die Box irritiert.
Wenn man das dann will, müßte man das auch im Template vorsehen.
Wenn man das dann will, müßte man das auch im Template vorsehen.
webEdition-Kern-Entwickler
-
- webEdition Partner
- Beiträge: 1825
- Registriert: Di 7. Mär 2006, 16:50
- Wohnort: Wien
- Kontaktdaten:
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Das war auch mein erster Gedanke. Wir hatten aber auch schon ähnliche Projekte bzw. Anforderungen. Die Frage ist, ob webEdition definieren soll, was und wie ein Redakteur arbeiten soll. Mit entsprechender Schulung / Kenntnis, können RedakteurInnen auch problemlos mit HTML-Tags arbeiten.mokraemer hat geschrieben:Ein Redakteur gibt zum einen keine anderen Tags ein und ist eher über die Box irritiert. Wenn man das dann will, müsste man das auch im Template vorsehen.
Die andere Überlegung ist, wie groß der tatsächliche Bedarf für "Autobreak" ist. Ich persönlich werde das Feature jedenfalls nicht missen, da ich das ohnehin auf der Ausgabeseite einbauen würde.
Liebe Grüße,
Sascha
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Wir machen das ganz einfach:Die Frage ist, ob webEdition definieren soll, was und wie ein Redakteur arbeiten soll. Mit entsprechender Schulung / Kenntnis, können RedakteurInnen auch problemlos mit HTML-Tags arbeiten.
das Tag hat (wie bisher auch) das Attribut "Autobreak" da wird ein Enter als <br/> intepretiert. Wenn man das Attribut nicht setzt ist es Text und man kann dort auch html eingeben. Aber es handelt sich beim Editieren halt um ein CMS, also entweder nutzt man dann "plain" Text weil man etwas befüllen will ohne Formatierung, oder man macht einen angepaßten wysiwyg Editor dort hin. Das man von Hand HTML eingibt sollte man sich doch eher fragen ob das Feld falsch ist, oder ob der Redakteur versucht das System auszutricksen um damit bspw. die Formatierung die man für eine Seite festgelegt hat wieder durcheinander bringt.
webEdition-Kern-Entwickler
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
# Ein Redakteur gibt zum einen keine anderen Tags ein
Aus Erfahrung kann ich nur sagen: Stimmt nicht.
Wenn ein Redakteur z. B. eine Liste eingibt
<ul>
<li>Punkt 1</li>
<li>Punkt 2</li>
</ul>
und er das Kontrollkästchen autobr nicht deaktiviert, steht im Quellcode der Seite:
<ul><br>
<li>Punkt 1</li><br>
<li>Punkt 2</li><br>
</ul><br>
Aus Erfahrung kann ich nur sagen: Stimmt nicht.
Wenn ein Redakteur z. B. eine Liste eingibt
<ul>
<li>Punkt 1</li>
<li>Punkt 2</li>
</ul>
und er das Kontrollkästchen autobr nicht deaktiviert, steht im Quellcode der Seite:
<ul><br>
<li>Punkt 1</li><br>
<li>Punkt 2</li><br>
</ul><br>
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Ich arbeite viel mit nicht-wysiwyg Texteingabefeldern (autobr="true"), um so strukturiertes und semantisch korrektes HTML zu bekommen. Die Checkbox habe ich mit CSS ausgeblendet, da diese den Redakteur eher verwirrt.
Das Problem mit den Listen (</li><br> ) kenne ich auch, Lösungsansätze:
- Listen vermeiden
- eine freies Texteingabefeld (autobr="false") für diese "Spezialfälle"
- oder ein we:block extra für Listen
Mein Wunsch fürs kommende WE8.x bei "textarea wysiwyg false"
-> default Autobreak Einstellung "false" -> Autobreak möglich ohne Checkbox per autobr="true"
Das Problem mit den Listen (</li><br> ) kenne ich auch, Lösungsansätze:
- Listen vermeiden
- eine freies Texteingabefeld (autobr="false") für diese "Spezialfälle"
- oder ein we:block extra für Listen
Mein Wunsch fürs kommende WE8.x bei "textarea wysiwyg false"
-> default Autobreak Einstellung "false" -> Autobreak möglich ohne Checkbox per autobr="true"
Re: WE 8: Autobreak-Funktion bei textarea wysiwyg false entfällt
Genau so soll es aussehen.Mein Wunsch fürs kommende WE8.x bei "textarea wysiwyg false"
-> default Autobreak Einstellung "false" -> Autobreak möglich ohne Checkbox per autobr="true"
webEdition-Kern-Entwickler
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 56 Gäste