Hallo!

Ich schreibe grad an eine Seite. Sie ist ungefähr so aufgebaut:


Das Problem ist folgendes.

Für den ersten Container habe ich die Überschriften (h1, h2, etc...) formatiert.

Kurioserweise wird diese Einstellung auch für den Container Nr. 2 übernommen.

Weiß jemand ich das wegbekomme?


MfG

Wie hast Du denn die Überschriften formatiert?

Als:

h1{...} (also falsch)

Oder als bspw.:

*#Container1 > h1{...}

Hallo,

im Style-Tag so:



MfG

Hallo,


Kurze Zwischenfrage.

Wenn ich den Elementen h1 und h2 in dem Container 1 gleichzeitig eine oder mehrere Eigenschaften zuweisen möchte, was muß ich dann noch mal eingeben?


oder ohne Komma?!


MfG

Dein Selektor enthält alle h1-Tags im Container1 und alle h2-Tags.

Bevor ich irgendwas anderes sage oder schreibe:

Warum verwendest Du


statt


Welche HTML-Elemente verwendest Du oder hast vor zu verwenden, die noch im Transitional-Doctype enthalten sind?

Siehe auch

W3C HTML 4.01: 7.2 HTML version information

Entsprechender Abschnitt der (kommentierten!) Deutschen Übersetzung der HTML 4.01-Spezifikation:


Wenn Du ein sauberes Rendering haben willst und den Browser der Gegenseite nicht unnötig zum Raten veranlassen willst, dann verwende Strict und die in Strict enthaltenen Elemente! Elemente, die in Transitional enthalten sind nur dann, wenn es sich gar nicht anders vermeiden lässt und Du sie begründen kannst, warum an der entsprechenden Stelle Du auf das betreffende missbilligte Element nicht verzichten kannst. Und das dann auch durch Wahl des Transitional Doctypes so klarmachen. Ansonsten auf derlei missbilligten Elemente verzichten und das dann entsprechend durch Wahl des Strict-Doctypes deutlich machen. Die Wahl des Strict-Doctypes sollte möglichst immer der Normalfall sein. Grundsätzlich.

Treffen die Browser auf einen Transitional-Doctype, so gehen die in aller Regel sofort in den sog. Quirks-Modus und rendern ggf. etwas anders und unvorhersagbarer.

Im Transitional-Doctype sind Elemente drin definiert, die von der Spezifikation her deprecated (sprich: missbilligt) sind, von deren Gebrauch also nicht nur abgeraten wird, sondern die in einer späteren Spezifikation fehlen werden. Im Strict-Doctype sind sie ganz bewusst NICHT enthalten, und der Browser rendert ggf. anders und sauberer (besonders bei evtl. vorkommenden Tabellen und deren Inhalten macht sich das u.U. sichtbar bemerkbar). Deshalb meine Eingangsfrage.


Mit Komma. Denn Du zählst in dem Moment auf. Entweder nebeneinander geschrieben und durch Kommata getrennt oder untereinander geschrieben und durch Kommata getrennt, wie es Dir und Deiner Lesgewohnheit beliebt. Nebeneinander geschrieben spart's Dir Platz, untereinander geschrieben erhöht's evtl. die Übersichtlichkeit.


Selektoren, Übersicht:

W3C CSS 2.1, 5 Selectors:

Entsprechender Abschnitt der (kommentierten!) Deutschen Übersetzung der CSS2-Spezifikation:

W3C CSS 3, 2. Selectors

Nee, wenn ich Doctype weglasse, wechseln die Browser in den Quirks-Modus. getestet mit Firefox.

Und ja, das mit Transitional ist Absicht, damit auch etwas ältere Browser meine Sachen richtig anzeigen.

MDN: Mozilla's DOCTYPE sniffing
MDN: Gecko's "Almost Standards" Mode

Michael Jendryschik: Doctype Switching
Henri Sivonnen: Activating Browser Modes with Doctype

Wikipedia: Quirks Mode
Wikipedia: Quirks Mode - Comparison of document types

Wie alt sollen/dürfen die Browser sein, denen Du damit (warum auch immer) eine Extrafreude machen willst? Noch Netscape 4? Oder IE3?

Du machst es Dir und dem Browser schwieriger als es sein muss. Welche Elemente verwendest Du denn, für die Du unbedingt den Transitional-Doctype brauchst? Ich vermute mal: kein Einziges. Also kannst Du am Anfang auch den Strict-Doctype nehmen, der dem Browser anzeigt: "Hier kommt ein Strict-Dokument, Du (Browser) hast weniger Arbeit!" Solltest Du auf irgendeine Art Tabellen in Deinem Dokument verwenden und damit arbeiten und in diesen tabellen zufälliug Bilder haben, ändert sich z.B. die Darstellung allein schon nur, wenn Du den Doctype von "Transitional" auf "Strict" setzt und Dir dann das Ergebnis mal anschaust (siehe dazu auch ).

