Umstieg von HTML 4.01 auf XHTML 1.0

[Siechfred]

Hallo allerseits,

ich habe die Zeit des Forumsausfalles u.a. dafür genutzt, mich mal grundsätzlich mit XHTML zu befassen. Da ich vorhabe, in nächster Zeit unsere Kanzleihomepage neu zu gestalten, hielt ich das für einen guten Anlass, über die Verwendung von XHTML statt HTML nachzudenken und habe mich mal ein wenig im Netz umgeschaut (mich sozusagen klug gegoogelt ;-)). Mir ist allerdings noch nicht so ganz klar, worin der Vorteil eines Umstiegs liegt. Auch der Artikel auf der HP von Michael Jendryschik hat mich noch nicht überzeugen können. Damit keine Missverständnisse aufkommen, worin die gravierenden Unterschiede liegen, ist mir im Groben bekannt.

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Viele Grüße
Torsten

[Stefan Einspender]

Hallo Torsten,

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Deinem offensichtlich vorhandenen Verdacht muß ich zustimmen, ich
habe bisher auch keine Gründe finden können, warum ich nicht mehr
HTML 4.01 (Strict) verwenden sollte. Oder umgekehrt,  XHTML korrekt
zu schreiben ist schwieriger, bringt aber bei der späteren Anzeige
im Browser keine Vorteile. Da nicht zu erwarten ist, dass es in
absehbarer Zeit Browser gibt, die kein HTML 4.01 Strict mehr ver-
stehen, werde ich diesen Standard beibehalten.

Viele Grüße,
Stefan

[Christoph Schnauß]

tagchen,

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Ich habe bisher weder entscheidende Vorteile noch gravierende Nachteile bemerken können. XHTML verlangt noch etwas mehr Genauigkeit als HTML, aber das hat man schnell drauf.

Grüße aus Berlin

Christoph S.

[Wilhelm Turtschan]

habe d'ehre

über die Verwendung von XHTML statt HTML nachzudenken Mir ist allerdings noch nicht so ganz klar, worin der Vorteil eines Umstiegs liegt.

Dann sind wir ja schom zu zweit. (oder doch noch mehr?)

Was meint ihr also, worin liegen die Vorteile

<fluester>

1. Man wird von manchen Gurus[1] hier nicht mehr herablassend betrachtet.
2. Man ist cool
   </fluester>

Ironie-Tag bitte selber setzen. :-)
[1] Praefix "Pseudo" nur angedacht

[AndreD]

Hallo zusammen

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Deinem offensichtlich vorhandenen Verdacht muß ich zustimmen, ich
habe bisher auch keine Gründe finden können, warum ich nicht mehr
HTML 4.01 (Strict) verwenden sollte.

Ein Vorteil in meinen Augen ist zum Beispiel das sich in einer strict-validen XHTML-Datei ausschliesslich Elemente für die Seitenbeschreibung befinden dürfen damit die Datei valide ist. Somit könnte endlich das erreicht werden was mit HTML versucht, aber nie durchgesetzt werden konnte: (X)HTML ausschliesslich für die Seitenbeschreibung und CSS für die Formatierung zu verwenden.

Natürlich kann man jetzt sich sagen: Warum soll ich mir die Mühe geben und strictes XHTML schreiben wenn doch HTML 4.01 Transistional genauso funktioniert (und wahrscheinlich noch die kommenden Jahre funktionieren wird). Aber erstens sollte man versuchen sich IMHO im professionellen Bereich an Konventionen und Vorschläge des W3C zu halten; schliesslich wird man als Designer/Programmierer langfristig davon profitieren. Man denke nur an Javascript und das DOM-Modell als Standardisierung... Zweitens soll XHTML langfristig nunmal die Norm der Seitenbeschreibung werden, somit kann man heute schon seine Seiten zukunftssicher schreiben. Und Drittens könnte man ja auch genau so behaupten das man kein CSS einsetzen braucht, <font>, <i>, <b> funktionieren in den aktuellen und (wahrscheinlich) in den kommenden Browsern immer noch, also warum sich die Mühe machen machen? Die Gründe findet man oben aufgeführt...

Soweit mal meine Meinung zu diesem (interessanten) Thema, ich hoffe ich hab einigermassen der Kern der Frage getroffen?

Schönes langes Wochenende,
Gruss AndreD

[Stefan Einspender]

Hallo Andre,

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Deinem offensichtlich vorhandenen Verdacht muß ich zustimmen, ich
habe bisher auch keine Gründe finden können, warum ich nicht mehr
HTML 4.01 (Strict) verwenden sollte.

auch mal eine Variante, fremde Zitate unter einen anderen Beitrag
kopieren und kommentieren ... naja ;-)

Ein Vorteil in meinen Augen ist zum Beispiel das sich in einer strict-validen XHTML-Datei ausschliesslich Elemente für die Seitenbeschreibung befinden dürfen damit die Datei valide ist.

Das b-Element dient zur Seitenbeschreibung, warum?

Somit könnte endlich das erreicht werden was mit HTML versucht, aber nie durchgesetzt werden konnte:

XHTML 1.0 ist lediglich die Reformulierung von HTML 4.01 Strict.

Aber erstens sollte man versuchen sich IMHO im professionellen Bereich an Konventionen und Vorschläge des W3C zu halten;

HTML 4.01 ist selbstverständlich ein W3C-Standard. Wir reden hier
nicht über XHTML vs. Nicht-W3C-Standard, sondern XHTML vs. HTML ;-)

Man denke nur an Javascript und das DOM-Modell als Standardisierung...

JavaScript ist kein W3C-Standard.

Zweitens soll XHTML langfristig nunmal die Norm der Seitenbeschreibung werden, somit kann man heute schon seine Seiten zukunftssicher schreiben.

Wohlgemerkt _soll_, es gibt unzählige Beispiele, gerade im techn.
Bereich wor etwas auch die Norm werden sollte. Und selbst wenn es
so ist und in X Jahren nur noch XHTML unterstützt wird, werden
dann die von mir heute erstellten Internetseiten noch online
sein? Nein, da dieser Zeitpunkt ganz bestimmt in weiter Zukunft
liegt, in absehbarer Zeit wird HTML 4.01 noch unterstützt.

Und Drittens könnte man ja auch genau so behaupten das man kein CSS einsetzen braucht, <font>, <i>, <b> funktionieren in den aktuellen und (wahrscheinlich) in den kommenden Browsern immer noch, also warum sich die Mühe machen machen?

Nein, der Vergleich hinkt. Der Einsatz von CSS hat ganz wichtige
Vorteile, die nicht von der Hand zu weisen sind. Und genau die
werden für den Einsatz von XHTML noch gesucht ;-)

Wobei es mir persönlich weniger um die Vorteile für mich als Ent-
wickler, sondern mehr um die Vorteile als Anwender geht und da
kann ich etwas mit Druckstylesheets etc. Vergleichbares nicht finden.

Viele Grüße,
Stefan

[molily]

Hallo,

XHTML 1.0 ist lediglich die Reformulierung von HTML 4.01 Strict.

Eigentlich von allen 4.01-Varianten.

Mathias

[AndreD]

Hi Stefan,

auch mal eine Variante, fremde Zitate unter einen anderen Beitrag
kopieren und kommentieren ... naja ;-)

Warum? Ich habe doch lediglich Dein Beitrag rezitiert und zum besseren Verständnis auch gleich das Zitat des Ausgangpostings drangelassen?

Das b-Element dient zur Seitenbeschreibung, warum?

Ist das inzwischen nicht depricated und durch <strong> ersetzt? Ich meinte das auch mehr im Zusammenhang mit Schriftformatierung.

XHTML 1.0 ist lediglich die Reformulierung von HTML 4.01 Strict.

Aber eben mit ein paar "strengeren" Auslegungen was erlaubt ist, alles im Hinblick auf XML.

HTML 4.01 ist selbstverständlich ein W3C-Standard. Wir reden hier
nicht über XHTML vs. Nicht-W3C-Standard, sondern XHTML vs. HTML ;-)

Ok, da hast Du wohl recht... :-)

JavaScript ist kein W3C-Standard.

Ok, andersrum: Aber das DOM-Model als Standard bei der Verwendung in Javasciript schon, oder?

Wohlgemerkt _soll_, es gibt unzählige Beispiele, gerade im techn.
Bereich wor etwas auch die Norm werden sollte. Und selbst wenn es
so ist und in X Jahren nur noch XHTML unterstützt wird, werden
dann die von mir heute erstellten Internetseiten noch online
sein? Nein, da dieser Zeitpunkt ganz bestimmt in weiter Zukunft
liegt, in absehbarer Zeit wird HTML 4.01 noch unterstützt.

Ja, da geb ich Dir recht und das ist ja auch allgemein bekannt. Allerdings kann man ja versuchen eine solche Norm durch Anwendung zu unterstützen?

Nein, der Vergleich hinkt. Der Einsatz von CSS hat ganz wichtige
Vorteile, die nicht von der Hand zu weisen sind. Und genau die
werden für den Einsatz von XHTML noch gesucht ;-)

Na gut, ich helf Dir suchen... :-P

Wobei es mir persönlich weniger um die Vorteile für mich als Ent-
wickler, sondern mehr um die Vorteile als Anwender geht und da
kann ich etwas mit Druckstylesheets etc. Vergleichbares nicht finden.

FullACK

Gruss AndreD

[Stefan Einspender]

Hallo Andre,

Das b-Element dient zur Seitenbeschreibung, warum?
Ist das inzwischen nicht depricated und durch <strong> ersetzt?

Nein, wobei ich dies nicht nachvollziehen kann, imho gehört b raus ;-)

Allerdings kann man ja versuchen eine solche Norm durch Anwendung zu unterstützen?

Nur um sie zu unterstützen, soll ich sie unterstützen? Wie gesagt,
mir fehlen die handfesten Vorteile, in erster Linie die Vorteile
für meine Besucher, die suche ich.

Na gut, ich helf Dir suchen... :-P

Brauche noch eine kleine Hilfestellung, noch nix gefunden ;-)

Habe gerade [pref:t=50016&m=273738] gelesen und muß da doch etwas
schmunzeln, weil sowas kann vielleicht in einigen wenigen
Fällen als Vorteil genannt werden, aber i.d.R. eher nicht,
99% aller Websites brauchen nicht WML2-kompatibel sein.

Viele Grüße,
Stefan

PS: Die Zusammenfassung von Utz am Ende seines Beitrages gefällt
    mir ganz gut: [pref:t=50016&m=273728]

[Herbalizer]

Hi!

Habe gerade [pref:t=50016&m=273738] gelesen und muß da doch etwas
schmunzeln, weil sowas kann vielleicht in einigen wenigen
Fällen als Vorteil genannt werden, aber i.d.R. eher nicht,
99% aller Websites brauchen nicht WML2-kompatibel sein.

Es ging nicht darum, das alle Websites WML2-kompatibel sein sollen, sondern das 100% der konformen WML2-Useragents XHTML können müssen! Und ich wollte eigentlich nur darauf hinaus, das die normale, script- und famesetlose Website nicht mehr Elemente benutzt als diejenigen, die in XHTML Mobile Profile deklariert sind und somit ein und dieselbe XHTML-Version (nicht WML2) für Desktop-Browser und Mobile-Browser benutzt werden könnte.

Gruß Herbalizer

[Michael Jendryschik]

Hallo,

Ist das inzwischen nicht depricated und durch <strong> ersetzt?

'b' und 'strong' sind vollkommen unterschiedliche Elemente, siehe http://jendryschik.de/wsdev/einfuehrung/xhtml/textauszeichnung.html. Das ändert natürlich nichts an der Tatsache, dass Element wie 'b', 'i' oder 'hr' in einer modernen Auszeichnungssprache nichts mehr zu suchen haben.

Gruß,

MI

[Christian Seiler]

Hallo Michael,

Das ändert natürlich nichts an der Tatsache, dass Element wie 'b', 'i' oder 'hr' in einer modernen Auszeichnungssprache nichts mehr zu suchen haben.

Bei b und i bin ich einverstanden. Bei hr jedoch nicht. Eine logische Trennung ohne weitere Überschrift halte ich in manchen Fällen durchaus für wünschenswert. Das Element ist höchstens unglücklich genannt, ein <sep/> oder ähnliches wäre vmtl. besser geeignet.

Viele Grüße,
Christian

[Michael Jendryschik]

Hallo,

Bei b und i bin ich einverstanden. Bei hr jedoch nicht. Eine logische Trennung ohne weitere Überschrift halte ich in manchen Fällen durchaus für wünschenswert. Das Element ist höchstens unglücklich genannt, ein <sep/> oder ähnliches wäre vmtl. besser geeignet.

Du lässt außer acht, dass in Auszeichnunssprachen Inhalte durch Tags umschlossen, nicht voneinander abgetrennt werden sollten. XHTML 2.0 führt 'line' ein, dass Zeilen umschließt und 'br' ersetzt, dass Zeichen voneinander abtrennt. Ein weiteres Element ist 'section', mit dem genau das erreicht werden kann, was du dir wünscht. BTW: Ich würde bereits heute Blöcke mit 'div' umfassen, statt sie mit 'hr' voneinander zu separieren.

Gruß,

MI

[Christian Seiler]

Hallo Michael,

BTW: Ich würde bereits heute Blöcke mit 'div' umfassen, statt sie mit 'hr' voneinander zu separieren.

Hmmm, so wie ich jetzt darüber nachdenke... Einverstanden, <hr> ist böse[tm]. ;-)

Viele Grüße,
Christian

[Utz]

Hi Michael,

XHTML 2.0 führt 'line' ein, dass Zeilen umschließt und 'br' ersetzt, dass Zeichen voneinander abtrennt.

Sorry, aber darin kann ich keinen Vorteil erkennen. Meiner unmaßgeblichen Meinung nach hat "Da soll ein Zeilenumbruch hin" auch nicht weniger mit logischer Struktur zu tun als "Die Zeile soll von da bis dort gehen".

Persönlich fänd ich es besser einzugestehen, dass in der EDV der Zeilenwechsel ein lange Tradition als (Steuer-)Zeichen hat und würde ihn dementsprechend am liebsten als Entität definiert sehen: &br; o.s.ä.

In dem Zusammenhang fänd ich auch eine Konstruktion wie &img['name']; in Kombination mit

<style type="text/css">
&img['name'];
  {
  src: url(pic.jpg);
  width: 100px;
  height: 100px;
  /* plus weitere Angaben */
  }
</style>

eigentlich ganz sinnig.

Grüße,

Utz

[Michael Jendryschik]

Hallo,

XHTML 2.0 führt 'line' ein, dass Zeilen umschließt und 'br' ersetzt, dass Zeichen voneinander abtrennt.

Sorry, aber darin kann ich keinen Vorteil erkennen.

Ein 'br' bewirkt einen Zeilenumbruch, mehr nicht. Man kann nicht einmal argumentieren, dass mit diesem Element ein Zeilenende markiert wird, da es schließlich keinen Tag für den Beginn einer Zeile gibt. Eine solche fängt entweder unmittelbar nach dem Start-Tag des übergeordneten Containers oder beim vorausgegangenen '<br />' an. Logisch definiert ist eine Zeile auf diesem Weg nicht. Darüber hinaus lässt sich eine Zeile nicht mit CSS formatieren, da sie nicht durch einen Container ausgezeichnet ist. Ein weiterer Vorteil liegt darin, dass mit 'line' ausgezeichnete Zeilen eindeutig zählbar sind.

Meiner unmaßgeblichen Meinung nach hat "Da soll ein Zeilenumbruch hin" auch nicht weniger mit logischer Struktur zu tun als "Die Zeile soll von da bis dort gehen".

Da sind sowohl ich als zum Glück auch die Entwickler von XHTML anderer Meinung.

Gruß,

MI

[Hans Thomas Vogler]

Hallo,

XHTML 2.0 führt 'line' ein, dass Zeilen umschließt und 'br' ersetzt, dass Zeichen voneinander abtrennt.

Sorry, aber darin kann ich keinen Vorteil erkennen.

Ich ehrlich gesagt auch nicht. der <br>-tag (den ich eigentlich so gut wie nie verwende) bezeichnet ja auch einen erzwungenen Zeilenumbruch und als solcher ein bestimmtes Element innerhalb eines Absatzes o.ä. Er soll ja gerade keinen Text umschließen.

Aus der inneren Logik von HTML heraus wäre das genaugenommen ein Fall für eine entity '&br;'

Ein Text oder Bild enthaltender <line>-tag als gewissermaßen einzeiliger Absatz wäre aber etwas völlig anderes und meiner Ansicht nach eine Erweiterung des HTML-Umfangs.

Logisch definiert ist eine Zeile auf diesem Weg nicht.

Ein "harter Zeilenumbruch" soll ja auch gar keine Zeile definieren, sondern sie erzwungenermaßen beenden.

Darüber hinaus lässt sich eine Zeile nicht mit CSS formatieren, da sie nicht durch einen Container ausgezeichnet ist.

Brauche ich da einen <line>-tag? Tut´s nicht auch ein <span class="line"> für die paarmal, wo man sowas wirklich brauchen kann?

Ein weiterer Vorteil liegt darin, dass mit 'line' ausgezeichnete Zeilen eindeutig zählbar sind.

Welcher Vorteil soll das sein? Dazu müßte ich ja jede einzelne Zeile eines Textes als <line> auszeichnen, um am Ende eine verläßliche Zeilenzahl zu bekommen und dürfte keinen mehrzeiligen <p>-tag verwenden... Das wäre ja Horror-Code!

