nicht angemeldet
DTD Erweiterung XHTML1.1
Hallo,
ich möchte für ein bestimmtes Project Iframes einsetzen. Um zu vermeiden das ich auf XHTML1.0 Transitional zurückgreifen muß, möchte ich die XHTML1.1 DTD um das XHTML-Modul Iframes erweitern.
Also habe ich die XHTML1.1 DTD heruntegeladen und das Modul am Ende hinzugefügt, den offiziellen public identifier mit einem eigenen ersetzt und diese Declaration in eine xhtml-Datei eingebunden.
Nun erkennt der Validator auch das iframe-Element mit allem drum und dran, hat aber kann das Element aber nicht einordnen:
<div><iframe></iframe></div>
^Error: element "iframe" not allowed here; check which elements this element may be contained within
Also ran an das XHTML 1.1 Document Model in der xhtml11-model-1.mod und ran an das entity Inline.extra und dort das im Iframe-Modul spezifizerte Entitiy %iframe.qname; eingetragen:
<!ENTITY % Inline.extra "%iframe.qname;" >
Nu meckert der vali wider rum. Und zwar das er das Entity %iframe.qname; nicht finden kann.
So, ab hier weis ich dann nicht mehr weiter, und eine komplett neue DTD bzw. Modul will ich auch nicht schreiben.
Hat also irgendjemand eine Ahnung wie ich am einfachsten das Iframe-Modul in XHTML1.1 integriere, bzw. XHTML 1.1 um das Iframe modul erweitere, dass es korrekt benutzt werden kann.
Gruß Herbalizer
-
Hallo,
ich möchte für ein bestimmtes Project Iframes einsetzen. Um zu vermeiden das ich auf XHTML1.0 Transitional zurückgreifen muß, möchte ich die XHTML1.1 DTD um das XHTML-Modul Iframes erweitern.
Es geht nicht gegen dich sondern allgmein:
Ich kapiere es eigentlich nicht, warum Leute etwas einsetzen wollen,
das der DTD wiederläuft, sie aber unbedingt die DTD dazu haben wollen.
Lass doch alle DOCTPYES weg, die Browser werden deine Seite auch problemlos darstellen.Also ran an das XHTML 1.1 Document Model in der xhtml11-model-1.mod und ran an das entity Inline.extra und dort das im Iframe-Modul spezifizerte Entitiy %iframe.qname; eingetragen:
<!ENTITY % Inline.extra "%iframe.qname;" >
Nu meckert der vali wider rum.
Du hast das iframe-Modul auch eingebunden?
<!-- Inline Frames Module ........................................ -->
<!ENTITY % xhtml-iframe.module "INCLUDE" >
<![%xhtml-iframe.module;[
<!ATTLIST %iframe.qname;
align ( top | middle | bottom | left | right ) #IMPLIED
>
<!ENTITY % xhtml-iframe.mod
PUBLIC "-//W3C//ELEMENTS XHTML Inline Frame Element 1.0//EN"
"xhtml-iframe-1.mod" >
%xhtml-iframe.mod;]]><!-- end of xhtml-iframe-1.mod -->
Du hast es überlesen:
<!-- Extending the Model
While in some cases this module may need to be rewritten to accommodate changes to the document model, minor extensions may be accomplished by redeclaring any of the three *.extra; parameter entities to contain extension element types as follows:
%Misc.extra; whose parent may be any block or inline element.
%Inline.extra; whose parent may be any inline element.
%Block.extra; whose parent may be any block element.
If used, these parameter entities must be an OR-separated list beginning with an OR separator ("|"), eg., "| a | b | c"
All block and inline *.class parameter entities not part of the *struct.class classes begin with "| " to allow for exclusion from mixes.
-->also: <!ENTITY % Inline.extra "| %iframe.qname;" >
Grüße
Thomas-
Hallo,
Es geht nicht gegen dich sondern allgmein:
Ich kapiere es eigentlich nicht, warum Leute etwas einsetzen wollen,
das der DTD wiederläuft, sie aber unbedingt die DTD dazu haben wollen.Aus demselben Grund weshalb das W3C DTD-Profile als Drafts zu XHTML 1.1 plus MathML 2.0 plus SVG 1.0 und XHTML 1.1 plus SMIL veröffenlicht?!
Du hast das iframe-Modul auch eingebunden?
Jup.
Du hast es überlesen:
also: <!ENTITY % Inline.extra "| %iframe.qname;" >Nein hab ich nicht. Doch der Einsatz von | führt zu einer Flut Fehlermeldungen für einige der in der DTD eingebundenen Module, sowohl im W3C-Validator als auch im xerces XML-Parser.
Während der Validator in diesen Modulen bemängelt, das | un ) ungültig ist, meint xerces an selbigen Stellen:An element type is required in the declaration of element type "[Elementname]"
Zum Austesten:
[link: http://rcswww.urz.tu-dresden.de/~rs324721/iframe_xhtml11_profile/
Gruß Herbalizer
-
Jetzt funktionierts. Muste das Entity noch im qualified-name-module bekannt machen.
-
-
-
ich möchte für ein bestimmtes Project Iframes einsetzen. Um zu vermeiden das ich auf XHTML1.0 Transitional zurückgreifen muß, möchte ich die XHTML1.1 DTD um das XHTML-Modul Iframes erweitern.
Das geht nicht. XHTML 1.1 enthält kein <iframe>. Wenn du ein solches Element - wie auch immer - hinzufügst, ist es kein XHTML 1.1 mehr, du kannst also entweder W3C XHTML 1.0 Transitional verwenden, oder Herbalizer XHTML. Zu Herbalizer XHTML habe ich dann einen prima Link: http://www.mauthner-gesellschaft.de/mauthner/intro/bichsel.html
-
Hallo, Björn,
Das geht nicht. XHTML 1.1 enthält kein <iframe>. Wenn du ein solches Element - wie auch immer - hinzufügst, ist es kein XHTML 1.1 mehr, du kannst also entweder W3C XHTML 1.0 Transitional verwenden, oder Herbalizer XHTML.
Keine Suggestivfrage, rein naiver Natur: was bringt XHTML Modularisation dann? Soll auch kein Widerspruch zu deiner These sein, mir geht dieses Verlangen nach target/iframe usw. in XHTML 1.0 Strict/1.1 auch auf die Nerven, es wird hier fast schon zur FAQ.
Im Gesamtzusammenhang gesehen spiegelt es meiner Erfahrung nach einen Trend wider, der zwar eindeutig in Richtung XHTML Strict geht, aber die Autoren schreiben kein besseres (X)HTML als vorher. Nach der CSS-Revolution sind semantische Blockelemente sowieso out, man kennt nur noch das div-Element, für sontige Formatierungen nimmt man span und eine CSS-Klasse. target="_blank" wird über JavaScript simuliert und ein mehrfach verschachteltes Tabellenlayout stylt man neuerdings mit CSS2, ist ja schließlich en vogue, oder das auf 800x600 zementierte Layout wird pixelgenau nachgebaut.
XHTML-Validität/Wohlgeformtheit sagt also nahezu gar nichts über die Codequalität oder die Projektstrukturierung aus. Mir sind HTML 4.01 Trans.-Seiten bekannt, welche in ihrer Durchdachtheit mit ihrem eleganten Code manche XHTML 1.1-Seiten mit dem unnützesten, aber heißesten position:fixed-Scheiß überbieten.
Zu Herbalizer XHTML habe ich dann einen prima Link: http://www.mauthner-gesellschaft.de/mauthner/intro/bichsel.html
Die Geschichte gefällt mir. Aber ich sehe nur einen oberflächlichen Zusammenhang mit diesem Problem hier, ich glaube, in ihr steckt viel mehr.
Mathias
-
Hallo Mathias,
Keine Suggestivfrage, rein naiver Natur: was bringt XHTML Modularisation dann?
in der XHTML Modularisation gibt es duchauch (nebst frame-Modul) ein iframe-Modul http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_iframemodule
XHTML 1.1 basiert auf die Module die unter XHTML Modularisation beschrieben sind.
Und wie die W3C selber zu XHTML 1.1 sagt:
"This document type is essentially a reformulation of XHTML 1.0 Strict using XHTML Modules. This means that many facilities available in other XHTML Family document types (e.g., XHTML Frames) are not available in this document type. These other facilities are available through modules defined in Modularization of XHTML, and document authors are free to define document types based upon XHTML 1.1 that use these facilities (see Modularization of XHTML for information on creating new document types)."Was also bedeutet, dass es zwar im XHTML 1.1 in der "Grundausrüstung" kein iframe-Modul gibt, aber die Autoren können XHTML 1.1 mit anderen Modulen erweitern, z.B. eben mit dem iframe-Modul.
Grüße
Thomas-
Aloha, :)
Keine Suggestivfrage, rein naiver Natur: was bringt XHTML Modularisation dann?
[...]
Ja, das war mir bekannt, genau deswegen fragte ich: was bringt es *dann*, nämlich wenn das Einbinden von Modulen dazu führt, dass man nicht mehr von XHTML 1.1 sprechen kann. Was soll dann Modularisation, wenn es doch formal nichts mit XHTML 1.1 zu tun hat? (Siehe
http://www.8ung.at/w3c-trans-de/xhtml11/conformance.html#s_conform.)Die Möglichkeit, abgeänderte DTDs für Eigenzwecke zu schreiben, bestand doch AFAIK schon immer/schon vor XHTML Mod. Wie ich das erkenne ist Modularisation für das öffentliche Web kontraproduktiv, in diesem speziellen Fall geht es meist nur darum, sich mit dem strengen XHTML 1.1 zu schmücken und trotzdem Transitional-Module einzubinden, weil man nicht auf XHTML 1.0 Transitional ausweichen will, welches sich AFAIK von der HTML 4.01 Transitional nur durch seine XML-Natur unterscheidet, womit dargelegt wäre, dass überhaupt keine Weiterentwicklung passiert ist, wenn man von den paar XML-Änderungen absieht.
Ähm, wieso wollen eigentlich manche iframe in XHTML 1.1, es gibt doch das object-Element, und iframe ist/war nur eine spezielle Unterart des object-Elements, wie schon die 4.01 Spez. festlegte...
(...) document authors are free to define document types based upon XHTML 1.1 that use these facilities (...)
Was also bedeutet, dass es zwar im XHTML 1.1 in der "Grundausrüstung" kein iframe-Modul gibt, aber die Autoren können XHTML 1.1 mit anderen Modulen erweitern, z.B. eben mit dem iframe-Modul.Aber mit XHTML 1.1 und festen Standards hat das doch wenig zu tun. XHTML 1.1 plus Modifikationen ist anscheinend nicht "besser" als XHTML 1.0 Transitional, wieso also die Modularisation, es gibt doch schon DTDs für alle erdenklichen Fälle, ob Strict oder Transitional, ob SGML oder XML...
Ich verstehe den ganzen Rummel nicht; ich freue mich, dass es eine XHTML 1.1-DTD gibt ohne den historischen Präsentationsballast und sehe nicht ein, wieso man diese verwässern sollte.
Etwas verwirrt,
Mathias-
Holla ;-)
Die Möglichkeit, abgeänderte DTDs für Eigenzwecke zu schreiben, bestand doch AFAIK schon immer/schon vor XHTML Mod.
eben. und die DTDs vom W3C darf man auch für die eigene Zwecken nutzen, aber dann eben nicht mehr mit dem FPI (Formal Public Identifier) vom W3C.
womit dargelegt wäre, dass überhaupt keine Weiterentwicklung passiert ist, wenn man von den paar XML-Änderungen absieht.
Warum sollte da was weiterentwickelt worden sein? XHTML 1.0 ist nichts anderes als die Reformulierung von HTML 4.01 nach den Regeln von XML.
Aber mit XHTML 1.1 und festen Standards hat das doch wenig zu tun. XHTML 1.1 plus Modifikationen ist anscheinend nicht "besser" als XHTML 1.0 Transitional, wieso also die Modularisation, es gibt doch schon DTDs für alle erdenklichen Fälle, ob Strict oder Transitional, ob SGML oder XML...
Mal davon abgesehen, dass ich das ganze für die Auswüchse von Paar sich langweilenden W3C-WG-Members halte, entbährt die Sache nicht eine gewisse Logik.
Die Modularisation ist nichts anderes als das Zerstückeln der XHTML 1.0 DTD auf einzelene Module. Es gibt aber keine "xhtml-modul.dtd" die man in einer FPI verwenden könnte.
Die DTD für XHTML 1.1 ist eine DTD die auf diese Module basiert, sie entbährt jedoch jegliche der "unsicheren" Module. Z.B. das [i]frame-Modul und das an sich nur wegen die ungeklärte Benützung von target="". Deshalb gibt es z.B. in den Strickt DTDs keine <a target="">. Das Problem will die W3C durch http://www.w3.org/TR/2002/WD-hlink-20020913/ lösen.
Sinn und Zweck der Modularisation und XHTML 1.1 ist dass man die Möglichkeit hat auch XML in die "HTML" Seiten einzubinden (eben durch eigene Module), oder andere XML-Anwendungen wie MathML, SVG, SMIl etc. Natürlich ist es eine Frage des verarbeitenden Programms das dann auch darzustellen. So kann man z.B. eine DTD haben die nur für Seiten gilt die von irgendwelchen PDAs dargestellt werden können.
Und damit das ganze eben nicht wild herumwuchert und wieder ein jeder seine eigene DTDs "kocht" gibt es diese Module (z.B. XHTML Basic)Wie dem auch sei. XHTML 1.1 ist eben dafür da, dass man sie erweitern kann. Der Sinn der Erweiterung, statt einfach eine andere existierende DTD zu nehmen ist aber eine andere Frage. ;-)
Grüße
Thomas -
Ja, das war mir bekannt, genau deswegen fragte ich: was bringt es *dann*, nämlich wenn das Einbinden von Modulen dazu führt, dass man nicht mehr von XHTML 1.1 sprechen kann. Was soll dann Modularisation, wenn es doch formal nichts mit XHTML 1.1 zu tun hat?
XHTML M12N richtet sich überhaupt nicht an Dokument-Autoren, sondern praktisch ausschliesslich an Organisationen, die Dokumenttypen schaffen, die entweder auf XHTML aufbauen oder XHTML einbinden. Die Modularisierung wird genutzt, um XHTML 1.1 zu definieren. Als anderes Beispiel nehme man WML 2.0. Die Modularisierung wird zunächst benutzt, um XHTML Basic 1.0 zu definieren, später dann um dieses durch einige Elemente zu erweitern, was rauskommt ist dann ein neuer XHTML-Dokumenttyp mit Namen WML 2.0.
Die Möglichkeit, abgeänderte DTDs für Eigenzwecke zu schreiben, bestand doch AFAIK schon immer/schon vor XHTML Mod.
Nein, die gab es nicht, zumindest hätte man da nicht von HTML/XHTML sprechen können.
Wie ich das erkenne ist Modularisation für das öffentliche Web kontraproduktiv, in diesem speziellen Fall geht es meist nur darum, sich mit dem strengen XHTML 1.1 zu schmücken und trotzdem Transitional-Module einzubinden, weil man nicht auf XHTML 1.0 Transitional ausweichen will,
Das ist ein Problem der Personen, die die falschen Probleme mit den falschen Mitteln beheben wollen.
welches sich AFAIK von der HTML 4.01 Transitional nur durch seine XML-Natur unterscheidet, womit dargelegt wäre, dass überhaupt keine Weiterentwicklung passiert ist, wenn man von den paar XML-Änderungen absieht.
XHTML ist ein zeitlich lang angelegter Versuch, die Schäden des Browserkriegs zu reparieren.
Ähm, wieso wollen eigentlich manche iframe in XHTML 1.1, es gibt doch das object-Element, und iframe ist/war nur eine spezielle Unterart des object-Elements, wie schon die 4.01 Spez. festlegte...
Tja, das fragst du am besten Herbalizer. Wahrscheinlich soll das resultierende XHTML-Dokument dann auch noch als text/html ausgeliefert werden, was ebenfalls nicht wirklich im Einklang mit den veröffentlichten Spezifikationen steht.
-
Moin!
Ähm, wieso wollen eigentlich manche iframe in XHTML 1.1, es gibt doch das object-Element, und iframe ist/war nur eine spezielle Unterart des object-Elements, wie schon die 4.01 Spez. festlegte...
Wenn du einen Würgaround für den IE kennst mit dem ich die DOM 2 HTML Eigentschaft contentDocument des HTMLObjectElements nachbilden kann: gerne.
Andererseits ist dies eh nur Readonly, so das ich so oder so auf iframes zurückgreifen muss.Frag auch mal Thomas Meinike (?) über SVG-plugins, Objects und abstürzende Mozillas >= 0.9.(?)8.
Aber mit XHTML 1.1 und festen Standards hat das doch wenig zu tun. XHTML 1.1 plus Modifikationen ist anscheinend nicht "besser" als XHTML 1.0 Transitional, wieso also die Modularisation, es gibt doch schon DTDs für alle erdenklichen Fälle, ob Strict oder Transitional, ob SGML oder XML...
Du übersiehst das diese Modularisierung nicht nur HTML betrifft, sondern auch das Einbinden anderer Sprachen ermöglicht, und man dies dann auch validieren kann. Sowas wie XHTML 1.1 plus MathML 2.0 geht zwar ohne DTD auch, aber ein bisschen Ordnung kann da auch rein.
Gruß Herbalizer
-
Ähm, wieso wollen eigentlich manche iframe in XHTML 1.1, es gibt doch das object-Element, und iframe ist/war nur eine spezielle Unterart des object-Elements, wie schon die 4.01 Spez. festlegte...
Wenn du einen Würgaround für den IE kennst mit dem ich die DOM 2 HTML Eigentschaft contentDocument des HTMLObjectElements nachbilden kann: gerne.
Andererseits ist dies eh nur Readonly, so das ich so oder so auf iframes zurückgreifen muss.Die Frage ist nicht, warum du auf <iframe> zurückgreifen willst, sondern warum auf XHTML 1.1, das <iframe> nunmal zugunsten <objects> bewusst abgeschafft hat. Wenn dir das nicht gefällt, benutze XHTML 1.1 nicht, sondern eine HTML-Version, die <iframe> enthält. Du solltest XHTML 1.1 auch nicht als text/html ausliefern, sondern als application/xhtml+xml, was dann auch nicht im IE funktionieren wird. Und?
-
-
-
-
Das geht nicht. XHTML 1.1 enthält kein <iframe>. Wenn du ein solches Element - wie auch immer - hinzufügst, ist es kein XHTML 1.1 mehr, du kannst also entweder W3C XHTML 1.0 Transitional verwenden, oder Herbalizer XHTML.
Keine Suggestivfrage, rein naiver Natur: was bringt XHTML Modularisation dann? Soll auch kein Widerspruch zu deiner These sein, mir geht dieses Verlangen nach target/iframe usw. in XHTML 1.0 Strict/1.1 auch auf die Nerven, es wird hier fast schon zur FAQ.
Mit XHTML M12N lässt sich vieles anstellen, so ist es relativ leicht, verschiedene XHTML-Sprachen zu definieren, so zum Beispiel XHTML 1.1, XHTML Basic 1.0 oder WML; ferner erlaubt sie es, XHTML auch mit anderen Sprachen zu vermischen, so zum Beispiel Profile für XHTML + (MathML, SMIL, SVG, ...) Neue, auf XHTML basierende Sprachen zu "erfinden", macht genau dann Sinn, wenn es genügend Leute gibt, die sich auf die Verwendung eben dieser Sprache einigen können, WML ist hier ein schönes Beispiel, es gibt Hersteller, die implementieren WML in ihre Produkte und es gibt Anbieter, die Inhalte in WML anbieten. Bei "Herbalizer XHTML" halte ich das nicht für gegeben.
Im Gesamtzusammenhang gesehen spiegelt es meiner Erfahrung nach einen Trend wider, der zwar eindeutig in Richtung XHTML Strict geht, aber die Autoren schreiben kein besseres (X)HTML als vorher. Nach der CSS-Revolution sind semantische Blockelemente sowieso out, man kennt nur noch das div-Element, für sontige Formatierungen nimmt man span und eine CSS-Klasse. target="_blank" wird über JavaScript simuliert und ein mehrfach verschachteltes Tabellenlayout stylt man neuerdings mit CSS2, ist ja schließlich en vogue, oder das auf 800x600 zementierte Layout wird pixelgenau nachgebaut.
Dennoch betrachte ich die Gesamtentwicklung als positiv, es gibt zumindest ein Bewusstsein dafür, dass es noch andere Kriterien gibt, als "it works in both browsers", das war lange Zeit nicht so. Gerade für dieses Forum ist der W3C HTML Validator ein schönes Beispiel. Vor ein paar Jahren war der unsinniges, unnützes Teufelszeug. Danach wurde er zum "Valigator", der zwar benutzt wurde, aber böse war und sicherlich nicht das letzte Wort hatte. Heute hat er meist das letzte Wort. Wenn man mich fragt, geht es jetzt daran, an den Details in diesem Bewusstsein zu feilen.
-
Hallo, Björn,
danke für die Erläuterungen, auch im Nebenthread.
Mit XHTML M12N lässt sich vieles anstellen, so ist es relativ leicht, verschiedene XHTML-Sprachen zu definieren, so zum Beispiel XHTML 1.1, XHTML Basic 1.0 oder WML; ferner erlaubt sie es, XHTML auch mit anderen Sprachen zu vermischen, so zum Beispiel Profile für XHTML + (MathML, SMIL, SVG, ...)
Aha, mir war bisher nur das direkte Einbinden über "Dateninseln" und mehrerer Namensräume bekannt.
Neue, auf XHTML basierende Sprachen zu "erfinden", macht genau dann Sinn, wenn es genügend Leute gibt, die sich auf die Verwendung eben dieser Sprache einigen können, WML ist hier ein schönes Beispiel, es gibt Hersteller, die implementieren WML in ihre Produkte und es gibt Anbieter, die Inhalte in WML anbieten.
Apropos, ist die erste Version WML nicht älter als die erste XML-Recommendation? Ich finde nur: "In the mid-90's WML was derived from XML for use with wireless devices." Ich finde aber für die Zeit nur den allerersten XML WD vom 14. November 1996. Andererseits scheint WML 1.0 von 1998 zu sein, es würde also passen.
Naja, nur eine Frage.Bei "Herbalizer XHTML" halte ich das nicht für gegeben.
Das Gefühl habe ich auch. :)
Im Gesamtzusammenhang gesehen spiegelt es meiner Erfahrung nach einen Trend wider, der zwar eindeutig in Richtung XHTML Strict geht, aber die Autoren schreiben kein besseres (X)HTML als vorher. (...)
Dennoch betrachte ich die Gesamtentwicklung als positiv, es gibt zumindest ein Bewusstsein dafür, dass es noch andere Kriterien gibt, als "it works in both browsers", das war lange Zeit nicht so.
ACK.
Gerade für dieses Forum ist der W3C HTML Validator ein schönes Beispiel. Vor ein paar Jahren war der unsinniges, unnützes Teufelszeug. Danach wurde er zum "Valigator", der zwar benutzt wurde, aber böse war und sicherlich nicht das letzte Wort hatte.
Das habe ich beim Lesen von alten Diskussionen im Archiv auch gemerkt, die Standards wurden mehr als Empfehlungen (Recommendations halt) gesehen, an die man sich nicht zwingend halten musste. Wer dennoch die Standards hochhielt, wurde als verbohrt und dogmatisch bezeichnet.
Vielleicht liegt es aber auch an der allgemeinen Entwicklung, die eine Einsicht ermöglichte. Es war früher tatsächlich ab einem gewissen Punkt nur Traumtänzerei, heute ist es um einiges einfacher, validen Code zu rechtfertigen.
Es gibt viele Anknüpfungspunkte, welche die Entwicklung vorantreiben, bspw. wenn die gesellschaftliche und politische Akzeptanz von der Notwendigkeit der Barrierefreiheit steigt, werden gleichzeitig auch die Webseiten besser, da die WCAG und ähnliche Richtlinien Standardkonformität mit sich bringen.Heute hat er meist das letzte Wort. Wenn man mich fragt, geht es jetzt daran, an den Details in diesem Bewusstsein zu feilen.
Die Regulars dieses Forums muss man IMO nicht mehr überzeugen, da sie bereits durch die Bank Wert auf Standardkonformität, Trennung von Inhalt und Präsentation und zusammengefasst verantwortungsvolles Publizieren im Web legen. Das hiesige Klientel lässt sich meist durch Argumente auf den richtigen Weg bringen. Zumindest trifft man immer seltener auf Mentalitäten wie "Hauptsache es funktioniert bei mir".
Ich finde wichtig, dass man den Anfängern das einfach verständliche XHTML ans Herz legt, wenn man schon nicht Pxelschubser resozialisieren kann. Es muss auch Autorenwerkzeuge geben, die es jedem ermöglichen, ohne viel Vorwissen valide und zugängliche Hypertextdokument zu verfassen (sofern das in Bereich des Möglichen liegt).
Ein Hypertextautor hat es imho heutzutage viel einfacher, da es endlich verbindliche Vereinbarungen gibt und man kein Mischmasch aus Microsoft-HTML und Netscape-HTML schreiben muss, sondern für alle Browser schreiben kann, die die Standards unterstützen. Alleine die wiedererlangte Vielfalt auf dem Browsermarkt und die Existenz eines Open Source-Browsers, der in vielerlei Hinsicht die Referenz darstellt, sind Anzeichen für die nicht mehr aufzuhaltende webweite Revolution. ;)Mathias
-
Apropos, ist die erste Version WML nicht älter als die erste XML-Recommendation? Ich finde nur: "In the mid-90's WML was derived from XML for use with wireless devices." Ich finde aber für die Zeit nur den allerersten XML WD vom 14. November 1996. Andererseits scheint WML 1.0 von 1998 zu sein, es würde also passen.
WML 1.0 wurde Anfang 1998 veröffentlicht, vgl. http://www1.wapforum.org/tech/terms.asp?doc=wml-30-apr-98.pdf. Es sei allerdings angemerkt, dass ich von WML 2.0 spreche.
Das habe ich beim Lesen von alten Diskussionen im Archiv auch gemerkt, die Standards wurden mehr als Empfehlungen (Recommendations halt) gesehen, an die man sich nicht zwingend halten musste. Wer dennoch die Standards hochhielt, wurde als verbohrt und dogmatisch bezeichnet.
Du kannst dir vorstellen wie ich mich über jeden gefreut habe, der sich hier und anderswo ausweinen wollte, weil NN6 die so mühevoll erstellte Seite nicht mochte :-)
-
-
Hi Björn,
Danach wurde er zum "Valigator", der zwar benutzt
wurde, aber böse war und sicherlich nicht das letzte
Wort hatte. Heute hat er meist das letzte Wort.
Wenn man mich fragt, geht es jetzt daran, an den
Details in diesem Bewusstsein zu feilen.solange mich der Validator dazu zwingt, entweder bei HTML 4.01 Transitional zu bleiben, obwohl meine Dokumente valides "XHTML 1.1 plus target" sind, oder invalide Dokumente zu erzeugen, finde ich die Situation sehr unglücklich.
Derzeit entscheide ich mich für die invaliden Dokumente, weil ich beim Validieren gegen XHTML 1.1 die ganzen Altasten finde, die ich gerne entfernt, d. h. durch CSS-Konstruktionen ersetzt sehen will - meine Dokumente werden bei diesem Vorgang einfach qualitativ besser.
Wenn aber XHTML ansonsten einfach weniger Funktionalität hat als HTML und ich auf meiner Domain nun mal massiv Frames einsetze (aber 95% aller Dokumente trotzdem XHTML 1.1 sind, der Rest jeweils die Framesets und die Seiten mit den target-Links drin), dann sitze ich zwischen zwei Stühlen.
Ich finde nicht, daß ein "Produkt" dadurch besser wird, daß es ein für mich lebenswichtiges Feature ohne Vorwarnung ersatzlos streicht. Ich habe in einem früheren Thread in diesem Forum versucht, zu skizzieren, was man tun könnte, um das URL-Konzept so zu erweitern, daß es Frames umfassen würde ... schade, daß in dieser Richtung sonst offenbar niemand denkt.
Insofern habe ich diesen Thread mit großem Interesse verfolgt und überlege mir ebenfalls, einen solche Hybrid-Sprache zu bauen ... wenn ich sicherstellen kann, daß ich gegenüber einer _mir_ genehmen Sprache valide bin, dann kann ich beispielsweise mit relativ geringem Aufwand einen automatischen Validierer für meine weit über 1000 Seiten bauen und damit systematisch nach Fehlern suchen - als welche ich die Verwendung von "target" derzeit nicht ansehe, im Gegensatz zum Validator.
Viele Grüße
Michael-
solange mich der Validator dazu zwingt, entweder bei HTML 4.01 Transitional zu bleiben, obwohl meine Dokumente valides "XHTML 1.1 plus target" sind, oder invalide Dokumente zu erzeugen, finde ich die Situation sehr unglücklich.
Du kannst nicht alles haben, entweder du betrachtest HTML 4.0 Strict und darauf aufbauende Dokumenttypen (HTML 4.01 Strict, XHTML 1.0 Strict, XHTML 1.1) als sinnvoll und hälst dich an ihre Regeln, oder du tust das nicht und benutzt es daher nicht. Du kannst ohnehin nicht XHTML 1.1 verwenden und das Dokument im Microsoft Internet Explorer betrachten, da du XHTML 1.1 selbstverständlich entsprechend http://www.w3.org/TR/xhtml-media-types/ als application/xhtml+xml auslieferst, was der IE aber nicht unterstützt (und viele andere Browser ebensowenig).
Derzeit entscheide ich mich für die invaliden Dokumente, weil ich beim Validieren gegen XHTML 1.1 die ganzen Altasten finde, die ich gerne entfernt, d. h. durch CSS-Konstruktionen ersetzt sehen will - meine Dokumente werden bei diesem Vorgang einfach qualitativ besser.
Validiere gegen eine andere DTD als die in der Dokumenttyp-Deklaration angegebene und du hast folglich keine Probleme mehr.
Ich finde nicht, daß ein "Produkt" dadurch besser wird, daß es ein für mich lebenswichtiges Feature ohne Vorwarnung ersatzlos streicht. Ich habe in einem früheren Thread in diesem Forum versucht, zu skizzieren, was man tun könnte, um das URL-Konzept so zu erweitern, daß es Frames umfassen würde ... schade, daß in dieser Richtung sonst offenbar niemand denkt.
Dass das 'target'-Attribut nicht in HTML 4.0 Strict auftaucht ist seit mind. fünf Jahren öffentlich bekannt, das kannst du nicht ernsthaft als "ohne Vorwarnung" bezeichnen.
Doch, diese Gedanken hat man sich schon lange gemacht, http://www.w3.org/TR/xframes/ hast du offensichtlich verpasst. Nicht dass mir XFrames gefallen würden, aber das ist eine andere Geschichte...
-
Hi Björn,
Du kannst ohnehin nicht XHTML 1.1 verwenden und das Dokument im
Microsoft Internet Explorer betrachten, da du XHTML 1.1
selbstverständlich entsprechend http://www.w3.org/TR/xhtml-
media-types/ als application/xhtml+xml auslieferst, was der IE
aber nicht unterstützt (und viele andere Browser ebensowenig).Tja, gerade der letzte Teil Deines Satzes untergräbt die Selbstverständlichkeit doch ziemlich massiv. ;-)
Doch, diese Gedanken hat man sich schon lange gemacht,
http://www.w3.org/TR/xframes/ hast du offensichtlich verpasst.Gut möglich. Welche Browser unterstützen das?
Viele Grüße
Michael-
Du kannst ohnehin nicht XHTML 1.1 verwenden und das Dokument im
Microsoft Internet Explorer betrachten, da du XHTML 1.1
selbstverständlich entsprechend http://www.w3.org/TR/xhtml-
media-types/ als application/xhtml+xml auslieferst, was der IE
aber nicht unterstützt (und viele andere Browser ebensowenig).Tja, gerade der letzte Teil Deines Satzes untergräbt die Selbstverständlichkeit doch ziemlich massiv. ;-)
Entweder application/xhtml+xml oder kein XHTML 1.1.
Doch, diese Gedanken hat man sich schon lange gemacht,
http://www.w3.org/TR/xframes/ hast du offensichtlich verpasst.Gut möglich. Welche Browser unterstützen das?
Stellst du mir die Frage wieder, wenn XFrames eine Candidate Recommendation ist? Vorher sind höchstens experimentelle Implementationen in explizit als experimentell deklarierter Software sinnvoll.
-
Entweder application/xhtml+xml oder kein XHTML 1.1.
Nichmal der W3C-Vali versteht diesen Media-Type. Einzig Mozilla und Amaya können damit umgehen.
Im Übrigen ist es etwas vermessen darauf zu pochen, dass XHTML1.1 als application/xhtml+xml ausgelifert werden muss, und sich selbst nicht dran zu halten http://bjoern.hoehrmann.de. Also, hopphopp, die DTD wieder auf auf HTML4.01 Strict gesetzt ;-)
Gruß Herbalizer
-
-
-
-
-
-
-