Wieso <b> in XHTML Strict??

[Christian]

Hi,

ich frage mich wieso das <b>-Element in Strict erlaubt ist!

Ähnlich Style Elemente wie <u> und <i> sind ja auch nicht erlaubt. Was soll das also? Ich finde das W3C hat hier entweder geschlampt oder ich verstehe was nicht.

Kann mir das jemand erklären?
Es ist doch nun eindeutig kein Element, was die logische Struktur auszeichnet sondern nur eben fettschrift macht. Und das ist wohl Sache von CSS, imo!

Gruß
Christian

[Cyx23]

Hallo,

Es ist doch nun eindeutig kein Element, was die logische Struktur auszeichnet sondern nur eben fettschrift macht. Und das ist wohl Sache von CSS, imo!

"<i> sind ja auch nicht erlaubt"?

Aber egal, da span und div auch keine logische Struktur abbilden und
da bei der Kombination von "zeitgemäßem" HTML und CSS die
Leistungsfähigkeit des Gesamtpakets eh immer dürftiger geworden ist
sehe ich da vorerst kein Problem.

Grüsse

Cyx23

[Christian]

Hi,

"<i> sind ja auch nicht erlaubt"?

ups, sorry, aber <u> ist kein Strict!

Aber egal, da span und div auch keine logische Struktur abbilden und

naja, schon irgendwie, es werden zusammengehörige Elemente gruppiert.

da bei der Kombination von "zeitgemäßem" HTML und CSS die
Leistungsfähigkeit des Gesamtpakets eh immer dürftiger geworden ist
sehe ich da vorerst kein Problem.

Hä??? Was meinst du ?

Gruß
Christian

[Cyx23]

Hallo,

Aber egal, da span und div auch keine logische Struktur abbilden und

naja, schon irgendwie, es werden zusammengehörige Elemente gruppiert.

Erstmal nicht, bzw. die Gruppierung tritt als (womöglich auch
störendes) Layoutmerkmal und weniger als logiche Struktur auf.

da bei der Kombination von "zeitgemäßem" HTML und CSS die
Leistungsfähigkeit des Gesamtpakets eh immer dürftiger geworden ist
sehe ich da vorerst kein Problem.

Hä??? Was meinst du ?

Z.B. dass die Trennung von Layout per CSS nicht so umfassend möglich ist,
und abgesehen von grundsätzlichen Fragen wo die Grenzen zu ziehen sind
ist die Kombination von validem HTML-strict und CSS (und gebräuchlichen
Browsern) wenig leistungsfähig.
Layoutumsetzung wird u.U. schwieriger als bei nicht validem Code, und
zur Strukuturierung fehlt es HTML oder den Browsern derzeit z.B. noch
an den Elementen zur Gruppierung.

Und auch umgekehrt wirds lästig wenn "neutrale" Divs o.ä. eingesetzt
werden und anschliessend beim CSS diese zusätzlichen Container immer
in der "Cascade" zu berücksichtigen sind.

Oder Spalten bei Tabellen, da kann wohl col oder colspan keine
Hintergrundfarbe zugeordnet werden, es muss also ggf. immer noch
jedes td eine Klasse erhalten um Spalten zu gestalten, da ists
letztlich auch nicht so weit mit der Trennung Inhalt vs. Layout.

Dazu kommt dass HTML-Elemente nicht verschachtelt bzw. überlappt
werden dürfen, und tabellenähnliche Strukturen ohne Tabellen nicht
gut darstellbar sind, der Verzicht auf Layouttabellen also u.U.
den Aufwand erhöht und Strukturen eindimensionaler und damit
womöglich schlechter darstellt.

Ein Beispiel sind auch die nötigen Klimmzüge um mittels verschiedener
Hintergrundbilder und doppelter Container-Divs ein einfaches
dreispaltiges (tableless) Layout zu gestalten.

Grüsse

Cyx23

[Peter Körner]