Da sind sowohl ich als zum Glück auch die Entwickler von XHTML anderer Meinung.

Mir ist nur nicht klar, warum.

Gruß,

MI

servus,
T.

[Michael Jendryschik]

der <br>-tag (den ich eigentlich so gut wie nie verwende) bezeichnet ja auch einen erzwungenen Zeilenumbruch und als solcher ein bestimmtes Element innerhalb eines Absatzes o.ä. Er soll ja gerade keinen Text umschließen.

Und genau das ist die Schwäche dieses Elements.

Ein Text oder Bild enthaltender <line>-tag als gewissermaßen einzeiliger Absatz wäre aber etwas völlig anderes und meiner Ansicht nach eine Erweiterung des HTML-Umfangs.

'line' IST eine Erweiterung. XHTML 2.0 wird nicht den Anspruch erheben, vollständig abwärtskompatibel zu sein.

Darüber hinaus lässt sich eine Zeile nicht mit CSS formatieren, da sie nicht durch einen Container ausgezeichnet ist.

Brauche ich da einen <line>-tag? Tut´s nicht auch ein <span class="line"> für die paarmal, wo man sowas wirklich brauchen kann?

Braucht man wirklich ein Element 'p'? Wozu, 'div class="absatz"' tut es doch auch. Welchen Sinn hat das Element 'blockquote', schließlich kann ich doch 'div class="zitat"' verwenden? Warum ersetze ich 'code' nicht durch 'span class="quelltextbeispiel"'?

Ein weiterer Vorteil liegt darin, dass mit 'line' ausgezeichnete Zeilen eindeutig zählbar sind.

Welcher Vorteil soll das sein?

Es erleichtert (oder ermöglicht gar erst, so genau weiß ich das gar nicht) die Weiterverarbeitung von Dokumenten in eigenen Anwendungen und die Adressierung z.B. durch XPath.

Dazu müßte ich ja jede einzelne Zeile eines Textes als <line> auszeichnen, um am Ende eine verläßliche Zeilenzahl zu bekommen und dürfte keinen mehrzeiligen <p>-tag verwenden... Das wäre ja Horror-Code!

Folgendes Beispiel findest du unter http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.13.:

<p class="program">
  <line>program p(input, output);</line>
  <line>begin</line>
  <line>    writeln("Hello world");</line>
  <line>end.</line>
  </p>

Die Zeilennummerierung gehört nicht zum Quellcode und soll daher nicht festcodiert in den XHTML-Quelltext geschrieben werden. Denkbar wäre eine Nummerierung per CSS wie folgt:

.program { counter-reset: linenumber }

line:before {
      position: relative;
      left: -1em;
      counter-increment: linenumber;
      content: counter(linenumber);
  }

Würde wie bisher 'br' zur Abtrennung von Zeilen verwendet werden, wäre eine solche Vorgehensweise nicht möglich.

Gruß,

MI

[Hans Thomas Vogler]

Er soll ja gerade keinen Text umschließen.

Und genau das ist die Schwäche dieses Elements.

bzw. seine Stärke, wenn man ihn wirklich mal brauchen sollte. Aber eine entsprechende entity wäre "logischer".

Folgendes Beispiel findest du unter http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.13.:

<p class="program">
  <line>program p(input, output);</line>
  <line>begin</line>
  <line>    writeln("Hello world");</line>
  <line>end.</line>
  </p>

Ok. ok. Habe nicht an die Programmierer gedacht, die Code publizieren wollen. Das kommt in meinem Anwendungsbereich nun mal praktisch nicht vor.

Würde wie bisher 'br' zur Abtrennung von Zeilen verwendet werden, wäre eine solche Vorgehensweise nicht möglich.

Das ist richtig. Die Möglichkeit eines "harten Zeilenumbruchs" sollte es dennoch geben.

Gruß,

MI

servus,
T.

[Utz]

Hallo Michael,

unter logischer Struktur (hätte es gleich definieren sollen *g*) verstehe ich, die Bestandteile eines Textes entsprechend ihrer semantisch-logischer Bedeutung auszuzeichnen. In dem Zusammenhang verstehe ich Dinge wie "Von hier bis hier ist eine Adresse", "Von hier bis hier ist eine Betonung" oder "Dieser Absatz geht von hier bis hier", sogar "Von hier bis hier ist ein Abschnitt, für den es in HTML keine passende Entspechung gibt, also vergebe ich selber eine". Welche Bedeutung soll aber "Von hier bis hier ist eine Zeile" haben?

1. Haben Texte sowieso Zeilen, ganz von selber.
2. Zweitens kann innerhalb von <l>...</l> sehr wohl noch ein bis mehrere Zeilenumbrüche sein, es geht also nicht wirklich um eine Zeile.
3. Ist die Frage nach simplen Zeilenumbrüchen IMHO eh eine Thematik der Darstellung, nicht der logischen Strukturierung.
4. Find ich es kurios, dann ein Inline-Element zu haben, dass sich by default eher wie ein Blocklevel-Element verhält.
5. Erschließt sich mir der Sinn der Unterscheidung zwischen <div>...</div> und <l>...</l> nicht wirklich.

Also: ich verstehe schon, warum man Schwierigkeiten mit <br /> hat und es gerne draußen hätte, aber ich sehe nach wie vor nicht, wie <l>...</l> daran grundlegend etwas ändern könnte. Mir erscheint das Konzept von <l>...</l> nicht perfekt zu sein. Was ich besser fände, hab ich ja schon im vorigen Posting genannt.

Grüße,

Utz

[Michael Jendryschik]

unter logischer Struktur (hätte es gleich definieren sollen *g*) verstehe ich, die Bestandteile eines Textes entsprechend ihrer semantisch-logischer Bedeutung auszuzeichnen.

ACK.

In dem Zusammenhang verstehe ich Dinge wie "Von hier bis hier ist eine Adresse", "Von hier bis hier ist eine Betonung" oder "Dieser Absatz geht von hier bis hier", sogar "Von hier bis hier ist ein Abschnitt, für den es in HTML keine passende Entspechung gibt, also vergebe ich selber eine". Welche Bedeutung soll aber "Von hier bis hier ist eine Zeile" haben?

Wo liegt denn für dich der Unterschied zwischen "von hier bis hier ist ein Absatz", "von hier bis hier ist eine Betonung" und "von hier bis hier ist eine Zeile"?

1. Haben Texte sowieso Zeilen, ganz von selber.

Ein in ein 'p' eingeschlossener Text besteht zunächst einmal aus einer einzigen Zeile. Nur dann, wenn die Breite der Darstellungsfläche nicht groß genug ist, um den Text in einer Zeile anzuzeigen, wird umgebrochen.

2. Zweitens kann innerhalb von <l>...</l> sehr wohl noch ein bis mehrere Zeilenumbrüche sein, es geht also nicht wirklich um eine Zeile.

Du verwechselst logische Auszeichnung mit Darstellung. Vermutlich wird eine mit 'line' ausgezeichnete Zeile tatsächlich umgebrochen, wenn du das Fenster ganz schmal ziehst, um die Inhalte weiterhin zugänglich zu machen, aber das kann nicht ernsthaft ein Argument sein.

3. Ist die Frage nach simplen Zeilenumbrüchen IMHO eh eine Thematik der Darstellung, nicht der logischen Strukturierung.

Sag das mal dem Autor eines Gedichts, der sich bei der Einteilung seines Werkes in Strophen und Verse etwas gedacht hat. Im übrigen geht es bei 'line' nicht mehr um Zeilenumbrüche, sondern um die Auszeichnung einer Zeile an sich!

4. Find ich es kurios, dann ein Inline-Element zu haben, dass sich by default eher wie ein Blocklevel-Element verhält.

Wer sagt, dass 'line' ein Inline-Element ist?

5. Erschließt sich mir der Sinn der Unterscheidung zwischen <div>...</div> und <l>...</l> nicht wirklich.

Weshalb erschließt sich dir dann der Unterschied zwischen 'p' und 'div'?

Gruß,

MI

[Utz]

Hallo Michael,

Wo liegt denn für dich der Unterschied zwischen "von hier bis hier ist ein Absatz", "von hier bis hier ist eine Betonung" und "von hier bis hier ist eine Zeile"?

Zeilen gibt es i.d.R. sowieso, eine Auszeichnung als Zeile fügt keine zusätzlichen Informationen hinzu. Außer, dass am Schluss ein Zeilenumbruch sein soll. Von hinten durch die Brust ins Auge.

1. Haben Texte sowieso Zeilen, ganz von selber.

Ein in ein 'p' eingeschlossener Text besteht zunächst einmal aus einer einzigen Zeile. Nur dann, wenn die Breite der Darstellungsfläche nicht groß genug ist, um den Text in einer Zeile anzuzeigen, wird umgebrochen.

Meine Rede *g*: Zeilen gibt es sowieso.

2. Zweitens kann innerhalb von <l>...</l> sehr wohl noch ein bis mehrere Zeilenumbrüche sein, es geht also nicht wirklich um eine Zeile.

Du verwechselst logische Auszeichnung mit Darstellung. Vermutlich wird eine mit 'line' ausgezeichnete Zeile tatsächlich umgebrochen, wenn du das Fenster ganz schmal ziehst, um die Inhalte weiterhin zugänglich zu machen, aber das kann nicht ernsthaft ein Argument sein.

Warum nicht? Welchen Sinn hat eine Auszeichnung als Zeile, wenn die Darstellung dann halt doch wieder mehrzeilig sein kann?

3. Ist die Frage nach simplen Zeilenumbrüchen IMHO eh eine Thematik der Darstellung, nicht der logischen Strukturierung.

Sag das mal dem Autor eines Gedichts, der sich bei der Einteilung seines Werkes in Strophen und Verse etwas gedacht hat.

Wenn wir <l>...</l> als Spezialfall zur Auzeichnung von Gedichten betrachten wollen, dann: ACK

4. Find ich es kurios, dann ein Inline-Element zu haben, dass sich by default eher wie ein Blocklevel-Element verhält.

Wer sagt, dass 'line' ein Inline-Element ist?

Es ist im Draft zumindest im Inline-Modul. Übersehe ich da was?

5. Erschließt sich mir der Sinn der Unterscheidung zwischen <div>...</div> und <l>...</l> nicht wirklich.

Weshalb erschließt sich dir dann der Unterschied zwischen 'p' und 'div'?

<p>...</p> zeichnet einen Absatz aus. <div>...</div> dagegen etwas, was zusammengehört und entsprechend behandelt werden soll, wofür aber in (X)HTML kein eigenes Element spezifiziert worden ist.

Grüße,

Utz

[Michael Jendryschik]

Wenn wir <l>...</l> als Spezialfall zur Auzeichnung von Gedichten betrachten wollen, dann: ACK

Nicht nur für Gedichte. http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.13. führt die Auszeichnung von Programmcode als Beispiel an. Es sind auch noch weitere Anwendungsfälle denkbar, zum Beispiel Adressen. Was machst du bisher, wenn du den ersten Buchstaben jeder Zeile auf eine bestimmte Art und Weise darstellen möchtest? Separate Auszeichnung mit 'span'?

Wer sagt, dass 'line' ein Inline-Element ist?

Es ist im Draft zumindest im Inline-Modul.

In welchem Draft? http://www.w3.org/TR/2002/WD-xhtml2-20020805/? Vielleicht übersehe ich etwas. An welcher Stelle steht denn, dass 'line' ein Inline-Element werden soll?

Gruß,

MI

[Utz]

Hallo Michael,

Was machst du bisher, wenn du den ersten Buchstaben jeder Zeile auf eine bestimmte Art und Weise darstellen möchtest? Separate Auszeichnung mit 'span'?

Bin bisher nicht auf die Idee gekommen, das zu tun und würde das auch nicht tun (stört den Lesefluss erheblichst). Wenn ich dazu gezwungen wäre das zu tun, würde ich jede Zeile als div auszeichnen.

In welchem Draft? http://www.w3.org/TR/2002/WD-xhtml2-20020805/? Vielleicht übersehe ich etwas.

Sieht so aus - das von Dir verlinkte Draft ist überholt, es gibt ein Neueres: http://www.w3.org/TR/2003/WD-xhtml2-20030506/. Darin gibt es erstens kein <line>...</line> mehr, man hat es zu <l>...</l> verkürzt, und zweitens wird zwischen einem XHTML Block Text Module und einem XHTML Inline Text Module unterschieden. Die Defintion des Inline Text Modules ist:

"This module defines all of the basic text container elements, attributes, and their content models that are "inline level"."

Und in eben diesem Modul befindet sich <l>...</l>.

Grüße,
Utz

[molily]

Hallo,

Nicht nur für Gedichte. http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.13. führt die Auszeichnung von Programmcode als Beispiel an.

ol ist ebenso angemessen meinem unmaßgeblichen Markupempfinden nach. Thomas Caspers nutzt das auf einfachfueralle.de recht treffend.

Es sind auch noch weitere Anwendungsfälle denkbar, zum Beispiel Adressen.

div-Elemente mit Klassen haben m.M.n. nicht weniger Semantik.

Mir ist unklar, wieso folgende Datenstruktur:

<adresse>
<vorname>Petrosilius</vorname>
<nachname>Zwackelmann</nachname>
<strasse>Schwarze Petergasse 13</strasse>
<wohnort>Pusemuckel</wohnort>
</addresse>

...in folgender Form...

<p class="adresse">
<l class="vorname">Petrosilius</l>
<l class="nachname">Zwackelmann</l>
<l class="strasse">Schwarze Petergasse 13</l>
<l class="wohnort">Pusemuckel</l>
</p>

...sonderlich semantisch stimmiger und/oder reicher ist als in folgender Form...

<div class="adresse">
<div class="vorname">Petrosilius</div>
<div class="nachname">Zwackelmann</div>
<div class="strasse">Schwarze Petergasse 13</div>
<div class="wohnort">Pusemuckel</div>
</div>

Lediglich finde ich ein p-Element unter Umständen tatsächlich passender, aber eine Adresse hat mit einen Textabsatz in der Regel wenig zu tun.

Einzig angemessen wäre hier m.M.n. table (oder dl, was den Relationen nach ähnlich ist). Die th-Elemente ließen sich ausblenden bei der Ausgabe...

M.

[molily]

..

Thomas Caspers

Er heißt Tomas.

M.

[Michael Jendryschik]

Hallo,

Nicht nur für Gedichte. http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-text.html#sec_8.13. führt die Auszeichnung von Programmcode als Beispiel an.

ol ist ebenso angemessen meinem unmaßgeblichen Markupempfinden nach. Thomas Caspers nutzt das auf einfachfueralle.de recht treffend.

Ich persönlich kann mich mit Programmcode als geordnete Liste nicht anfreunden. Ebensowenig mit der Idee, eine Adresse sei nichts anderes als ein Haufen von 'div'-Elementen. Darüber könnte man endlos diskutieren, ohne zu einem Ergebnis zu kommen.

MI

[molily]

Hallo, Michael,

Ich persönlich kann mich mit Programmcode als geordnete Liste nicht anfreunden.

Jaaa, anfreunden will ich mich damit auch nicht. :) Pragmatisch ist es aber, ohne den momentan noch rein hypothetischen Vergleich zu XHTML2 zu ziehen, m.M.n. angemessener als <p><code>code<br/>code<br/>code<br/>...</code></p> oder <p><code>code</code><br/><code>code</code><br/>...</p>. In XHTML2 würde ich vermutlich auch die l-Lösung wählen.

Das pre-Element hat beispielsweise überhaupt keine logische Semantik und spielt in einem Verein mit font. Dann zumindest <pre><code>...</code></pre>, womit aber das Problem der Nummerierung ungelöst bliebe. Dafür ist ol praktisch angemessen, weil CSS counter und generated content nicht annähernd interoperabel sind.

Ebensowenig mit der Idee, eine Adresse sei nichts anderes als ein Haufen von 'div'-Elementen.

Was würdest du stattdessen im Idealfall wählen? Die p/l-Lösung? Oder eine Tabellenlösung? Und was im praktischen Fall?

Im Übrigens ist ein Haufen von div-Elementen etwas anderes als ein Haufen von div-Elementen mit class-Attributen, und zwar ohne das eindimensionale Verständnis von class als Attribut, welches oft nur als Handlanger des class selectors in CSS fungiert, ohne eine Elementklasse zu bilden (class="blaugruenmeliert" usw., hatten wir schon einmal, glaube ich).

Darüber könnte man endlos diskutieren, ohne zu einem Ergebnis zu kommen.

Nö, »Ergebnis« vielleicht nicht, aber das strebt ein Meinungsaustausch ja auch nicht an.

Grüße,
Mathias

[Michael Jendryschik]

Hallo,

Ebensowenig mit der Idee, eine Adresse sei nichts anderes als ein Haufen von 'div'-Elementen.

Was würdest du stattdessen im Idealfall wählen? Die p/l-Lösung?

<adresse>
    <vorname>Petrosilius</vorname>
    <nachname>Zwackelmann</nachname>
    <strasse>Schwarze Petergasse 13</strasse>
    <wohnort>Pusemuckel</wohnort>
  </addresse>

wäre für mich der Idealfall. In XHTML 2.0 würde ich vermutlich tatsächlich jede Zeile mit 'l' auszeichnen. Heute würde ich wohl einfach

<p class="adresse">Petrosilius<br />
  Zwackelmann<br />
  Schwarze Petergasse 13<br />
  Pusemuckel</p>

schreiben, ohne davon sonderlich überzeugt zu sein, aber jede andere Lösung gefällt mir ebenso wenig.