Also warum unnötig verkomplizieren? Nach Möglichkeit Strict! Immer. Es sei denn, man hat triftige Gründe, weil man meinetwegen ein bestimmtes HTML-Element verwenden MUSS und es auch nicht vermeiden oder durch andere Semantik oder CSS ersetzen kann (was wohl eher sehr selten der Fall sein dürfte, dass sowas unersetzbar ist) und welches nur in der Transitional-DTD definiert ist, nicht jedoch in der Strict-DTD.
Nur dann, in solchen Ausnahmefällen sollte man zum Transitional-Doctype greifen. Der heißt übrigens nicht ohne Grund "Transitional" zu deutsch "übergangsweise" oder auch "vorübergehend". Er soll also eine Brücke bauen zwischen altem HTML-Inhalt (wo misbilligte Präsentations-Elemente wie z.B. <small></small> oder <center></center> oder <font></font> noch drin vorkommen, die misbilligten Elemente findest Du z.B. hier gekennzeichnet: ), den man noch irgendwie in die Neuzeit retten will. Altem Inhalt dahingehend, dass da zum Beispiel Präsentations-Elemente drin vorkommen, die eigentlich in CSS ausgedrückt gehören. Bei neueren Inhalten (und da bastelst Du ja wohl grad' dran herum, solltest Du mit HTML nur die Struktur des Dokuments definieren und alles, was Präsentation, Positionierung und Aussehen ist, das solltest Du in CSS definieren und ausdrücken).

Gleichlautend wie meine Empfehlung steht's übrigends auch direkt am Anfang der jeweiligen DTD drin:

Strict DTD: http://www.w3.org/TR/html401/sgml/dtd.html

Transitional DTD: http://www.w3.org/TR/html401/sgml/loosedtd.html

HTML 4.01, dt. Übersetzung: 7.2 HTML-Versionsinformation (Doctypes)

Und in der deutschen und mit Kommentaren versehenen deutschen Übersetzung von HTML 4.01 findest Du u.a. auch diesen Hinweis:

HTML 4.01, dt. Übersetzung: B.1 Anmerkungen zu ungültigen Dokumenten

Schon aus Performance-Gründen ist es dem Autor immer angeraten, so strikt, valide und wohlgeformt wie möglich zu schreiben. Weil der Browser dann nämlich weniger Arbeit hat, weniger seine eingebaute Fehlerkorrektur bemühen muss, dadurch ggf. weniger raten muss (teilweise rät er dann wirklich, und die Ergebnisse, die dann rauskommen, sind nicht vorhersehbar), sondern sich auf das verlassen kann, was er da grad' vorgesetzt bekommt und deshalb unterm Strich auch schneller das Ergebnis anzeigen kann (und wenn es auch nur ein paar Millisekunden sind, die dadurch gewonnen werden). Schon allein das ist ein Vorteil, wenn man Strict schreibt, und es sollte einem doch wert sein, sowas (also einen Geschwindigkeitsvorteil beim Anzeigen) nicht einfach außer acht zu lassen, oder?!

Sag mal, möchtest du mir jetzt einreden, was ich gesehen habe oder eben nicht?!

Wenn ich dir sage, daß Firefox bei der Angabe Transitional "standardkonformer Modus" anzeigt, dann stimmt das auch.

Lies die obigen Dokumente, u.a. auch die von Mozilla selber, und entscheide dann selber was Du siehst bzw. was da passiert.

Firefox schaltet bei dem Doctype, den Du da verwendest, in den "Almost Standards"-Mode! Lies Dir durch, was das heißt, und worin sich der "Almost Standards Mode" vom "Full Standards Mode" unterscheidet.

Quelle: Mozilla's DOCTYPE sniffing und Gecko's "Almost Standards" Mode

Hallo Sierkb,



Das kann ich dir ganz genau sagen.

Ich benötige dies für die Einbindung des Google Kalenders sowie einer Google Karte (Maps).

Google liefert leider kein valides HTML.

Ich habe dafür noch keine brauchbare Alternative gefunden, bis außer für die Karte. Dort habe ich iFrame anders verwendet, die "Formatierung" erfolgt nun über CSS.

Wenn du mir eine Möglichkeit aufzeigst wie man mit validem HTML 4.01 Strict + CSS 2.1 Links zu Google Maps, Google Kalender (Einbindung) und Google Karte (Maps) herstellt, dann immer her damit.

MfG

dom_beta:

Kann ich fast kaum glauben. Zumal es Dir freisteht, jegliches invalides Zeugs selber dahingehend zu korrigieren, dass es nach der Korrektur valide ist (helfen dazu tut Dir z.B. HTML Tidy in einer seiner zahlreichen Erscheinungsformen, auch MacOSX hat standardmäßig Tidy (/usr/bin/tidy) und die TidyLib mit an Bord -- zwar veraltet, aber immerhin). Und außerdem: Validität hat nix mit dem Doctype Strict oder Transitional zu tun. Valide sollte es immer sein -- egal, ob mit Transitional oder Strict Doctype.

Dann leg' mal die Karten auf den Tisch und zeig' her die Code-Schnipsel von Google, die Du da meinst, die da angeblich nicht valide sein sollen/wollen (entweder per Copy & Paste oder per Nennung des URLs).

Dies hier (Karte: Berlin)


teste dies mal mit dem W3C Validator mit HTML 4.01 Strict.

Bei HTML 4.01 Transitional meldet er mir 4 Fehler.



Er sagt mir 11 Fehler.

Und bei Transitional / Strict hat er ein Problem mit einem Teil eines Hyperlinks. Er meint,



Warning Line 37, Column 114: cannot generate system identifier for general entity "ctz"

Ich war auch erst dabei, den Google Kalender sowie Google Karten mit dem HTML-Tag "object" einzubinden, aber irgendwie verstehe ich die Funktionsweise bzw. die Attributierung noch nicht.

Falls es also einen Weg gibt, den Google Kalender und die Einbindung der Karte und Verweise auf eine Karte in gültigem HTML 4.01 Strict oder Transitional hinzubekommen, immer her damit.

dom_beta:


Validiert ohne Fehler gegen die Transitional-DTD: "This document was successfully checked as HTML 4.01 Transitional!"
Die Warnung, die er bzgl. Encoding ausspuckt, darf getrost ignoriert werden (steht da auch). Deshalb ist's auch eine Warnung. Und keine Fehlermeldung.

Ich habe nix weiter gemacht, als Deinen von Google stammenden Code zu nehmen, in ein Gerüst zu stecken, den Code ein wenig umzustellen zwecks besserer Lesbarkeit
Da ließe sich noch Einiges vereinfachen und aufräumen und vor allem auch einige Dinge in CSS auslagern, aber dazu bin ich jetzt zu faul.

Ich finde interessant, dass ich diese Diskussion ausgerechnet in DIESEM Forum finde.
Zum Glück scheinen wir einen Experten für valides HTMl anwesend zu haben und dann will ich mal eine Frage stellen:

Laut selfhtml enthält die strict-Variante nur block-Elemente. Wie sieht es damit aus, wenn ein bis zwei Wörter aus einem Fließtext ein Link <a>bla</a> sein sollen. Werden sie dann auch als Block und nicht inline, wie es normal wäre, dargestellt? Für jeden Link einen eigenen Absatz zu haben, ist doch völlig am Sinn vorbei... Jedenfalls nach der Aussage von selfhtml müsste es so sein.

Erstens ist eine solche Aussage grundfalsch, und zweitens glaube ich auch nicht, dass das so bei SelfHTML steht. Da musst Du Dich gehörig verhört oder verlesen haben.
Und wenn's trotzdem dort so stünde, wäre es immer noch grundfalsch.

Guck in die Spezififaktion rein: , das Anker-Element a ist von natura aus immer noch ein Inline-Element.

Was man jederzeit machen kann, per CSS die Elemente in ihrer Darstellung so umdefinieren, wie es einem in den Kram passt. Du kannst aus jedem Inline-Element ein Block-Element machen und aus jedem Block-Element ein Inline-Element. Mit der CSS-Regel display angewendet auf das betreffende Element. Siehe dazu auch Siehe dazu auch in der CSS 2.1-Spezifikation das Kapitel 9 Visual formatting model bzw. 9.2.4 The 'display' property

Diese Werte kann display laut CSS 2.1 alle annehmen: inline | block | list-item | run-in | inline-block | table | inline-table | table-row-group | table-header-group | table-footer-group | table-row | table-column-group | table-column | table-cell | table-caption | none | inherit


Frage wurde zuvor beantwortet.

Stütze Dich nie einzig und allein auf Aussagen, die in SelfHTML getätigt werden. Sie sind nicht immer komplett und manchmal auch falsch. SelfHTML taugt nicht als Referenz. Um einen schnellen Überblick mal zu gewinnen, ist's OK. Wer es genau wissen will und dann auch verlässlich, der sollte lieber gleich in die Original-Spezifikation schauen. Da steht nämlich zum Teil noch viel mehr an Information drin als bei SelfHTML.

Schau lieber gleich in die jeweilige Spezifikation rein oder in deren offizielle deutsche Übersetzung (teilweise von den Übersetzern fachlich kommentiert und mit weiteren Beispielen versehen zur besseren Verständlichkeit -- ein Novum, das die engl.-sprachigen Originale nicht haben, das macht die deutschen vom W3C offiziell abgesegneten und verlinkten Übersetzungen so besonders und einzigartig!)


Ich nehme außerdem an, Du beziehst Dich auf diese Tabelle: . Die solltest Du dann aber auch richtig lesen und verstehen. Und den Unterschied zwischen Element und Attribut kennen.

In der HTML 4.01-Spezifikation dürften die Entsprechung diese beiden Tabellen haben: (bzgl. Elementen) und (bzgl. Attributen). Und überall, wo ein "D" (für deprecated = zu deutsch: missbilligt) in der Spalte "Depr." (Deprecated) steht, das betreffende Element oder Attribut ist dann nicht Bestandteil der Strict-DTD und bestenfalls Bestandteil der Transitional/loose-DTD. (Transitional= zu deutsch: vorübergehend/übergangsweise). Man erkennt also schon an dem Wortlaut Transitional, dass das etwas ist, was man nur übergangsweise und zur Not einsetzen sollte. Als Ziel sollte man möglichst immer Strict schreiben und seinen Inhalt danach ausrichten. Geht's nicht anders (z.B. bei alten Dokumenten, die man nachträglich aufhübscht und nicht komplett neu schreiben will, und wo veraltete Elemente drin sind), dann eben "zur Not" Transitional.
So manches Transitional-Dokument ließe sich ohne viel Aufhebens in ein Strict-Dokument umwandeln, bei anderen kann das etwas schwieriger werden, ist aber in der Regel nicht unlösbar. Manchmal ist ein Transitional-Doctype aber auch nicht zu vermeiden, oder man müsste es mit einigem Aufwand bewerkstelligen, der nicht immer in einem positiven Verhältnis zum Ergebnis steht.

Obiges Dokument von dom_beta ließe sich sicher auch recht einfach in ein Strict-Dokument umwandeln, wenn man z.B. auf den iframe verzichten würde und die fremde(n) Seite(n) statt per iframe dann per object-Element in das Dokument einbinden würde. Muss ich mal mit rumspielen, bin ein wenig faul grad'. Gemacht habe ich das schon öfters. Geht eigentlich von der Grundsätzlichkeit her einfacher als man zunächst denkt.

dom_beta:

Den jeweiligen iFrame hiermit zu ersetzen:


und dann die Transitional-DTD ersetzen durch die Strict-DTD
ginge nicht (Habe jetzt noch nicht ausprobiert, ob das validiert. Müsste aber eigentlich validieren, habe ich im Gefühl)?

Und wenn Du's mit XHTML-Dokumenten machst, dann halt entsprechend anpassen und mit dem entsprechenden Mimetype referenzieren und ausliefern.

Nein, das steht da überhaupt nicht. Da steht, dass alle Inhalte in Block-Elementen stehen müssen und demnach dürfte man z.B. span innerhalb von div verwenden.

Ich nehme an, er bezieht sich auf diese Formulierung bei SelfHTML (es fällt mir grad' schwer, nicht auszurasten angesichts dieser Formulierung):

und

Wie ich finde, eine völlig irreführende Darstellung/Beschreibung der Strict- und Transitional-DTD. Am besten gleich vergessen, was SelfHTML da schreibt.
SelfHTML beschreibt da höchstens etwas, was seit Jahren als Unsitte einfach praktiziert worden ist (sich nämlich nicht an die Definition zu halten und einfach zu schreiben und Block-Elemente und Inline-Elemente so zu schreiben und zu verschachteln, wie einem grad' der Schnabel gewachsen ist). Daraus eine gewollte Intention seitens der Spezifikation abzuleiten, finde ich doch sehr weit hergeholt und völlig an den Haaren herbeigezogen. Der draußen in der WWW-Welt über Jahre gewachsene Schlendrian im Umgang mit der Syntax und Notation bzgl. HTML (mit allen daraus erfolgten negativen Konsequenzen) wird durch diese bei SelfHTML dargelegte Formulierung quasi nachträglich abgenickt und als "immer so gewollt" dargestellt. Das ist mitnichten der Fall.

Wenn es zum Beispiel invalide ist, in ein <blockquote>-Element gleich irgendeinen Text reinzuschreiben, ohne diesen zuvor in ein Absatz-Element <p> zu packen, dann war das schon immer falsch und schon immer invalide und schon immer entgegen dem Wortlaut in der Spezifikation! Nur mit dem Unterschied, dass ein Benutzer-Agent (Browser, Validator), wenn er das Dokument im Strict-Modus parst, ein wenig genauer hinschaut und genauer rechnet und seine Fehlerkorrektur möglichst nicht anschmeißen muss und raten muss, was denn evtl. gemeint sein könnte, sondern sich darauf verlässt, dass das da so richtig ist, was man ihm vorlegt und das Dokument deshalb zügiger parsen und darstellen kann. Und im Transitional-Modus ist er weniger genau und toleriert durchaus auch mal Abweichungen vom "Soll". Und das ist nur möglich, weil HTML eine SGML-Sprache ist, wo solche Tolerierungen und Abweichungen vom "Soll" überhaupt möglich sind. U.a. deshalb gibt es auch XML. Weil da solche Tolerierungen nicht mehr möglich sind. Da ist ein entsprechendes XML-Dokument entweder wohlgeformt und valide und hält sich Punkt für Punkt an die Spezifikation, und dann wird es auch geparst und angezeigt, oder es verstößt gegen die Spezifikation, ist invalide und wird demzufolge dann auch weder ganz geparst noch angezeigt. XML ist also strenger als SGML. Dort gibt es nur: 100% valide nach XML-Syntax (kann geparst/angezeigt werden). Oder fehlerhaft/nicht valide (kann nicht geparst/angezeigt werden).

So gibt es in HTML4, weil es eine SGML-Sprache ist, auch die Notation der sog. Shorttags, also verkürzte Schreibweisen. Wenn man die sieht oder schreibt, dan nsieht das zwar teilweise fehlerhaft aus, kann aber durchaus valide sein und völlig konform zur SGML-Syntax sein und wird deshalb von keinem Benutzer-Agenten (z.B. Browser, Validator) angemeckert, siehe dazu auch:

W3C Blog: Shorttags - the odd side of HTML 4.01
W3C: HTML 4.01 Specification: B.3.7 Shorthand markup (engl.)
W3C: HTML 4.01 Spezifikation: B.3.7 Auszeichner abkürzen (Deutsche Übersetzung)

Es ist also dem Umstand geschuldet, dass HTML4 eine SGML-Sprache ist (SGML ist viel viel älter und komplexer als HTML, SGMLs Anfänge gehen bis in die 60er Jahre zurück, die Flugzeug-Firma Boeing hat zum Beispiel ihre sämtlichen Konstruktionspläne und Anweisungen in SGML abgelegt), die gewisse Laxheiten im Umgang mit der Sprache schlicht und einfach erlaubt bzw. toleriert. Gewollt und dass diese Laxheiten bewusst ausgenutzt werden können, war niemals und zu keinem Zeitpunkt Intention des W3C. Und um dem schon von der Grundlage her Einhalt zu gebieten und auch, um die Komplexität und den Umfang von SGML auf Web-Bedürfnisse runterzubrechen, gibt es XML.

HTML5 ist übrigens weder eine SGML-Sprache noch eine XML-Sprache. Es ist wiederum etwas völlig Neues und bedient sich aus beiden Welten (der (X)HTML5-Parser ist strenger als der SGML-Parser und wohlwollender als der gestrenge XML-Parser). Deshalb braucht ein HTML5-fähiger Browser auch einen neuen, einen eigenen Parser, statt sich auf den in den Browsern jahrelang vorhandenen SGML- und XML-Parsern aufzustützen. Und wie dieser Parser zu sein hat, wie er aufgebaut sein muss und wie er sich in bestimmten Situationen wie zu verhalten hat, steht gleich mit in der (X)HTML5-Spezifikation drin. Ein absolutes Novum, dass das in der Spezifikation gleich mit drinsteht! Das gab's bisher noch nie. Bisher hat jeder Browser-Hersteller sich die jeweilige Spezifikation hernehmen müssen und den Wortlaut interpretieren müssen. Und der Eine hat das Geschriebene dann so verstanden und umgesetzt, und der andere so. Größtes Negativ-Beispiel in dieser Hinsicht: IE6. Und um für die Zukunft so einen fehlgeleiteten Interpretationsversuch wie bei IE6 durch Microsoft geschehen, zu vermeiden, hat man's gleich für alle verständlich und nachvollziehbar und verbindlich in die HTML5-Spezifikation mitreingeschrieben. Und die Browser-Hersteller sind überglücklich darüber. Weil es zum ersten Mal möglich ist, Parser zu bauen, die schon von der Spezifikation her ganz eineindeutige Vorgaben bekommen haben. Spielräume für Missinterpretierungen sind minimiert und im Vorfeld weitgehend ausgeräumt worden. Auch und gerade das ist ein unschätzbarer Vorteil von HTML5. Und gerade auch deshalb so zukunftsweisend. Und gerade auch deshalb hofieren die Browser-Hersteller alle HTML5. Weil da in dieser Hinsicht glasklare Handlungsanweisungen bzgl. des Parsers drinstehen, die für alle gleichermaßen gelten und von allen gleichermaßen verstanden und interpretiert werden.

Anmerkung: der HTML5-Parser, den Henri Sivonen für den Mozilla Firefox geschrieben hat (, ), der kommt seit dem Jahre 2008 ebenfalls im Referenz-Validator, dem Markup Validator des W3C, zum Einsatz (, , , ).

Ich bin der Meinung, wenn man über halbwegs gute Englischkentnisse verfügt, sollte man gleich beim W3C nachlesen. So vermeidet man Übersetzungsfehler, inhaltliche Fehler und veraltete Definitionen etc.
Die Intention der Strict-Variante wird bei SelfHTML in dieser Beschreibung überhaupt nicht deutlich und die drastischen Auswirkungen auf die Browser werden in dem Abschnitt anscheinend nicht mal erwähnt.

Ich würde auch nicht Definitionen von Funktionen in PHP auf hinz-und-kunz-eigene-seite-zu-php.example.com nachlesen, sondern eher bei php.net.

Aus dieser Diskussion habe ich gelernt, dass es sehr wohl SInn macht, nicht aus der Einfachheit heraus Traditional zu benutzen. Es macht sehr wohl Sinn, strict zu verwenden.

In meiner Schulzeit musste ich zwei mal HTML "lernen" (obwohl ich es bereits konnte). Das war zum einen in der Realschule und zum anderen auf dem Gymnasium. Bei beiden Unterrichten wurde nicht einmal auf Semantic und Co eingegangen, aber alle Klassenkollegen würden sicherlich noch heute behaupten, sie könnten HTML. Letztens hatte ich noch ein Gespräch mit einem Bekannten, der ebenfalls Lehrer ist, und bei ihm an der Schule lernen die Kiddies schon in der 7. Klasse HTML, weil es einfach nur "cool" ist und die Kinder sehen können, was sie da gerade schreiben. Solch ein Unterricht ist war alters- und niveaugerecht, aber auf der anderen Seite völlig irreführend, da die Kinder hinterher überzeugt sind, etwas wirklich<- zu können.

So landet beispielsweise auf Bewerbungen für eine Ausbildungsstelle unter Computerkenntnissen oftmals neben Word, Excel und Powerpoint das ach so beliebte HTML. Und wenn ihr mich fragt: Wahrscheinlich kann es nicht mal 1% der Jugendlichen wirklich.

Entweder das. Oder man liest in den vom W3C offiziell authorisierten Übersetzungen (, , ) nach, für die deutsche Sprache hier zu finden:

W3C: German Translations of W3C Documents
(Übersetzungen von W3C Dokumenten)

Oder auch (in geringerem Umfang) hier:

edition W3.de - Web-Standards in deutscher Sprache , von Stefan Mintert.

Stefan Minterts Zusammenstellung ins Deutsche übersetzter W3C-Spezifikationen ist auch in Buchform im Addison Wesley-Verlag erschienen: , Amazon führt sie hier:

Stefan Mintert, W3C: XML & Co. Die W3C-Spezifikationen für Dokumenten- und Datenarchitektur [Gebundene Ausgabe], ISBN-10: 3827318440, ISBN-13: 978-3827318442:

Stefan Mintert, W3C: XHTML, CSS und Co . Die W3C-Spezifikationen für das Web-Publishing [Gebundene Ausgabe], ISBN-10: 3827318726, ISBN-13: 978-3827318725:

Die beiden Bücher sind recht dicke Schinken und beinhalten eine Zusammenstellung der wichtigsten ins Deutsche übersetzen W3C Spezifikationen zu dem im Buchtitel genannten Thema. Leider werden diese Bücher nicht mehr aufgelegt bzw. dieses interessante Buchprojekt von Stefan Mintert in Zusammenarbeit mit dem W3C.de und dem Addison Wesley-Verlag hatte leider nur eine Auflage, die zudem noch schnell vergriffen war. Leider nur eine einzige Auflage, da die Nachfrage zu gering war und der Umfang der immer schneller nachwachsenden Spezifikationen irgendwann einfach zu groß war, diese beständig in Buchform zu pressen (so ein Buch zu machen, braucht ja auch seine Zeit und ist mit immenser Arbeit verbunden). Das war irgendwann dann allein vom Umfang her nicht mehr zu schaffen. Deshalb ist das Angebot allein in elektronischer Form im Rahmen des W3C W3C Translations Projektes unter bzw. wohl die beste und unaufwendigste Form, Übersetzungen anzubieten. Das W3C stellt dazu auch einige softwaretechnische Vorlagen/Templates und Skripte bereit. Stafan Mintert hatte die Übersetzungen für sein Buchprojekt sehr wesentlich auf Basis von XML und XSLT gebaut (die XML- und XSLT-Dateien zum größten Teil selbst geschrieben), woraus dann die Übersetzungen in Form verschiedener Ausgabeformate (HTML, XHTML, PDF, PostScript, Plaintext etc.) automatisch erzeugt werden konnten.

Die deutschen Übersetzungen (egal, ob online zu finden oder in Buchform von Stefan Mintert) sind offiziell vom W3C abgesegnet und gegengelesen und geschrieben mit Masse von einem Heer freiwilliger Fachleute. Gegengelesen und geprüft von W3C Staff Migliedern, die deutschen Übersetzungen bzgl. CSS sogar teilweise gegengelesen und auf Fehler und Übersetzungsfehler hin geprüft von Bert Bos, dem Miterfinder von CSS. Bert Bos ist Niederländer und versteht und spricht ziemlich gut Deutsch, und sowas lässt er sich nicht nehmen.

Das Wertvolle an einigen dieser deutschen Übersetzungen ist, dass sie an mancher Stelle (je nach Lust und Laune und Fachwissen des betreffenden Übersetzers) vom W3C offiziell akzeptierte und deutlich gekennzeichnete Anmerkungen, Kommentierungen und Beispiele des betreffenden Übersetzers beinhalten, die das engl.-sprachige Original nicht aufweist. Diese Kommentierungen und Ergänzungen machen den Text an mancher Stelle noch verständlicher als das engl.-sprachige Original.

Nichtsdestotrotz und bei aller Güte der Übersetzung -- normativ bindend ist immer das engl.-sprachige Original (in der Übersetzung auch immer ganz zu Anfang referenziert), so wie es international auch üblich ist. Trotzdem sind die deutschen Übersetzungen für so manchen eine sehr wertvolle Hilfe und Bereicherung. Weil sich ein Text, abgefasst/übersetzt in der eigenen Muttersprache für manche Menschen leichter liest. Genau deshalb gibt's das Übersetzungsprojekt des W3C .

dom_beta:

Hier, schau mal: ist HTML 4.01 Strict, verzichtet auf <iframe>, benutzt <object> und validiert somit einwandfrei und akurat gegen HTML 4.01 Strict:


Oder besser lesbar und mit schönen Einrückungen und mit Syntax-Highlighting auch zeitweilig online bei Pastebin einsehbar und abrufbar: .
Habe für diesen Code-Schnipsel dort 1 Tag Gültigkeit eingestellt, danach verfällt er und ist dort nicht mehr abrufbar

So wolltest Du es doch haben, richtig?

Ja genau so!

Danke sehr!

Hallo sierkb,

ich bräuchte da noch einmal deine Hilfe.

Es geht um einen einfachen Link zu einer Google Karte. Als Beispiel habe ich Berlin gewählt.


Der Link (von Google):


Der Validator meldet:


und so weiter.


Das kannst du selbst testen, indem du den Google-Link in einer Testseite übernimmst.

Für eine Lösung in validem HTML 4.01 Transitional oder Strict freue ich mich immer!


Vielen Dank im Voraus!

dom_beta:

Einfaches HTML-Einmaleins: maskiere "&"-Zeichen mit der Entität (engl. Entity) &amp; dafür (&amp; = engl. für: Ampersant = & ).
Weil der HTML-Parser sonst das &-Zeichen als Einleitung für eine Entität hält und diese zahlreichen Strings, denen das "&" unmaskiert voransteht, natürlich nicht kennt. Und deshalb sagt der Parser (auch im Validator werkelt ein Parser) Dir z.B. sowas wie "general entity 'source' not defined and no default entity" oder "cannot generate system identifier for general entity 'q'". Weil eine Entität namens &source; oder namens &q; nicht in der DTD von HTML definiert sind.

Richtig müsste es deshalb so heißen:


Sollte dieser Output von PHP generiert worden sein, so ist PHP falsch konfiguriert (bzw. in der Standardeinstellung geblieben). Es gibt da eine betreffende Config-Option in der php.ini-Datei, die leider standardmäßig auskommentiert/deaktiviert ist und die, um solche Ergebnisse zu vermeiden, eigentlich standardmäßig eingeschaltet sein sollte:

Einige oder viele Webserver, die ihre Inhalte mit PHP generieren, laufen leider in dieser Standardkonfiguration von PHP, sodass dann solche invaliden Ergebnisse wie Dein Code von oben erzeugt werden. Warum diese Zeile standardmäßig deaktiviert ist statt aktiviert (bzw. das Verhalten standardmäßig nicht einfach umgedreht ist), ist mir -- da diese Standardeinstellung am laufenden Band wegen so einer kleinen Fitzelsache invalide Dokumente erzeugt -- bis heute ein Rätsel.

Müsste ich mal bei Google selber nachschauen, wie die das ausliefern. Eigentlich sollten sie das maskiert ausliefern und zum Kopieren und Weiterverwenden anbieten. Kommt drauf an, wo Du obige Code-Zeile rauskopiert hast.

dom_beta:

Wenn Du's nochmal etwas genauer in der Spezifikation bzw. beim W3C nachlesen willst (hier mal eine kleine Auswahl auf die Schnelle rausgesucht):

IETF: RFC 1738 -- Uniform Resource Locators (URL) , Abschnitt 2.2. URL Character Encoding Issues (en)
W3C: XHTML 1.0: C.12. Using Ampersands in Attribute Values (and Elsewhere) (en)
W3C: XHTML 1.0: C.12. Die Verwendung von et-Zeichen in Attributwerten (und anderswo) (de)
W3C: HTML 4.01: 5.3.2 Character entity references (en)
W3C: HTML 4.01: 5.3.2 Zeichen-Entity-Referenzen (de)
W3C: Using character escapes in markup and CSS (en)
W3C: Verwendung von Zeichen-Escapes in Markup und CSS (de)

Ich hab's schon hingekriegt. Ich habe hinter dem & einfach ein ; gesetzt, jetzt akzeptiert er dies als gültig.



Ich verwende kein PHP.

PS: Danke für die Links.

dom_beta:

Nicht Fuddeln! Mach's bitte korrekt und nicht irgendwie dahingefuddelt. Also "&" mit &amp; maskieren bzw. dafür die korrekte Entität verwenden. Sonst wunderst Du Dich später ggf. an anderer Stelle, dass irgendwas nicht hinhaut und kommst dann wieder hier angetrabt...
Eine leere oder verkürzte Entität à la "&;" ist meines Wissens in keiner DTD und keiner Entität-Tabelle definiert und deshalb und generell nicht zulässig.

Validiere dasselbe Dokument mal spaßeshalber gegen XHTML 1.0 Strict (kann man ja im Validator einstellen, die Einstellung überschreibt dann den Doctype im Dokument), da wird Dir dann meiner Ansicht nach völlig zurecht auch beispielsweise folgender Fehler ausgespuckt, wenn Du an der Stelle testeweise mal "&;" schreibst statt "&amp;":

XHTML 1.0 ist lediglich eine Umformulierung von HTML 4 in die XML-Schreibweise. Hat also als auch dieselbe Entity-Definition wie HTML 4.01. Wird das Dokument als "text/html" geparst, so parst das der SGML-Parser (wie bei HTML4); wird's als "application/xhtml+xml" oder "application/xml" oder "text/xml" geparst, dann kommt nicht der SGML-Parser (wie bei HTML4) zum Einsatz, sondern der XML-Parser.

Da muss ich mal umgehend Ville oder Olivier fragen, ob das nicht evtl. ein Fehler im Validator ist, wenn er "&;" beim Validieren gegen die HTML4-Strict-DTD einfach so durchgehen lässt (das darf meiner Ansicht nicht sein) und beim Validieren mit dem selben SGML-Parser und gegen die XHTML-Strict-DTD (und damit auch derselben Entity-Definitionsliste wie der von HTML4) erwartungsgemäß und richtigerweise einen Fehler moniert.

dom_beta:

Ich bekräftie an dieser Stelle nochmals meine Aussage von 20.04.11 16:04 Uhr.
Möglicherweise (bzw. inzwischen wohl sehr wahrscheinlich, da ich mich inzwischen mit verschiedenen Leuten um Umfeld des Validators und der HTML WG ausgetauscht habe und die alle unisono sich meiner Meinung anschließen und meine Sichtweise und Interpretation stützen und bekräftigen) wird Deine verkürzte Schreibweise "&;" fälschlicherweise vom Validator moniert. Möglicherweise ein Bug des Validators, der gefixt gehört. Ich kläre das noch ab. Validiert man solchen Code als XHTML 1.0, wird zurecht und erwartungsgemäß ein Fehler ausgeworfen. Validiert man solchen Code gegen HTML5 (und dessen eigenen Parser), so wird ein zurecht und erwartungsgemäß ein Fehler ausgeworfen. Warum das beim Validieren gegen HTML 4.01 nicht geschieht und er sowas als valide ansieht, das wird zur Zeit geklärt. Wenn ich mehr weiß, gebe ich Dir nochmal Bescheid.

Bezüglich XML sieht die normative Definition eines Entities so aus: bzw. . Die Schreibweise "&;" ist somit auf keinen Fall gültig! Die Frage ist, ob's in SGML anders ist oder aus irgendeinem Grund tolerabler gehandhabt werden kann. Ich vermute mal, nein. Denn sonst würde das Parsen gegen XHTML 1.0 Strict auf Basis des SGML-Parsers (der wird automatisch zugrundegelegt, wenn XHTML als text/html geparst wird und keinen XML-Mimetype à la application/xhtml+xml oder */xml hat) ebenfalls keinen Fehler auswerfen. Tut es aber. (Nicht nur) meiner Ansicht nach völlig zurecht.

Hallo,

es gibt ein Problem.

Der Firefox Browser zeigt das zwar an, allerdings nicht der Internet Explorer 8 unter Windows XP sowie Internet Explorer 9 unter Windows 7.

Gibt es eine Möglichkeit, den Code IE8 / 9 kompatibel zu machen?


MfG

Auf die Schnelle -- vielleicht steht da ja was Brauchbares für Dich drin:

Microsoft msdn: HTML Enhancements in Internet Explorer 8
Microsoft msdn: HTML Enhancements in Internet Explorer 8 - Using Object Elements to Display Images
Microsoft msdn: HTML Enhancements in Internet Explorer 8 - Improved Object Fallback

Microsoft msdn:

Q: The object element will not load Web pages from different domains
A: http://msdn.microsoft.com/en-us/library/ms535859(VS.85).aspx#ctl00_MTContentSelector1_mainContentContainer_ctl08

Microsoft msdn: OBJECT Element | object Object