Hallo

bzw. die Gruppierung tritt als (womöglich auch
störendes) Layoutmerkmal

divs sind doch IMHO logikfrei und als leere Container für Aufgaben der Layoutgestaltung prädestiniert.

Und auch umgekehrt wirds lästig wenn "neutrale" Divs o.ä. eingesetzt
werden und anschliessend beim CSS diese zusätzlichen Container immer
in der "Cascade" zu berücksichtigen sind.

Ähm.. du weißt schon dass innerhalb der Cascade auch elemente ausgelassen werden können?

[html]<div id="content"><div id="foo"><h1>Bar></h1></div></div>[/html]
#content h1 { ... }
spricht die Überschrift erster Ordnung CSS-Valid an. Die Leer-Divs azwischen werden dabei einfach übersprungen.

Oder Spalten bei Tabellen, da kann wohl col oder colspan keine
Hintergrundfarbe zugeordnet werden, es muss also ggf. immer noch
jedes td eine Klasse erhalten um Spalten zu gestalten

Oha.. das ist mir bisher noch garnicht aufgefallen.. aber recht hast du.

Dazu kommt dass HTML-Elemente nicht verschachtelt bzw. überlappt
werden dürfen

Warum? Mit position:absolute ist dies doch durchaus möglich.

und tabellenähnliche Strukturen ohne Tabellen nicht
gut darstellbar sind

warum auch? Eben dazu sind doch Tabellen da. Das Tabellenfreie Layout ziehlt nur auf Layouttabellen ab - für tabellarische Inhalte SOLLEN ja Tabellen weiterbenutzt werden.

eindimensionaler und damit womöglich schlechter darstellt.

Das kann ich nicht nachvollziehen.

Ein Beispiel sind auch die nötigen Klimmzüge um mittels..

Ja, CSS-Layouts sind anstrengender umzusetzen, komplexer zu bergreifen und erfordern wesentlich mehr Planung, allerdings sind sie wesentlich flexibler was die Darstellungsverhältnisse des Endbenutzers angeht und ist der einzige (derzeit technisch umsetzbare) Weg, Inhalkt und Layout zu trennen. Ein anderer Weg wäre z.B. XSLT auf XML, aber dazu fehlt die umfassende Browserunterstützung.

Gruß, Peter

[Ashura]

Hallo Peter.

Dazu kommt dass HTML-Elemente nicht verschachtelt bzw. überlappt
werden dürfen
Warum? Mit position:absolute ist dies doch durchaus möglich.

Ich denke Cyx23 meinte vielmehr:

<span><strong>TEXT</span></strong> - Nicht valide.

<span><strong>TEXT</strong></span> - Valide.

Gruß, Ashura

[Cyx23]

Hallo Peter,

bzw. die Gruppierung tritt als (womöglich auch
störendes) Layoutmerkmal
divs sind doch IMHO logikfrei und als leere Container für Aufgaben der Layoutgestaltung prädestiniert.

z.Zt. fehlen u.a. Gruppierungselemente (inhaltlich) im Sprachumfang von
HTML bzw. der Browser.
Und die logikfreien leeren Container fürs Layout wiederum können ja
auch nicht ganz frei eingesetzt werden, oder würden womöglich ohne
CSS-Anpassung durch Layoutveränderungen etwas wie "Inhalt" erzeugen.

Und auch umgekehrt wirds lästig wenn "neutrale" Divs o.ä. eingesetzt
werden und anschliessend beim CSS diese zusätzlichen Container immer
in der "Cascade" zu berücksichtigen sind.
Ähm.. du weißt schon dass innerhalb der Cascade auch elemente ausgelassen werden können?

"immer" bezog sich darauf dass die zusätzlichen Elemente immer
in der Cascade vorhanden sind. Je nach Aufbau des vorhandenen CSS
stören nachträglich aus Layoutgründen eingesetzte Divcontainer schon
den Ablauf und erfordern Anpassungen, ausserdem gibt es bei einigen
Browsern mitunter merkwürdige Effekte bei Vererbung und Schriftgrössen.