Im Übrigens ist ein Haufen von div-Elementen etwas anderes als ein Haufen von div-Elementen mit class-Attributen,

Im Bezug auf die maschinenlesbare Semantik des Elementes nicht wirklich. In <dciwam/> fiel mal der Begriff "Feinstruktur" in diesem Zusammenhang, aber das ist wohl nur was für Theoretiker.

Gruß,

MI

[Tim Tepaße]

Hallo Michael,

Was würdest du stattdessen im Idealfall wählen? Die p/l-Lösung?
  <adresse>
  </addresse>

Dämlicher Vorschlag in die Runde geworfen: RDF und FOAF. ;-)

• Tim

[Tim Tepaße]

Hallo Utz,

Sorry, aber darin kann ich keinen Vorteil erkennen. Meiner unmaßgeblichen
Meinung nach hat "Da soll ein Zeilenumbruch hin" auch nicht weniger mit
logischer Struktur zu tun als "Die Zeile soll von da bis dort gehen".

Hmm. Ich finde, es gibt durchaus Textstücke, die eine Auszeichnung als
einzelne Zeile verdienen. Zum Beispiel Gedichte. Zum Beispiel Quelltext
von Programmmen, wie das Beispiel vom W3C, das Michael gepostet hat. Und
es gibt bestimmt mehr.

(Ok, es ist auch eine Techie-Inzest-Lösung, aber HTML ist voll davon.)

In dem Zusammenhang fänd ich auch eine Konstruktion wie &img['name']; in
Kombination mit <style type="text/css"> (...)

Kannst Du das genauer erläutern? Ich sehe da den Sinn nicht wirklich.

Das img-Element wie sein (eventueller) Nachfolger object dient doch
dazu, externe Objekte in ein Dokument einzubinden. Gibt es irgendeinen
Grund dafür, nicht die klassische HTML/XML-Syntax mit den spitzen
Klämmerchen zu benutzen, sondern stattdessen ein Entity mit einer
neuen, noch zu erfindenen Entity-Technologie mit Parameter?

Und da eingebundene externe Ressourcen wie Bilder mittels img oder
aber auch anderes mittels object ein integraler Bestandteil des
Dokumentes sein sollen, sehe ich auch keinen Grund dafür, die Angabe
der Ressource ins Stylesheet zu verbannen, dessen eigentlich
Eigenschaft nunmal der Konjunktiv der Anwendbarkeit ist.

• Tim

[Utz]

Hallo Tim,

Hmm. Ich finde, es gibt durchaus Textstücke, die eine Auszeichnung als
einzelne Zeile verdienen. Zum Beispiel Gedichte. Zum Beispiel Quelltext
von Programmmen, wie das Beispiel vom W3C, das Michael gepostet hat. Und
es gibt bestimmt mehr.

D'accord, sofern man nicht gezwungen wird, _alles_ als Zeile auszuzeichnen, bloß weil man nen simplen harten Zeilenumbruch braucht. Das verwässert die semantische Bedeutung der Zeilen-Auszeichnung komplett.

Das img-Element wie sein (eventueller) Nachfolger object dient doch
dazu, externe Objekte in ein Dokument einzubinden. Gibt es irgendeinen
Grund dafür, nicht die klassische HTML/XML-Syntax mit den spitzen
Klämmerchen zu benutzen, sondern stattdessen ein Entity mit einer
neuen, noch zu erfindenen Entity-Technologie mit Parameter?

Die Parameter-Technologie war nur so dahinfantasiert...im Ernst: ein Bild innerhalb eines Hypertext-Dokuments ist für mich Bestandteil des Inhaltes (wir ignorieren hier mal die Existenz von a) Null-GIFs und b) Marketing"experten") und als solches eine Entität der dargebotenen Information. Die Grenze zwischen Buchstabe und Bild ist bekanntlich fließend. Keiner käme auf die Idee, chinesische Schriftzeichen als <object> zu referenzieren. Wie würdest Du Hieroglyphen abbilden wollen?

Zweiter, persönlicher Grund: Für mich ist <object> ein deutlicher Hinweis auf blödes Klicki-Bunti und eigentlich ein schöner Anlass, sich mal mit benutzerdefinierten Stylesheets und display:none; zu versuchen. Bilder aber würd ich damit nicht gern killen wollen.

Und da eingebundene externe Ressourcen wie Bilder mittels img oder
aber auch anderes mittels object ein integraler Bestandteil des
Dokumentes sein sollen, sehe ich auch keinen Grund dafür, die Angabe
der Ressource ins Stylesheet zu verbannen, dessen eigentlich
Eigenschaft nunmal der Konjunktiv der Anwendbarkeit ist.

Das versteh ich nicht: nicht nur hat das komplette Web ja eigentlich nämlich diese Eigenschaft, außerdem ist auch die separate Ausschaltbarkeit von Bilder ist ja eine der ältesten Browser-Traditionen.

Grüße,
Utz

[Tim Tepaße]

Hallo Utz,

Wie würdest Du Hieroglyphen abbilden wollen?

Bald mit Unicode. ;o)

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n1637/n1637.htm

(...) außerdem ist auch die separate Ausschaltbarkeit von Bilder ist ja eine
der ältesten Browser-Traditionen.

Wie Du sagtest: Bilder (und andere eingebundene Objekte) sind integraler
Bestandteil eines Dokumentes, ob nun via object oder über deine dynamische
Entity Technologie eingebunden. Stylesheets nicht. Stylesheets sind nur
ein Vorschlag. Wer also Bilder ausschaltet, schaltet einen Teil des
Dokumentes ab.

• Tim

[Michael Jendryschik]

Hallo,

XHTML 1.0 ist lediglich die Reformulierung von HTML 4.01 Strict.

Wie erklärst du dir dann eine XHTML 1.0 Transitional DTD? ;-)

Gruß,

MI

[Michael Jendryschik]

Hallo,

Ein Vorteil in meinen Augen ist zum Beispiel das sich in einer strict-validen XHTML-Datei ausschliesslich Elemente für die Seitenbeschreibung befinden dürfen damit die Datei valide ist.

(X)HTML ist keine Seitenbeschreibungssprache! Bitte lies http://www.sysiphus.de/anybrowser/t_htmlweb.html. (X)HTML ist eine Textauszeichnungssprache, siehe http://jendryschik.de/wsdev/befehle.

Somit könnte endlich das erreicht werden was mit HTML versucht, aber nie durchgesetzt werden konnte: (X)HTML ausschliesslich für die Seitenbeschreibung und CSS für die Formatierung zu verwenden.

Auch wenn wir hier das Wort "Seitenbeschreibung" durch ein geeignetes ersetzen, ist es falsch, was du schreibst. XHTML bietet genauso eine Transitional DTD wie HTML, genau genommen gibt es zwischen beiden Sprachversionen nur syntaktische Unterschiede, insbesondere keine Unterschiede im Element- oder Attributumfang. Es lässt sich also problemlos (und valide!) genau so schlechtes XHTML wie HTML schreiben.

Zweitens soll XHTML langfristig nunmal die Norm der Seitenbeschreibung werden, somit kann man heute schon seine Seiten zukunftssicher schreiben.

Langfristig werden Webautoren XHTML 2.0 mit entsprechenden Erweiterungen wie XFrames verwenden, Techniken also, die mit heutigen zum Teil inkompatibel sind, auch mit dem heutigen XHTML.

Gruß,

MI

[molily]

Hallo,

Ein Vorteil in meinen Augen ist zum Beispiel das sich in einer strict-validen XHTML-Datei ausschliesslich Elemente für die Seitenbeschreibung befinden dürfen damit die Datei valide ist.

(X)HTML ist keine Seitenbeschreibungssprache!

Pawlow lässt grüßen. Woher wusste ich bloß, dass jemand bzw. du im speziellen darauf reagieren würdest?

Erst letztens war eine Diskussion in dciwam, in welcher jemand von (X)HTML als Seitenbeschreibungssprache sprach, ohne offensichtlich etwas anderers als Textauszeichnungssprache zu meinen - eine Sprache zur Beschreibung der Struktur von Hypertextdokumenten eben. Und ein umgangssprachliches Wort für »Hypertextdokument« ist »Webseite«, die Abkürzung davon »Seite«. Der Punkt ist eben, dass »Seitenbeschreibungssprache« bereits vergeben ist, was aber denjenigen, die das Wort für HTML benutzen, i.d.R. fremd ist, weshalb sie gar nicht intendierten, HTML mit PDF et cetera gleichsetzen zu wollen. Es kann sie also gar nicht tangieren, wenn man ihnen mit der genannten Argumentation vorwirft, sie würden die Unwahrheit sagen. Aber das will in die Schädel mancher offensichtlich nicht hinein, obwohl wir es wirklich schon tausendmal durchgekaut haben. Indem man jedes Mal ohne nähere Betrachtung des Kontexts auf dem Begriff herumreitet, lässt sich nicht das Verständnis des Sprechers verbessern. Das ist genausowenig von Erfolg gekrönt wie das erklärungslose Keifen von »HTML kennt keine Befehle!« und Dergleichen (womit ich nicht dein Posting/Artikel im speziellen meine), denn wenn man sich ein wenig in den Sprecher versetzt, ist »Anweisung« bzw. »Befehl« usw. durchaus passend (hatten wir auch schon). Es mag ja stimmen, dass die heilige Terminologie der Informatik verletzt wird, aber wenn ich jemanden etwas erklären möchte, dann ist es nur über bereits vertraute Verständnismodelle möglich.

Ich wette, von mir gibt es mindestens zwei inhaltsgleiche Postings im Archiv.

Grüße,
Mathias

[Michael Jendryschik]

Hallo,

(X)HTML ist keine Seitenbeschreibungssprache!

Pawlow lässt grüßen. Woher wusste ich bloß, dass jemand bzw. du im speziellen darauf reagieren würdest?

Der Aussage zu widersprechen, HTML sei eine Programmiersprache, wäre mir ein eigenes Posting wert gewesen, in diesem Fall jedoch war meine Erwiderung nur eine von dreien, die ich ohne die anderen nicht gepostet hätte.

Erst letztens war eine Diskussion in dciwam, in welcher jemand von (X)HTML als Seitenbeschreibungssprache sprach, ohne offensichtlich etwas anderers als Textauszeichnungssprache zu meinen - eine Sprache zur Beschreibung der Struktur von Hypertextdokumenten eben. Und ein umgangssprachliches Wort für »Hypertextdokument« ist »Webseite«, die Abkürzung davon »Seite«. Der Punkt ist eben, dass »Seitenbeschreibungssprache« bereits vergeben ist, was aber denjenigen, die das Wort für HTML benutzen, i.d.R. fremd ist, weshalb sie gar nicht intendierten, HTML mit PDF et cetera gleichsetzen zu wollen.

Um "AndreD" diese Zusammenhänge klar zu machen, habe ich auf die entsprechenden Artikel verwiesen. Ähnlich handhabe ich es es auch, wenn im Zusammenhang mit HTML von Befehlen gesprochen wird; es folgt immer ein Link zur ausführlichen Erklärung. Wer mein Posting liest, kann der Erklärung folgen und davon profitieren, indem er sie entweder hier diskutiert und seine Schlüsse aus der Diskussion zieht, oder er akzeptiert sie und verwendet im folgenden die richtige Terminologie, er kann es aber auch sein lassen und sich weiterhin ungenau bzw. falsch ausdrücken. Beiträge dieser Art sind somit lediglich ein Angebot, und speziell das Posting, auf das du dich bezogen hast, beinhaltet schließlich noch weitere Aussagen, die die Diskussion in diesem Forum bereichern.

Gruß,

MI

[molily]

Hallo Michael,

Erst letztens war eine Diskussion in dciwam, in welcher jemand von (X)HTML als Seitenbeschreibungssprache sprach, ohne offensichtlich etwas anderers als Textauszeichnungssprache zu meinen - eine Sprache zur Beschreibung der Struktur von Hypertextdokumenten eben. Und ein umgangssprachliches Wort für »Hypertextdokument« ist »Webseite«, die Abkürzung davon »Seite«. Der Punkt ist eben, dass »Seitenbeschreibungssprache« bereits vergeben ist, was aber denjenigen, die das Wort für HTML benutzen, i.d.R. fremd ist, weshalb sie gar nicht intendierten, HTML mit PDF et cetera gleichsetzen zu wollen.

Um "AndreD" diese Zusammenhänge klar zu machen, habe ich auf die entsprechenden Artikel verwiesen.

Genau das stelle ich ja in Frage.

Der sysiphus.de-Artikel argumentiert gegen eine Aussage, die diejenigen, die den Link vorgesetzt bekommen, in der Regel nie getätigt haben. Wie gesagt, sie hatten nicht im Sinn, HTML mit PDF oder gar, wie im Artikel, mit TeX gleichzusetzen. Der Artikel handelt von »Layout im Web«, führt also die Diskussion HTML-Formatierungen/-Layout versus CSS-Formatierungen. Natürlich wird darin auch angesprochen, was HTML eigentlich ist.

In Andres Postings habe ich aber kein Wort darüber gelesen, dass er mit »Seitenbeschreibungssprache« im Sinn hatte, dass HTML dafür gedacht ist, die Darstellung/Präsentation eines Dokuments festzulegen. Insofern ist es m.M.n. absolut unpassend, in einem nicht vorhanden Kontext auf einen Artikel zu verweisen, welcher eine Problematik behandelt, zu der offensichtlich kein Zusammenhang besteht, außer, dass der Artikel ebenfalls den Begriff »Seitenbeschreibungssprache« *in* *einer* *bestimmten,* *anderen* *Lesart* kritisiert. Andre könnte den Artikel durchlesen und ihm möglicherweise vollinhaltlich zustimmen, ohne dass seine Idee von HTML als Seitenbeschreibungssprache tangiert wird.

Ähnlich handhabe ich es es auch, wenn im Zusammenhang mit HTML von Befehlen gesprochen wird; es folgt immer ein Link zur ausführlichen Erklärung.

Die W3C-Terminologie von (X)HTML bzw. SGML/XML basiert auf abstrakten Dokumentmodellen, welche versuchen, die Merkmale der Sprache in ein zusammenhängendes System zu gießen. Alleine die Bezeichnung einer Ansammlung von eckigen Klammern und Zeichen als »HTML-Dokument« ist bereits eine abstrakte Denkleistung (das Verständnis dieses Systems sollte am Anfang der Arbeit mit HTML/CSS/DOM stehen, ohne Frage). Deine Erklärung bzw. die verbreiteten Erklärungen ziehen jedoch keinen Faden von eckigen Klammern zu dem, was als Element und letztlich Dokument bezeichnet wird. Man kann den gängigen Belehrungen, dass es »Element« und nicht »Befehl« heißt, nicht entnehmen, warum dieser strukturierende Teil ausschließlich als Element und nicht als Anweisung o.ä. (mit umgangssprachlicher Bedeutung) verstanden und bezeichnet werden kann bzw. warum ein mit »Elementen«/»Knoten« u.ä. agierendes Dokumentmodell zum Verständnis der übrigen Zusammenhänge extrem hilfreich ist - und um letzteres geht es mir.

Dein Artikel mixt auch einiges durcheinander, bzw. du hast das Durcheinander teilweise Michael Nahraths Posting übernommen. Die Idee »HTML-Befehl« hat nichts zwangsläufiges mit der Problematik »physisches« versus »logisches/semantisches« Markup zu tun, wie deine/Nahraths Erklärung suggeriert. Zudem wird die Idee »HTML-Befehl« unpassenderweise mit der Auffassung »HTML ist eine Programmiersprache« gleichgesetzt. Dagegen ließe sich zunächst dasselbe einwenden wie gegen die Kritik an der Seitenbeschreibungskiste, nämlich dass der Sprecher i.d.R. nicht weiß, was die Fachmenschen unter dem Terminus technicus »Programmiersprache« verstehen. Die Verbindung zwischen »HTML-Befehl« und »HTML ist eine Programmiersprache« entsteht i.d.R. nicht im Kopf derjenigen, die es nicht besser wissen, sondern lediglich im Kopf der Informatiker, die bei »Befehl« sofort Programmiersprachen denken, ohne dass der Sprecher selbiges im Sinn hatte.

Will heißen, wenn hier jemand nach einem HTML-»Befehl« fragt, setzt er im Kopf HTML nicht unbedingt mit einer Programmiersprache gleich. Die Antwort »HTML ist keine Programmiersprache« wäre ebenso absurd wie die Seitenbeschreibungsgeschichte und ginge am Kritisierten vorbei. Die meisten, die hier fragen, leben eben nicht in der Begriffswelt des Duden der Informatik.

(Nebenbei, der von Michael N. verlinkte Artikel versucht zumindest ansatzweise eine Erklärung über ein Dokumentmodell, was mir sehr zusagt, ich schreibe gerade eine ähnliche Abhandlung: »The elements form a containment hierarchy that is actually a tree, as a data structure, with all text data at the leaf nodes. In fact, a document with SGML markup is no more than a linearized representation of such a tree, where all text is embedded in markup.« Dieser Artikel argumentiert auch auf passende Weise gegen die Idee »HTML-Befehl« bzw. definiert/kennzeichnet sie vor allem exakt. Für das Verständnis von HTML im Allgemeinen finde ich einen solchen Hintergrundartikel angemessener, die Begrifflichkeiten bauen darauf auf.)

Wer mein Posting liest, kann der Erklärung folgen und davon profitieren, indem er sie entweder hier diskutiert und seine Schlüsse aus der Diskussion zieht, oder er akzeptiert sie und verwendet im folgenden die richtige Terminologie, er kann es aber auch sein lassen und sich weiterhin ungenau bzw. falsch ausdrücken.

