nicht angemeldet
Formatierung mit CSS, statt mit HTML
Hello,
ich frage mich schon eine ganze Weile, ob es wohl eine Möglichkeit gibt, anstelle mit <br> einen Teilenumbruch im Text bei "newline" (also nei "\r", "\n" oder "\r\n") mittels CSS zu erzeugen. Denn eigentlich ist es doch Sache der Formatierung und nicht der Semantik, einen Zeilenumbruch darzustellen.
Leider konnten mir auch diverse Goolge-Fasttreffer da nicht weiterhelfen, obwohl dieselbe oder ähnliche Fragen von Vielen gestellt wurden.
Ich fand nur Krücken in JavaScript. Die kann ich aber leider nicht einsetzen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi,
ich frage mich schon eine ganze Weile, ob es wohl eine Möglichkeit gibt, anstelle mit <br> einen Teilenumbruch im Text bei "newline" (also nei "\r", "\n" oder "\r\n") mittels CSS zu erzeugen.
http://de.selfhtml.org/css/eigenschaften/ausrichtung.htm#white_space
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Hello Chris,
ich frage mich schon eine ganze Weile, ob es wohl eine Möglichkeit gibt, anstelle mit <br> einen Teilenumbruch im Text bei "newline" (also nei "\r", "\n" oder "\r\n") mittels CSS zu erzeugen.
http://de.selfhtml.org/css/eigenschaften/ausrichtung.htm#white_space
Vielen Dank für den Pfennig. Der fehlte noch an meinem Groschen. Aber nun ist er gefallen :-O
<!-- repeat_form--><!--{RECNO}--><!-- of form opinionbook_list_static -->
<tr>
<td><!--{CALC_ENTRY_DATE}--></td>
<td><!--{OWNER}--></td>
<td><!--{SUBJECT}--></td>
<td><input type="submit" name="btn[view][<!--{RECNO}-->]" value="ansehen"></td>
</tr>
<tr>
<td colspan="4" style="white-space:pre;"><!--{CALC_CONTENT}--></td>
</tr>Ich wollte das Rad nochmal erfinden und habe für unser kleines Callaborate-CMS ein Templatesystem gebastelt, dass es zulässt, dass die Templates vom Kunden erstellt werden, also auch per HTTP von einem entfernten Webserver geholt werden können (in der Regel von seinem). Und da darf ja dann kein aktiver PHP-Code mehr enthalten sein.
Paar Schöheitsfehler hat es jetzt noch, aber das lästige nl2br-Problem ist vom Tisch.
Das CSS steht dann sicherlich später nicht inline, aber zum Ausprobieren hat es eben gereicht :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
<!-- repeat_form--><!--{RECNO}--><!-- of form opinionbook_list_static -->
<tr>
<td><!--{CALC_ENTRY_DATE}--></td>
<td><!--{OWNER}--></td>
<td><!--{SUBJECT}--></td>
<td><input type="submit" name="btn[view][<!--{RECNO}-->]" value="ansehen"></td>
</tr>
<tr>
<td colspan="4" style="white-space:pre;"><!--{CALC_CONTENT}--></td>
</tr>Ich wollte das Rad nochmal erfinden und habe für unser kleines Callaborate-CMS ein Templatesystem gebastelt, dass es zulässt, dass die Templates vom Kunden erstellt werden, also auch per HTTP von einem entfernten Webserver geholt werden können (in der Regel von seinem). Und da darf ja dann kein aktiver PHP-Code mehr enthalten sein.
Für mich sieht das eher nach einem weiteren Dreieck aus das als Rad verkauft werden soll.)
Man kann durchaus auch PHP-Code in einem Template gegen erlaubte Bezeichner/Operatoren validieren (ausgehend von token_get_all).
Das ist mit IMHO einfacher/sicherer als die Umsetzung einer weiteren i.d.R. unzulänglichen Template-Syntax.Für ein Template reichen als "Whitelists" meist ein paar Operatoren/Token (+-?: etc.),
die Bezeichner der alternativen Syntax (foreach: if: etc.),
sowie einige ausgesuchte Funktionen zur Zeichen- und Zahlenformatierung bzw. Berechnung.Die sich daraus ergebenden Vorteile sind:
1. Kunden mit PHP-Kenntniss müssen keine weitere nutzlose Syntax erlernen
2. Kunden können ggf. notwendige Berechnungen/Formatierung vornehmen die ein Template-System mit eigener Syntax irgendwie nachbilden müsste
3. Validierte Templates lassen sich direkt mit include einbinden, wodurch die Vorteile eines Opcode-Caches genutzen werden können*
4. Templates mit PHP-Code Einschüben können in einem brauchbaren Editor sinnvoll ausgezeichnet/überpüft/gefaltet werden*Template-Systeme müssen dazu zusätzliche Dateien erzeugen
-
Hello,
<!-- repeat_form--><!--{RECNO}--><!-- of form opinionbook_list_static -->
<tr>
<td><!--{CALC_ENTRY_DATE}--></td>
<td><!--{OWNER}--></td>
<td><!--{SUBJECT}--></td>
<td><input type="submit" name="btn[view][<!--{RECNO}-->]" value="ansehen"></td>
</tr>
<tr>
<td colspan="4" style="white-space:pre;"><!--{CALC_CONTENT}--></td>
</tr>Ich wollte das Rad nochmal erfinden und habe für unser kleines Collaborate-CMS ein Templatesystem gebastelt, dass es zulässt, dass die Templates vom Kunden erstellt werden, also auch per HTTP von einem entfernten Webserver geholt werden können (in der Regel von seinem). Und da darf ja dann kein aktiver PHP-Code mehr enthalten sein.
Für mich sieht das eher nach einem weiteren Dreieck aus das als Rad verkauft werden soll.)
Klar, du hast ja auch nur drei Ecken von unserem Vieleck gesehen bisher :-P
Man kann durchaus auch PHP-Code in einem Template gegen erlaubte Bezeichner/Operatoren validieren (ausgehend von token_get_all).
Man muss aber nicht, wenn man nicht will. Und der Anspruch dieses Systems ist nunmal die absolute Trennung von Daten und Formatbeschreibungssprache/Auszeichnungssprache. Das muss nämlich nicht HTML sein, es kann auch HSV-Form oder eine Ableger von RTF sein.
Das ist mit IMHO einfacher/sicherer als die Umsetzung einer weiteren i.d.R. unzulänglichen Template-Syntax.
Die Template-Syntax ist nachher ganz einfach. Alle in Templates enthaltenen Daten werden durch Platzhalter ersetzt. Wir haben uns jetzt für die Schreibweise |{PLATZHALTER(index)}| entschieden. Es gibt bisher nur einen geschützten Platzhalter, nämlich |{REPEAT}|. Bislang lösst sich so alles darstellen. Wir sind aber noch nicht ganz fertig - das räumen wir durchaus ein. Vielleicht kommt ja nuoch eine "Über-Geraschung".
Für ein Template reichen als "Whitelists" meist ein paar Operatoren/Token (+-?: etc.),
Den Zusammenhang habe ich jetzt nicht verstanden. Wie meinst Du das?
die Bezeichner der alternativen Syntax (foreach: if: etc.),
Brauchen wir nicht.
sowie einige ausgesuchte Funktionen zur Zeichen- und Zahlenformatierung bzw. Berechnung.
Brauchen wir auch nicht, weil alles Absonderliche, was nicht durch die Auszeichnungsprache erledigt werden kann, unterlassen werden muss. Ganz simple Ausnahmen bestätigen, wie immer, die Regel.
Die sich daraus ergebenden Vorteile sind:
- Kunden mit PHP-Kenntniss müssen keine weitere nutzlose Syntax erlernen
Müssen sie bei uns auch nicht.
- Kunden können ggf. notwendige Berechnungen/Formatierung vornehmen die ein Template-System mit eigener Syntax irgendwie nachbilden müsste
Versstehe ich jetzt nicht.
- Validierte Templates lassen sich direkt mit include einbinden, wodurch die Vorteile eines Opcode-Caches genutzen werden können*
Der Kunde kann sein Template mittels "validator.w3.org" (kennst Du?) validieren. Wenn es sein muss, kann unser System das bei Anmeldung des Templates auch.
- Templates mit PHP-Code Einschüben können in einem brauchbaren Editor sinnvoll ausgezeichnet/überpüft/gefaltet werden
Unsere Templates enthalten nur die Elemente der jeweiligen Formatbeschreibungs- oder Auszeichnungssprache, können also keine "aktiven" Teile enthalten. Sollten sie das doch tun, dann werden die einfach als Quellcode mit ausgegeben, aber nicht interpretiert.
*Template-Systeme müssen dazu zusätzliche Dateien erzeugen
Wir müssen nichts zusätzlich erzeugen.
Unsere Devise ist: "Keep it simple and simplify" oder wie auch immer Du "KISS" übersetzen magst.Die Daten liefern wir, die Darstellung der Kunde.
Wenn er sein HTML-Template und sein CSS nicht valide hält, können wir das zwar feststellen, wollen wir aber gar nicht unbedingt. Ist doch seine Sache, wenn seine Webseite blinkt und zwitschert, Hauptsache die von uns zu liefernden Daten stimmen.
Während Andere "Web 2.0" basteln, haben wir uns mit "Web Client-Server" beschäftigt :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-