Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #4961 > unrolled thread

"Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern

Back to article view | Back to de.comp.lang.php

Contents

  "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-04 00:36 +0100
    Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-04 07:57 +0000
      Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-04 09:17 +0100
        Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Claus Reibenstein <creibens@gmail.com> - 2025-11-04 11:33 +0100
        Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-04 11:26 +0000
          Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-04 20:36 +0100
            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-19 20:17 +0100
              Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-19 21:24 +0100
                Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-20 01:16 +0100
                  Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-21 17:59 +0100
                    Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Markus Heinz <markus.heinz@uni-dortmund.de> - 2025-11-22 01:12 +0100
                      Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-26 14:21 +0100
                    Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-27 08:42 +0100
              Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-28 09:35 +0100
                Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-11-28 10:51 +0100
                  Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-12-04 14:21 +0100
                    Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-12-07 15:43 +0100
                      Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-12-07 20:09 +0100
                        Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-12-07 19:36 +0000
                          Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-12-07 21:55 +0100
                            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-12-08 09:07 +0000
                              Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-12-11 14:07 +0100
                                Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-12-11 18:45 +0000
                            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-12-15 12:23 +0100
      Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-08 07:20 +0100
        Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-08 10:05 +0000
          Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-08 18:10 +0100
            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-08 19:50 +0000
          Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-11-10 01:58 +0100
            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-10 09:52 +0100
            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Andreas Borutta <borumat@gmx.de> - 2025-11-10 09:53 +0100
            Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-10 09:20 +0000
              Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-11-10 11:12 +0100
                Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-10 11:09 +0000
                  Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-11-10 17:51 +0100
                    Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-11 08:09 +0000
                      Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Arno Welzel <usenet@arnowelzel.de> - 2025-11-11 10:16 +0100
                        Re: "Prettify" (Umbrüche, Leerzeichen) vor dem Ausliefern Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-11-11 10:03 +0000

Page 2 of 2 — ← Prev page 1 [2]

#5008

On Sun, 07 Dec 2025 21:55:57 Andreas Borutta wrote:
> Stefan Froehlich:
>> On Sun, 07 Dec 2025 20:09:34 Andreas Borutta wrote:
>>> Arno Welzel:
>>>> Andreas Borutta, 2025-12-04 14:21:
>>> Wir reden ja über das Konzept von Erweiterungen. Ich nahm an,
>>> dass es für den Standardfall "Erweiterung X anwenden" den
>>> fertigen Befehl gibt.

>> Naja, es sind doch eh nur drei Befehle: Daten einlesen, Daten
>> verarbeiten, Daten ausgeben:
 
>>| $tidy->parseString($html, $config, 'utf8');
>>| $tidy->cleanRepair();
>>| return (string) $tidy;
 
>> Der ganze Rest drumherum ist Initialisierung, Prüfung und
>> Fehlerverarbeitung. Fast alles davon könntest Du theoretisch auch
>> weglassen, aber wenn dann irgendetwas nicht nach Plan läuft,
>> fliegt Dir das Programm um die Ohren - das ist kein Gewinn.

> Sollte denn die Aufgaben Initialisierung, Prüfung und
> Fehlerverarbeitung nicht Bestandteil jeder Erweiterung oder des
> aufrufenden Moduls sein.

Sind sie ja auch, nur:

> Mir leuchtet bisher eine Architektur nicht ein, wo der jeder
> Anwender einer Erweiterung "das Rad neu erfindet" - nur um die
> Erweiterung aufzurufen.

...ist es dennoch keine Neuerfindung des Rades: Teilweise stellen
sich zusätzliche Fragen, und häufig müssen diese Dinge auf jeder
Ebene innerhalb einer Software stattfinden. Schauen wir es uns an:

| // Prüfe ob Tidy verfügbar ist
| if (!class_exists('tidy')) {
|   return $html;
| }

