Gunnar Bittersmann: XHTML 1.1 und text/html

Hi,
Dokumente in XHTML 1.1 sollten laut [XHTMLMIME] nicht als text/html ausgeliefert werden. Aber SHOULD NOT heißt ja nicht MUST NOT.

Im Dokument ist nichts enthalten, was laut [molily] kritisch ist. Dann sollte es doch keine Probleme bereiten, dies trotzdem zu tun, oder?

Gunnar

--
"Nobody wins unless everybody wins." (Bruce Springsteen)
  1. Hallo Gunnar,

    [[ ... ]]  [[ ... ]]

    wikisüchtigen ertappt ... *SCNR*

    Gruß aus Köln-Ehrenfeld,

    Elya

    --

    keep passing the open windows.
  2. Hallo,

    Dokumente in XHTML 1.1 sollten laut [XHTMLMIME] nicht als text/html ausgeliefert werden.

    Das ist die These dieser Abhandlung, die man eher als Teil einer Argumentation verstehen sollte statt als eine in der Luft hängende Vorschrift.

    Aber SHOULD NOT heißt ja nicht MUST NOT.

    Du wirst nicht nur ein Posting von mir im Archiv finden, dass sich damit auseinandersetzt. Ich halte den Umstand, ob in dieser W3C-Note »should not« oder »must not« steht, nach wie vor für irrelevant. Siehe z.B. </archiv/2004/4/77771/#m450200>.

    Im Dokument ist nichts enthalten, was laut [molily] kritisch ist. Dann sollte es doch keine Probleme bereiten, dies trotzdem zu tun, oder?

    Gibst du nicht die Sprache des Dokuments mit lang an (solltest du vielleicht)? Benutzt du nirgendwo dokumentinterne Anker? Dann würde es zumindest keine größeren Probleme als XHTML 1.0 Strict unter denselben Bedingungen verursachen. Da du vermutlich sowieso von XHTML 1.0 als Vergleichsbasis ausgehst: Nein, voraussichtlich gibt es keine Probleme (zumindest nach jetzigen »Stand der Forschung« etc. pp.).

    Es bliebe natürlich die Frage, welche Vorteile die Zweckentfremdung der Techniken hat, wenn es schon keine nennenswerten Nachteile gibt im Vergleich zur Verwendung der Techniken gemäß ihrer Existenzzwecke.

    Mathias

    1. Danke, Mathias.

      Gibst du nicht die Sprache des Dokuments mit lang an?

      Ja.*

      Ich mach's mit xml:lang und http-equiv="content-language". Zur Erhöhung der Redundanz könnte ja noch eine DC.language-Metaangabe dazukommen, aber das ist doch unnötig, oder?

      Benutzt du nirgendwo dokumentinterne Anker?

      Ja.*

      Na dann schick ich entgegen der Empfehlung mein XHTML 1.1 als text/html raus. Wobei ich auch gar nicht wüsste, wie ich den Server überzeugen könnte, es anders zu tun: andere Dateiendung als .html?

      Gruß,
      Gunnar

      * Bei verneinenden Fragen muss man zweimal überlegen, ob man mit ja oder nein antworten muss. ;-)

      --
      "Nobody wins unless everybody wins." (Bruce Springsteen)
      1. Hallo Gunnar,

        Ich mach's mit xml:lang und http-equiv="content-language". Zur Erhöhung der Redundanz könnte ja noch eine DC.language-Metaangabe dazukommen, aber das ist doch unnötig, oder?

        Content-Language ist auf jeden Fall gut. Damit sollte das fehlende lang-Attribut z.B. in gewissen Screenreadern ausgeglichen werden. Ich habe aber keinen Überlick über die mannigfachen Anwendungen, die das lang-Attribut auslesen könnten und darüber, ob diese sich auch mit Content-Language zufrieden geben (JAWS macht dies z.B., wenn ich mich recht an meine Tests erinnere - aber der erkennt zumindest in Version 5 auch xml:lang, insofern ist es dort nicht tragisch).
        Mit lang bist du auf jeden Fall auf der sichereren Seite...

        Na dann schick ich entgegen der Empfehlung mein XHTML 1.1 als text/html raus. Wobei ich auch gar nicht wüsste, wie ich den Server überzeugen könnte, es anders zu tun: andere Dateiendung als .html?

        Neuere Apaches sollten Dateien, die auf .xhtml enden, als application/xhtml+xml ausliefern.
        Man arbeitet aber eher z.B. mit mod_rewrite, um die XHTML-Dokumente je nach Browser mit text/html oder application/xhtml+xml auszuliefern, siehe etwa http://schneegans.de/tips/apache-xhtml/.

        Mathias

  3. Hi,

    Dokumente in XHTML 1.1 sollten laut [XHTMLMIME] nicht als text/html ausgeliefert werden. Aber SHOULD NOT heißt ja nicht MUST NOT.

    http://www.ietf.org/rfc/rfc2119.txt

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.

    4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
       there may exist valid reasons in particular circumstances when the
       particular behavior is acceptable or even useful, but the full
       implications should be understood and the case carefully weighed
       before implementing any behavior described with this label.

    Im Dokument ist nichts enthalten, was laut [molily] kritisch ist. Dann sollte es doch keine Probleme bereiten, dies trotzdem zu tun, oder?

    Ich halte XHTML 1.1 derzeit für nicht praxistauglich (egal ob mit korrektem mime-type oder inkorrektem).
    Die wenigsten Browser (wenn es überhaupt solche gibt) können z.B. mit dem usemap-Attribut, das in XHTML 1.1 nicht mehr eine URL, sondern eine IDREF enthält, umgehen.

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
    1. Ich halte XHTML 1.1 derzeit für nicht praxistauglich (egal ob mit korrektem mime-type oder inkorrektem).

      Andreas,
      SHOULD NOT oder NOT RECOMMENDED heißt nicht "inkorrekt".

      Die wenigsten Browser (wenn es überhaupt solche gibt) können z.B. mit dem usemap-Attribut, das in XHTML 1.1 nicht mehr eine URL, sondern eine IDREF enthält, umgehen.

      Dafür kennt der IE ab Version 5.0 Ruby-Annotation. Andere Browser hinken da hinterher, ohne Plugins jedenfalls.

      Gunnar

      --
      "Nobody wins unless everybody wins." (Bruce Springsteen)