Dazu kommt dass HTML-Elemente nicht verschachtelt bzw. überlappt
werden dürfen
Warum? Mit position:absolute ist dies doch durchaus möglich.

Wie von Ashura geposted meinte ich den HTML-Code.

und tabellenähnliche Strukturen ohne Tabellen nicht
gut darstellbar sind
warum auch? Eben dazu sind doch Tabellen da. Das Tabellenfreie Layout ziehlt nur auf Layouttabellen ab - für tabellarische Inhalte SOLLEN ja Tabellen weiterbenutzt werden.

Ich würde eher empfehlen für bestimmte Layoutaufgaben die einer
tabellarischen Struktur entsprechen ruhig Layouttabellen zu
verwenden, zumal eine Trennung von Layout und Inhalt häufig
nicht hilfreich oder nicht klar möglich ist und die semantische
Bedeutung der Tabelle auch nicht so weltbewegend ist.

eindimensionaler und damit womöglich schlechter darstellt.
Das kann ich nicht nachvollziehen.

Wie willst du mit float o.ä. 4 x 4 Boxen so aufbauen dass wie
bei einer Tabelle Höhen- und Breitenänderungen in den Zeilen
und Spalten umgesetzt werden (auch Sonderfälle wie width:25%
kommen damit damit nicht richtig klar)?

Ein Beispiel sind auch die nötigen Klimmzüge um mittels..

Ja, CSS-Layouts sind anstrengender umzusetzen, komplexer zu bergreifen und erfordern wesentlich mehr Planung, ..

Eigentlich gar nicht, sie sind m.E. einfacher, bloß funktioniert ein
objektorienterter Ansatz nur solange wie die Objekte die geforderten
Eigenschaften bieten oder annehmen.

Und wenn du schreibst "erfordern wesentlich mehr Planung" würde es
darauf hinauslaufen dass CSS-Layouts einen Mangel an Flexibilität
sowie schlechte Anpass- und Wartbarkeit aufweisen.

.. allerdings sind sie wesentlich flexibler was die Darstellungsverhältnisse des Endbenutzers angeht und ist der einzige (derzeit technisch umsetzbare) Weg, Inhalkt und Layout zu trennen.

Nein. Tabellen sind bis auf den Sonderfall Handheld o.ä.(und so
gelungenes floaten dass alle Elemente ggf. untereinander sitzen)
flexibler, stabiler und auf allen Browsern stimmig darstellbar.
Und den o.g. Sonderfall könnte man per @media auch noch anpassen
und die tabellarische Anordnung zerlegen.
Die Trennung von Inhalt und Layout gelingt auch nur bedingt und
erfordert eigentlich eine lästige "Div-Suppe". Wobei natürlich in der
Praxis noch ein CMS hinzukommen könnte.

Grüsse

Cyx23

[Tim Tepaße]

Hallo Christian,

ich frage mich wieso das <b>-Element in Strict erlaubt ist! Ähnlich Style Elemente wie <u> und <i> sind ja auch nicht erlaubt. Was soll das also? Ich finde das W3C hat hier entweder geschlampt oder ich verstehe was nicht.

seufz

Immer diese Dogmen und die daraus resultierenden Missverständnisse.

Fangen wir mal am Anfang an, bei HTML 2. Dort werden die Elemente <b>, <i> und <tt> in der Sektion „Phrase Markup“ einsortiert, dort in den Unterabschnitt „Typographic Elements“, dies im Gegensatz zu den „Idiomatic Elements“, bei denen sich die logischen Auszeichnungen (em, code, etc.) finden. Dort steht dazu, wozu man typographische Elemente benutzen soll, diese Text:

