**fett** bedeutet fettiger Text, aber wie wird er farbig?

[Linuchs]

Moin,

seit Monaten grüble ich darüber nach, wie man Text in einem HTML-Eingabefeld so auszeichnen kann, dass er später farbig wird. Anwender sind Vereinsmitglieder in Europa (Farben heißen unterschiedlich), die ihre Veranstaltungstermine eingeben.

Da ich mit farbigen Noten für Anfänger arbeite, bietet sich die Boomwhacker-Farbpalette an:

Und dies ist meine Idee, die heute als Anleitung über dem textarea steht:

Intuitiv (selbsterklärend) ist das nicht gerade und die vielen Plusses und Minusses verwirren. Ich wollte bei den Farb-Steuersequenzen aber ohne Tastenkombinationen auskommen, zusätzlich [Shift][Strg][Alt] macht Knoten in die Finger.

Bin mit meiner Idee also noch nicht zufrieden, wie könnte es besser färben?

Gruß, Linuchs

[pl]

Biete doch die Farbpalette als farbige Buttongs über der Textarena an. Text markieren, klick, fertig. Und nicht vergessen: Ein Vorschau! MFG

[Rolf B]

Hallo Linuchs,

+c+Rot+c+ ist natürlich umständlich, wenn man es mit **rot** vergleicht. Aber nicht sehr. Farbe ist in Mark- und Kramdown nicht vorgesehen, daher kann man dort nicht abgucken. Kramdown bietet nur die Möglichkeit, HTML Attribute zu ergänzen. Und ein <span> Element einzufügen.

Dieser Satz ist rot
{: style="color:red"}

Dieses <span>Wort</span>{: style="color:red"} ist rot.

So ist es *auch nicht*{: style="color:red; font-style: normal"} schöner.

Brrr.

Andererseits ist es natürlich auch mehr Funktion - der Notenname wird gebraucht. Aber worum geht es Dir? Um Farben, oder um Noten? Oder sind die Noten nur ein Vehikel, um via Boomwhacker-Palette eine Merkhilfe für die Farben zu haben?

Was auf jeden Fall nervt ist die Wiederholung der Farbe. Die ++ sind als Pseudomarkdown dagegen gar nicht so verkehrt, finde ich. Sternchen und Unterstriche sind bereits von Markdown für <em> und <strong> belegt, und ~~ für <s>.

Das Plus wäre also eine legitime Möglichkeit, wenn Du nicht auf [{(Klammern)}] oder den \Backslash ausweichen willst.

Man könnte die Wiederholung der Farbe beim Schließen und das doppelte Nesting bei Angabe von Vorder- und Hintergrundfarbe so optimieren:

• ++c+Das ist rot ohne eigenen Hintergrund++
• ++/c+Das ist roter Hintergrund++
• ++a/e+Das ist blau auf Gelb++

Statt ++farbe+Text++ könnte man auch ++farbe: text++ nehmen, das könnte sich besser lesen.

Und man ist auch nicht auf boomwhacker Codes begrenzt. Eigentlich kannst Du einfach alles an color und background-color durchreichen, dann geht auch:

• ++red: Das ist rot++
• ++/yellow: Das ist gelb hinterlegt++
• ++blue/yellow: Das ist blau auf gelb++

Für wichtige Farben kannst Du ja noch ein paar deutsche Synonyme unterstützen, und die Boomwhacker-Notenbuchstaben sind auch möglich.

Wer Blödsinn schreibt, kriegt damit natürlich auch Blödsinn raus (ggf. kannst Du den GIGO-Effekt durch ein paar Plausis begrenzen). Was aber für Hardcore-Maler auch nicht schlecht wäre, ist die Unterstützung von

++#0000FF/#FFFF00: Das ist blau auf gelb++

Rolf

[Linuchs]

Hallo Rolf,

erstmal ein herzliches Danke für deinen sehr ausführlichen Beitrag zur farbigen „Grundlagenforschung”.

Die Schreibweise mit dem / zwischen Schrift- und Hintergrundfarbe gefällt mir. Mal schauen, wie sich das programmtechnisch umsetzen lässt.

Bisher habe ich die Farb-Angaben paarig angelegt, [] für Schriftfarbe, {} für Hintergrund, aber Eingabe mit [Alt Gr], deshalb geändert auf ++ und --

[Rolf B]

Hallo Linuchs,

das sollte eine relativ einfach Regex sein:

\+\+(.*?)(?:\/(.*?))?\+(.+?)\+\+

oder, wenn Du die capturing-Gruppen benennen willst:

\+\+(?<fg>.*?)(?:\/(?<bg>.*?))?\+(?<text>.+?)\+\+