Ich glaube, du hast die Grundaussage meines Postings nicht verstanden. Dein »richtig/falsch ausdrücken« geht nämlich am Kern vorbei.

Die Terminologie ist zweitrangig, das dahinterliegende Konzept ist entscheidend, und das sehe ich nicht hinreichend vermittelt.

und speziell das Posting, auf das du dich bezogen hast, beinhaltet schließlich noch weitere Aussagen, die die Diskussion in diesem Forum bereichern.

Darum ging es mir auch nicht, das wollte ich auch nicht bezweifeln. Ich gedachte schon, bevor du dein Posting geschrieben hattest, eine Antwort zu schreiben à la »Ich wette, ein ganz Schlauer weist jetzt unpassenderweise darauf hin, dass HTML keine Seitenbeschreibungssprache ist«. Und siehe da... ;)

Grüße,
Mathias

[Michael Jendryschik]

Die W3C-Terminologie von (X)HTML bzw. SGML/XML basiert auf abstrakten Dokumentmodellen, welche versuchen, die Merkmale der Sprache in ein zusammenhängendes System zu gießen.

Viel zu abstrakt, um sie in meinem bewusst sehr kurz gehaltenen Artikel zu erläutern.

Dein Artikel mixt auch einiges durcheinander, bzw. du hast das Durcheinander teilweise Michael Nahraths Posting übernommen. Die Idee »HTML-Befehl« hat nichts zwangsläufiges mit der Problematik »physisches« versus »logisches/semantisches« Markup zu tun, wie deine/Nahraths Erklärung suggeriert.

Du sprichst vor allem das Beispiel am Ende des Artikels an? Ich stimme dir zu, es ist ín diesem Zusammenhang nicht passend, auch die Argumentation an sich lässt sich hinterfragen. Ich bin auf deine Abhandlung zu diesem Thema gespannt und hoffe, dass du sie auch auf deutsch veröffentlichst.

Wer mein Posting liest, kann der Erklärung folgen und davon profitieren, indem er sie entweder hier diskutiert und seine Schlüsse aus der Diskussion zieht, oder er akzeptiert sie und verwendet im folgenden die richtige Terminologie, er kann es aber auch sein lassen und sich weiterhin ungenau bzw. falsch ausdrücken.

Ich glaube, du hast die Grundaussage meines Postings nicht verstanden.

Das geht mir bei deinen Postings oft so.

Gruß,

MI

[molily]

Hallo,

Die W3C-Terminologie von (X)HTML bzw. SGML/XML basiert auf abstrakten Dokumentmodellen, welche versuchen, die Merkmale der Sprache in ein zusammenhängendes System zu gießen.

Viel zu abstrakt, um sie in meinem bewusst sehr kurz gehaltenen Artikel zu erläutern.

Dann fallen offensichtlich für das Verständnis entscheidende Details unter den Tisch.

Dein Artikel mixt auch einiges durcheinander, bzw. du hast das Durcheinander teilweise Michael Nahraths Posting übernommen. Die Idee »HTML-Befehl« hat nichts zwangsläufiges mit der Problematik »physisches« versus »logisches/semantisches« Markup zu tun, wie deine/Nahraths Erklärung suggeriert.

Du sprichst vor allem das Beispiel am Ende des Artikels an?

Ja.

Ich stimme dir zu, es ist ín diesem Zusammenhang nicht passend, auch die Argumentation an sich lässt sich hinterfragen. Ich bin auf deine Abhandlung zu diesem Thema gespannt und hoffe, dass du sie auch auf deutsch veröffentlichst.

Da war mein Satzbau unpassend, das Zitat stammte aus http://css.nu/markup/markup-tagsoup.html; der Artikel, den ich schreibe, liegt momentan hingegen extrem unfertig auf http://home.t-online.de/home/dj5nu/fanhost/dokumentmodelle.html (die Grafiken fehlen) und wird auf Deutsch erscheinen (wobei ich nicht grundsätzlich abgeneigt bin, ihn nachträglich zu übersetzen). Bisher bin ich auf die Problematik »Befehl« selbst nicht eingegangen (und hatte bisher auch nur den Programmiersprachen-Aspekt im Kopf hatte).

Grüße,
Mathias

[Michael Jendryschik]

Hallo,

Da war mein Satzbau unpassend, das Zitat stammte aus http://css.nu/markup/markup-tagsoup.html; der Artikel, den ich schreibe, liegt momentan hingegen extrem unfertig auf http://home.t-online.de/home/dj5nu/fanhost/dokumentmodelle.html

Zu deinem Abschnitt "Häufige Begriffsverwechslungen und -variationen" passt die Tabelle auf http://www.flightlab.com/~joe/sgml/faq-not.txt, Part 5. Terminology:

--------------------------------------------------
    ISO/W3C terminology                Common name
    --------------------------------------------------
    attribute                          tag
    attribute value                    tag
    attribute value literal            tag
    attribute value specification      tag
    character reference                tag
    comment                            tag
    comment declaration                tag
    declaration                        tag
    document type declaration          tag
    document type definition           tag
    element                            tag
    element type                       tag
    element type name                  tag
    entity                             tag
    entity reference                   tag
    general entity                     tag
    generic identifier                 tag
    literal                            tag
    numeric character reference        tag
    parameter entity                   tag
    parameter literal                  tag
    processing instruction             tag
    tag                                command
    --------------------------------------------------

:-))

Ansonsten habe ich den Text nur sehr oberflächlich überflogen, aber sag bitte Bescheid, wenn er fertig ist.

Gruß,

MI

[Tim Tepaße]

Hallo Mathias,

Alleine die Bezeichnung einer Ansammlung von eckigen Klammern und Zeichen
als »HTML-Dokument« ist bereits eine abstrakte Denkleistung

Neulich war ich versucht, sämtliche Begriffe wie Webseite, Datei, Dokument
und ähnliches aus meinem Posting-Vokabular zu verbannen und konsequent nur
noch den Begriff 'Ressource' zu verwenden.

Ich habe es dann doch gelassen. Im Fernsehen lief gerade Big Brother. ;o)

• Tim

[molily]

Hallo,

Alleine die Bezeichnung einer Ansammlung von eckigen Klammern und Zeichen als »HTML-Dokument« ist bereits eine abstrakte Denkleistung

Neulich war ich versucht, sämtliche Begriffe wie Webseite, Datei, Dokument und ähnliches aus meinem Posting-Vokabular zu verbannen und konsequent nur noch den Begriff 'Ressource' zu verwenden.

Ich denke nicht, das das irgendwie hilfreich wäre. Es sind verschiedene Modelle bzw. Sichtweisen, welche alle ihre jeweiligen Vorzüge haben und berechtigt sind. Sie bedeuten keinesfalls dasselbe und lassen sich auch nicht verlustlos in »Ressource« subsummieren.

Eine Datei kann beispielsweise ein PHP-Script sein, welches Markup und PHP-Code enthält, aber nicht zwangsläufig eine vollständige Hypertext-Datei produziert. Im Zusammenspiel mit anderen Dateien (Scripts oder Datenspeicherdateien) und Quellen wie Datenbanken wird aber letztlich ein vollständiges HTML-Dokument erzeugt. Dieses Dokument referenziert wiederum andere Quellen wie Grafiken, Stylesheets, JavaScripts (welche in der Regel auf Dateien basieren, welche aber auch generiert werden können etc.). Das Ergebnis würde ich dann als Webseite bezeichnen. Zuletzt greift natürlich der Begriff Ressource für diese Bestandteile, aber alles Darunterliegende lässt sich nicht »Ressource« zusammenfassen.

M.

[Hans Thomas Vogler]

Hallo,

Hallöchen,

(X)HTML ist keine Seitenbeschreibungssprache! Bitte lies http://www.sysiphus.de/anybrowser/t_htmlweb.html. (X)HTML ist eine Textauszeichnungssprache, siehe http://jendryschik.de/wsdev/befehle.

Ich will ja nicht den Oberlehrer spielen, aber eine "Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein eine "Auszeichnungssprache" oder wenn schon, dann eine "Dokumentenelementauszeichnungssprache", wobei "Text" eines von etlichen möglichen Elementtypen sein kann - wenn auch das vorrangige und hauptsächliche. Insofern halte ich diesen Faden der Diskussion für einen Streit um des Kaisers Bart.

Aber ich studiere ja auch nicht Informatik und bekomme gute Noten für besonders penible Anwendung der Terminologie...

Ansonsten kann ich molily im Beitrag [pref:t=50016&m=273999] nur beipflichten.

Gruß,

MI

servus,
T.

[Michael Jendryschik]

Hallo,

(X)HTML ist keine Seitenbeschreibungssprache! Bitte lies http://www.sysiphus.de/anybrowser/t_htmlweb.html. (X)HTML ist eine Textauszeichnungssprache, siehe http://jendryschik.de/wsdev/befehle.

Ich will ja nicht den Oberlehrer spielen, aber eine "Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein eine "Auszeichnungssprache" oder wenn schon, dann eine "Dokumentenelementauszeichnungssprache", wobei "Text" eines von etlichen möglichen Elementtypen sein kann - wenn auch das vorrangige und hauptsächliche.

http://dict.leo.org/?search=markup sieht das anders.

Aber ich studiere ja auch nicht Informatik und bekomme gute Noten für besonders penible Anwendung der Terminologie...

Wer bekommt das schon?

Gruß,

MI

[Hans Thomas Vogler]

Hallo,

Tach,

http://dict.leo.org/?search=markup sieht das anders.

Wenn die dort "markup language" mit "Textauszeichnungssprache" übersetzen, ist das ganz klar ein Fehler. Die korrekte Übersetzung ist "Auszeichnungssprache" und kein Tüttelchen dazu.

Daß HTML als Kürzel für "Hypertext Markup Language" steht, hat auch nichts mit vermeintlicher "Textauszeuchnung" zu tun. Es bedeutet lediglich, daß es sich um eine Auszeichnungssprache handelt, die für das *Medium* Hypertext geschaffen wurde.

Auch LEO-Redakteure dürfen Fehler machen. Deswegen hat aber LEO nicht immer recht.

servus,
T.

[molily]

Hallo,

Ich will ja nicht den Oberlehrer spielen, aber eine "Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein eine "Auszeichnungssprache"

Wenn du darauf anspielst, dass sich theoretisch beliebige andere Medientypen in (X)HTML integrieren lassen können und sich die Auszeichnung auch auf diese Inhalte vererbt: Das stimmt m.M.n. nur teilweise. Zwar kann ein (X)HTML-Dokument eine Metastruktur bilden, in welcher externe Objekte angeordnet/miteinander in Bezug gesetzt werden und durch Metadaten ergänzt bzw. determiniert werden (Beispiel: Grafiken in einer Tabelle mit Bildbeschreibungen), aber die »Eigenschaften«, welche durch das Markup auf die externen Objekte weitergegeben werden, beziehen sich bei allen direkt inhaltstragenden Objekten (bei welchen die Transformierung sinnig ist) genauso bzw. vor allem auf den Alternativinhalt, welcher letztendlich Text ist. Dass (X)HTML-Dokumente auch in einem bestimmenden Zusammenhang auf externe Inhalte referenzieren, bedeutet m.E. in der Regel nicht, dass sie diese der Definition nach »auszeichnen« im Sinne von differenzieren/analysieren/strukturieren, wenn doch das Objekt selbst nur eine mehr oder weniger äquivalente Repräsentanz eines Textes bildet, auf welchen sich das Dokument zurückführen lässt.

oder wenn schon, dann eine "Dokumentenelementauszeichnungssprache",

Wieso passt das besser? Aufgrund des Hypermedia-Aspektes, welcher andere Knoten als nur Text annimmt?

wobei "Text" eines von etlichen möglichen Elementtypen sein kann

Was verstehst du unter Elementtypen?
Der Elementinhalt ist immer Text. Ein object-Element zeichnet strenggenommen nur den Text darin aus und verweist auf Inhalte, welche diesen Text in anderer Weise aussagekräftiger wiedergeben. Diese Theorie geht natürlich an der Realität vorbei, weil (X)HTML tatsächlich als Hypermedia-Sprache genutzt wird und beim Einbinden vieler Objekte kein dadurch ausgezeichneter Text zugrunde liegt.

Grüße,
Mathias

[Hans Thomas Vogler]

Hallo,

Ich will ja nicht den Oberlehrer spielen, aber eine "Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein eine "Auszeichnungssprache"

Wenn du darauf anspielst, dass sich theoretisch beliebige andere

...[viel Text]...

oder wenn schon, dann eine "Dokumentenelementauszeichnungssprache",

Wieso passt das besser? Aufgrund des Hypermedia-Aspektes, welcher andere Knoten als nur Text annimmt?

Da spricht der Programmiertheoretiker. Ich habe einen anderen Hintergrund. Studiert habe ich Kommunikationswissenschaften, gearbeitet lange Zeit als Redakteur. SGML, die "Mutter aller Auszeichnungssprachen" (besser:Auszeichnungssysteme), kommt aus der Welt der großen Redaktionssysteme und wurde dazu geschaffen, die Layout-Elemente einer Zeitung auszuzeichnen - nicht den Text! Der ist nur Füllmaterial. Die "Elemente", um die es da geht, sind z.B. Überschrift, Untertitel, Abstract, Fließtext, Seitenheader, Bildkasten, Bildunterschrift, Zwischentitel usw. usf.

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

HTML als Abkömmling von SGML ist das alles noch anzumerken, XHTML genauso. Mit den Stylesheets, die o.a. Elementen ihre Eigenschaften zuweisen, ist die Entwicklung noch deutlicher und stärker in Richtung professioneller Seitengestaltung gegangen, wie sie bei der Produktion moderner Zeitungen und Magazine längst selbstverständlich ist.

Was verstehst du unter Elementtypen?

Sollte damit hinreichend geklärt sein.

Der Elementinhalt ist immer Text.

Unwidersprochen. Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

Wenn sich mehr Leute der Herkunft von HTML aus dem Bereich der sogenannten "Schwarzkunst" im Klaren wären und sich ein wenig mit dessen Gesetzmäßigkeiten und immanenter Logik auseinandersetzen würden, hätten wir weitaus mehr informative und tatsächlich rezipierbare Websites anstelle der leider immer noch üblichen infantilen Klick- und Blinkorgien.

Grüße,
Mathias

servus,
T.

[Michael Jendryschik]

SGML, die "Mutter aller Auszeichnungssprachen" (besser:Auszeichnungssysteme), kommt aus der Welt der großen Redaktionssysteme und wurde dazu geschaffen, die Layout-Elemente einer Zeitung auszuzeichnen - nicht den Text! Der ist nur Füllmaterial. Die "Elemente", um die es da geht, sind z.B. Überschrift, Untertitel, Abstract, Fließtext, Seitenheader, Bildkasten, Bildunterschrift, Zwischentitel usw. usf.

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

Verstehe ich nicht. So wie ich HTML verwende, habe ich einen Text vorliegen, den ich für das Web geschrieben habe oder nachträglich ins Weg bringen möchte, vielleicht noch ergänzt durch Bildunterschriften oder Anmerkungen, und "bastle" meine HTML-Tags drumherum, zeichne also die Überschrift als solche aus, eine Liste, eine Tabelle und so weiter. Was genau meinst du mit "Inhalt Elementen zuweisen" oder mit folgender Aussage?

Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

Gruß,

MI

[Hans Thomas Vogler]

HiMi,

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

Verstehe ich nicht. So wie ich HTML verwende, habe ich einen Text vorliegen, den ich für das Web geschrieben habe oder nachträglich ins Weg bringen möchte, vielleicht noch ergänzt durch Bildunterschriften oder Anmerkungen, und "bastle" meine HTML-Tags drumherum, zeichne also die Überschrift als solche aus, eine Liste, eine Tabelle und so weiter. Was genau meinst du mit "Inhalt Elementen zuweisen" oder mit folgender Aussage?

In der Vor-Computer-Ära sahen Artikel mit redaktioneller Auszeichnungen schreibmaschinengetippt in etwa so aus:

((Überschrift:)) King Kong ausgebrochen!

((Untertitel:)) Mutter des Vermißten fiel im Schock vom Eukalyptus

((Abstract:)) Seattle, USA: Das erst zwei Wochen alte Koala Baby "King Kong", das erste, das im Zoo von Seattle je geboren wurde, nutzte einen unbeobachteten Moment, als Wärter George W. Kush frische Eukalyptusblätter ins Koala-Gehege brachte, um auszubüxen. Seither ist  "King Kong" spurlos verschwunden. Die Polizei in Seattle ist ratlos, ihre Spürhunde machtlos: sie vertragen den Eukalyptusgeruch nicht.

((Fließtext:))
Irgendeintext und noch mehr Text und nochmehr...

((Zwischentitel:)) King Kong ist ein süßer "Teddy"

Undweiterimtext: Koalas gelten als die eigentlichen Stammväter der sogenannten "Teddy-Bären", die nach dem amerikanischen Präsidenten Theodore Roosevelt benannt wurden. Undnochmehrtext undsoweiterundsofortblablabla

((Zwischentitel:)) Hundenasen sind empfindlich

Und nochmehrtextsolangebisdas vorgegebene Limit von Zeichen und Zeilen erreicht ist.

((Kürzel:)) -htv-

Auszeichnungssprachen wie SGML machten diese noch für Menschenaugen (die des "Herstellers") gedachte und noch nicht standardisierte Auszeichnungssprache "maschinengerecht".