Das kann naturgemäß nicht innerhalb von tidy passieren. Lässt Du
diese Zeilen weg, passiert nichts schlimmes - solange tidy
installiert ist, andernfalls stürzt die Software einfach ab (bzw.
passiert das, was irgendeine Fehlerroutine weiter oben vorsieht, und
das wird ziemlich sicher nicht die Rückgabe des unformatierten
Quelltexts sein). Drei Zeilen, die praktisch nichts kosten, sich
ggf. aber lohnen.

| // Lade Config
| $iniFile = __DIR__ . '/tidy.ini';
| $config = file_exists($iniFile)
|   ? parse_ini_file($iniFile, false, INI_SCANNER_TYPED)
|   : [];

Auch die Initialisierung von tidy kann naturgemäß nicht in tidy
passieren. Brauchst Du keine (via externer Datei durchgeführte)
Initialisierung, kannst Du diese Zeilen auch einfach weglassen, aber
es ist IMO durchaus sinnvoll, in einer generischen Erweiterung die
Möglichkeit dafür vorzusehen. Auch das kostet ja praktisch nichts.

| // Fallback auf Default-Config wenn Parse fehlschlägt
| if ($config === false) {
|   $config = [
|     'indent' => true,
|     'wrap' => 0,
|     'output-html' => true,
| ]  ;
| }

Das mag der am ehesten redundante Teil der Geschichte sein: Es gibt
eine Konfigurationsdatei, aber sie ist kaputt. Hier könnte man auch
einfach auf [] zurückfallen, so wie es bei fehlender Datei getan
wird. Geschmacksfrage, aber auch hier: Kostet fast nichts, kann man
halten, wie man möchte.

| // Fehlerbehandlung
| if ($tidy->errorBuffer) {
|   // Optional: Logge Tidy-Warnungen
|   // error_log('Tidy warnings: ' . $tidy->errorBuffer);
| }

Die Fehlerbehandlung passiert innerhalb von tidy - tidy schreibt die
Fehlermeldungen in einen Puffer, aber tidy kann nicht wissen, wie
damit umgegangen werden soll. Wer sie nicht braucht, kann sie auch
ignorieren, aber sie ggf. weiterzureichen erscheint nicht ganz dumm.
(Kostet auch hier wieder nicht viel, zumal im Regelfall ja keine
Meldungen vorhanden sein sollten).

| try {
|   [...]
| } catch (\Exception $e) {
|   // Bei Fehler: Original-HTML zurückgeben
|   return $html;
| }

Und zu guter Letzt überlegen wir uns noch, was passiert, wenn tidy
selbst fehlerhaft ist, Lassen wir unsere Software dann einfach
abstürzen (so wie oben, beim Fehlen von tidy), oder tun wir so, als
wäre alles in Ordnung und geben den unformatierten Quelltext zurück?
Auch diese Entscheidung kann nur lokal getroffen werden, und für die
zweite, IMO zu bevorzugende Option sind neuerlich ein paar wenige
Zeilen Code erforderlich.

In Summe also 5x mehr Schutzmaßnahmen als eigentliche Arbeit, und
das wiederholt sich vermutlich ganz ähnlich auf den Ebenen darunter
(innerhalb von tidy) und darüber.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - lutschen!? Aber verseuchen ist makelloser.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#5009

Stefan Froehlich:

