[PHP] Zeilenumbruch!

[Bluescreen]

Kein guter Ansatz. Wenn du Schwierigkeiten kriegst, weil dein PHP-Skript an irgendeiner Stelle nicht wohlgeformten Output erzeugt oder weil einfach ein Styesheet nicht das tut, was es tun sollte, dann wirst du dir ordentliche Zeilenumbrüche und Einrückung wünschen.

...

Ganz meine Meinung. Und die (Probleme) wird man schon bekommen, wenn man groößere Projekte mal editieren muss!

Zum Thema "<br>"* vs. "\n": "<br>" verwendest du nur, wenn du HTML ausgibst. PHP muß aber nicht unbedingt HTML ausgeben. Ich habe Shellskripte in PHP geschrieben und verwende in einer Webanwendung ein PHP-Backend, um JSON-Strings zu erzeugen. Luki verwendet PHP als Präprozessor für das Datenformat einer Chemiesoftware (oder hat das mal getan). Da braucht man überall nur "\n".

Es kommt also immer darauf an, was man erzeugt - und das ist nicht immer HTML.

* "<br />" ignoriere ich mal, weil XHTML effektiv tot ist.

...

Schon, ich hab aber auch bewusst ins Webentwicklungs-Forum gepostet.

[Xardas der Dunkle]

* "<br />" ignoriere ich mal, weil XHTML effektiv tot ist.

...

Schwachsin! XHTML ist groß im kommen, zumal XHTML im Gegensatz zu HTML auch durch einen XML-Parser laufen kann ...
Vorallem spuckt PHP selber XHTML aus (siehe die Funktion nl2br)!

/EDIT: Ich weise auch mal auf den Doctype dieses Forums hin

[mitaki]

Schwachsin! XHTML ist groß im kommen, zumal XHTML im Gegensatz zu HTML auch durch einen XML-Parser laufen kann ...

...

Dreht man es etwas, erkennt man, dass XHTML von XML- und HTML-Parsern verarbeitet werden kann. Wobei das mit dem XML-Parser auch nicht immer stimmt.

Vorallem spuckt PHP selber XHTML aus (siehe die Funktion nl2br)!

...

Aus gerade genanntem Grund.

/EDIT: Ich weise auch mal auf den Doctype dieses Forums hin

...

Das ist doch der Beweis, dass dies gerade nicht der Fall ist.

Aber da XHTML schon mal da ist wirds auch weiterentwickelt, synchron zu HTML.

[Xardas der Dunkle]

Das mit dem Parser war jetzt nicht unbedingt auf den Parser des Browsers bezogen. (Zudem gehe ich von validem XHTML aus, was leider kaum einer umsetzt ).

Das ist doch der Beweis, dass dies gerade nicht der Fall ist.

...

Habe ich gesagt das es valide ist?, Ich sagte der Doctype ist ein XHTML-Doctype!

Aber da XHTML schon mal da ist wirds auch weiterentwickelt, synchron zu HTML.

...

Trotzdem ist XHTML einiges sauberer als HTML. Zudem sind beide Versionen die gerade in Planung sind Mist, <h>-Tag, anstatt <h[1-6]> was zu ein scheiß.

[mitaki]

Das mit dem Parser war jetzt nicht unbedingt auf den Parser des Browsers bezogen. (Zudem gehe ich von validem XHTML aus, was leider kaum einer umsetzt ).

...

Parser ist Parser. Letzteres ist leider wahr.

Habe ich gesagt das es valide ist?, Ich sagte der Doctype ist ein XHTML-Doctype!

...

Nein, aber was beweist das schon? Ich meine, es spricht nicht viel gegen XHTML, aber auch nicht viel dafür.

Trotzdem ist XHTML einiges sauberer als HTML. Zudem sind beide Versionen die gerade in Planung sind Mist, <h>-Tag, anstatt <h[1-6]> was zu ein scheiß.

...

XHTML ist einfacher auf Fehler zu prüfen, das wars aber auch schon.

Es ist ja bekannt, dass ich eher zu HTML 5 tendiere, welches du nur angestriffen hast. Ich denke diese Entwicklung geht in die Richtige Richtung und erlaubt das, was XHTML erlaubt auf autorenfreundlicherem Weg (SVG, MathML, Ruby).

XHTML 2.0 wird momentan nicht wirklich weiterentwickelt, die WG arbeitet an allem anderen, nur nicht daran.

[Crash-Override]

Trotzdem ist XHTML einiges sauberer als HTML. Zudem sind beide Versionen die gerade in Planung sind Mist, <h>-Tag, anstatt <h[1-6]> was zu ein scheiß.

...

Ist imho sehr viel logischer. Die Groesse und das Aussehen des letztendlichen Headers sollte mehr oder weniger sowieso von CSS uebernommen werden, da sind die 6 Abstufungen unangebracht, da man durch Klassen viel sinnvollere, je nach Situation, erzeugen kann.

[The Best Isaac]

Ist imho sehr viel logischer. Die Groesse und das Aussehen des letztendlichen Headers sollte mehr oder weniger sowieso von CSS uebernommen werden, da sind die 6 Abstufungen unangebracht, da man durch Klassen viel sinnvollere, je nach Situation, erzeugen kann.

...

Geht es bei den <h[1-6]>-Tags nicht eher um die logische Gliederung des Textes als um die gestalterische? Ist doch genauso wie mit dem <cite>-Tag, da wird der Text kursiv dargestellt, obwohl man das ganze, wenn's um das gestalterische geht, genauso gut mit dem <i>-Tag erreichen kann. Aber <cite> kennzeichnet eben ein Zitat (das soll dann z.B. für Sprachbrowser eine Kennung sein, das besonders zu betonen oder was weiß ich).
So gesehen hätten <h[1-6]> imo durchaus ihre Berechtigung.

[mitaki]

Geht es bei den <h[1-6]>-Tags nicht eher um die logische Gliederung des Textes als um die gestalterische? Ist doch genauso wie mit dem <cite>-Tag, da wird der Text kursiv dargestellt, obwohl man das ganze, wenn's um das gestalterische geht, genauso gut mit dem <i>-Tag erreichen kann. Aber <cite> kennzeichnet eben ein Zitat (das soll dann z.B. für Sprachbrowser eine Kennung sein, das besonders zu betonen oder was weiß ich).

...

Das Problem das XHTML 2.0 damit lösen möchte ist, dass man eben nur 6 Ebenen zur Gliederung zur Verfügung hat, mit <section> und <h> gibt es unendlich viele Untergliederungen.

HTML 5 definiert dagegen <h[1-6]> zusammen mit den neuen Elementen so um, dass dies auch hier möglich ist. Ein <section> Element gibt es hier ebenfalls, aber auch z.B. <article> usw.