Bei professioneller Textarbeit mache ich mir zuerst Gedanken über die Elemente, die ich verwenden werde bzw. zu verwenden habe. Sie haben in der Regel Limitierungen, beispielsweise "Überschrift maximal 35 Zeichen" oder "Fließtext 300 Zeilen à 60 Anschläge". Auch Absätze haben Limitierungen wie "mindestens 8, maximal 15 Zeilen à 60 Anschläge".

Der Grund: der Text ist so ziemlich das Letzte, was ankommt. Meist steht das Basis-Layout schon vor dem Thema fest, die Anzeigenplätze sind zugewiesen, mit seiner Zugehörigkeit zu einer bestimmten Rubrik bzw. Artikelgruppe sind die grundlegenden Eigenschaften aller Elemente bereits festgelegt, bevor der Text "hineinproduziert" wird.

Die formalen Beschränkungen haben ihren Grund in der optimalen Ausnutzung der Rezeptionsfähigkeit des Lesers. Da gibt es Unterschiede. Der BILD-Leser braucht eine 100-Punkt-Überschrift mit maximal 15 Buchstaben, weil alles andere seinen Aufmerksamkeitspuffer überladen würde, der Fließtext darf maximal 10 Zeilen à 40 Zeichen haben, weil er sonst einschläft. Einem SPIEGEL-Leser kann man da mehr zumuten: die Überschriften sind entsprechend kleiner und ein üblicher Artikel besteht aus sehr viel mehr Elementen.

Die durchgängige Elementenzuordnung und -gestaltung hilft dem Leser (Rezipienten) bei der Orientierung und erleichtert ihm die Informationsaufnahme. Aus neurophysiologischen Gründen haben alle 'Blöcke' bestimmte Maxima. Es ist kein Zufall, daß die Zeilenlängen von Tageszeitungen selten mehr als 45 Anschläge haben. Dieser kleinste "Block" nach dem "Wort" ist ein Durchschnittswert, der wenige Leser überfordert. Sie können eine solche Zeile 'en bloc' rezipieren und brauchen sie nicht unbedingt Wort für Wort durchzulesen. Bei etwa 60 Zeichen ist auch beim Gebildeten Oberkante: wenn das Gehirn keine Blöcke bekommt, macht es sich welche. d.h. eine Zeile von 90 Zeichen ist mühsamer zu lesen als zwei Zeilen mit 60 Zeichen, obwohl da immerhin ein Viertel mehr drin steht.

Das setzt sich immer weiter fort. Und wenn Du Deine HTML-Texte wie beschrieben herstellst, ist das aus professioneller Warte strenggenommen falsch. Du müßtest Dir *vor* dem Schreiben überlegen, welche Elemente du verwenden willst, wie sie formatiert, definiert und dimensioniert sein sollen, um Deine Zielgruppe optimal ansprechen zu können. Diese formalen Vorgaben haben nämlich letztlich Einfluß nicht nur auf die Text-Ausgestaltung, sondern auch auf Art und Stil des Inhalts.

Es gibt nichts, was man nicht auch kürzer sagen könnte.

Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

...sondern das, was am Schluß reinkommt.

Gruß,

MI

servus,
T.

[Michael Jendryschik]

In der Vor-Computer-Ära sahen Artikel mit redaktioneller Auszeichnungen schreibmaschinengetippt in etwa so aus:

((Überschrift:)) King Kong ausgebrochen!

<h1>King Kong ausgebrochen!</h1>

((Untertitel:)) Mutter des Vermißten fiel im Schock vom Eukalyptus

<h2>Mutter des Vermißten fiel im Schock vom Eukalyptus</h2>

((Abstract:)) Seattle, USA: Das erst zwei Wochen alte Koala Baby "King Kong", das erste, das im Zoo von Seattle je geboren wurde, nutzte einen unbeobachteten Moment, als Wärter George W. Kush frische Eukalyptusblätter ins Koala-Gehege brachte, um auszubüxen. Seither ist  "King Kong" spurlos verschwunden. Die Polizei in Seattle ist ratlos, ihre Spürhunde machtlos: sie vertragen den Eukalyptusgeruch nicht.

<p class="abstract">Seattle, USA: Das erst zwei Wochen alte Koala Baby "King Kong", das erste, das im Zoo von Seattle je geboren wurde, nutzte einen unbeobachteten Moment, als ...</p>

((Fließtext:))
Irgendeintext und noch mehr Text und nochmehr...

<p>Irgendeintext und noch mehr Text und nochmehr...</p>

((Zwischentitel:)) King Kong ist ein süßer "Teddy"

<h3>King Kong ist ein süßer "Teddy"</h3>

...

Bei professioneller Textarbeit mache ich mir zuerst Gedanken über die Elemente, die ich verwenden werde bzw. zu verwenden habe. Sie haben in der Regel Limitierungen, beispielsweise "Überschrift maximal 35 Zeichen" oder "Fließtext 300 Zeilen à 60 Anschläge". Auch Absätze haben Limitierungen wie "mindestens 8, maximal 15 Zeilen à 60 Anschläge".

Der Grund: der Text ist so ziemlich das Letzte, was ankommt. Meist steht das Basis-Layout schon vor dem Thema fest, die Anzeigenplätze sind zugewiesen, mit seiner Zugehörigkeit zu einer bestimmten Rubrik bzw. Artikelgruppe sind die grundlegenden Eigenschaften aller Elemente bereits festgelegt, bevor der Text "hineinproduziert" wird.

Das lässt sich nur dann nachvollziehen, wenn Texte für ein vorher bekanntes Layout geschrieben werden, also immer eine Hauptüberschrift haben, einen Untertitel, eine Zusammenfassung und so weiter. Redaktionell betreute Seiten werden so verfahren, damit meine ich vor allem Online-Ausgabe von Zeitschriften und Zeitungen wie Spiegel oder Bild. Das darfst du allerdings nicht auf das gesamte Publizieren im Web verallgemeinern.
Ich für meinen Teil schreibe Texte, die ich im Web zu veröffentlichen beabsichtige, in einem beliebigen Textverarbeitungsprogramm und drucke mir den fertigen Text aus. Dann folgen handschriftliche Anmerkungen, vergleichbar mit Anweisungen für Setzer, wie es früher üblich gewesen ist. Bevor ich einen Text ins Web übertrage, habe ich somit dessen Inhalt vorliegen und mir bereits Gedanken über die Semantik seiner Bestandteile gemacht. Diese versuche ich nun mit den geeigneten Elementen zu erfassen, wenn ich den Text in XHTML übertragen.
Ich bin überzeugt davon, dass viele es ähnlich machen. Deine Aussage "Der 'Inhalt' ist aber eben nicht das auszuzeichnende Element." kann ich aus diesem Grund überhaupt nicht nachvollziehen.

Und wenn Du Deine HTML-Texte wie beschrieben herstellst, ist das aus professioneller Warte strenggenommen falsch.

Publizieren im Web und Publizieren in Printmedien sind zwei vollkommen verschiedene Paar Schuhe. Es gibt wenig Gesetzmäßigkeiten, die sich von einem Medium ins andere übertragen lassen. Ich denke, unsere unterschiedlichen Auffassungen sind ein guter Beleg dafür.

Gruß,

MI

[Hans Thomas Vogler]

In der Vor-Computer-Ära sahen Artikel mit redaktioneller Auszeichnungen schreibmaschinengetippt in etwa so aus:

((Überschrift:)) King Kong ausgebrochen!

<h1>King Kong ausgebrochen!</h1>

Ebent. Das zeigt die Herkunft. Es steht eben nicht so da:

<fett und richtig groß>King Kong ausgebrochen</fett und richtig groß>

sondern:

<Überschrift erster Ordnung>King Kong ausgebrochen</Überschrift erster Ordnung>

Der Grund: Typographie und Eigenschaftszuweisungen der Elemente wurden und werden von anderen Abteilungen gemacht - ohne den Text dazu. Sie bleiben auch für eine Menge 'n' von Texten gleich, obwohl der Inhalt sich ändert.

Das lässt sich nur dann nachvollziehen, wenn Texte für ein vorher bekanntes Layout geschrieben werden, also immer eine Hauptüberschrift haben, einen Untertitel, eine Zusammenfassung und so weiter.

Das sollte aber so sein. Und tatsächlich sind HTML und alle Derivate darauf ausgerichtet.

Redaktionell betreute Seiten werden so verfahren, damit meine ich vor allem Online-Ausgabe von Zeitschriften und Zeitungen wie Spiegel oder Bild. Das darfst du allerdings nicht auf das gesamte Publizieren im Web verallgemeinern.

Doch. Auch wenn Du diesbezüglich Amateur bist, bist Du letztlich Redakteur, Layouter, Grafiker und Hersteller in einer Person, die verantwortlich ist für die redaktionelle Betreuung ihrer Seiten. Und wenn Du ein schlauer Amateur bist, dann orientierst Du Dich an der professionellen Vorgehensweise und legst erst einmal die passenden Elemente als eine Art Schablone an, die Du dann für alle Seiten einer bestimmten Artikelgruppe verwendest. Können je nach Anforderung natürlich verschiedene sein mit unterschiedlichen Elementen und typographischen Merkmalen.

Ich für meinen Teil schreibe Texte, die ich im Web zu veröffentlichen beabsichtige, in einem beliebigen Textverarbeitungsprogramm und drucke mir den fertigen Text aus.

Das mag schon sein, und man kann ja auch mit einem Buntstift sowas ähnliches wie eine Zeitung oder ein Buch malen. Ab einer gewissen Menge von Inhalten ist das aber ein sehr mühsames Verfahren.

HTML 2.0 hat einem dieses Vorgehen durch die unselige Vermengung von Inhalt, Struktur und Outfit aufgezwungen, weswegen professionelles Arbeiten damit eben so gut wie nicht möglich war. Heute ist das gottlob anders. Deswegen muß aber niemand seinen liebgewonnenen Buntstift wegwerfen. Wer unbedingt umständlicher bei geringerer Effektivität arbeiten will, soll das ruhig tun.

Ich bin überzeugt davon, dass viele es ähnlich machen.

Davon bin ich überzeugt. Das heißt aber nicht, daß sie es "richtig" machen im Sinne eines einerseits professionellen Anspruchs (optimale Effektivität bzgl. der Rezipierbarkeit und damit Leserfreundlichkeit) und andererseits im Hinblick auf Rationalisierung und Vereinfachung ihrer Textarbeit.

Deine Aussage "Der 'Inhalt' ist aber eben nicht das auszuzeichnende Element." kann ich aus diesem Grund überhaupt nicht nachvollziehen.

Dann versuch einfach, es mal anders zu sehen. Deine Leser werden es Dir danken, weil sie sich leichter orientieren können, und wenn Du Dich erst mal dran gewöhnt hast, wirst Du nicht verstehen, warum Du Dich so lange mit dem Buntstift geplagt hast. Du hast weniger Arbeit damit und kommst wesentlich besser "rüber".

Publizieren im Web und Publizieren in Printmedien sind zwei vollkommen verschiedene Paar Schuhe. Es gibt wenig Gesetzmäßigkeiten, die sich von einem Medium ins andere übertragen lassen.

Einspruch. Natürlich gibt es medienbedingte Unterschiede. Die sind aber so groß nicht, wie es zunächst den Anschein hat. Es gibt etliche Gesetzmäßigkeiten, die einfach deshalb gleich bleiben, weil die gleichen Menschen mit demselben neurophysiologischen Instrumentarium die Leserschaft bilden. *Das* setzt nämlich die Grundbedingungen und nicht die Möglichkeiten des Mediums.

Ich denke, unsere unterschiedlichen Auffassungen sind ein guter Beleg dafür.

Hast Du Dir jemals Gedanken darüber gemacht, daß Du als Schreiber Deinen Output gar nicht aus der Warte des Lesers beurteilen kannst?

Preisfrage: warum kann man eine Zeitung oder ein Buch "lesen", einen Schuhkarton mit bedruckten DIN-A4-Blättern, auf denen dasselbe steht, aber nicht?

Gruß,

MI

servus,
T.

PS.: Um den Ausgangspunkt dieses Diskussionsfadens ins Gedächtnis zu rufen: es ging um die Frage ob "Seitenauszeichnungssprache" richtig ist oder "Textauszeichnungssprache". Ich sage: beides falsch, aber "Seitenauszeichnungssprache" ist nicht ganz so irreführend wie "Textauszeichnungssprache".

Daß andere das vielleicht anders sehen und dies sogar publizieren dürfen, sagt da erst mal gar nichts aus. Ich habe mein Handwerk von der Pike auf gelernt und weiß, wovon ich rede.

Und englisch kann ich gut genug, um versichern zu können, daß LEO´s Übersetzung von "markup language" in "Textauszeichnungssprache" einfach falsch ist. "markup" heißt "Auszeichnung", "language" heißt "Sprache", und "markup language" heißt demzufolge "Auszeichnungssprache".

[Michael Jendryschik]

Das lässt sich nur dann nachvollziehen, wenn Texte für ein vorher bekanntes Layout geschrieben werden, also immer eine Hauptüberschrift haben, einen Untertitel, eine Zusammenfassung und so weiter.

Das sollte aber so sein.

Das glaube ich dir gern, wenn ich davon ausgehe, einen Artikel für eine mir bekannte Zeitschrift oder ein Online-Magazin zu schreiben, nach deren Styleguide ich mich dann richte. Aber denkst du wirklich, komplexe Dokumente wie http://www.w3.org/TR/WAI-WEBCONTENT/ sind ausschließlich nach einem solchen Muster entstanden? Natürlich werden die Inhalte des Dokumentkopfes in bekannte Schemata gefüllt, natürlich gibt es einen Abschnitt "Abstract" und ein Inhaltsverzeichnis, ein Abschnitt mit Referenzen. Insofern verstehe ich, was du meinst. Aber dann? Die einzelnen Listen, die Richtlinien, Checkpunkte - das *alles* wurde doch nicht in vorgefertigte Strukturen gepresst?

Deine Aussage "Der 'Inhalt' ist aber eben nicht das auszuzeichnende Element." kann ich aus diesem Grund überhaupt nicht nachvollziehen.

Dann versuch einfach, es mal anders zu sehen. Deine Leser werden es Dir danken, weil sie sich leichter orientieren können, und wenn Du Dich erst mal dran gewöhnt hast, wirst Du nicht verstehen, warum Du Dich so lange mit dem Buntstift geplagt hast. Du hast weniger Arbeit damit und kommst wesentlich besser "rüber".

Reden wir konkret über http://jendryschik.de/wsdev/css/fixed/. Hier war die Vorgehensweise ähnlich, wie im letzten Posting von mir beschrieben. wie hätte ich es anders machen sollen, um "professionell" oder in deinem Sinne effektiv zu sein? Oder gar http://jendryschik.de/michael/inf/wissensgesellschaft/, das Ergebnis einer Seminararbeit. Auch hier existierte die Arbeit auf dem Papier und fand erst dann ihren Weg ins Netz. Wie lässt sich das mit deiner Vorgehensweise vereinbaren?

Hast Du Dir jemals Gedanken darüber gemacht, daß Du als Schreiber Deinen Output gar nicht aus der Warte des Lesers beurteilen kannst?

Habe ich. Und ich bin der Ansicht, ein grottenschlechter Autor zu sein, der selten in der Lage ist, seine Aussagen auf den Punkt zu bringen und seiner Leserschaft zu vermitteln.

Preisfrage: warum kann man eine Zeitung oder ein Buch "lesen", einen Schuhkarton mit bedruckten DIN-A4-Blättern, auf denen dasselbe steht, aber nicht?

Weil der bereits vorliegende Text nicht in geeignetem Maße nachträglich gesetzt worden ist? *g*

Gruß,

MI

[Hans Thomas Vogler]

Aber denkst du wirklich, komplexe Dokumente wie http://www.w3.org/TR/WAI-WEBCONTENT/ sind ausschließlich nach einem solchen Muster entstanden?

Absolut. Für diese Arbeit gibt es Spezialisten, und wenn ich das Geld hätte, würde ich mir auch so einen leisten - damit ich mich eben auf die Textarbeit konzentrieren kann.

In der Regel wird eine solche Publikation - ob nun online oder print - zunächst nach den benötigten Elementen aufgelöst, ggf. wird nachgebessert. Die Elementenliste, die der Autor dann nur noch ansprechen muß, erleichtert ihm seine Arbeit. Wenn sich herausstellt, daß er mehr Elemente benötigt, als vorgesehen, wird das ausdiskutiert und entsprechend umgesetzt.

Bei solchen Projekten darfst Du nicht vergessen, daß ja immer mehrere Autoren an der Dokumentation arbeiten und deren Dokumente sollten dennoch ein durchgängiges Outfit und eine vereinheitlichte Dokumentenstruktur haben. Trotzdem unterscheiden sie sich - allerdings nur, wo das nötig ist. Deswegen kommt die Element-Auszeichnung zuerst, und dann der Text bzw. der Inhalt. Die Autoren haben damit einen Leitfaden für ihre Arbeit. Printmedien haben idR übrigens noch weitaus komplexere Strukturen.

Natürlich werden die Inhalte des Dokumentkopfes in bekannte Schemata gefüllt, natürlich gibt es einen Abschnitt "Abstract" und ein Inhaltsverzeichnis, ein Abschnitt mit Referenzen. Insofern verstehe ich, was du meinst. Aber dann? Die einzelnen Listen, die Richtlinien, Checkpunkte - das *alles* wurde doch nicht in vorgefertigte Strukturen gepresst?