> On Sun, 07 Dec 2025 21:55:57 Andreas Borutta wrote:
>> Stefan Froehlich:
>>> On Sun, 07 Dec 2025 20:09:34 Andreas Borutta wrote:
>>>> Arno Welzel:
>>>>> Andreas Borutta, 2025-12-04 14:21:
>>>> Wir reden ja über das Konzept von Erweiterungen. Ich nahm an,
>>>> dass es für den Standardfall "Erweiterung X anwenden" den
>>>> fertigen Befehl gibt.
> 
>>> Naja, es sind doch eh nur drei Befehle: Daten einlesen, Daten
>>> verarbeiten, Daten ausgeben:
>  
>>>| $tidy->parseString($html, $config, 'utf8');
>>>| $tidy->cleanRepair();
>>>| return (string) $tidy;
>  
>>> Der ganze Rest drumherum ist Initialisierung, Prüfung und
>>> Fehlerverarbeitung. Fast alles davon könntest Du theoretisch auch
>>> weglassen, aber wenn dann irgendetwas nicht nach Plan läuft,
>>> fliegt Dir das Programm um die Ohren - das ist kein Gewinn.
> 
>> Sollte denn die Aufgaben Initialisierung, Prüfung und
>> Fehlerverarbeitung nicht Bestandteil jeder Erweiterung oder des
>> aufrufenden Moduls sein.
> 
> Sind sie ja auch, nur:
> 
>> Mir leuchtet bisher eine Architektur nicht ein, wo der jeder
>> Anwender einer Erweiterung "das Rad neu erfindet" - nur um die
>> Erweiterung aufzurufen.
> 
> ...ist es dennoch keine Neuerfindung des Rades: Teilweise stellen
> sich zusätzliche Fragen, und häufig müssen diese Dinge auf jeder
> Ebene innerhalb einer Software stattfinden. Schauen wir es uns an:
> 
>| // Prüfe ob Tidy verfügbar ist
>| if (!class_exists('tidy')) {
>|   return $html;
>| }
> 
> Das kann naturgemäß nicht innerhalb von tidy passieren. Lässt Du
> diese Zeilen weg, passiert nichts schlimmes - solange tidy
> installiert ist, andernfalls stürzt die Software einfach ab (bzw.
> passiert das, was irgendeine Fehlerroutine weiter oben vorsieht, und
> das wird ziemlich sicher nicht die Rückgabe des unformatierten
> Quelltexts sein). Drei Zeilen, die praktisch nichts kosten, sich
> ggf. aber lohnen.
> 
>| // Lade Config
>| $iniFile = __DIR__ . '/tidy.ini';
>| $config = file_exists($iniFile)
>|   ? parse_ini_file($iniFile, false, INI_SCANNER_TYPED)
>|   : [];
> 
> Auch die Initialisierung von tidy kann naturgemäß nicht in tidy
> passieren. Brauchst Du keine (via externer Datei durchgeführte)
> Initialisierung, kannst Du diese Zeilen auch einfach weglassen, aber
> es ist IMO durchaus sinnvoll, in einer generischen Erweiterung die
> Möglichkeit dafür vorzusehen. Auch das kostet ja praktisch nichts.
> 
>| // Fallback auf Default-Config wenn Parse fehlschlägt
>| if ($config === false) {
>|   $config = [
>|     'indent' => true,
>|     'wrap' => 0,
>|     'output-html' => true,
>| ]  ;
>| }
> 
> Das mag der am ehesten redundante Teil der Geschichte sein: Es gibt
> eine Konfigurationsdatei, aber sie ist kaputt. Hier könnte man auch
> einfach auf [] zurückfallen, so wie es bei fehlender Datei getan
> wird. Geschmacksfrage, aber auch hier: Kostet fast nichts, kann man
> halten, wie man möchte.
> 
>| // Fehlerbehandlung
>| if ($tidy->errorBuffer) {
>|   // Optional: Logge Tidy-Warnungen
>|   // error_log('Tidy warnings: ' . $tidy->errorBuffer);
>| }
> 
> Die Fehlerbehandlung passiert innerhalb von tidy - tidy schreibt die
> Fehlermeldungen in einen Puffer, aber tidy kann nicht wissen, wie
> damit umgegangen werden soll. Wer sie nicht braucht, kann sie auch
> ignorieren, aber sie ggf. weiterzureichen erscheint nicht ganz dumm.
> (Kostet auch hier wieder nicht viel, zumal im Regelfall ja keine
> Meldungen vorhanden sein sollten).
> 
>| try {
>|   [...]
>| } catch (\Exception $e) {
>|   // Bei Fehler: Original-HTML zurückgeben
>|   return $html;
>| }
> 
> Und zu guter Letzt überlegen wir uns noch, was passiert, wenn tidy
> selbst fehlerhaft ist, Lassen wir unsere Software dann einfach
> abstürzen (so wie oben, beim Fehlen von tidy), oder tun wir so, als
> wäre alles in Ordnung und geben den unformatierten Quelltext zurück?
> Auch diese Entscheidung kann nur lokal getroffen werden, und für die
> zweite, IMO zu bevorzugende Option sind neuerlich ein paar wenige
> Zeilen Code erforderlich.
> 
> In Summe also 5x mehr Schutzmaßnahmen als eigentliche Arbeit, und
> das wiederholt sich vermutlich ganz ähnlich auf den Ebenen darunter
> (innerhalb von tidy) und darüber.