»Typographic elements are used to specify the format of marked text.   Typical renderings for idiomatic elements may vary between user agents. If   a specific rendering is necessary - for example, when referring to a   specific text attribute as in "The italic parts are mandatory" - a   typographic element can be used to ensure that the intended typography is   used where possible.«

Das ist natürlich noch aus Zeiten vor CSS. Allerdings, wenn man den Kontext beachtet: das konkrete Rendering von logischen Elementen ist nirgendwo festgelegt, es bleibt Sache des Browsers. Wenn ich das recht sehe, hatte schon der allererste Browser/WYSIWYG-Editor fürs Web eine Unterstützung für userdefinierte Styles, siehe z.b. diesen Screenshot.

D.h. wenn man so will, bestand die Trennung zwischen Auszeichnung und Darstellung schon damals. Wie man nun aber im obigen Zitat lesen kann, wird auch beachtet, daß manchmal ein festes, verbindliches Rendering nötig ist, und sei es nur das etwas phantasievolle Beispiel dort. Deswegen gibt es in HTML auch Elemente zur Präsentation. Man muß sie ja nicht benutzen, wenn es keinen zwingenden Grund gibt.

Springen wir eins weiter, mitten in die Browser-Kriege und zu HTML 3.2. Mal abgesehen davon, daß ich den Standard nicht so schön und durchdacht finde, wie HTML 2.0 gibt es auch hier diese Elemente zu Präsentation, dazu kommen <u>, <strike>, <big>, <sub> und <sup> (wobei letztere ein besonderer Fall sind). Hier nennen sie sich „Font Style Elements“ und werden von logischen Elementen wieder getrennt. Leider gibt es dazu keinen einprägsamen Satz.

Nächste Version, CSS erscheint und das W3C versucht seine Sache mit HTML 4 richtig zu machen. Und das tut es. Praktisch ist HTML 4 immer noch die authorative Version, die uns betrifft. Dazu gleich mehr.

In HTML 4 wird m.W. erstmals die Vokabel „deprecated“ benutzt, zu deutsch am besten mit „missbilligt“ benutzt. Die Definition dafür sagt u.a. folgendes:

»A deprecated element or attribute is one that has been outdated by newer   constructs.«   ...   »This specification includes examples that illustrate how to avoid using   deprecated elements. In most cases these depend on user agent support for   style sheets. In general, authors should use style sheets to achieve   stylistic and formatting effects rather than HTML presentational   attributes. HTML presentational attributes have been deprecated when style   sheet alternatives exist (see, for example, [CSS1]).«

Wir lesen das im Kontext: Es gibt inzwischen neuere Elemente bzw. eine bessere Technik für Formatierungszwecke (CSS). Wenn diese Technik vorhanden ist, sollte sie auch benutzt werden. Wenn.

Unsere Elemente befinden sich inzwischen in der Sektion „Graphics“, dort wieder unter dem Titel „Font Style Elements“. Zwei Dinge fallen auf: Zum einen der Satz „Rendering of font style elements depends on the user agent.“ - es ist nicht mehr verpflichtend, wie diese Elemente angezeigt werden, es gibt nur noch ein informative, d.h. nicht verpflichtende Beschreibung, die sich natürlich an der klassischen typographischer Darstellung orientiert.

Zum anderen sind hier nur zwei (drei) Elemente als deprecated markiert (jeweils mit einem von mir angenommenen Grund): Für die Durchstreichelemente <strike>/<s> gibt es seit HTML 4 das logische Element <del> mit seinem Zwilling <ins>. Das wäre dann eine „neueres Konstrukt“, wie in der Definition von „deprecated“ und hat dazu noch den Vorteil sehr viel genereller zu sein. Und das Element <u> wird in der normalen gedruckten Typographie eigentlich weniger verwendet, im Web dagegen verstößt es aber gegen das Default-Rendering so ziemlich aller Browser von Links.