Die non-greedy Fragezeichen hinter .* und .+ kannst Du in PHP durch das Rexexp-Flag U ersetzen, in JacaScript scheint das nicht zu gehen. Wenn Du alle Vorkommen in einem Rutsch ersetzen willst, sollte auch noch das g-Flag dazu (global). Und wenn ein Zeilenumbruch in einer Farbgruppe erlaubt sein soll, auch noch das s Flag.

Getestet mit PHP und JavaScript Regex auf dieser Regex101 Testseite

Eine stumpfsinnige Ersetzung würde mit diesem Replacement-Ausdruck gehen:

<span style="color:$1;background-color:$2">$3</span>

aber dann gibt's keine Plausi und keine Bequemlichkeit bei Farbnamen 😉

Rolf

[Linuchs]

Hallo Rolf,

dieses Regex habe ich nie verstanden. Es scheitert schon daran, mit preg_replace aus //kursiv// <i>kursiv</i> zu machen, der Schrägstrich weigert sich, maskiert zu werden, wird also nicht erkannt und nicht umgesetzt:

  $search = array (
   "**"    // fett
  ,"//"    // kursiv
  ,"__"    // unterstrichen
  );
  $replace_1 = array (
   "<b>"    // fett
  ,"<i>"    // kursiv
  ,"<u>"    // unterstrichen
  );
  $replace_2 = array (
   "</b>"   // fett
  ,"</i>"   // kursiv
  ,"</u>"   // unterstrichen
  );

  // den gesamten Text nacheinander nach allen Suchbegriffen $search durchsuchen
  for ( $i=0; $i < count($search); $i++ ) {
    // 1., 2., .. n. Suchbegriff
    $arr = explode ( $search[$i], $text );    // Formatierungs-String $search[$i] trennt

    // Formatierungs-String muss paarig sein count also ungerade: [Text **fett** Text **fett**] count=5
    while ( count($arr) > 2 && count($arr) % 2 != 0 ) {
      if        ( $search[$i] == "**" ) $such = "\*\*";     // ** maskieren
      else  if  ( $search[$i] == "//" ) $such = "//";
//    else  if  ( $search[$i] == "//" ) $such = "\/\/";     // // maskieren
//    else  if  ( $search[$i] == "//" ) $such = "\057\057"; // oktal
//    else  if  ( $search[$i] == "//" ) $such = "\x2F\x2F"; // hex
      $text = preg_replace( "/".$such."/", $replace_1[$i], $text, 1 );  // nur einen ersetzen, nacheinander den 1. 3. 5. ...
      $text = preg_replace( "/".$such."/", $replace_2[$i], $text, 1 );  // nur einen ersetzen, den 2. 4. 6. ...
      $arr  = explode ( $such, $text );                                 // Suchbegriff auf das naechste Vorkommen setzen
    }
  }

Da es bei **fett** und __unterstrichen__ klappt, scheint das Konzept doch okay zu sein.

Linuchs

[Rolf B]

Hallo Linuchs,

du musst das / ebenfalls maskieren, weil es der Regex-Delimitier ist. Ansonsten entsteht für preg_replace als erster Parameter der String "////", was eine leere Regex gefolgt von zwei unbekannten Optionszeichen ist. Das Ergebnis ohne Maskierung sollte wie folgt lauten:

Warning: preg_replace(): Unknown modifier '/' in ... on line 4

Darüber hinaus solltest Du beachten, dass ein String in doppelten Anführungszeichen bereits auf PHP Ebene eine Backslash-Interpretation enthält. Eine Regex "[aeiou].*\1" würde scheitern, weil \1 nicht als Back Reference, sondern als Zeichen mit Code 1 interpretiert wird. Entweder musst Du alle Backslashes doppeln, oder Patterns in einfache Anführungszeichen setzen.

Aber prinzipiell halte ich deinen Algorithmus für fehlerhaft. Was passiert bei

„Ein **Ring, sie zu __knechten**, sie alle__ zu finden“

Das Kramdown im Forum macht daraus

„Ein Ring, sie zu __knechten, sie alle__ zu finden“

also:

„Ein <b>Ring, sie zu __knechten</b>, sie alle__ zu finden“

D.h. das __ zwischen den ** wird als unpaarig erkannt und ignoriert. Du machst das nicht; ich würde vermuten, dass Du dieses (fehlerhafte) HTML generierst:

„Ein <b>Ring, sie zu <u>knechten</b>, sie alle</u> zu finden“

Ich habe im Moment zu wenig Zeit für einen Alternativvorschlag - das wird bis morgen dauern - aber ich denke, dass man mit sinnvollen Regexen deine Explode-Technik verbessern kann.

Rolf

[Linuchs]

Moin,