Erstmal vielen Dank für deine Erläuterungen : )

Vielleicht gibt es noch ein Missverständnis zu meiner Frage.

Ich vertraue euch erfahrenen Programmierern selbstverständlich, dass
der Code sinnvoll ist und die damit gelösten Aufgaben auch.

Mir ist nur nicht klar, dass es dafür keine "Schicht" gibt, die fix
und fertig bereit steht. Weil diese Aufgaben für jeden anfallen, der
Tidy nutzen möchte. 

Aber wir müssen das auch nicht weiter vertiefen. Ich muss eh hinnehmen
dass es diese "Schicht", diese "Architektur" nicht gibt.


Andreas
-- 
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#5010

On Thu, 11 Dec 2025 14:07:31 Andreas Borutta wrote:
> Stefan Froehlich:
>> [...]
>> In Summe also 5x mehr Schutzmaßnahmen als eigentliche Arbeit, und
>> das wiederholt sich vermutlich ganz ähnlich auf den Ebenen
>> darunter (innerhalb von tidy) und darüber.
> 
> Erstmal vielen Dank für deine Erläuterungen : )
> 
> Vielleicht gibt es noch ein Missverständnis zu meiner Frage.
> 
> Ich vertraue euch erfahrenen Programmierern selbstverständlich,
> dass der Code sinnvoll ist und die damit gelösten Aufgaben auch.

> Mir ist nur nicht klar, dass es dafür keine "Schicht" gibt, die
> fix und fertig bereit steht. Weil diese Aufgaben für jeden
> anfallen, der Tidy nutzen möchte. 

Doch, ich hatte Dich schon genau so interpretiert, nur: Wie sollte
das funktionieren? Manche Dinge (z.B. die Initialisierung) sind
nicht für jede Anwendung gleich, und bei Fehlern wird nicht jede
Anwendung ident reagieren wollen (hier ganz klar durch: Gib den
unformatierten Code aus, damit wenigstens der User seine Seite
bekommt - in anderen Umgebungen möchte man evt. genau im Gegenteil
den User möglichst deutlich auf den/die Fehler hinweisen).

> Aber wir müssen das auch nicht weiter vertiefen. Ich muss eh
> hinnehmen dass es diese "Schicht", diese "Architektur" nicht gibt.

Welche Schicht auch immer da noch eingezogen würde, am Ende müsste
man so ziemlich alle der obigen Entscheidungen erst recht wieder
in irgendeiner Art und Weise treffen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die vollkommenste Sache der Poesie!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#5011

Andreas Borutta, 2025-12-07 21:55:

> Stefan Froehlich:
[...]
>> Naja, es sind doch eh nur drei Befehle: Daten einlesen, Daten
>> verarbeiten, Daten ausgeben:
>>
>> | $tidy->parseString($html, $config, 'utf8');
>> | $tidy->cleanRepair();
>> | return (string) $tidy;
>>
>> Der ganze Rest drumherum ist Initialisierung, Prüfung und
>> Fehlerverarbeitung. Fast alles davon könntest Du theoretisch auch
>> weglassen, aber wenn dann irgendetwas nicht nach Plan läuft, fliegt
>> Dir das Programm um die Ohren - das ist kein Gewinn.
> 
> Sollte denn die Aufgaben Initialisierung, Prüfung und
> Fehlerverarbeitung nicht Bestandteil jeder Erweiterung oder des
> aufrufenden Moduls sein.
> 
> Mir leuchtet bisher eine Architektur nicht ein, wo der jeder Anwender
> einer Erweiterung "das Rad neu erfindet" - nur um die Erweiterung
> aufzurufen.

