Sven (κ): Content-Script-Type und Content-Style-Typ als <meta>-Angabe

Hallo,

nur eine allgemeine Frage:

<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
 <meta http-equiv="Content-Script-Type" content="text/javascript" />
 <meta http-equiv="Content-Style-Type" content="text/css" />

Sind diese Header-Angaben überhaupt sinnvoll? SELFHTML sagt zu Content-Style-Type: "Die Angabe ist in der gegenwärtigen Praxis und für die CSS-Sprache nicht zwingend erforderlich."

Ich mache sie trotzdem seit Jahren. Den Zeichensatz angeben finde ich prinzipiell sinnvoll (nicht, dass er es als UTF-8 interpretiert), aber auch hier könnte doch als content-type eher text/xhtml stehen als text/html, oder?

Viele Grüße,

Sven

--
ich hatte mal meterlange signs, die sind alle weg
  1. Hallo,

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
    <meta http-equiv="Content-Script-Type" content="text/javascript" />
    <meta http-equiv="Content-Style-Type" content="text/css" />

    Sind diese Header-Angaben überhaupt sinnvoll? SELFHTML sagt zu Content-Style-Type: "Die Angabe ist in der gegenwärtigen Praxis und für die CSS-Sprache nicht zwingend erforderlich."

    Den COntent-Type angeben ist nur eingeschränkt sinnvoll, da er von dem HTTP-header normalerweise überschrieben wird. Fürs offline-Arbeiten kann er aber ganz hilfreich sein.

    Content-Script-Type und Content-Style-Type sind meines Wissens nach für ein valides Dokument u.U. voraussetzung.

    Jonathan

    1. Hallo Jonathan,

      Den COntent-Type angeben ist nur eingeschränkt sinnvoll, da er von dem HTTP-header normalerweise überschrieben wird. Fürs offline-Arbeiten kann er aber ganz hilfreich sein.

      ah, interessant. Wusste ich nicht.

      Content-Script-Type und Content-Style-Type sind meines Wissens nach für ein valides Dokument u.U. voraussetzung.

      ja? Das wäre ja auch mal was neues. Meines Wissens sind die Inhalte von meta-Angaben völlig egal und spielen für die Korrektheit eines XML/SGML-Dokumentes keine Rolle.

      Grüße,sven

      1. Hello out there!

        Content-Script-Type und Content-Style-Type sind meines Wissens nach für ein valides Dokument u.U. voraussetzung.

        ja? Das wäre ja auch mal was neues. Meines Wissens sind die Inhalte von meta-Angaben völlig egal und spielen für die Korrektheit eines XML/SGML-Dokumentes keine Rolle.

        Mit einer DTD kann nicht ausgedrückt werden, dass Content-Script-Type und Content-Style-Type _unter gewissen Umständen_ vorhanden sein müssen.

        In der Spec steht: „Dokumente, die keine Informationen zur Standard-Skriptsprache geben und Elemente enthalten, die Skripte für eingebettete Ereignisse spezifizieren, sind inkorrekt. Benutzerprogramme können trotzdem versuchen, inkorrekt angegebene Skripte zu interpretieren, sind jedoch nicht dazu verpflichtet. Autoren-Tools sollten die Standard-Skriptsprachen-Information erzeugen, um Autoren dabei zu unterstützen, ungültige Dokumente zu vermeiden.“ [HTML401 §18.2.2]

        Also: wenn Eventhandler als HTML-Attribute verwendet werden, muss die Scriptsprache im HTTP-Header bzw. HTTP-EQUIV angegeben sein. Andererseits gibt es wohl keinen UA, der den Wert solcher nicht auch ohne Angabe als JavaScript interpretieren würde.

        „Autoren müssen die Stylesheet-Sprache angeben, die für die Formatierungsinformationen eines HTML-Dokuments gelten soll.

        Anmerkung der Übersetzer:
        Die praktische Relevanz dieses Abschnitts ist ziemlich gering: […] Der Sinn dieses Abschnitts beschränkt sich im Übrigen dann auf die inzeiligen Formatierungsanweisungen, die im nächsten Abschnitt erklärt werden. Allerdings ist gerade diese inzeilige Platzierung von Formatierungsanweisungen diejenige, von der man möglichst Abstand nehmen soll.

        Autoren sollten das Element META verwenden, um die voreingestellte Stylesheet-Sprache für ein Dokument zu bestimmen.“ [HTML401 §14.2.1]

        Also: Wenn 'style'-Attribute verwendet werden, muss die Stylesheetsprache im HTTP-Header bzw. HTTP-EQUIV angegeben sein. Andererseits gibt es wohl keinen UA, der den Wert solcher nicht auch ohne Angabe als CSS interpretieren würde.

        Und natürlich sollte man Styleangaben aus Gründen der Übersichtlichkeit durch die Trennung von Markup und Style niemals in 'style'-Attribute pferchen.

        See ya up the road,
        Gunnar

        --
        „Wer Gründe anhört, kommt in Gefahr nachzugeben.“ (Goethe)
        1. Hallo Gunnar,

          heißt also effektiv: Theoretisch nötig, praktisch unsinnig. Oder?

          Grüße,

          Sven

          1. Hello out there!

            heißt also effektiv: Theoretisch nötig, praktisch unsinnig. Oder?

            Eher: Theoretisch sinnig, praktisch unnötig.

            Ihre Unnötigkeit ergibt sich aber schon aus der Unsinnigkeit ihrer Erforderlichkeit. (Ist der Satz verständlich? Ich bin stolz auf ihn. ;-))

            Man sollte ja Inhaltsstruktur (HTML), Präsentation (CSS) und Verhalten (JavaScript) voneinander trennen. [molily]

            Also keine 'style'-Attribute, aber auch keine Eventhandler-Attribute im HTML haben. Dann braucht man auch keine 'Content-Script-Type'- und 'Content-Style-Type'-Angaben.

            See ya up the road,
            Gunnar

            --
            „Wer Gründe anhört, kommt in Gefahr nachzugeben.“ (Goethe)
            1. Hallo,

              Man sollte ja Inhaltsstruktur (HTML), Präsentation (CSS) und Verhalten (JavaScript) voneinander trennen.

              Was aber schon im Vorfeld schwierig sein mag, was ist bei mouseover
              Verhalten und was ist Präsentation?

              Ein tooltip ist da vmtl. als Präsentation zu sehen, dann kann er
              auch per CSS realisiert werden, falls es die Reihenfolge im HTML-Code
              überhaupt erlaubt, dann noch die Browserfähigkeit. Im HTML gibt es
              dazu wohl auch wenig passendes, um bestimmte Beziehungen darzustellen.
              Als Ergänzung und per CSS gesteuert könnte er u.U. im Inhalt etwas
              untergeordnet oder nachgeordnet stehen, zugleich hat er ja ggf. einen
              festen Bezug zu einer Textstelle usw..

              Und für alte Browser wie den IE 6 gibt es dann u.U. eine Ergänzung
              per JavaScript.

              Also keine 'style'-Attribute, aber auch keine Eventhandler-Attribute im HTML haben.

              In der Praxis fehlen oft Möglichkeiten, etwa bei Bildern, Abstände,
              Größe usw. anzugeben. Es sind Eigenschaften der Bilder, dann
              Gestaltungsprobleme die mit diesen Eigenschaften zusammenhängen, und
              schließlich fehlende CSS-Möglichkeiten um etwa Bilder vertikal zu
              zentrieren.

              Hier z.B. ist das Bild vom Flughafen in einer bestimmten Größe und
              Orientierung und erfordert passende Abstände.
              Praktischen Gründe, etwas das externe CSS nicht aufzublähen, CMS
              etc., dann der direkte Zusammenhnag mit dem Bild selbst, und
              mangelnde Alternativen -ausser vmtl. eine Tabelle- führen dann zu so
              etwas beim img-Tag:

                
              style="width:312px;height:432px;margin-left:60px;margin-right:60px;"  
              
              

              Zu Bildern im Querformat gibt es natürlich passende Angaben mit
              margin-top und margin-bottom.

              Abgesehen von anderen möglichen Codeverbesserungen wäre also hier die
              'Content-Style-Type'-Angabe eigentlich nötig.

              Falls der "Tooltip" auf der Seite mit den Kameraangaben wegen der
              Probleme mit Safari 3ß eine Javascriptunterstützung benötigt, wäre
              aber wohl mit einem externen Script eine weitere Metanagabe unnötig.

              Grüsse

              Cyx23

            2. Nabend Gunnar,

              heißt also effektiv: Theoretisch nötig, praktisch unsinnig. Oder?
              Eher: Theoretisch sinnig, praktisch unnötig.

              stimmt.

              Ihre Unnötigkeit ergibt sich aber schon aus der Unsinnigkeit ihrer Erforderlichkeit. (Ist der Satz verständlich? Ich bin stolz auf ihn. ;-))

              verständlich ja, aber unsinnig und praktisch unnötig. *SCNR*

              Man sollte ja Inhaltsstruktur (HTML), Präsentation (CSS) und Verhalten (JavaScript) voneinander trennen. [molily]

              Wow, guter Satz. Danke auf den Artikel von molily.

              Also keine 'style'-Attribute, aber auch keine Eventhandler-Attribute im HTML haben. Dann braucht man auch keine 'Content-Script-Type'- und 'Content-Style-Type'-Angaben.

              Gutes Argument. Genau so eine Antwort hab ich gebraucht. Danke =)

              Viele Grüße,

              Sven

  2. Hallo Sven.

    nur eine allgemeine Frage:

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
    <meta http-equiv="Content-Script-Type" content="text/javascript" />
    <meta http-equiv="Content-Style-Type" content="text/css" />

    Sind diese Header-Angaben überhaupt sinnvoll? SELFHTML sagt zu Content-Style-Type: "Die Angabe ist in der gegenwärtigen Praxis und für die CSS-Sprache nicht zwingend erforderlich."

    Ja, da es neben CSS im derzeiten Web keine weitere Formatierungssprache gibt.

    Selbst die Angabe zur Scriptsprache sehe ich als unnötig an. Im öffentlichen Netz dürfte man höchst selten etwas anderes als JavaScript antreffen.

    Zudem ist mir nicht bekannt, dass das Notieren oder Weglassen dieser Angaben irgendeinen Unterschied im Rendering irgendeines Browsers machen würde.

    Ich mache sie trotzdem seit Jahren. Den Zeichensatz angeben finde ich prinzipiell sinnvoll (nicht, dass er es als UTF-8 interpretiert), …

    Damit musst du nur rechnen, wenn du XML auslieferst.

    … aber auch hier könnte doch als content-type eher text/xhtml stehen als text/html, oder?

    Könnte schon, wäre aber Unsinn, da es diesen MIME-Typen nicht gibt. Meintest du „application/xhtml+xml“? (Inklusiver aller Nachteile, welche im hIEsigen Archiv aufgeführt sind.)

    Einen schönen Mittwoch noch.

    Gruß, Mathias

    --
    ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
    debian/rules