Kleiner Advocatus Diaboli Einschub: Warum sind nicht die anderen Elemente deprecated? Zwei mögliche Antworten: Zeitlicher Kontext, 1997 wurden diese Elemente noch sehr gerne benutzt. Und ist <em> wirklich ein Ersatz für <i>, <strong> ein Ersatz für <b> und wieso überhaupt zwei Elemente, um etwas zu hervorzuheben? Ist das wirklich besser?

Ich fasse mal den bisherigen Kenntnisstand zusammen:

• Elemente zur Präsentation wurden und werden als Bestandteil HTML betrachtet, bis hin zu HTML 4.01.
• Mit dem Aufkommen von CSS wird davon abgeraten, diese Elemente zu benutzen, wo CSS zur Verfügung steht. Ansonsten sind sie zur Rückwärtskompatibilität noch erlaubt.

Kommen wir nun zu XHTML 1.0. Und verlassen es gleich wieder. XHTML 1.0 ist nichts weiter als HTML 4 in XML neu formuliert. Und da es aus Kompatibilitätsgründen mit dem MIME-Typ text/html versendet werden darf, ist es für den Browser nichts anderes als HTML. Man fragt sich, wofür das ganze. Meine Top-Vermutung: Damit die Leute etwas haben können, mit dem sie vor noch Unwissenderen angeben können. Wie ich sagte: Der für uns relevante Standard ist immer noch HTML 4.

Interessanter ist da schon die Modularisierung von XHTML. Hier wird der von HTML 4 in XHTML 1.0 übernommene Sprachbestand auseinandergenommen, in logische Module gesteckt, die Autoren, die Zeug aus der XHTML-Familie benutzen wollen, in ihre Sprache einbinden können. Und daraus kann man Teilmengen des XHTML Sprachumfangs basteln, für begrenzte Zwecke. Aber: Es wird immer noch nichts am Sprachumfang von XHTML gemacht, weder hinzugefügt, noch weggenommen.

Hier treffen wir wieder auf unsere Elemente: Sie befinden sich in dem Modul mit dem korrekten Namen Presentation Module. Dort heißt es zum Sinn und Zweck dieses Moduls:

»This module defines elements, attributes, and a minimal content model for simple presentation-related markup«

Präsentation ist also immer noch ein Bestandteil von XHTML. Kein Wunder, wenn doch immer noch nicht am Sprachbestand gerüttelt wird. Die in HTML 4 als deprecated markierten Elemente lassen sich  deswegen hier auch immer noch finden, in dem Legacy Module, Erbschaften aus früheren Versionen.

Was wir bisher also unter XHTML verstanden, war eigentlich nur die Anstrengung, den HTML Sprachstandard in XML zu kriegen, damit man vollwertige XML-Dokumente in XHTML schreiben kann und Bestandteile von XHTML woanders einbinden kann. Am besten man sieht es nicht als Innovation, sondern als .. äh .. Wartung und Produktpflege für das 21. Jahrhundert. Kein großer Wurf, den man erwartete. Interessanter wird es zu den jetzt entstehenden XHTML-Dialekten, da kann man sich schließlich aussuchen, was man da hineinpackt. Hier ein paar Beispiele von beim W3C entwickelten XHTML-Dialekten:

XHTML 1.1 ist so ziemlich genau das, was die meisten wohl unter dem Schlagwort XHTML verstehen. Denn es ist eine Neuformulierung von XHTML 1.0 Strict mittels der XHTML Module. Als deprecated markierte Elemente finden sich hier nicht mehr. Das heißt, es ist das, was man erwartet hat, ein kleiner Fortschritt, missbilligtes Zeug wird rausgeworfen. Aber: Der nicht als als deprecated bezeichnete Sprachbestand von HTML findet sich hier immer noch. Im wesentlichen ist es also HTML 4 Strict in XML. Es ist also eine lange Geburt gewesen.