Kirby bietet offensichtlich Möglichkeit an, eine "Template"-Klasse zu
erstellen, die dann zusätzliche Dinge machen, wie z.B. bei der Ausgabe
des Dokuments vorher noch Dinge mit dem Inhalt zu machen.

Dazu ist der vermutlich vorgesehene Minimalcode:

class TidyTemplate extends Template
{
    public function render(array $data = []): string
    {
        $html = parent::render($data);
        return $html;
    }
}

Warum ist das so? Weil $data eben kein HTML ist, sondern die Daten, die
Kirby hat, um daraus dann HTML zu generieren. Und ja, das ist sicher
sinnvoll, da ein Template u.U. eben nicht nur HTML verarbeiten soll,
sondern auch die zugrundeliegenden Daten kenne soll, die für das HTML
verwendet werden sollen.

Und von Dir kamen jetzt eben noch ein paar Dinge dazu, um auch Tidy zu
verwenden. Du kannst Dir die Prüfung auf "existiert Tidy überhaupt" etc.
natürlich auch sparen, da Du ja selber weißt, wo deine eigene
Template-Implementierung laufen soll und Du da auch sicherstellen
kannst, dass die Tidy-Erweiterung in PHP eingerichtet wurde:

class TidyTemplate extends Template
{
    public function render(array $data = []): string
    {
        $html = parent::render($data);
        $tidy = new tidy();
        $tidy->parseString($html, $config, 'utf8');
        $tidy->cleanRepair();
        return (string) $tidy;
    }
}

Und dass Tidy selbst so benutzt wird, ist halt so - so funktioniert Tidy
halt, dass es nicht nur einen simplen Funktionsaufruf hat, der dann das
bereinigte HTML zurückliefert. Für PHP wurde das nicht extra so
entwickelt, sondern PHP nutzt halt hier die Tidy-Bibliothek, wie sie
angeboten wird.

Viele Werkzeue sind halt so, dass sie unterschiedliche Funktionen bieten
und man muss sie eben so anwenden, wie sie für den eigenen Zweck am
besten funktionieren.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4967

Stefan Froehlich:

> Ich habe am Ende meiner Programme idR einen Aufruf von tidy(1),
> das genau diesen Job rasch und zuverlässig leistet.

Aus Neugier:

Lässt du die optionalen Endtags entfernen?

(body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)

Andreas
-- 
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#4968

On Sat, 08 Nov 2025 07:20:31 Andreas Borutta wrote:
> Stefan Froehlich:
>> Ich habe am Ende meiner Programme idR einen Aufruf von tidy(1),
>> das genau diesen Job rasch und zuverlässig leistet.

> Aus Neugier:
> 
> Lässt du die optionalen Endtags entfernen?
> (body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)

Himmel, nein!

HTML sollte so XML wie möglich sein, in meinen Augen. Jede
Abweichung davon war von Anfang an ein Sündenfall.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Ein edles Teil! Stefan, so schmierig...
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4969

Stefan Froehlich:

> On Sat, 08 Nov 2025 07:20:31 Andreas Borutta wrote:
>> Stefan Froehlich:
>>> Ich habe am Ende meiner Programme idR einen Aufruf von tidy(1),
>>> das genau diesen Job rasch und zuverlässig leistet.
> 
>> Aus Neugier:
>> 
>> Lässt du die optionalen Endtags entfernen?
>> (body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)
> 
> Himmel, nein!

Ich dachte mir das schon : )

Aber sind dir denn Situationen bekannt, wo das zu einem Problem führen
würde? 

Ich habe noch nichts entdecken können.