Nicht vergessen: es geht um variable Strukturen, die einem vereinheitlichten Schema entsprechen, aber nicht gleich sind. Es gibt unterschiedliche Anzahlen von Elementen und unterschiedliche Klassen. Aber es kommt einfach nicht vor, daß da ein Autor selber ein bißchen nachbessert, weil er´s schöner und passender findet. Jedes neu entwickelte Elementenschema wird zu festgelegten Bedingungen auch von allen Autoren verwendet.

Reden wir konkret über http://jendryschik.de/wsdev/css/fixed/. Hier war die Vorgehensweise ähnlich, wie im letzten Posting von mir beschrieben. wie hätte ich es anders machen sollen, um "professionell" oder in deinem Sinne effektiv zu sein? Oder gar http://jendryschik.de/michael/inf/wissensgesellschaft/, das Ergebnis einer Seminararbeit. Auch hier existierte die Arbeit auf dem Papier und fand erst dann ihren Weg ins Netz. Wie lässt sich das mit deiner Vorgehensweise vereinbaren?

Ich will Deine Website hier nicht kritisieren, die Dokumente sind schön und übersichtlich gestaltet. Als Leser fehlt mir aber eben der stringente Aufbau. Gleichartige Elemente sollten auch gleichartig aussehen, einzelne Seiten einem Basis-Muster entsprechen, an dem ich mich auf jeder einzelnen Seite gleichermaßen orientieren kann. Wenn ich das eine Mal mit einem Menükasten empfangen werde, auf einer anderen Seite mit einem schönen Sinnspruch und eine dritte mich unvermittelt auf anderen Webspace mit völlig anderem Design und anderer Struktur verweist, muß ich einfach zuviel Zeit und Energie aufwenden, um mich neu zu orientieren. Das geht dann für das Rezipieren des Inhalts - worum es eigentlich ja geht - verloren. Es ermüdet mich schnell.

Hast Du Dir jemals Gedanken darüber gemacht, daß Du als Schreiber Deinen Output gar nicht aus der Warte des Lesers beurteilen kannst?

Habe ich. Und ich bin der Ansicht, ein grottenschlechter Autor zu sein, der selten in der Lage ist, seine Aussagen auf den Punkt zu bringen und seiner Leserschaft zu vermitteln.

Bei diesem "Aussagen auf den Punkt bringen" hilft die Selbstbeschränkung ungemein. Das Problem, das zu lösen ist, ist dann nicht "Was will ich alles sagen und wie schreibe ich das?" sondern beispielsweise "Was will ich in diesem Absatz eigentlich genau sagen und wie sage ich es in höchstens fünf Sätzen mit jeweils höchstens zwei Kommata?" Das hangelt sich nach oben durch ("Was will ich in diesem Abschnitt genau sagen und wie sage ich es in höchstens drei Absätzen?") bis hinauf zum Gesamtdokument.

Deine Ansicht bezüglich Deiner Autorenqualitäten ist übrigens falsch. Du kannst formulieren und Deine Sätze sind nicht übermäßig kompliziert. Alles weitere sind letztlich nur Tricks und Knowhow über die Dramaturgie eines Textes. Das kann man lernen. Am besten lernt man es durch konsequente Selbstbeschränkung.

Preisfrage: warum kann man eine Zeitung oder ein Buch "lesen", einen Schuhkarton mit bedruckten DIN-A4-Blättern, auf denen dasselbe steht, aber nicht?

Weil der bereits vorliegende Text nicht in geeignetem Maße nachträglich gesetzt worden ist? *g*

Weil alle Elemente irgendwie rumliegen und irgendwie mehr oder weniger zufallsgesteuert aussehen, weil die Blätter unterschiedlich ausschauen, weil sie nicht "gebunden" sind, weil man nicht weiß, wo "vorne" und "hinten" ist, weil man sich nicht darin orientieren kann usw. usf.

Gruß,

MI

servus,
T.

[Hans Thomas Vogler]

In der Regel wird eine solche Publikation - ob nun online oder print - zunächst nach den benötigten Elementen aufgelöst, ggf. wird nachgebessert. Die Elementenliste, die der Autor dann nur noch ansprechen muß, erleichtert ihm seine Arbeit. Wenn sich herausstellt, daß er mehr Elemente benötigt, als vorgesehen, wird das ausdiskutiert und entsprechend umgesetzt.

Nachtrag: es gilt natürlich die Regel: soviele Elemente wie nötig, sowenige Elemente wie möglich.

servus,
T.

[Thomas J.S.]

Hallo,

Bei professioneller Textarbeit mache ich mir zuerst Gedanken über die Elemente, die ich verwenden werde bzw. zu verwenden habe. Sie haben in der Regel Limitierungen, beispielsweise "Überschrift maximal 35 Zeichen" oder "Fließtext 300 Zeilen à 60 Anschläge". Auch Absätze haben Limitierungen wie "mindestens 8, maximal 15 Zeilen à 60 Anschläge".

Das ist genau der Ansatz bei dem ich einen Schreikrapf kriege.
All diese von dir aufgelisteten Dinge haben genau 0 (null) mit Auszeichnung zu tun. Das mag für die Layoutierung (oder für dich als Gedankenstütze)  wichtig sein, aber für die Auszeichnung als solches hat es absolute keine Relevanz wieviele buchstaben in einer Überschrift enthalten sein dürfen.
Diese Eigenschaften werden nicht mal durch ein StyleSheet (DSSL, etc.) wirklich beeinflußt, sonder wenn überhaupt, werden vom einem Programm bestimmt, der dazu aber bereits die Ausziechung verstehen muss!

Der Grund: der Text ist so ziemlich das Letzte, was ankommt. Meist steht das Basis-Layout schon vor dem Thema fest, die Anzeigenplätze sind zugewiesen, mit seiner Zugehörigkeit zu einer bestimmten Rubrik bzw. Artikelgruppe sind die grundlegenden Eigenschaften aller Elemente bereits festgelegt, bevor der Text "hineinproduziert" wird.

OK, das ist die Heragehensweise von jemanden der außschließlich im DTD-Bereich arbeitet.
Dass semantische Eigenschaften (ob eine Überschrift, Absatz etc.) festgelegt werden ist das Normale, aber wenn du erst anfagst ein Layout zu machen und dann für einen solchen in Stein gemeißelten Rahmen einen Text zurechthobelst, hast du alles was mit Sinn zu tun hat über Board geworfen.

Die formalen Beschränkungen haben ihren Grund in der optimalen Ausnutzung der Rezeptionsfähigkeit des Lesers.
Die durchgängige Elementenzuordnung und -gestaltung hilft dem Leser (Rezipienten) bei der Orientierung und erleichtert ihm die Informationsaufnahme. Aus neurophysiologischen Gründen haben alle 'Blöcke' bestimmte Maxima. Es ist kein Zufall, daß die Zeilenlängen von Tageszeitungen selten mehr als 45 Anschläge haben.

Du betonst immer wieder "professionelles Arbieten" was du hier Schilderst ist das professinolle herangehensweise von DTP-Dilettanten, die von Auszeichnung so viel verstehen wie ein Huhn von der Relativitästheorie.

Das Layout _darf_ nicht auf die Aussage, Sinn und Bedeutung des Textes Einfluss ausüben, geschweige denn deise Bestimmen.
Oder hast du mal bitte irgendwo in der ISO-Article DTD über solche Layoutbeschränkugen was gelesen?!?

Du müßtest Dir *vor* dem Schreiben überlegen, welche Elemente du verwenden willst, wie sie formatiert, definiert und dimensioniert sein sollen, um Deine Zielgruppe optimal ansprechen zu können. Diese formalen Vorgaben haben nämlich letztlich Einfluß nicht nur auf die Text-Ausgestaltung, sondern auch auf Art und Stil des Inhalts.

Man kann dies vor dem Schreiben überlegen, aber diese Dinge _dürfen nicht_ den Art und Stiel des Inhalts beeinflussen. Wenn sie das tun, sollte man mit dem Schreiben aufhören und schläunigst was aderes tun, denn dann schreib man nicht mehr sonder layoutier man.

Und Zeitungen als Maßstab für eine Auszeichung zu nehmen ist ziemlich abwägig um nicht zu sagen lächerlich, oder warum jammern immer wieder Journalisten (ich meine damit keinen Bildreporter) dass sie ihre Texte vergewaltigen müssen, weil sie nicht ins Layout passen.

Es gibt nichts, was man nicht auch kürzer sagen könnte.

Ja und was am Ende rauskommt ist Quatsch mit Soße.

Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.
...sondern das, was am Schluß reinkommt.

Ja, man sieht es an der Bildzeitung und Kohorten wohin das führt.
Wer keinen Inhalt hat, sollte einfach den Schnabel oder Feder halten, aber Inhalte für ein festzementiertes Layout zu produzieren ist alles andere als Schreiben.

Grüße
Thomas

[molily]

Hallo,

Da spricht der Programmiertheoretiker.

Hehe, nein nein, sicherlich nicht. Ich beschäftige mich nur nebenbei damit und habe auch keine Ausbildung in diese Richtung. Ich habe weder Informatik oder ähnliches studiert und ich habe es beileibe auch nicht vor. Im Übrigen haben viele hier ebenfalls einen technikfremden Hintergrund, bestes Beispiel ist wohl Stefan Münz, welcher in erster Linie »gelernter« Philosoph ist.

SGML, die "Mutter aller Auszeichnungssprachen" (besser:Auszeichnungssysteme), kommt aus der Welt der großen Redaktionssysteme und wurde dazu geschaffen, die Layout-Elemente einer Zeitung auszuzeichnen - nicht den Text! Der ist nur Füllmaterial.

Das kann ich so nicht nachvollziehen. Zugrunde liegt ein fortlaufender »plain« Text ohne herausgearbeitete Struktur, in welchem Bereiche voneinander ihrer Bedeutung nach abgegrenzt werden. Natürlich ist es nicht nur Text, aber du nennst diese Bereiche, wie sie sich auch teilweise in HTML wiederfinden:

Die "Elemente", um die es da geht, sind z.B. Überschrift, Untertitel, Abstract, Fließtext, Seitenheader, Bildkasten, Bildunterschrift, Zwischentitel usw. usf.

Die Tags sagen etwas über den Inhalt zwischen selbigen aus, insofern denke ich schon, dass die Tags den Textinhalt näher beschreiben, beispielsweise sagt »<Überschrift>Bla</Überschrift>« im Gegensatz zu »Bla« ohne Markup aus, dass der Text »Bla« eine bestimmte Bedeutung hat. Alle von dir genannten Beispiele sind im Grunde textstrukturierende Marken, denn das Layout, also die »physische« Darstellung, wird nur indirekt daraus berechnet, es ist also durchaus »logisches« Markup (welches eben den *Text* darin näher beschreibt/bestimmt).

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

Das denke ich anders. Das Dokumentmodell ist zwar vergleichsweise starr, sodass nur noch »einsortiert« werden muss (andere Metapher: man schraubt die Texte wie Glübirnen in die Fassungen an einer Lichterkette), dadurch schwindet aber keinesfalls der Charakter der Textauszeichnung (wenn es in eine menschenlesbare Sprache wie SGML/XML linearisiert wird, bei einem Satz an Formularen, in welche Text eingetragen wird, kann natürlich nicht von Auszeichnung im Sinne von metasprachlichen Markierungen gesprochen werden). Wenn man einen Begriff im Flißetext hervorhebt, folgt man nämlich keinem Schema oder Modell, und eine Liste oder Tabelle tritt auch nicht zwangsläufig auf, dafür existieren keine in jedem Dokument zwangsweise vorhandenen vordefinierten »Fassungen«

Die Zeit Online arbeitet beispielsweise mit XML-Speicherung aller Artikel und transformiert »live« per XSL - würdest du bei diesen an den Drucksatz angelehnten Datenstrukturen nicht von Textauszeichnung sprechen? Wo ist der fundamentale Unterschied zur (vornehmlich) Text-Auszeichnungssprache (X)HTML?

Der Elementinhalt ist immer Text.

Unwidersprochen. Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

Dem kann ich nicht zustimmen bzw. kann deinen Gedankengang nicht nachvollziehen, zumindest für (X)HTML und die mir bekannten SGML/XML-Sprachen nicht.

Grüße,
Mathias

[Hans Thomas Vogler]

Hallo,

Moin moin,

Da spricht der Programmiertheoretiker.

Hehe, nein nein, sicherlich nicht. Ich beschäftige mich nur nebenbei damit und habe auch keine Ausbildung in diese Richtung. Ich habe weder Informatik oder ähnliches studiert und ich habe es beileibe auch nicht vor.

Ich meinte auch weniger Deine Ausbildung als Deine Herangehensweise, die programmtheoretisch geprägt ist und nicht redaktionell.

Im Übrigen haben viele hier ebenfalls einen technikfremden Hintergrund, bestes Beispiel ist wohl Stefan Münz, welcher in erster Linie »gelernter« Philosoph ist.

Was? Können die mit Computern umgehen? Können Kommunikationswissenschaftler das wömöglich auch?

SGML, die "Mutter aller Auszeichnungssprachen" (besser:Auszeichnungssysteme), kommt aus der Welt der großen Redaktionssysteme und wurde dazu geschaffen, die Layout-Elemente einer Zeitung auszuzeichnen - nicht den Text! Der ist nur Füllmaterial.

Das kann ich so nicht nachvollziehen.

Frage: Warum gibt es CSS in ausgelagerten Dateien, auf die mehrere HTML-Dokumente mit ähnlicher oder gleicher Auszeichnungsstruktur zugreifen können?

Die "Elemente", um die es da geht, sind z.B. Überschrift, Untertitel, Abstract, Fließtext, Seitenheader, Bildkasten, Bildunterschrift, Zwischentitel usw. usf.

Die Tags sagen etwas über den Inhalt zwischen selbigen aus,

Eben nicht! Es ist wurscht, ob da "Kohlsuppe" drinsteht oder "Atombombe". Die Zuordnung weist dem enthaltenen Text die Bedeutung des Elements zu, sagt aber natürlich überhaupt nichts über den Inhalt aus!

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

Das denke ich anders. Das Dokumentmodell ist zwar vergleichsweise starr, sodass nur noch »einsortiert« werden muss (andere Metapher: man schraubt die Texte wie Glübirnen in die Fassungen an einer Lichterkette),

Schöner Vergleich. Genauso ist es nämlich. Und die Fassung sagt auch nichts über die Glühbirne aus, sondern stellt nur Anforderungen an das passende Gewinde.

dadurch schwindet aber keinesfalls der Charakter der Textauszeichnung

Ein Charakter, der nie da war, kann auch nicht "schwinden"

Wenn man einen Begriff im Flißetext hervorhebt,

Warum, glaubst Du, gibt es in (X)HTML solche eigenen Elemente zur "Textauszeichnung", wenn doch (X)HTML angeblich eine einzige "Textauszeichnungssprache" ist (s.u.)?

folgt man nämlich keinem Schema oder Modell, und eine Liste oder Tabelle tritt auch nicht zwangsläufig auf, dafür existieren keine in jedem Dokument zwangsweise vorhandenen vordefinierten »Fassungen«

Natürlich nicht. Der ganze Sinn ist aber, daß Du Dir eben die passenden "Fassungen" einmal schreibst und sie dann bei Bedarf wiederverwendest. Spart Zeit, Arbeit und überflüssiges Nachdenken, schafft dabei strukturelle Übersicht und damit leichtere Rezipierbarkeit durch den Leser.

Die Zeit Online arbeitet beispielsweise mit XML-Speicherung aller Artikel und transformiert »live« per XSL - würdest du bei diesen an den Drucksatz angelehnten Datenstrukturen nicht von Textauszeichnung sprechen?

Nein. XSL macht mit XML da dasselbe, was CSS mit HTML macht: es weist den strukturellen und 'gesichtslosen' Elementen formale Eigenschaften zu.

Wo ist der fundamentale Unterschied zur (vornehmlich) Text-Auszeichnungssprache (X)HTML?

(X)HTML ist keine "Textauszeichnungssprache"! Das ist ein Übersetzungsfehler! Es ist eine "Auszeichnungssprache". Insofern existiert auch kein "fundamentaler Unterschied".

Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

Dem kann ich nicht zustimmen bzw. kann deinen Gedankengang nicht nachvollziehen, zumindest für (X)HTML und die mir bekannten SGML/XML-Sprachen nicht.

[code on]
<html>
<head>
<meta name="Author" content="JavaScript">
<style type="text/css">
h1 {richtig groß und fett}
h2 {groß, kursiv und fett}
h3 {mittel, kursiv und fett}
p  {klein, Blocksatz 200 Pixel}
#abstract {fett}
</style>
<script type="text/javascript">
Artikel = new Array()
Artikel[0] = new Array(4)
Artikel[0][0] = document.createTextNode('Kohlsuppe')
Artikel[0][1] = document.createTextNode('macht aggressiv')
Artikel[0][2] = document.createTextnode('Hier steht ein Vortext')
Artikel[0][3] = new Array(8)
for (i=0;i<Artikel[0][3].length;i++)
    {
     Artikel[0][3][i] = new Array(2)
     if (i != 0) Artikel[0][3][i][0] = document.createTextNode('Das isser Zwüschendiddel')
     Artikel[0][3][i][1] = new Array(3)
     for (j=0;j<Artikel[0][3][i][1].length;j++)
          Artikel[0][3][i][1][j] = document.createTextNode('Und das hier ist der '+(j+1)'te Absatz im '+(i+1)+'ten Textabschnitt des Artikels "'+Artikel[0][0].data+'".')
     }