XHTML Basic ist dagegen eine Spezifikation, in dem der Sprachstandard wesentlich reduziert wurde. Kein Wunder, Zielgruppe dieser Spezifikation für „small devices“, soll heißen: Mobiltelefone, PDAs, Autos, Armbanduhren. Tatsächlich ist XHTML Basic auch gleich WAP 2, soweit ich informiert bin, aber die Mobilfunkszene ist mir immer fern geblieben. Witzig finde ich nur, daß sich der reduzierte Sprachbestand von XHTML Basic auf das abbilden läßt, was die meisten Semantikprediger für sich selbst einsetzen - man sollte doch meinen, sie hätten ein Bedürfnis nach mehr, nach aussagekräftigeren Elementen als nur etwas Textauszeichnung und divs.

Du wirst es erraten: Präsentationsmarkup oder noch schlimmer deprecated markup findet sich hier nicht. Es ist genau die Reduktion auf logische Strukturen, die gepredigt wird. Im Kontext von XHTML Basic finde ich das etwas unlogisch, aber es wird wohl angenommen, daß CSS-fähige Browser inzwischen zur Grundausstattung intelligenter Armbanduhren gehören.

XHTML Print ist eine Spezifikation, die sich an gedruckte Texte richtet. Zielgruppe sind nicht unbedingt Drucker mit allen Schnickschnack, sondern eher Low-Tech-Drucker. Erinnert sich noch jemand an Nadeldrucker? Genau.

ACHTUNG (Nur damit die bis hierhin eingeschlafenen wieder aufgewachen ;-) Hier findet sich nämlich einer der praktischen Anwendungsfälle für Präsentations-Markup. Hier muß man keine abstrakten Modelle zur Trennung von Content und Präsentation fahren (Auch wenn CSS natürlich erlaubt ist), hier hat man den typographischen Fall, in dem z. B. Hervorhebungen noch durch Fettdruck bzw. manchmal durch Kursivdruck gemacht werden. Demzufolge ist das Presentation Module in diesem XHTML Dialekt enthalten.

Man sieht hier einen Trend: XHTML 1.x ist nicht mehr nur ein Sprachstandard für alles, sondern eine Familie von Sprachelementen, die man unterschiedlichster Verwendung zuführen kann. Präsentationsmarkup war immer in HTML, wieso soll man es nicht beibehalten, wo es sinnvoll sein kann? Es zwingt einen ja keinen dazu, es zu benutzen. Oder um es für Semantiker zu sagen: Fettdruck kann auch eine semantische Information sein, die nicht unbedingt gleich der Information Hervorhebung sein muß.

Und was ist mit der Vision von XHTML als rein logische Dokumentstrukturierungssprache? Obacht, Rettung ist nahe.

Die ganzen Visionen finden sich in der Entwicklung von XHTML 2. Diese Spezifikation versucht sozusagen ein „HTML made right“ zu sein. Und da kommen ziemliche Änderungen auf Nutzer zu. Mit dem Nebeneffekt, daß XHTML 2 nicht rückwärtskompatibel zu XHTML 1.x sein wird. Das wird auch noch spannend. Da das noch im Status einen Working Draft ist, ist das ganze natürlich noch ein bewegliches Ziel, aber ein Trend ist sichtbar: Es wird nur noch logisch strukturiert, es gibt keine Workarounds für Weicheier zum Zwecke der Präsentation mehr (OK, das wurde inzwischen auch verwässert, siehe style-Attribut). Aber es wird zumindest interessant.

Tja.

Q: Soll das heißen, Präsentationsmarkup ist noch in HTML 4, weil das in    vorherigen HTML-Versionen als Bestandteil von HTML angesehen wurde? A: Ja.

Q: Und es kam mit in XHTML 1, weil das ganze Projekt XHTML 1 nur darauf    abzielte, HTML 4 in XML zu kriegen und nix zu verändern? A: Riiichtig.