Auf die Sache gestoßen wurde ich vor Jahren bei Jens Meiert.

https://meiert.com/blog/optional-html/

Einen einzigen potentiell kritischen Fall erwähnt er dort selber.
<p>Lorem
<img ...>

Selber platziere ich imgs tradtionell nicht "nackt" ohne
Blocklevel-Elternelement.




Andreas
-- 
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#4970

On Sat, 08 Nov 2025 18:10:48 Andreas Borutta wrote:
> Stefan Froehlich:
>> On Sat, 08 Nov 2025 07:20:31 Andreas Borutta wrote:
>>> Lässt du die optionalen Endtags entfernen?
>>> (body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)

>> Himmel, nein!

> Ich dachte mir das schon : )

> Aber sind dir denn Situationen bekannt, wo das zu einem Problem
> führen würde?

Im Grund genommen jede Routineuntersuchung, bei der mein Blutdruck
gemessen wird.

Ansonsten: natürlich nicht, nein.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der grandiose Spaß reichlicher Klagen. Stefan!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4971

Stefan Froehlich, 2025-11-08 11:05:

> On Sat, 08 Nov 2025 07:20:31 Andreas Borutta wrote:
>> Stefan Froehlich:
>>> Ich habe am Ende meiner Programme idR einen Aufruf von tidy(1),
>>> das genau diesen Job rasch und zuverlässig leistet.
> 
>> Aus Neugier:
>>
>> Lässt du die optionalen Endtags entfernen?
>> (body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)
> 
> Himmel, nein!
> 
> HTML sollte so XML wie möglich sein, in meinen Augen. Jede
> Abweichung davon war von Anfang an ein Sündenfall.

HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
auch <https://www.rfc-editor.org/rfc/rfc1866>.

Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
nicht erst in HTML erfunden.

XHTML wurde erst später explizit als XML-kompatible Variante entwickelt.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4972

Arno Welzel:

>> HTML sollte so XML wie möglich sein, in meinen Augen. Jede
>> Abweichung davon war von Anfang an ein Sündenfall.
> 
> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
> auch <https://www.rfc-editor.org/rfc/rfc1866>.
> 
> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
> nicht erst in HTML erfunden.

Ich werde, sobald ich mehr von der Konfiguration meines CMS Kirby
verstanden habe, versuchen einen "Prettifyer" zu realisieren, der
nicht nur "gut einrückt und umbricht", sondern auch optionale Endtags
entfernt.
Das Schließen von "Void Elements" kann auch weg.
Und überflüssige Anführungszeichen in Attributwerten.

Mir gefiel es immer schon, wenn Quelltext hübsch und minimal ist.


Andreas
-- 
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#4973

Arno Welzel:

>> HTML sollte so XML wie möglich sein, in meinen Augen. Jede
>> Abweichung davon war von Anfang an ein Sündenfall.
> 
> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
> auch <https://www.rfc-editor.org/rfc/rfc1866>.
> 
> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
> nicht erst in HTML erfunden.

Ich werde, sobald ich mehr von der Konfiguration meines CMS Kirby
verstanden habe, versuchen einen "Prettifyer" zu realisieren, der
nicht nur "gut einrückt und umbricht", sondern auch optionale Endtags
entfernt.
Das Schließen von "Void Elements" kann auch weg.
Und überflüssige Anführungszeichen in Attributwerten.

Siehe auch: <https://meiert.com/blog/stop-closing-void-elements/>

Mir gefiel es immer schon, wenn Quelltext hübsch und minimal ist.


Andreas
-- 
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#4974