die Zeichenfolge // wird durchaus gefunden, aber da im Text Links enthalten sind http://..., an die ich nicht gedacht habe, gibt's Fehler, weil die auch gefunden werden.

Ich codiere die um zu http:^^ / https:^^ und nach der Routine wieder zurück.

Linuchs

[Mitleser]

die Zeichenfolge // wird durchaus gefunden, aber da im Text Links enthalten sind http://..., an die ich nicht gedacht habe, gibt's Fehler, weil die auch gefunden werden.

Ich codiere die um zu http:^^ / https:^^ und nach der Routine wieder zurück.

Hört sich verdächtig nach einem regulärem Ausdruck in Deiner Routine an. Falls ja, gilt oftmals: „Now You Have Two Problems“

EDIT: Vorigen Post gelesen. Ja, trifft zu. Bei solchen Aufgabenstellungen führen reguläre Ausdrücke meist zwangsläufig ins Verderben. Lernen durch Schmerz ;-)

[Linuchs]

Oder sind die Noten nur ein Vehikel, um via Boomwhacker-Palette eine Merkhilfe für die Farben zu haben?

Ja. Prinzipiell will ich unterschiedliche Sprachen nicht im PHP-Programm haben. Die gibt es in der Platzhalter-Datei in der Form ###rot###red###rood### (de, en, nl), wovon die richtige ausgegeben wird.

Eingegebene Texte können jede beliebige Sprache haben, ich hatte schon russisch dabei. Farben will ich nicht nicht mit fremdsprachigen Werten steuern (red ist für de, ru und nl Fremdsprache).

[Felix Riesterer]

Lieber Linuchs,

offensichtlich stößt Du hier mit einer plain/text-Eingabe an die Grenzen des für unbedarfte User Zumutbaren. Lohnt es nicht, hier einen WYSIWYG-Editor einzusetzen? So etwas wie den TinyMCE? Da kann man eigene Buttons definieren, die dann ein passendes Element (z.B. <span class="key-c">C</span>) in den gerade bearbeiteten Fließtext einfügen. Zusätzlich kann man vermeiden, dass da ungewolltes Markup entsteht.

Liebe Grüße

Felix Riesterer

[Mitleser]

offensichtlich stößt Du hier mit einer plain/text-Eingabe an die Grenzen des für unbedarfte User Zumutbaren. Lohnt es nicht, hier einen WYSIWYG-Editor einzusetzen? So etwas wie den TinyMCE? Da kann man eigene Buttons definieren, die dann ein passendes Element (z.B. <span class="key-c">C</span>) in den gerade bearbeiteten Fließtext einfügen. Zusätzlich kann man vermeiden, dass da ungewolltes Markup entsteht.

In die Richtung wollte ich zunächst auch empfehlen, aber wieder davon abgelassen. Das wäre ganz klar der Königsweg, bringt aber auch einige Komplexität und Stolperfallen mit sich.

Würde es „nur“ darum gehen, mittels WYSIWYG etwas zu bauen, was dann eben WYSIWYG in der Bearbeitung so aussieht, wie später in der Darstellung im Browser: OK.

Aber ich unterstelle mal, dass der OP die WYSIWYG-Eingabe letztlich wieder in „Boomwhacker-Markup“ überführen möchte statt einfach das potentiell wüste HTML-Markup zu speichern. So etwas in der Richtung habe ich schon einmal gebaut, das war nicht trivial und für Linuchs vermutlich zu heftig.

[Felix Riesterer]

Lieber Mitleser,

Das wäre ganz klar der Königsweg, bringt aber auch einige Komplexität und Stolperfallen mit sich.

machen! Alles andere ist nicht (so) gut!

Würde es „nur“ darum gehen, mittels WYSIWYG etwas zu bauen, was dann eben WYSIWYG in der Bearbeitung so aussieht, wie später in der Darstellung im Browser: OK.

Aber ich unterstelle mal, dass der OP die WYSIWYG-Eingabe letztlich wieder in „Boomwhacker-Markup“ überführen möchte statt einfach das potentiell wüste HTML-Markup zu speichern.

Das wäre unnötig kompliziert, da die Seiteninhalte ja als HTML ausgegeben werden sollen. Die Eingabe ist das Problem, weil hier eine Eigenkonstruktion von Markdown/Kramdown/Wiki-Syntax verwendet wird.

So etwas in der Richtung habe ich schon einmal gebaut, das war nicht trivial und für Linuchs vermutlich zu heftig.

Man kann ja bei Problemen diese (exakt) beschreiben, um (dann) hilfreiche Hinweise zu erhalten. Oder man bleibt bei seinen Krücken und beschwert sich nicht mehr, dass das Gehen damit mühsam ist.

Liebe Grüße

Felix Riesterer