Q: Aber das ist unsemantisch!! A: Verwende es doch einfach nicht. Oder nutze einen XHTML Dialekt, der    Deinen semantischen Vorstellungen mehr entspricht.

Q: Wann kann ich denn mit dem meinen Bürzel vor Freude erregenden XHTML 2.0    rechnen? A: Ich las neulich was von 2006. Rechne mal plus ein Extra-Jahr, dann wird    das 2007 mit dem Status der Candidate Recommendation, ab der das dann in    den Browsern implementiert werden soll. Beim Marktführer dauert das natürlich    etwas länger.

Q: Kann das sein, daß die Mühlen des W3C eeeetwas langsam mahlen? A: Ach? </loriot>

Tim

[Schuer]

Fangen wir mal am Anfang an, bei HTML 2. [..] Zeiten vor CSS. [..] Springen wir eins weiter, mitten in die Browser-Kriege und zu HTML 3.2 [..] Nächste Version, CSS erscheint und das W3C versucht seine Sache mit HTML 4 richtig zu machen [..] „deprecated“ [..] Kleiner Advocatus Diaboli Einschub: Warum [..] Ich fasse mal den bisherigen Kenntnisstand zusammen [..] Kommen wir nun zu XHTML 1.0 [..] XML neu formuliert [..] nichts anderes als HTML [..] Der für uns relevante Standard ist immer noch HTML 4 [..] die Modularisierung von XHTML [..] Hier treffen wir wieder auf unsere Elemente [..] Presentation Module [..] auch immer noch finden, in dem Legacy Module, Erbschaften aus früheren Versionen [..] XHTML 1.1 [..] XHTML Basic [..] XHTML Print [..] ACHTUNG (Nur damit die bis hierhin eingeschlafenen wieder aufgewachen ;-) [..] Man sieht hier einen Trend: XHTML 1.x ist nicht mehr nur [..] Obacht, Rettung ist nahe [..] XHTML 2 [..] „HTML made right“ [..] ziemliche Änderungen [..] nicht rückwärtskompatibel [..] Working Draft [..] 2006 [..] 2007 mit dem Status der Candidate Recommendation [..] Ach? </loriot>

Gewöhnst du dir gerade an, hier im Forum nur noch in Feature-Artikeln zu posten? Man könnte glatt meinen, du seist ein Lehrerkind ;-)

Viele Grüße!
_Dirk
DECAF°

P.S.: Aber natürlich: wie immer schön und informativ geschrieben!

[Dada]

Guten Morgen _Dirk,

P.S.: Aber natürlich: wie immer schön und informativ geschrieben!

aber er kann`s. Wenn ich hier im Forum oder auch anderswo lese, denke ich öfters: oh Kultur, oh Land - da manche (?) nicht einmal die Anzahl, Art und Reihenfolge der Buchstaben im Worte richtig hinbekommen.

Mit Gruß
Dada

[Anonymous]

aber er kann`s. Wenn ich hier im Forum oder auch anderswo lese, denke ich öfters: oh Kultur, oh Land

Ist das die moderne Form von "oh tempora! oh mores!"?

• da manche (?) nicht einmal die Anzahl, Art und Reihenfolge der Buchstaben im Worte richtig hinbekommen.

Da solltest du dir ruhig auch an die eigene Nase fassen.

[Ingo Turski]

Hi,

Gewöhnst du dir gerade an, hier im Forum nur noch in Feature-Artikeln zu posten?

Stimmt - eigentlich ist dieser Beitrag zu schade "nur" für's Forum.

freundliche Grüße
Ingo

[Jeena Paradies]

Hallo,

Stimmt - eigentlich ist dieser Beitrag zu schade "nur" für's Forum.

Ich habe mir die Erlaubnis geholt und Tim als ersten Gastautor in mein Weblog eingeladen. Der Beitrag ist jetzt dauerhaft unter der Adresse: http://jeenaparadies.net/weblog/2005/may/typografische-elemente-in-xhtml in meinem Weblog erreichbar.