function Anzeige (n)
 {
  with (document.getElementsByTagName('body')[0])
       {
         getElementsByTagName('h1')[0].appendChild(Artikel[0][0].data)
         getElementsByTagName('h2')[1].appendChild(Artikel[0][1].data)
         getElementById('abstract').appendChild(Artikel[0][2].data)
         for (i=0;i<Artikel[0][3].length;i++)
             {
              TMP = appendChild(document.createElement('h3'))
              TMP.appendChild(Artikel[0][3][i][0].data)
              for (j=0;j<Artikel[0][3][i][1].length;j++)
                  {
                   TMP = appendChild(document.createElement('p'))
                   TMP.appendChild(Artikel[0][3][i][1][j].data)
                  }
             }
       }
 }

onload = Anzeige
</script>
</head>
<body>
<h1></h1>
<h2></h2>
<p class="Abstract"></p>
</body>
</html>
[code off]

Ähem. Nur mal so geschrieben. Ausführbarkeit ohne Gewehr...

Vielleicht kann ich´s so erklären... Wo siehst Du im Beispiel eines Artikelgenerators eine "Textauszeichnung"? Nirgends! Der Generator tut dabei nichts anderes als das, was normalerweise Du als Autor machst bzw. machen solltest, nämlich einen Bezug von Inhalt und Dokumentenschablone herstellen.

Etwas anderes wäre es, wenn der Artikelgenerator beispielsweise noch ein "strong"-Element in die Absätze einflechten würde. Nur die Elemente zur logischen und physikalischen Textauszeichnung haben nämlich ausschließlich diesen Zweck, alle anderen sind strukturelle Elemente des Dokuments, die lediglich ihre formalen Eigenschaften an den zugewiesenen Inhalt vererben. Es sind aber in erster Linie Struktur-Elemente und keine "Textauszeichnungs"-Elemente.

Die Tatsache, daß (X)HTML eigene Elemente zur "Textauszeichnung" braucht, um lediglich formale Eigenschaften zuzuweisen, und daß diese Elemente extra in den Baum eingehängt werden und dazu aus dem Fließtext herausgenommen werden müssen, weist darauf hin, daß (X)HTML eben *keine* "Textauszeichnungssprache" ist, sondern eine allgemeine Auszeichnungssprache zur strukturellen Gestaltung eines Dokuments. Einem Robot beispielsweise ist es wurscht, wie ein Element aussieht, er will nur die strukturelle Zuordnung interpretieren können. "Text" versteht er eh nicht...

Daß man den Elementen überhaupt formale Eigenschaften zuweisen kann, ist gewissermaßen lediglich ein Zugeständnis an die "Menschenlesbarkeit" des Dokuments.

Habe ich Dir "meinen Gedankengang" - der letztlich auch der der HTML-Entwickler war und ist (siehe: Semantic Web) damit einigermaßen nachvollziehbar darlegen können?

servus,
T.

Grüße,
Mathias

[Michael Jendryschik]

XSL macht mit XML da dasselbe, was CSS mit HTML macht: es weist den strukturellen und 'gesichtslosen' Elementen formale Eigenschaften zu.

Nun, eigentlich transformiert XSLT einen Ausgangsbaum in einen Ergebnisbaum, mehr nicht. Ich sehe überhaupt keine Ähnlichkeiten zu CSS und sehe auch nicht, inwiefern XSLT XML-Elementen irgendwelche Eigenschaften zuweist.

MI

[Hans Thomas Vogler]

XSL macht mit XML da dasselbe, was CSS mit HTML macht: es weist den strukturellen und 'gesichtslosen' Elementen formale Eigenschaften zu.

Nun, eigentlich transformiert XSLT einen Ausgangsbaum in einen Ergebnisbaum, mehr nicht. Ich sehe überhaupt keine Ähnlichkeiten zu CSS und sehe auch nicht, inwiefern XSLT XML-Elementen irgendwelche Eigenschaften zuweist.

????

Hab ich da jetzt XSL mit XSLT verwexelt oder Mathias oder Du? Ich kenne die Zeditungsseiten nicht, nehme aber an, daß Du richtig liegst. Wahrscheinlich wird da XML nach HTML transformiert.

Dann hat das aber gleich überhaupt nichts mit "Textauszeichnung" zu tun. Fragt sich jetzt, was Mathias da gemeint hat.

MI

servus,
T.

[Michael Jendryschik]

Nun, eigentlich transformiert XSLT einen Ausgangsbaum in einen Ergebnisbaum, mehr nicht. Ich sehe überhaupt keine Ähnlichkeiten zu CSS und sehe auch nicht, inwiefern XSLT XML-Elementen irgendwelche Eigenschaften zuweist.

????

Hab ich da jetzt XSL mit XSLT verwexelt oder Mathias oder Du?

XSL besteht aus drei Komponenten:

* aus einer Sprache, mit der auf die Struktur des XML-Dokuments zugegriffen werden kann (XPath)
* aus einem Transformationsteil (XSLT)
* aus einem Ziel-Vokabular, das das Layout beschreibt (XSL-FO)

Mathias sprach von einer Anwendung von XSLT, die eine XML-Eingabe in eine (X)HTML-Ausgabe transformiert. Was genau er damit sagen wollte, habe ich mal wieder nicht verstanden. ;-)

Gruß,

MI

[Herbalizer]

Hi!

(X)HTML ist keine "Textauszeichnungssprache"! Das ist ein Übersetzungsfehler! Es ist eine "Auszeichnungssprache". Insofern existiert auch kein "fundamentaler Unterschied".

Genau genommen ist es eine _Hypertext_ Auszeichnungssprache! Und zwar ist die Betonung nicht auf Text zu legen, handelt es sich bei diesem Begriff gewissermassen um die Essenz des Konzepts netzartig verknüpfter Informationenen und den nichtsequenziellen Zugriff auf selbige. Und diese verknüpften Informationen sind eben nicht nur Text, sondern auch multimediale Inhalte, so das der Begriff Hypermedia vielleicht etwas treffender wäre.

Ansonsten ist der redaktionelle Ansatz den du in Bezug auf (X)HTML herausgearbeitet hast eine sehr interessante Ansichtsweise, welche allerdings auf andere Auszeichnungsprachen absolut nicht anwendbar ist. Denn in SVG ist zB. das rect-Element bereits die zu vermittelnde Information, und nicht nur ein mit Information zu füllender Container, ähnliches gilt zB. für MathML oder SMIL.

Gruß Herbalizer

[Hans Thomas Vogler]

Hi!

High!

Genau genommen ist es eine _Hypertext_ Auszeichnungssprache!

Besser: eine Auszeichnungssprache speziell für die Belange des Mediums "Hypertext", die über die des Printmediums einerseits hinausgehen, andererseits gegenüber den Auszeichnungssprachen für Print-Medien aber auch "abgespeckt" ist. Man denke nur an den Spaltensatz, den man anfangs auch übernehmen wollte, wovon man aber wieder völlig abgekommen ist.

Und diese verknüpften Informationen sind eben nicht nur Text, sondern auch multimediale Inhalte, so das der Begriff Hypermedia vielleicht etwas treffender wäre.

Eben. Die Konzeption von Hypertext stammt ja auch aus einer Zeit, als es tatsächlich um "Text" und fast nur darum ging, z.B. zu didaktischen Zwecken. Mit dem Sprung auf den Computer, dessen Sprung hin zu grafischen Benutzeroberflächen und erst recht die Entwicklung im Web haben die Wandlung hin zu "Hypermedia" längst Realität werden lassen.

Ansonsten ist der redaktionelle Ansatz den du in Bezug auf (X)HTML herausgearbeitet hast eine sehr interessante Ansichtsweise, welche allerdings auf andere Auszeichnungsprachen absolut nicht anwendbar ist. Denn in SVG ist zB. das rect-Element bereits die zu vermittelnde Information, und nicht nur ein mit Information zu füllender Container, ähnliches gilt zB. für MathML oder SMIL.

Von den genannten ist streng genommen nur MathML wirklich eine spezielle Auszeichnungssprache für mathematische Elemente, wo übrigens die Bildschirmdarstellung auch nur ein Nebeneffekt ist. Robots vor allem sollen solche mathematischen Formelbeschreibungen plattformübergreifend korrekt interpretieren können. "Schreiben" kann man das meiste auch in HTML nebst spezieller Entities, womit eine Maschine aber überhaupt nichts anfangen könnte.

SVG ist ein Ansatz, mit Hilfe von XML (das ja mehr kann, als nur "Auszeichnungssprachen" zu definieren) eine Art internationales und frei verfügbares PostScript zu deklarieren, das Brauser entsprechend verwerten und umsetzen können, SMIL wiederum ist der Versuch, eine dramaturgische Ordnung in die kreuz- und quer vernetzbaren XML-definierten Dateninseln zu bringen.

Gruß Herbalizer

servus,
T.

[Thomas J.S.]

Hallo,

Eben. Die Konzeption von Hypertext stammt ja auch aus einer Zeit, als es tatsächlich um "Text" und fast nur darum ging, z.B. zu didaktischen Zwecken. Mit dem Sprung auf den Computer, dessen Sprung hin zu grafischen Benutzeroberflächen und erst recht die Entwicklung im Web haben die Wandlung hin zu "Hypermedia" längst Realität werden lassen.

Ich meine es wirklich nicht böse, aber du hast wirklich was total falsches gelernt.

Mich wundert schon, dass ich noch so "alte" Dinge erklären muss:
Dr. Vannevar Bush veröffentlichte im Juli 1945 einen Artikel in der Zeitschrift The Atlantic Monthly mit dem Titel As We May Think. In diesem Artikel, der heute allgemein anerkannt den Beginn der Entwicklung darstellt, die letztlich zur HTML führte, stellte Vannevar Bush die Idee für eine Maschine mit dem Namen Memex vor, die in der Lage ist sowohl grafische wie textuelle Informationen zu speichern und darüber hinaus sollte man mit ihrer Hilfe jede Informationseinheit mit jeder anderen Informationseinheit im System beliebig zu verknüpfen können.

Die Idee von Memex beruht teils auf die Indexierung und Relationierung von Dokumenten teils auf Mikroverfilmung, Bush stellte sich eine Kamera vor, die - an der Stirn befestigt - alles, was das Interesse des Benutzers erweckte, sofort aufnehmen und im Memex zur Verfügung stellen sollte.

Dan kamen Xanadu, Docuverse, Agument etc.

Also nur um Text gig es schon von Anfang an nicht, setze bitte Hypertext nicht mit HTML gleich.

Von den genannten ist streng genommen nur MathML wirklich eine spezielle Auszeichnungssprache für mathematische Elemente, wo übrigens die Bildschirmdarstellung auch nur ein Nebeneffekt ist.

Man hätte hier noch etwa zwei dutzend andere Spachen nennen können, die alle für einen speziellen Zweck entwickelt worden sind, angefangen mit MML, CML, RDF, RSS, HML etc. etc. etc. bei al diesen ist die Bildschirmdarstellung ein "Nebeneffect".

SMIL wiederum ist der Versuch, eine dramaturgische Ordnung in die kreuz- und quer vernetzbaren XML-definierten Dateninseln zu bringen.

Wo hast du diesen Witz her?

Grüße
Thomas

[molily]

Hallo Hans,

ich glaube, wir werden keine Annäherung erzielen können. Ich verstehe deine Auffassung wirklich nicht und kann die Gedankengänge auch nach mehrmaligen Lesen nicht nachvollziehen. Vielleicht ist es mein Problem, oder wir benutzen »Element«, »(Element-)Inhalt« usw. mit anderen Bedeutungen, oder selbst wenn ich Mehrdeutigkeit annehme, komme ich zu keinem Verständnis.

... Wo siehst Du im Beispiel eines Artikelgenerators eine "Textauszeichnung"? Nirgends!

Ich sagte: »wenn es in eine menschenlesbare Sprache wie SGML/XML linearisiert wird«. Wenn also die hierarchische Objekt-/Knotenstruktur in Markup überführt wird, ist es verschachtelt ausgezeichneter Text. Ich sehe ja ein, dass du es anders siehst, aber wir sind offensichtlich bereits über die Grundlagen entgegengesetzter Meinung und in diesem Punkt ist mir auch nicht ersichtlich, wie meinen Standpunkt hinterfragen kann. Für mich ist die Erkenntnis, dass Tags in HTML in erster Linie bzw. letztlich Text auszeichnen, indem sie dessen strukturelle Bedeutung beschreiben, trivial und selbstverständlich. Das ist für mich insofern indiskutabel, obwohl ich wie gesagt einsehe, dass ein Element in HTML jeder beliebige Datentyp sein kann, aber wieso das nur eingeschränkt gilt, sagte ich schon. Natürlich gibt es XML/SGML-Anwendungen, bei welchen letztlich von »Markup« als geschriebene Metasprache nichts zu spüren ist, aber wenn ich ein simples Hypertextdokument schreibe, ist m.M.n. dieser Begriff sehr passend.

Alles, was ich noch sagen könnte, wäre eine Wiederholung des bereits Gesagten.

Grüße,
Mathias

[Thomas J.S.]

Hallo,

SGML, die "Mutter aller Auszeichnungssprachen" (besser:Auszeichnungssysteme), kommt aus der Welt der großen Redaktionssysteme und wurde dazu geschaffen, die Layout-Elemente einer Zeitung auszuzeichnen - nicht den Text!

Sorry, aber ich habe das Gefühl, du hast was falsches (ich meine damit die Fakten) gelernt.
SGML kommt nicht aus dem Bereich der großen Redaktionssysteme (welche wären denn diese übrigens?).

Darauf woher der Begriff "Murkup" stammt, muss ich nicht eigehen, erst entstand die "specific coding" dann auch ein Bedürfnis nach einer allgemeinen, einheitlichen Notierungsweise, nach "generic coding".
Die Idee hinter "generic" oder "generalized markup" war, dass für die Bezeichnung der Formate beschreibende Namen verwendet werden sollten z.B. heading statt Vorlage27 für eine Überschrift.

Die erste Bestrebungen in diese Richtung unternahm William Tunnicliffe als Vorsitzende des Graphic Communications Association (GCA) Composition Committee, als er in 1967 in einem Vortrag für eine Trennung des (informationellen) Inhalts eines Dokuments von seiner äußeren  Format plädierte.

Dann kam der New Yorker Buchdesigner Stanley Rice mit seinem Satz von sogenannten "editorial structure" tags (ebenfalls noch in den 60-er). Der damalige Direktor der GCA (Norman Scharpf) nahm seine Idee auf und führte das "generic encoding" Projekt in das Composition Committee ein. Dieses Komitee entwickelte dann das GenCode concept, und wurde dann im Laufe der Entwicklung selbst zum "GenCode Committee".

In 1969 arbeiteten Charles Goldfarb, Edward Mosher und Raymond Lorie bei IBM an einem Projekt mit dem Namen "integrated law office information systems". Goldfarb gab dann 1971 dem System den Namen GML, Generalized Markup Language.

1978 gründete das American National Standards Institute (ANSI) ein Komitee mit dem Ziel einen Standard für eine GML basierende Textbeschreibungssprache zu entwickeln. Die Arbeit des Komitee wurde vom GenCode-Komitee unterstützt. Goldfarb wurde zu Mitarbeit eingeladen und leitete teilweise die Arbeit des neuen Komitees.
Den ersten Normenentwurf des SGML-Standards präsentierte das Komitee 1980.

Als kleiner Witzt wird deshalb in "SGML-Kreisen" SGML auch als  "Standard Goldfarb Mosher Lorie" genannt (eben nach dem drei ursprünglichen Entwickler)

Die eigentliche Auftrag für die Entwicklung von GML bzw. SGML kam übrigens von der US Airforce, die eine standardisierte Form für die Beschreibung von Flugzuegteilen etc. gebraucht hat.

Der ist nur Füllmaterial. Die "Elemente", um die es da geht, sind z.B. Überschrift, Untertitel, Abstract, Fließtext, Seitenheader, Bildkasten, Bildunterschrift, Zwischentitel usw. usf.

Ah ja ... und wozu brauchst du denn diese Elemente, wenn du keinen Text hast?
Du zeichnest den Text eben aus, in dem du ihn in einem Element z.B. namens "heading" stellst. _Das_ ist die eigentliche Auszeichnung.

Text als solcher muß nämlich nicht "ausgezeichnet" werden, sondern er wird als "Inhalt" o.a. Elementen "zugewiesen" - oder auch nicht.

Das ist Quatsch mit Soße.
Text _muss_ eben ausgezeichnet werden um ihn überhaupt strukturiert erfassen und später darstellen zu können. Du läßt dich vollkommen von HTML leiten, was zwar eine Anwendung von SGML ist, aber eben für einen sehr speziellen Zweck geschaffen.

HTML als Abkömmling von SGML ist das alles noch anzumerken, XHTML genauso.

HTML sicher nicht, XHTML schon etwas eher.

Der Elementinhalt ist immer Text.

Unwidersprochen. Der "Inhalt" ist aber eben nicht das auszuzeichnende Element.

Der Inhalt _ist_ der auszuzeichnende Teil eines jeden Dokuments!

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas (1),

Ich will ja nicht den Oberlehrer spielen, aber eine
"Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein
eine "Auszeichnungssprache" (..)

Naja. Im Prinzip [tm] hast Du sicherlich recht, aber ich sehe da immer
noch ein recht starkes HyperTEXT in (X)HTML.

