Walli: Welche Syntax ist besser/zukunftsorientieter

Hallo,
welche der Formen

  
<script language="php">   (manchmal auch gelesen <script language=php>)  
....  
</script>

oder

  
<?php  
......  
?> 

ist vorzuziehen?

  1. Hallo,

    nutze immer <?php /* ... */ ?>.

    script-Elemente dürfen kein language-Attribut besitzen.

    Gruß, Daniel

    1. Hi,

      script-Elemente dürfen kein language-Attribut besitzen.

      in HTML 4.01 dürfen sie - aber das ist ja hier gar nicht relevant, denn die öffnenden und schließenden script-Tags müssen ja ebenso wie bei der üblichen Schreibweise <?php ... ?> vom PHP-Interpreter "konsumiert" werden, tauchen also in der Ausgabe nicht mehr auf.

      Ciao,
       Martin

      --
      Zivilisation bedeutet, dass die Eskimos warme Wohnungen bekommen und dann arbeiten müssen, damit sie sich einen Kühlschrank leisten können.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. ... <?php ... ?> vom PHP-Interpreter "konsumiert" werden, tauchen also in der Ausgabe nicht mehr auf.

        Korrekt !

        Da der Interpreter sie annimmt und nicht als Ausgabe wiedergibt ist es vollkommen "egal".

        Zukunftstechnisch gesehen glaube ich kaum das PHP Versionen in Zukunft kein <?php ?> mehr unterstützen werden ;)

    2. [latex]Mae  govannen![/latex]

      nutze immer <?php /* ... */ ?>.

      Soweit: Ja

      script-Elemente dürfen kein language-Attribut besitzen.

      Wie kommst du darauf? Bedenke, das dieses Script-Element nur _vor_ dem Parsen vorhanden ist, insofern sind HTML-Standards nicht anwendbar.

      Stur lächeln und winken, Männer!
      Kai

      --
      It all began when I went on a tour, hoping to find some furniture
       Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
      SelfHTML-Forum-Stylesheet
    3. Hallo,

      Hallo,

      nutze immer <?php /* ... */ ?>.

      http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."

      Gruß

      jobo

      1. Hallo,

        http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."

        Das würde ja allem bisher geschriebenen widersprechen!

        1. مرحبا

          http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."

          Das würde ja allem bisher geschriebenen widersprechen!

          Inwiefern?

          mfg

          1. Hallo,

            Das würde ja allem bisher geschriebenen widersprechen!

            Inwiefern?

            ... weil in dem Thread angegebenen Beispielen immer ?> am Ende angegeben war, ohne Hinweis auf die Ausnahme.

            1. مرحبا

              Inwiefern?

              ... weil in dem Thread angegebenen Beispielen immer ?> am Ende angegeben war, ohne Hinweis auf die Ausnahme.

              Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "?>" zu schliessen, wo ist da ein Widerspruch?
              Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.

              mfg

              1. Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "?>" zu schliessen, wo ist da ein Widerspruch?
                Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.

                Hallo,
                Ok - ich glaube Euch ja,
                aber bisher habe ich nun einmal gelesen, dass jedes öffnende tag auch wieder geschlossen werden sollte.
                Und was wäre daran:

                it´ prevents the accidental injection of trailing white space into the response

                schlimm?

                1. مرحبا

                  Ok - ich glaube Euch ja,

                  Das freut mich ;)

                  Es muss nicht einmal nur PHP-Code sein. Probiere es doch einfach aus:

                  <?php  /* index.php */  
                    
                    error_reporting(E_ALL | E_STRICT);  
                    
                  ?>  
                  <p>test</p>  
                  <?php  
                    
                    echo ' 1';  
                    
                  /* index.php ends */
                  

                  mfg

                  1. <?php  /* index.php */

                    error_reporting(E_ALL | E_STRICT);

                    ?>
                    <p>test</p>
                    <?php

                    echo ' 1';

                    /* index.php ends */

                    
                    >   
                      
                    Vermutlich verstand ich obiges nicht.  
                    Ich erhalte als Ausgabe  
                    test  
                    1
                    
                    1. مرحبا

                      Ich erhalte als Ausgabe
                      test
                      1

                      Richtig, auch ohne das schliessende "?>".
                      Und die vermeintlichen Probleme entstehen nicht, wenn du auf das abschliessende "?>" verzichtest, sondern umgekehrt.

                      mfg

                      1. Hallo,

                        Richtig, auch ohne das schliessende "?>".
                        Und die vermeintlichen Probleme entstehen nicht, wenn du auf das abschliessende "?>" verzichtest, sondern umgekehrt.

                        Ach, so!
                        Ich dachte, in einem Falle müsste durch die Angabe 'error_reporting(E_ALL | E_STRICT);'
                        eine Meldung kommen.

                2. Hallo,

                  Und was wäre daran:

                  it´ prevents the accidental injection of trailing white space into the response

                  schlimm?

                  solange man mit PHP nur HTML-Code ausgibt, ist das vielleicht nicht weiter tragisch. Sobald man aber andere Ressourcen erzeugt (z.B. binäre Daten wie Bilder, oder Textdokumente, bei denen Whitespace nicht ignoriert wird), dann spielt das schon eine Rolle.

                  Ciao,
                   Martin

                  --
                  ... und der FDP-Wähler gibt seine Stimme der FDP.
                     (Faszinierende Erkenntnis meines Gemeinschaftskunde-Lehrers, 9. Schuljahr)
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                  1. [latex]Mae  govannen![/latex]

                    it´ prevents the accidental injection of trailing white space into the response

                    schlimm?

                    solange man mit PHP nur HTML-Code ausgibt, ist das vielleicht nicht weiter tragisch.

                    Auch bei HTML-Erzeugung via PHP kann es schwerwiegende Auswirkungen haben, im schlimmsten Fall das berüchtigte "Headers already sent", wenn eine Datei vor dem ersten header()-Aufruf includiert wurde und diese Leerzeilen hinter dem Schließ-Tag enthält. Und auch Zeilenumbrüche vor dem DOCTYPE in Verbindung mit IE...

                    Stur lächeln und winken, Männer!
                    Kai

                    --
                    It all began when I went on a tour, hoping to find some furniture
                     Followed a sign saying "Beautiful Chest", led to a lady who showed me her best)
                    SelfHTML-Forum-Stylesheet
              2. Hallo,

                Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "?>" zu schliessen, wo ist da ein Widerspruch?
                Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.

                ... und gilt dies auch für eine php-Datei, die ich mit include oder inquire einfüge - im Gesamtdokument wäre das ?> ja nicht mehr am Ende der Datei.

                1. Hi,

                  Wenn du eine Ressource hast, in der nur PHP-Code steht, dann brauchst du diese ressource nicht mit "?>" zu schliessen, wo ist da ein Widerspruch?
                  Es ist keine Ausnahme-Regelung, sondern eine möglichkeit.
                  ... und gilt dies auch für eine php-Datei, die ich mit include oder inquire einfüge

                  Ja.

                  im Gesamtdokument wäre das ?> ja nicht mehr am Ende der Datei.

                  Das ist egal. In der Hinsicht wird jede include-Datei separat behandelt.

                  Ciao,
                   Martin

                  --
                  Wer im Glashaus sitzt, sollte sich nur im Dunkeln ausziehen.
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        2. Hi,

          http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
          Das würde ja allem bisher geschriebenen widersprechen!

          nein, es ist allgemein gängige Praxis bzw. eine gute Empfehlung, das schließende "?>" wegzulassen, wenn es sowieso am Dateiende ist. Dann ist nämlich auch ausgeschlossen, dass am Ende "aus Versehen" noch ein paar Leerzeilen in der Ausgabe landen.

          Dem PHP-Parser ist das egal; für ihn ist das Script mit dem Dateiende automatisch auch zu Ende.

          Ciao,
           Martin

          --
          Wieso heißen die Dinger eigentlich Anrufbeantworter? Eigentlich sind es doch nur Anrufanhörer.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      2. http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."

        Das kann auch nur PHP: Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…

        Mathias

        1. Tach!

          http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
          Das kann auch nur PHP:

          Du meinst sicher Zend, denn das ist deren Coding-Standard. Das PHP-Handbuch meint lediglich, dass bevorzugt werden soll, es wegzulassen.

          Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…

          Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.

          Es steht auch nicht PHPs Philosophie im Weg, nach der es am Ende selbständig offene Ressourcen schließt.

          dedlfix.

          1. Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.

            Ich fordere es nicht. Aber wie du in diesem Thread siehst, entspricht es zunächst der Erwartung der Webautoren, weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt. Wenn man PHP als Markup-Präprozessor betrachtet, was Anfänger erst einmal tun, ist es nur konsistent, ?> zu notieren.

            Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.

            Mathias

            1. Die Diskussion um die "Headers" hat mich nun ganz verwirrt.
              Wenn ich folgendes habe:

              PGM1.php:

              <?php  
                require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');  
              ?>  
              
              

              und
              inhalt.inc.php:

                
              <?php  
              .....  
              .....  
              ?>  
              
              

              Ist dann in beiden Dateien das endene "?>" wegzulassen?

              1. Tach!

                Ist dann in beiden Dateien das endene "?>" wegzulassen?

                Das kann man so nicht beantworten, weil du nicht sagst, was nachher kommt. Das Szenario ist vielmehr ein anderes: wenn zwischen ?> und dem Dateiende kein auszugebendes Zeug mehr steht, kann das ?> weggelassen werden, egal was vorher kam.

                dedlfix.

              2. Hallo,

                Die Diskussion um die "Headers" hat mich nun ganz verwirrt.

                das war nicht die Absicht, ist aber auch nur schwer zu vermeiden. *seufz*

                <?php

                require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');
                ?>

                  
                
                > ~~~php
                
                <?php  
                
                > .....  
                > .....  
                > ?>
                
                

                Ist dann in beiden Dateien das endene "?>" wegzulassen?

                Ja. Ähm, nein. Kommt drauf an. ;-)
                Damit keine Missverständnisse aufkommen: Es handelt sich beim Weglassen des schließenden "?>" nicht um ein "Muss", sondern um ein "Kann". Der PHP-Parser braucht das "?>" nicht, wenn an der Stelle die Scriptdatei sowieso zu Ende ist - ebenso wie du bei einem Buch auch keine Extra-Seite am Schluss brauchst, auf der nur in großen Lettern "ENDE" steht. Du merkst von selbst, dass das Buch da aufhört.

                Aber: Alles, was nach dem "?>" noch folgt, wird noch an den Client gesendet, ohne dass das noch irgendwie interpretiert wird. Und es gibt Fälle, in denen das nicht erwünscht ist oder gar üble Nebenwirkungen hat. Anstatt nun peinlich genau drauf zu achten, dass nach dem Ende des PHP-Codes keine weiteren Leerzeilen folgen, lässt man das Endesymbol einfach weg und schließt diese Fehlerquelle damit prophylaktisch aus. Das ist eine Empfehlung, ein guter Rat, mehr nicht.

                Ciao,
                 Martin

                --
                Fische, die bellen, beißen nicht.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              3. مرحبا

                PGM1.php:

                <?php

                require_once ($_SERVER['DOCUMENT_ROOT'].$_SERVER['MyAkt_Domain_Subdir_Sprache'].'/inhalt.inc.php');
                ?>
                <?php
                .....
                .....
                ?>

                  
                Füge in die Datei "PGM1.php" ein paar manuelle Zeilenumbrüche ein, nach dem schliessenden "`?>`{:.language-php}".  
                  
                ~~~php
                  
                <?php // pgm.php  
                  /* Programme */  
                ?>  
                  
                  
                # Zeilenumbrüche lassen, diese Zeile entfernen  
                
                

                und dann in der index.php

                <?php // index.php  
                  
                  require_once 'pgm.php';  
                  
                  /* Programme */  
                  
                ?>
                ~~~~~~html
                <!DOCTYPE html>  
                <!-- HTML ausgabe -->
                

                In der Quell-Ausgabe der index.php siehst du, was es mit der Empfehlung auf sich hat.

                mfg

            2. Tach!

              Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.
              Ich fordere es nicht. Aber wie du in diesem Thread siehst, entspricht es zunächst der Erwartung der Webautoren, weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt.

              Dann haben sie was falsch gelernt. Viele Elemente erfordern kein schließendes Tag, bei manchen ist es sogar verboten.

              Wenn man PHP als Markup-Präprozessor betrachtet, was Anfänger erst einmal tun, ist es nur konsistent, ?> zu notieren.

              Sollen sie es doch tun, mit den eventuellen Nebenwirkungen und ohne dass sie gezwungen werden.

              Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.

              Langfristig würde das nur noch mehr Chaos verursachen, wenn es nun zwei PHP-Datei-Typen gibt. Der Nutzen ist äußerst gering, eine Abwärtskompatibilität nicht gegeben - und das nur wegen eines angeblichen Schönheitsfehlers..

              dedlfix.

              1. @@dedlfix:

                nuqneH

                weil sie die Regel gelernt haben, dass auf einen öffnenden Tag ein schließender folgt.
                Dann haben sie was falsch gelernt. Viele Elemente erfordern kein schließendes Tag, bei manchen ist es sogar verboten.

                „Tag“ war nicht ganz der richtige Begriff; es ist eher eine Art Klammer: '<?' bzw. '<?php' ist die öffnende Klammer, '?>' die schließende.

                Als ich noch an einer PHP-basierten Plattform gewerkelt habe, waren dort auch in Models und Controllern keine '?>'. Lediglich in Views tauchten sie auf.

                Qapla'

                --
                Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
                (Mark Twain)
            3. Hallo,

              Ich halte es für keine saubere Lösung, Problemen wie »Headers already sent« so zu begegnen. Diese basieren auf dem Widerspruch zwischen PHP als Präprozessor versus PHP als reiner Code in separaten Dateien. Langfristig wäre hier eine Trennung, z.B. durch unterschiedliche Dateinamen, hilfreich. Klar, kurzfristig kann man dem nur mit Coding Guidelines beikommen.

              Naja, beim Zend framework heißen Dateien mit HTML-Output ".phtml"

              Gruß

              jobo

          2. Hallo,

            Tach!

            http://framework.zend.com/manual/en/coding-standard.coding-style.html - "For files containing only PHP code, the closing tag must always be omitted (See General standards)."
            Das kann auch nur PHP:

            Du meinst sicher Zend, denn das ist deren Coding-Standard. Das PHP-Handbuch meint lediglich, dass bevorzugt werden soll, es wegzulassen.

            Aus einer Fehlertoleranz und Inkonsistenz des Parsers eine Lösung für das Problem finden, dass PHP als HTML-Präprozessor gedacht war, man heute aber richtige Programme darin zu schreiben versucht…

            Was ist denn besser daran, am Dateiende noch auf einen oder zwei weitere Abschlüsse zu bestehen? Es ist Schluss - ob da noch ein Semikolon und ein ?> kommt, ändert nichts mehr daran. Ich sehe es eher als übertriebene Gründlichkeit, so etwas zu fordern.

            Es steht auch nicht PHPs Philosophie im Weg, nach der es am Ende selbständig offene Ressourcen schließt.

            Nein, du verhindetst einen nicht erwünschten Output von Whitespaces, der dir bei Session zum Beispiel im Weg steht. Es gilt ja auch nur für Files, in denen kein Output generiert werden soll.

            Gruß

            jobo

  2. Hi,

    welche der Formen

    <script language="php">   (manchmal auch gelesen <script language=php>)

    ....
    </script>

    
    > oder  
    > ~~~php
    
    <?php  
    
    > ......  
    > ?> 
    
    

    ist vorzuziehen?

    die zweite ist die übliche; dass die erste überhaupt möglich ist, wusste ich noch gar nicht. Habe ich jedenfalls noch nirgends angetroffen.

    Ciao,
     Martin

    --
    Lieber Blödeleien als blöde Laien.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  3. Hallo,

    Das PHP-Manual empfiehlt
    <?php ...... ?>

    Wenn Du aber die ungeparsten Dokumente im Browser anschauen willst,
    z.B. wenn Du viel HTML-Code hast und nur einen kleinen Bereich hast,
    der mit PHP eingefügt wird, dann ist die Schreibweise
    <script language="php"> ... </script>
    von Vorteil, denn die Browser werden hier einfach nichts anzeigen
    (da sie die Script-Sprache PHP nicht kennen), während sie beim ersten
    Beispiel den PHP-Quellcode anzeigen werden, was hässlich aussieht.

    Freundliche Grüsse
    Thomas

    1. Hi,

      Wenn Du aber die ungeparsten Dokumente im Browser anschauen willst, z.B. wenn Du viel HTML-Code hast und nur einen kleinen Bereich hast, der mit PHP eingefügt wird, dann ist die Schreibweise
      <script language="php"> ... </script>
      von Vorteil, denn die Browser werden hier einfach nichts anzeigen (da sie die Script-Sprache PHP nicht kennen), während sie beim ersten Beispiel den PHP-Quellcode anzeigen werden, was hässlich aussieht.

      nein, kein Browser wird den PHP-Code anzeigen, denn aus der Sicht eines HTML- oder SGML-Parsers stellt dieser Text ein unbekanntes Tag dar:

      <?php $foo=0; bar() ?>

      Erst wenn im PHP-Code das Zeichen '>' vorkommt, sieht ein gewöhnlicher HTML-Tagsoup-Parser das Ende des vermeintlichen Tags und zeigt den Rest wieder an. Dann ist die Schreibweise mit script-Tag dann wirklich günstiger.

      Ciao,
       Martin

      --
      Er:  Mit wem warst du gestern abend aus?
      Sie: Du bist mal wieder eifersüchtig wie immer!
      Er:  Wer ist Immer?
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Hallo Martin,

        Danke für die Ergänzung.

        Erst wenn im PHP-Code das Zeichen '>' vorkommt, sieht ein gewöhnlicher HTML-Tagsoup-Parser das Ende des vermeintlichen Tags und zeigt den Rest wieder an. Dann ist die Schreibweise mit script-Tag dann wirklich günstiger.

        Genau. Ich habe mal eine kleine Testseite gemacht.
        Doctype: HTML 4.01 Transitional.

        <?php  
        $ausgabe="<p>Das ist <b>voll fett</b>!</p>";  
        echo $ausgabe;  
        ?>
        

        Hier zeigt der MS IE 9 nichts an; Firefox 11.0 und Opera 11.62 zeigen an:
        Das ist voll fett!
        "; echo $ausgabe; ?>
        Das heisst, ab dem ersten > (dem von <p>) ist für sie das "unbekannte Tag" geschlossen, und der Rest ist eben Tagsoup, den sie zu interpretieren versuchen.

        Wenn man den gleichen PHP-Code mit den SCRIPT-Tags einpackt, also

        <script language="php">  
        $ausgabe="<p>Das ist <b>voll fett</b>!</p>";  
        echo $ausgabe;  
        </script>
        

        dann zeigen alle drei genannten Browser nichts an.

        Ich habe mich schon vor sehr langer Zeit (ca. 2003) mit dem Thema Schreibweisen zum Einbetten von PHP in HTML beschäftigt und kam damals zum Schluss, dass die Schreibweise mit den SCRIPT-Tags die empfehlenswerteste sei.

        Ein weiteres Argument für die SCRIPT-Schreibweise ist/war eben auch, dass einige WYSIWYG-Editoren (z.B. MS Frontpage 2000) bei der <?php ... ?> Schreibweise den PHP-Quellcode einfach löschten, während sie SCRIPT-Bereiche unangetastet liessen.

        Freundliche Grüsse
        Thomas

        1. Moin!

          Genau. Ich habe mal eine kleine Testseite gemacht.
          Doctype: HTML 4.01 Transitional.

          <?php

          $ausgabe="<p>Das ist <b>voll fett</b>!</p>";
          echo $ausgabe;
          ?>

          
          >   
          > Hier zeigt der MS IE 9 nichts an; Firefox 11.0 und Opera 11.62 zeigen an:  
          > Das ist voll fett!  
          > "; echo $ausgabe; ?>  
          > Das heisst, ab dem ersten > (dem von <p>) ist für sie das "unbekannte Tag" geschlossen, und der Rest ist eben Tagsoup, den sie zu interpretieren versuchen.  
          >   
          > Wenn man den gleichen PHP-Code mit den SCRIPT-Tags einpackt, also  
          > ~~~php
          
          <script language="php">  
          
          > $ausgabe="<p>Das ist <b>voll fett</b>!</p>";  
          > echo $ausgabe;  
          > </script>
          
          

          dann zeigen alle drei genannten Browser nichts an.

          In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.

          Im Gegenteil: Wenn der Browser alles schön versteckt - wie merkt man dann, dass was kaputt ist?

          Ich habe mich schon vor sehr langer Zeit (ca. 2003) mit dem Thema Schreibweisen zum Einbetten von PHP in HTML beschäftigt und kam damals zum Schluss, dass die Schreibweise mit den SCRIPT-Tags die empfehlenswerteste sei.

          Ich finde das gerade nicht!

          Anfänger haben schon genug Probleme damit, zu verstehen, dass PHP serverseitig ausgeführt wird, und Javascript clientseitig. Wenn man diesen Unterschied jetzt auch noch subtil in dem language-Attribut eines Script-Tags versteckt, wird die Unterscheidbarkeit noch geringer.

          Ein weiteres Argument für die SCRIPT-Schreibweise ist/war eben auch, dass einige WYSIWYG-Editoren (z.B. MS Frontpage 2000) bei der <?php ... ?> Schreibweise den PHP-Quellcode einfach löschten, während sie SCRIPT-Bereiche unangetastet liessen.

          Wer kaputte IDEs benutzt, die als Texteditor nichts taugen, dem ist sowieso nicht zu helfen. :)

          Gegen die Script-Schreibweise spricht vor allem eines: Die Länge! Und als zweites: Die Ungebräuchlichkeit! Und als Drittes: Die Empfehlung seitens PHP für die PHP-Tags!

          - Sven Rautenberg

          1. Hallo Sven,

            <?php

            $ausgabe="<p>Das ist <b>voll fett</b>!</p>";
            echo $ausgabe;
            ?>

            
            >   
            > In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.  
            
            Was ist an dem PHP kaputt?  
            Gruß  
            Walli
            
            1. Tach!

              In beiden Fällen ist dein PHP kaputt und der Quellcode wird ausgeliefert. Sowas sollte nicht zur Bewertung von "Best Practice" herangezogen werden.
              Was ist an dem PHP kaputt?

              Das ist nicht die Frage. Die individuelle Webserver-Konfiguration ist nicht richtig, wenn PHP nicht ausgeführt, sondern der Code in den Dateien einfach so an den Browser gesendet wird.

              dedlfix.