Grüße
Jeena Paradies

[Ingo Turski]

Hi,

Ich habe mir die Erlaubnis geholt und Tim als ersten Gastautor in mein Weblog eingeladen. Der Beitrag ist jetzt dauerhaft unter der Adresse: http://jeenaparadies.net/weblog/2005/may/typografische-elemente-in-xhtml in meinem Weblog erreichbar.

Sehr schön.
Ach übrigens:

» end tag for element "LORIOT" which is not open
  Ach? </loriot>
               ^«
;-)

freundliche Grüße
Ingo

[Gunnar Bittersmann]

Tim,
Wow. Eins, setzen. ;-)

Gestutzt hatte ich nur bei

XHTML 2. […] (OK, das wurde inzwischen auch verwässert, siehe style-Attribut)

Ich dachte, das gäbe es in XHTML 2 nicht mehr. Wieder was gelernt.

Gruß,
Gunnar

[Tim Tepaße]

Hallo Gunnar,

(style-Attribut in XHTML 2)
Ich dachte, das gäbe es in XHTML 2 nicht mehr. Wieder was gelernt.

Vor zwei Jahren war es draußen, dann gab es einen ziemlichen Aufstand aus der Webdesign-Community, Zeldman und so.

Tim

[Peter Körner]

Hallo

Whow.. eine wunderbare Abhandlung.
Ich werde in Zukunft dann doch eher XHTML1.1 statt 1.0 verwenden.. ;)

Eine Frage noch: Macht es sinn XHTML-Basic in "normalen" webseiten zu verwenden, und das Design komplett über CSS zu lösen (mach ich ja eigentlich heute schon, aber so würde ich dazu eher gezwungen..)

Aber den bLog-Link werde ich gleich mal an einige Freunde weitergeben, die das bestimmt auch uinteressieren dürfte..

Gruß, Peter

[Cyx23]

Hallo,

Ich werde in Zukunft dann doch eher XHTML1.1 statt 1.0 verwenden.. ;)

im vorliegenden Text hat Tim ja ausgeführt dass bei 1.0 der MIME-Typ
text/html versendet werden darf, mit dem Ergebnis "ist immer noch
HTML 4".

Handelt es sich bei XHTML1.1 aber bei richtiger Auslieferung im
Ergebnis um XML (mit mangelnder Kompatibilität)?

Grüsse

Cyx23

[Tim Tepaße]

Hallo Cyx,

Handelt es sich bei XHTML1.1 aber bei richtiger Auslieferung im
Ergebnis um XML (mit mangelnder Kompatibilität)?

Ja, soweit ich das verstehe, muß für XHTML 1.1 zwangsläufig der MIME-Typ application/xhtml+xml benutzt werden. Browser müssen dann den XML-Parser benutzen, was zu Problemen in den üblichen Verdächtigungen führen kann. molily hat in der Vergangenheit hier einiges zu den Interpretationen der MUSTs und SHOULDs in den verschiedenen Standards geschrieben.

Ich würde XHTML 1.1 derzeit noch nicht im Web einsetzen, höchstens wenn man sich über die Zielgruppe im Klaren ist.

Tim

[Gunnar Bittersmann]

Tim,

Ja, soweit ich das verstehe, muß für XHTML 1.1 zwangsläufig der MIME-Typ application/xhtml+xml benutzt werden.

Nein, MUSS nicht. SOLLTE. [XHTMLMIME]

Ich würde XHTML 1.1 derzeit noch nicht im Web einsetzen, höchstens wenn man sich über die Zielgruppe im Klaren ist.

Der einzige Grund für XHTML 1.1 ist die Verwendung der Elemente, die es in 1.0 noch nicht gibt: Ruby-Annotation.

Zu den Einschränkungen, denen XHTML 1.1 als text/html unterliegt, siehe [molily] und [Thread XHTML 1.1 und text/html].

Gunnar