On Mon, 10 Nov 2025 01:58:01 Arno Welzel wrote:
> Stefan Froehlich, 2025-11-08 11:05:
>> On Sat, 08 Nov 2025 07:20:31 Andreas Borutta wrote:
>>> Stefan Froehlich:
>>>> Ich habe am Ende meiner Programme idR einen Aufruf von tidy(1),
>>>> das genau diesen Job rasch und zuverlässig leistet.
>> 
>>> Aus Neugier:
>>>
>>> Lässt du die optionalen Endtags entfernen?
>>> (body|caption|head|html|input|li|link|p|tbody|thead|tfoot|td|th|tr)
>> 
>> Himmel, nein!
>> 
>> HTML sollte so XML wie möglich sein, in meinen Augen. Jede
>> Abweichung davon war von Anfang an ein Sündenfall.
> 
> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
> auch <https://www.rfc-editor.org/rfc/rfc1866>.
> 
> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
> nicht erst in HTML erfunden.

Das ist genau das, was ich als Sündenfall bezeichne. So etwas sollte
man in meinen Augen gar nicht erst in die Welt setzen.

> XHTML wurde erst später explizit als XML-kompatible Variante
> entwickelt.

Zu spät, da war das Kind schon in den Brunnen gefallen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. über den schlampischen Klee zu loben!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4975

Stefan Froehlich, 2025-11-10 10:20:

> On Mon, 10 Nov 2025 01:58:01 Arno Welzel wrote:
[...]
>> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
>> auch <https://www.rfc-editor.org/rfc/rfc1866>.
>>
>> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
>> nicht erst in HTML erfunden.
> 
> Das ist genau das, was ich als Sündenfall bezeichne. So etwas sollte
> man in meinen Augen gar nicht erst in die Welt setzen.

Dann war der "Sündenfall" aber SGML und nicht HTML.

Und als HTML erfunden wurde, gab es noch gar kein XML. Das kam erst
1998. HTML war aber schon 6 Jahre vorher da, im Jahr 1992.

Konkret also:

SGML (1986) ---> HTML (1992)
SGML (1986) ---> XML (1998)

Wo genau ist da jetzt der "Sündenfall" bei HTML? Du verwechselst hier
glaube ich ein paar Dinge.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4976

On Mon, 10 Nov 2025 11:12:31 Arno Welzel wrote:
> Stefan Froehlich, 2025-11-10 10:20:
>> On Mon, 10 Nov 2025 01:58:01 Arno Welzel wrote:
> [...]
>>> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
>>> auch <https://www.rfc-editor.org/rfc/rfc1866>.

>>> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
>>> nicht erst in HTML erfunden.

>> Das ist genau das, was ich als Sündenfall bezeichne. So etwas sollte
>> man in meinen Augen gar nicht erst in die Welt setzen.

> Dann war der "Sündenfall" aber SGML und nicht HTML.

Stimmt schon. SGML hat halt immer nur eine sehr lokale Bedeutung
gehabt.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - niemand beschallt falscher oder auch fanatischer.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4977

Stefan Froehlich, 2025-11-10 12:09:

> On Mon, 10 Nov 2025 11:12:31 Arno Welzel wrote:
>> Stefan Froehlich, 2025-11-10 10:20:
>>> On Mon, 10 Nov 2025 01:58:01 Arno Welzel wrote:
>> [...]
>>>> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
>>>> auch <https://www.rfc-editor.org/rfc/rfc1866>.
> 
>>>> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
>>>> nicht erst in HTML erfunden.
> 
>>> Das ist genau das, was ich als Sündenfall bezeichne. So etwas sollte
>>> man in meinen Augen gar nicht erst in die Welt setzen.
> 
>> Dann war der "Sündenfall" aber SGML und nicht HTML.
> 
> Stimmt schon. SGML hat halt immer nur eine sehr lokale Bedeutung
> gehabt.

Es diente als Grundlage für HTML und XML und DTDs kommen auch von SGML -
so ganz unbedeutend war es dann wohl nicht ;-)


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4978