Aber ich studiere ja auch nicht Informatik und bekomme gute Noten für
besonders penible Anwendung der Terminologie...

Ich tue es, sehe aber nirgens wirklich die Terminologie, die hier
verwendet wird. Kommt schon. Nur weil wir Computer benutzen, heißt
das nicht, daß man uns nicht "alles was mit Computer zu tun hat" (2)
ins Boot schieben.

(1) Ich vermute Thomas ist Dein Rufname, da Du mit 'T.' unterzeichnest?
(2) "Mein Enkel macht was mit Computern." ;o)

• Tim

[molily]

Hallo,

Ich will ja nicht den Oberlehrer spielen, aber eine
"Textauszeichnungssprache" ist (X)HTML auch nicht, sondern ganz allgemein
eine "Auszeichnungssprache" (..)

Naja. Im Prinzip [tm] hast Du sicherlich recht, aber ich sehe da immer noch ein recht starkes HyperTEXT in (X)HTML.

Eine Hypertextdatei kann andere Medientypen kategorisieren und eine Metastruktur bilden. Der Elementbaum bildet das Gerüst, in welches die Objekte eingehängt werden und dadurch in ihrer Bedeutung determiniert werden. Dazu ist im Grunde kein einziger Textfetzen nötig, weil die Beziehungen für sich sprächen. Das wäre ein Hypertextdokument ohne Text.

(1) Ich vermute Thomas ist Dein Rufname, da Du mit 'T.' unterzeichnest?

</archiv/2003/6/49681/#m271663>

M.

[Tim Tepaße]

Hallo Torsten,

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile
hat es, welche Browser können es, welche evtl. nicht.

Ich betreibe es als Sport.

• Tim

[Susanne Jäger]

Hallo,

Ich mag mich persönlich noch nicht an die Schreibweise der leeren tags <br /> gewöhnen. Also werde ich wohl noch eine Weile bei HTML4.01 strict bleiben und optionale End-Tags setze ich sowieso, weil ich das übersichtlicher finde. Sobald es möglich sein wird vollwertige XML-Dateien zu produzieren und auszuliefern (Prolog und mime-Type) lassen sich solche Dokumente mit tidy oder suchen und ersetzen problemlos nach XHTML konvertieren.

Die wichtigere Entscheidung ist IMHO Strict oder Transitional und da ist die Wahl ganz klar. Der Schwerpunkt liegt auf der Trennung von Inhalt und Präsentation  also für neue Seiten wenns irgendwie geht strict.

Gruß Susanne

[Utz]

Hallo Torsten,

meine persönliche Meinung:

Wenn Du Dir aus irgend einem Grund (es sind einige denkbar) einen Vorteil daraus ziehst, dass XHTML eben auch XML und mit XML-Parsern behandelt werden kann, solltest Du zu XHTML greifen.

Wenn nicht, ist es schnuppe.

Wenn Du nicht weißt, ob Du diesen Vorteil mal haben wirst oder nicht, gilt folgende Regel:

• Nimmst Du HTML, brauchst Du es doch irgendwann als XML.
• Nimmst Du XHTML, brauchst Du es nie als XML.

Grüße,

Utz

[Herbalizer]

Hi!

Ist zwar nicht gerade ein direkter Vorteil, aber das Benutzen entsprechender XHTML-Profile erleichtert es ungemein, identisch strukturierte Dokumente sowohl für den normalen Desktopbrowser als auch für WML2-fähige Mobilbrowser zu verfassen. Denn WML2 http://www1.wapforum.org/tech/terms.asp?doc=WAP-238-WML-20010911-a.pdf baut praktischerweise auf dem XHTML Mobile Profile http://www1.wapforum.org/tech/terms.asp?doc=WAP-277-XHTMLMP-20011029-a.pdf auf welches widerum auf XHTML Basic http://www.w3.org/TR/xhtml-basic/ basiert und nur um einige (partiele) XHTML-Module erweitert wurde. Insbesondere die Benutzung des style-Elements und des style-Attributes machen XHTML Mobile Profile fast perfekt als generelle XHTML-Sprache, so man denn auf Scripting verzichten kann und das basic-forms-Modul ausreichend ist.
Und WML2-fähige Browser müssen auch die angesprochenen XHTML Profile schlucken.

Gruß Herbalizer

[Michael Jendryschik]

Hallo,

[HTML <> XHTML]

Mir ist allerdings noch nicht so ganz klar, worin der Vorteil eines Umstiegs liegt. Auch der Artikel auf der HP von Michael Jendryschik hat mich noch nicht überzeugen können.

Welcher Artikel?

Was meint ihr also, worin liegen die Vorteile von XHTML

Der größte Vorteil gegenüber HTML ist die konsequente Syntax. Ich bemerke häufig in Schulungen, dass es Anfängern oftmals nicht einleuchtet, weshalb es Element gibt, die aus einem Start- und einem End-Tag bestehen müssen, Elemente, deren schließendes Tag optional ist, sowie Element, die nicht geschlossen werden dürfen. Auch die konsequente Kleinschreibung benannter Element- und Attributnamen sowie Attributwerte spart Arbeit und Zeit. Ihr glaubt gar nicht, wie oft Quereinsteiger der Ansicht sind, alle Tags müssten groß geschrieben werden.

Wer HTML bereits wie XHTML geschrieben hat, profitiert natürlich nicht von der "neuen" Syntax.
Ich gestehe allerdings gern, dass es mir persönlich mittlerweile direkt unangenehm ist, '<br>' oder '<img ...>' zu schreiben. Darüber hinaus gibt es in XHTML das Konzept der Wohlgeformtheit, und das ist so ein schönes Wort, dass ich darauf nicht mehr verzichten möchte. ;-)

Ein weiterer Vorteil ist zur Zeit vielleicht eher noch Zukunftsmusik: Im Gegensatz zu HTML ist XHTML ohne eine offizielle Neudefinition des gesamten Sprachumfanges erweiterbar, so können beispielsweise vordefinierte Erweiterungen wie MathML, SVG, Ruby oder auch eigene Elemente eingebunden werden.

welche  Nachteile hat es,

Wenn XHTML-Dokument als 'text/html' ausgeliefert werden, gibt es potentielle Fehlerquellen, die auch durch die Einhaltung der HTML-Kompatibilitätsrichtlinien nicht vollständig beseitigt werden können. Weitere Nachteile kannst du auf http://hixie.ch/advocacy/xhtml nachlesen.
Wenn XHTML als 'application/xhtml+xml' ausgeliefert wird, ist das theoretisch besser, praktisch aber fatal, da kaum ein Browser in der Lage ist, Dokument dieses Medientyps korrekt anzuzeigen, schon gar nicht der IE.
Die Lösung ist eine parallele Bereitstellung der Information. Es ist heute bereits mit wenig Aufwand möglich, allen Clients eine Version zu liefern, mit der sie gut umgehen können, siehe http://schneegans.de/tips/apache-xhtml/. Ich persönlich verwende auf http://jendryschik.de eine PHP-Lösung, die den HTTP_ACCEPT des Browsers ausliest und dann den entsprechenden MIME-Type ausliefert. Dann gibt es zumindest keine Argumente gegen die Verwendung von XHTML mehr, ob es welche dafür gibt, musst du für dich entscheiden.

Ich persönlich schreibe HTML nur noch dann, wenn ich die Projektumgebung nicht kontrollieren kann, also z.B. keinen Einfluss auf Server-Einstellungen habe, oder wenn noch weitere Menschen an dem Projekt beteiligt sind und ich nicht sicher sein kann, dass diese XHTML beherrschen geschweige denn überhaupt korrektes HTML produzieren können.

Gruß,

MI

[Siechfred]

Hallöle,

Welcher Artikel?

Der hier: http://jendryschik.de/wsdev/einfuehrung/xhtml/index.html

Viele Grüße
Torsten

[Michael Jendryschik]

Hallo,

Welcher Artikel?

Der hier: http://jendryschik.de/wsdev/einfuehrung/xhtml/index.html

Mag sein, dass ich mich nicht mehr an meine eigene Einführung erinnere, aber ich glaube nicht, dass in irgendwo die Verwendung von XHTML diskutiere oder empfehle oder die Vor- bzw. Nachteile von XHTML gegenüber HTML ausführe und werte. Ich versuche lediglich, XHTML näher zu bringen und die Verwendung der einzelnen Elemente und Attribute zu erläutern. Mehr nicht.

Gruß,

MI

[Siechfred]

Hallo Michael,

Nana, wer wird denn gleich ...

Der hier: http://jendryschik.de/wsdev/einfuehrung/xhtml/index.html
Mag sein , dass ich mich nicht mehr an meine eigene Einführung erinnere ...

Um das jetzt mal klar zu stellen. Ich habe vorgestern nacht den kompletten Artikel gelesen und er hat mir sehr geholfen zu verstehen, was XHTML eigentlich ist. Auch den Vergleich zwischen HTML und XHTML (http://jendryschik.de/wsdev/einfuehrung/xhtml/xhtml.html) habe ich gelesen.

... aber ich glaube nicht, dass in irgendwo die Verwendung von XHTML diskutiere oder empfehle oder die Vor- bzw. Nachteile von XHTML gegenüber HTML ausführe und werte.

Glaube mir, dass ich intelligent genug bin, deine Ausführungen zu lesen, zumindest ansatzweise zu verstehen und mir daraus selber eine Meinung zu bilden. _Dabei_ hat mir dein Artikel geholfen.

Mehr nicht.

Nicht mehr und nicht weniger.

Viele Grüße
Torsten

[Michael Jendryschik]

Um das jetzt mal klar zu stellen. Ich habe vorgestern nacht den kompletten Artikel gelesen und er hat mir sehr geholfen zu verstehen, was XHTML eigentlich ist.

Das freut mich. :-)

Glaube mir, dass ich intelligent genug bin, deine Ausführungen zu lesen, zumindest ansatzweise zu verstehen und mir daraus selber eine Meinung zu bilden. _Dabei_ hat mir dein Artikel geholfen.

Dein Posting klang so, als ob ich irgendwo versucht hätte, die Leser meiner Einführung davon zu überzeugen, von HTML zu XHTML umzusteigen. Das liegt mir fern, daher habe ich mich gewundert und lediglich nachgefragt, was genau du eigentlich meinst.

Nicht mehr und nicht weniger.

Sag ich doch.

Gruß,

MI

[emu]

Hallo!

Ich verwende nach Möglichkeit HTML 2.

emu

[Andres Freund]

N'Abend Drachentöter,

Was meint ihr also, worin liegen die Vorteile von XHTML welche  Nachteile hat es, welche Browser können es, welche evtl. nicht.

Ich finde, im Gegensatz zu einem großen Teil des Forums, dass xhtml, von der mangelnden Unterstützung abgesehen, viele Vorteile hat.
So finde ich, dass die maschinelle generierung, etwa aus xml in Templates, von xhtml durch die logischere Auszeichnung wesentlich einfacher ist. Mit logischer Auszeichnung meine ich, dass zum Beispiel alle Elemente irgendwo geschlossen werden müssen etc.

Ein anderer Vorteil, der meiner Meinung nach wesentlich wichtiger ist, dass xhtml, besonders bei Neueinsteigern, dazu führt, wenn richtig beigebracht, gut strukturierten quelltext zu schreiben. Sicherlich ist es auch in HTML 4.01 möglich seinen Quelltext einigermaßen sinnvoll zu strukturieren, aber lange nicht so zwingend.
Warum ich sinnvolle Auszeichnung mittlerweile sinnvoll finde, möchte ich jetzt, mangels Zeit und eigener genauer Beweggründe, nicht einfach so darlegen, da müsste ich noch eher darüber nachdenken.

Grüße Andres Freund

[Hans Thomas Vogler]

Hallo allerseits,

Hallöchen auch,

ich habe sowohl mit XHTML als auch mit XML experimentiert. In fernerer Zukunft wird XHTML wohl allmählich HTML verdrängen werden im Zuge der Weiterentwicklung mit anderen XML-kompatiblen Sprachmodulen wie SVG, WML, SMIL usw.

Im Augenblick ist es mir zu umständlich, mit XHTML zu arbeiten, weil der XML-Parser erst dann etwas anzeigt, wenn der HTML-Code wirklich "wohlgeformt" ist. Ein schrittweises "zum Ergebnis hangeln" wie es in HTML mit dem HTML-Parser funktioniert, der einfach alles schluckt und es irgendwie anzuzeigen versucht, ist so nicht möglich.

Natürlich könnte man eine Seite zunächst als "HTML" deklarieren und dann den Schlußschliff als "XHTML" besorgen.

Ich habe aber einen Einwand gegen XHTML bzgl. der geplanten Version XHTML 1.1, die keine drei Varianten mehr kennt, sondern nur noch eine der heute gültigen Variante "strict" entsprechende. Damit fallen die Frames aus dem Konzept, und die benutze ich als sehr praktisches Instrument, welches derzeit auch durch kein anderes Element ersetzt werden kann. Interessant ist XHTML für mich daher nur, wenn XHTML 1.1 mir eine Alternative zum Nachladen externer HTML-, XHTML- oder XML-Daten bietet. Die mit dem Verzicht auf eine solche Möglichkeit einhergehende strikte Dokumentenorientierung halte ich für nicht durchsetzbar.

Bezüglich der "Modularisierung", also der Anpassungsfähigkeit von XHTML für individuelle Bedürfnisse, bin ich einer Meinung mit Stefan Münz:

"Inwieweit sich das Konzept der Modularisierung durchsetzen wird, bleibt abzuwarten. Denn wer sich mit dem Design eigener Auszeichnungssprachen befasst, kann schließlich auch direkt die Möglichkeiten von XML nutzen, um entsprechende Sprachen zu entwerfen. Und "einfacher" als XML ist das Konzept der Modularisierung sicher nicht - im Gegenteil: es setzt im Grunde die Beherrschung von XML voraus und reizt dessen Möglichkeiten aus"

http://selfhtml.teamone.de/html/xhtml/modularisierung.htm

Vorwerfen kann man den W3-Vordenkern, daß sie bzgl. physikalischer Textauszeichnungen inkonsequent sind: den <b>- und den <i>-tag lassen sie zu, der <u>-tag gilt hingegen als "deprecated", weil man ihn mit CSS definieren kann und soll. Selbiges gilt aber ebenso für <b> und <i>. Also, wenn schon, dann bitte alle drei "deprecaten", oder eben keinen von den dreien, weil die logischen Textauszeichnungen ohnehin diese Rolle übernehmen können.

...welche Browser können es, welche evtl. nicht.

Da würde mich auch Erfahrungen der Forumsteilnehmer interessieren.

Viele Grüße
Torsten

Liebe Grüße auch aus S.
T.

[Michael Jendryschik]

Hallo,

Ich habe aber einen Einwand gegen XHTML bzgl. der geplanten Version XHTML 1.1, die keine drei Varianten mehr kennt, sondern nur noch eine der heute gültigen Variante "strict" entsprechende.

Nun, wer mit Frames und XHTML arbeiten möchte, muss derzeit bei XHTML 1.0 bleiben.

Damit fallen die Frames aus dem Konzept, und die benutze ich als sehr praktisches Instrument, welches derzeit auch durch kein anderes Element ersetzt werden kann.

Es wird an XFrames gearbeitet, eine XML-Applikation, die HTML-Frames ersetzen soll.

Gruß,

MI

[Christian Seiler]

Hallo Michael,

Nun, wer mit Frames und XHTML arbeiten möchte, muss derzeit bei XHTML 1.0 bleiben.

Nein. Du kannst Dir auch Deine eigene XHTML 1.1 DTD zusammenstellen, die das Frames-Modul und andere Dinge enthält.

Viele Grüße,
Christian

[Hans Thomas Vogler]

Hallo Michael,

Hi chris,

Nein. Du kannst Dir auch Deine eigene XHTML 1.1 DTD zusammenstellen, die das Frames-Modul und andere Dinge enthält.

Und wie schreibt man das?

Viele Grüße,
Christian

servus,
T.

[Christian Seiler]

Hallo,

Nein. Du kannst Dir auch Deine eigene XHTML 1.1 DTD zusammenstellen, die das Frames-Modul und andere Dinge enthält.

Und wie schreibt man das?

http://www.w3.org/TR/xhtml-modularization/dtd_developing.html#s_developingdtds

Viele Grüße,
Christian

[Hans Thomas Vogler]

Hallo,

Ola,

Es wird an XFrames gearbeitet, eine XML-Applikation, die HTML-Frames ersetzen soll.

Dann iss ja jut. Ich werde dann auch keine Probleme haben, auf XHTML umzusteigen. Allerdings wäre es schön, wenn die Brauser einen bei XHTML wählen lassen würden, welche Art von Parser man einsetzen möchte:

• einen HTML-Brachialparser, der wie gewohnt alles schluckt
• einen XML-Parser mit Bäumchen-Darstellung ohne Berücksichtigung von CSS
• oder einen gnadenlosen XHTML-Parser, der nichts akzeptiert außer korrektem und mit XSL designten Code

Gruß,

MI

servus,
T.

[Tim Tepaße]

Hallo Thomas,

Vorwerfen kann man den W3-Vordenkern, daß sie bzgl. physikalischer
Textauszeichnungen inkonsequent sind: (...) <b>, <i> und <u> (...)

Keine Angst.

In XHTML 2 sind diese Elemente schon rausgeworfen geworden. Eine der
kleineren, vernachlässigbaren Stolpersteine auf dem Weg zu XHTML 2.

http://www.w3.org/TR/xhtml2/xhtml2.html#s_inline-textmodule

• Tim