On Mon, 10 Nov 2025 17:51:23 Arno Welzel wrote:
> Stefan Froehlich, 2025-11-10 12:09:
>> On Mon, 10 Nov 2025 11:12:31 Arno Welzel wrote:
>>> Stefan Froehlich, 2025-11-10 10:20:
>>>> On Mon, 10 Nov 2025 01:58:01 Arno Welzel wrote:
>>> [...]
>>>>> HTML war nie XML, sondern basierte von den Ideen her auf SGML. Siehe
>>>>> auch <https://www.rfc-editor.org/rfc/rfc1866>.
>> 
>>>>> Und SGML erlaubt ebenfalls, schließende Tags wegzulassen - das wurde
>>>>> nicht erst in HTML erfunden.
>> 
>>>> Das ist genau das, was ich als Sündenfall bezeichne. So etwas sollte
>>>> man in meinen Augen gar nicht erst in die Welt setzen.
>> 
>>> Dann war der "Sündenfall" aber SGML und nicht HTML.
>> 
>> Stimmt schon. SGML hat halt immer nur eine sehr lokale Bedeutung
>> gehabt.

> Es diente als Grundlage für HTML und XML und DTDs kommen auch von SGML -
> so ganz unbedeutend war es dann wohl nicht ;-)

Das bezog sich auf die Verwendung. Ist ein bisschen vor meiner Zeit,
aber bei SGML-Files war doch gerne derjenige, der sie erstellt hat
auch derjenige, der sie verarbeitet bzw. die Software dafür
geschrieben hat. Da kann man tun, wie man lustig ist.

Bei XML hat man viele Schwächen ausgebügelt, bei HTML leider nicht.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan, so wundervoll wie das Weinen.
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#4979

Stefan Froehlich, 2025-11-11 09:09:

> On Mon, 10 Nov 2025 17:51:23 Arno Welzel wrote:
[...]
>> Es diente als Grundlage für HTML und XML und DTDs kommen auch von SGML -
>> so ganz unbedeutend war es dann wohl nicht ;-)
> 
> Das bezog sich auf die Verwendung. Ist ein bisschen vor meiner Zeit,
> aber bei SGML-Files war doch gerne derjenige, der sie erstellt hat
> auch derjenige, der sie verarbeitet bzw. die Software dafür
> geschrieben hat. Da kann man tun, wie man lustig ist.
> 
> Bei XML hat man viele Schwächen ausgebügelt, bei HTML leider nicht.

HTML war ja - wie SGML - auch dafür gedacht, von *Menschen* benutzt zu
werden. Und da ist weniger Tipparbeit, durch die Möglichkeit, Endtags
weglassen zu können, ein Vorteil.

Aber in deiner Welt müsst es vermutlich konsequent immer <br /> sein
oder noch besser <br></br>, damit Parser sich möglichst wenig Arbeit
machen müssen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4980

On Tue, 11 Nov 2025 10:16:22 Arno Welzel wrote:
> Stefan Froehlich, 2025-11-11 09:09:
>> On Mon, 10 Nov 2025 17:51:23 Arno Welzel wrote:
> [...]
>>> Es diente als Grundlage für HTML und XML und DTDs kommen auch von SGML -
>>> so ganz unbedeutend war es dann wohl nicht ;-)
>> 
>> Das bezog sich auf die Verwendung. Ist ein bisschen vor meiner Zeit,
>> aber bei SGML-Files war doch gerne derjenige, der sie erstellt hat
>> auch derjenige, der sie verarbeitet bzw. die Software dafür
>> geschrieben hat. Da kann man tun, wie man lustig ist.
>> 
>> Bei XML hat man viele Schwächen ausgebügelt, bei HTML leider nicht.
 
> HTML war ja - wie SGML - auch dafür gedacht, von *Menschen*
> benutzt zu werden. Und da ist weniger Tipparbeit, durch die
> Möglichkeit, Endtags weglassen zu können, ein Vorteil.

Das war genau der initiale Fehler. Im Grund genommen war von Anfang
an abzusehen, dass HTML sehr bald so gut wie gar nicht manuell
geschrieben werden wird.

> Aber in deiner Welt müsst es vermutlich konsequent immer <br />
> sein

Selbstverständlich.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die riesigste Beschreibung der Erotik.</b
(Sloganizer)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comp.lang.php

csiph-web