Wie legen ich das DOCTYPE für eine Website fest?

Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Forum>Entwickler>Wie legen ich das DOCTYPE für eine Website fest?

barbagianni28.08.0914:42

Wie legen ich das DOCTYPE für eine Website fest?

Auf welche Basis wird ein DOCTYPE definiert? ich habe ein Website mit Dreamweaver HTML4 bzw PHP geschrieben. Aber wenn ich den Test http://www.htmlhelp.com bzw. hier http://validator.w3.org durchführe kommt folgendes:

Error Line 1, Column 1: no document type declaration; will parse without validation

The document type could not be determined, because the document had no correct DOCTYPE declaration. The document does not look like HTML, therefore automatic fallback could not be performed, and the document was only checked against basic markup syntax.

Kommentare

pbr28.08.0914:46

http://lmgtfy.com/?q=doctype+declaration

Stranger28.08.0914:58

http://www.w3schools.com/tags/tag_DOCTYPE.asp

sierkb28.08.0915:22

W3C QA: Recommended DTDs to use in your Web document

Bzgl. des kommenden HTML 5 bzw. XHTML 5 wird der Doctype deutlich schlichter und einfacher zu merken sein: . Also schlicht: <!DOCTYPE html>
Aber das nur am Rande.

barbagianni28.08.0915:44

Ok, vielen dank für die Link.
Ich habe verstanden dass es ein kompliziertes Thema ist.
Jetzt habe ich es aber hin gekriegt.

nachdem ich das

<........... charset=iso-8859-1"> (so war es uhrsprunglich im Code drin!)

in

<........... charset=UTF-8"> geändert habe, will mir das W3C nicht mehr die Seite durch checken.

Ich dachte mit UTF-8 deutet mach darauf hin dass es in der Seite auch Umlaute und Sonderzeichen in Text gibt.

Stimmt es nicht?
Soll ich vielleicht jetzt alle Sonderzeichen andere schreiben?

Ich habe z.B. im Code "können" geschrieben und nicht "können", oder "für" und nicht "für".

ex_apple_user_neu28.08.0915:46

http://de.selfhtml.org/ (leider nicht mehr ganz aktuell, aber immer noch sehr gut für die Grundlagen.

MAch es am einfachsten so ohne Verstand:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

Stranger28.08.0915:52

Also ich nuzte:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

und hab nie Probleme mit dem Validator...

barbagianni28.08.0915:53

) ich hatte genau so: einfach "ohne Verstand" gemacht.

Aber mit bleibt das problem mit dem UTF-8 Warum will das W3C die seite nicht durchchecken?

barbagianni28.08.0915:58

Stranger

Aber mit XHTML muss ich die "/" überall einfügen.... wenn du weiss was ich meine.

Wie in deinem meta http-equiv ...... charteset=UTF-8" />

Stranger28.08.0916:23

Nein, das musst du nur bei tags die sich auch gleich selber schließen.

zB.: <hr /> <br /> <img /> <meta />

sonst hast du ja immer einen start- und end-tag

zB: <head> </head> <div> </div>

Viel einfacher wäre es du fügst uns einfach mal den Code vom Anfang ein.

sierkb28.08.0916:30

Aber mit XHTML muss ich die "/" überall einfügen.... wenn du weiss was ich meine.

Oder Du verwendest einfach HTML 4.01, gibst dem Ganzen dann auch den zugehörigen Doctype von HTML 4.01, und Du kannst Dir dann diese Besonderheiten bzgl. XHTML sparen.

XHTML 1.0 ist eh nur eine Umformulierung von HTML 4.01 in XML-Schreibweise. Außer dem Doctype und der Schreibweise bzgl. der geschlossenen leeren Elemente (Stranger hat sie bereits genannt), gibt es da keine Unterschiede.
Und wenn Du mit dem Verstehen und Durchdringen von XHTML Schwierigkeiten hast, dann bleib' ganz einfach bei HTML 4.01.

Lieber ein ordentliches HTML 4.01-Dokument, das validiert und das Du verstehst als ein unordentliches XHTML-Dokument, das nicht validiert und das Du nicht verstehst.

sierkb28.08.0916:35

Stranger:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

und hab nie Probleme mit dem Validator...

Und warum nimmst Du nicht gleich die Strict-Variante?
Was für alte, missbilligte HTML-Elemente verwendest Du denn mit Absicht, sodass die Transitional-DTD zwingend notwendig ist?

HTMl 4.01 wie auch XHTML 1.0 ist, wenn man streng nur die Elemente verwendet, die nicht veraltet bzw. missbilligt sind, immer Strict. Also kann man dann auch die Strict-DTD verwenden.

XHTML 1.1 unterscheidet zum Beispiel da gar nicht mehr. Das ist immer Strict. Weil da im Sprachschatz von XHTML 1.1 alle in HTML 4.01 und XHTML 1.0 missbilligten Elemente alle rausgeflogen sind. Wenn man sie aus irgendwelchen Gründen trotzdem verwenden will oder muss, ist es kein XHTML 1.1 mehr, sondern meinetwegen XHTML 1.0 Transitional oder HTML 4.01 Transitional.

Und man kann auf diese bereits in HTML 4.01 missbilligten Elemente GUT verzichten, ohne Einbußen zu haben. Die meisten wissen nur nix davon, dass dem so ist.

Stranger28.08.0916:54

Ich nutze häufige bei <input> Elementen das Attribut "autocomplete", was ja deprecated ist.

Außerdem fühl ich mich mit "Transitional" wohler, das ist jetzt aber kein Argument, sondern nur eine persönliche Einstellungen und Gewohnheit.

sierkb28.08.0917:20

Stranger

Ich nutze häufige bei <input> Elementen das Attribut "autocomplete", was ja deprecated ist.

Wo ist "autocomplete" offizieller HTML-Standard?
Hier: finde ich es nicht, und hier: finde ich es auch nicht.
Weder für das input-Element noch für das form-Element (welches Du evtl. meinen könntest). Folglich ist in der HTML-Spezifikation auch nix von deprecated zu lesen.

Das vorliegende Attribut ist eine browserspezifische Erweiterung (bin mir gar nicht sicher, ob's überhaupt von allen Browsern unterstützt wird), die aber kein offizieller HTML-Standard ist und folglich auch nicht in der Spezifikation zu finden ist. Findest Du sogar bestätigt bei SelfHTML, da steht's auch so geschrieben. Folglich kann so ein Dokument auch niemals valide sein -- zumindest nicht, wenn's gegen den W3C HTML Markup Validator geprüft wird.
Oder irre ich?

Außerdem fühl ich mich mit "Transitional" wohler, das ist jetzt aber kein Argument, sondern nur eine persönliche Einstellungen und Gewohnheit.

Dir ist aber schon klar, dass der Browser, wenn er auf ein Transitional-Dokument trifft, das betreffende Dokument im sog. "Quirks"-Modus rendert und darstellt? Will heißen: er rät. Er rät, was Du gemeint haben könntest bzw. ordnet die Elemente so an, wie er es nach seiner Logik für korrekt hält.
Und nicht immer kommt dabei das raus, was Du beabsichtigt hast bzw. so mancher Ersteller fängt dann wie wild an, irgendwelche Tricks und Kniffe und Workarounds zu basteln, damit's so aussieht, wie er sich das vorgestellt hat.

Im Strict-Modus rendert der Browser das Dokument aber genau so, wie es vom Ersteller gedacht und definiert worden ist. Strict heißt dann: sehr streng.

So manches Tabellenkonstrukt von so mancher Website hat dem betreffenden Erbauer (unnötige) Kopfschmerzen bereitet, weil zum Beispiel im Transitinal-Modus Tabellen und deren inneren Abstände und Ränder von den Browsern (ich spreche jetzt mal von Firefox) anders und laxer gerendert und berechnet werden als im Strict-Modus. Man kann die Unterschiede an so mancher Stelle ganz schnell plastisch machen, indem man einfach mal eine Transitional-DTD gegen eine Strict-DTD austauscht und sich die Ergebnisse im Browser dann einfach mal anschaut und vergleicht. Manchmal sind die Unterschiede deutlich sichtbar, manchmal nicht.

In jedem Fall erwartet der Browser im Strict-Modus, dass ein Strict-Dokument wirklich strict ist und valide ist. Und dann rendert er das Dokument auch schneller und zügiger, weil nämlich nicht die interne Fehlerkorrektur des Browsers angeschmissen werden muss, die im Transitional-Modus ständig in Bereitschaft steht und dann eben bei Zweifeln einfach mal rät.

Deshalb: nach Möglichkeit immer Strict. Hat am Ende nur Vorteile. Für Dich als Ersteller (spart Dir an der einen oder anderen Stelle Blut, Schweiß und Tränen) und für den Betrachter der Webseite auch (weil er aufgrund des nicht notwendigen Eingreifens der browserinternen Fehlerkorrektur sie noch einen Tick schneller angezeigt bekommt, sind zwar nur Sekundenbruchteile, aber immerhin).

Stranger28.08.0918:33

ok, dann nehme ich alles zurück, man lernt nie aus

Ich werde trotzdem autocomplete als Attribut weiter nutzen, auch wenn deswegen die Seite nicht zu 100% valide sein sollte, außer ich mache meine eigne DTD.
Es ist einfach irgendwie vom Vorteil, die Autocomplete-Funktion vom Browser bei Loginfeldern zu unterbinden und ab ie6 hatte ich damit bei den gängigen Browsern (Safaro,Opera,Firefox,IE) keine Probleme damit, jeder von denen hat es untersützt, außerdem nutzt es Amazon auch.

Stranger28.08.0918:50

Warum geht denn die Edit-Funktion schon wieder nicht? Naja egal..

Wenn ich jetzt meine Dokument mit Strict XHTML 1.0 durchlaufen lasse, bekomme ich bei einem <a> tag, there is no attribute "target", was soll ich denn dann benutzen?

sierkb28.08.0919:48

Stranger:

Wenn ich jetzt meine Dokument mit Strict XHTML 1.0 durchlaufen lasse, bekomme ich bei einem <a> tag, there is no attribute "target", was soll ich denn dann benutzen?

Ist das target-Attribut Bestandteil von HTML 4.01 Strict? Nein. Und von XHTML 1.0 Strict? Nein.
Und von der jeweiligen Transitional-Variante? Ja.
Also?
Wenn Du also unbedingt die Strict-Variante nutzen willst, dann musst Du halt aufs target-Attribut verzichten (oder XHTML 1.1 plus dem entsprechendem Modul verwenden, wo das target-Attribut drin ist) bzw. überlegen, ob Du aufs target-Attribut verzichten kannst. In den meisten aller Fälle wird es sowieso nur gebraucht, um damit irgendwelche Frames zu referenzieren, und Frames sind seit langer Zeit eigentlich schon verpönt und out. Genau wegen Letzterem sind Frames und das target-Attribut auch nicht Bestandteil von HTML/XHTML Strict.

Und in der überwiegenden Zahl aller Fälle kann man auf Frames (bei neuen Projekten) verzichten bzw. sollte es aus vielerlei Gründen tun.
Und um Sprungmarken anzuspringen, bedient man sich des Fragmentbezeichner (#) bzw. der ID, die zudem nicht nur bei einem Anker (a) gesetzt werden kann, sondern prinzipiell bei jedem beliebigen HTML/XHTML-Element, dazu braucht man m kein target-Attribut und auch kein name-Attribut. Dazu sind IDs ideal.

Wenn Du also unbedingt aus Rückwärtskompatibilität angewiesen bist auf das target-Attribut und Frames verwendest, so kommst Du nicht umhin, für das Frameset selber eine Frameset-DTD zu verwenden und für alle anderen Dateien, die einzelne Frames innerhalb des Framsets ansteuern wollen, das target-Attribut zu nutzen. Für alle anderen Sprungmarken innerhalb eines Dokuments oder auch dokumentübergreifend erfüllt eine ID an entsprechender Stelle bzw. der zugehörige Fragmentbezeichner im anspringenden URL viel besser diesen Zweck, weil viel flexibler und viel mehr Möglichkeiten.

Siehe dazu auch der entsprechende Abschnitt in der Spezifikation von XHTML 1.0 : und .

Ich habe seit Jahren schon keine Transitional-DTD mehr verwenden müssen und bin immer mit der Strict-DTD gut zurandegekommen.

bmc desgin28.08.0922:56

Naja, das Attribute macht aber dennoch Sinn...

Man muss ja nicht immer ein Script schreiben, nur um einen Link in einem neuen Fenster öffnen zu lassen, oder?

Dieses ganze xhtml ist sowieso Quatsch mit Soße.

Cheers

„Ask your questions...“

sierkb29.08.0914:49

bmc desgin

Man muss ja nicht immer ein Script schreiben, nur um einen Link in einem neuen Fenster öffnen zu lassen, oder?

Ist in nicht immer sinnvoll, das zu tun (wenn man sich mal in den gemeinen, völlig unerfahrenen Nutzer hineinversetzt), und deshalb gilt es auch als "deprecated". Abgesehen davon soll's dafür eigentlich auch eine entsprechende CSS-Anweisung geben (die zwar im Entwurf von CSS3 bereits existiert, von den Browser-Herstellern bisher aber nicht umgesetzt worden ist).

Abgesehen davon wird das target-Attribut in HTML5 bzw. XHTML5 sehr wahrscheinlich wieder Einzug erhalten: .

Dieses ganze xhtml ist sowieso Quatsch mit Soße.

...sagen vor allem diejenigen, die es nie richtig verstanden und die die Vorteile davon nie wirklich verstanden und erfahren haben. Ein Vorteil davon ist nämlich unter anderem, dass, wenn als XML und mit dem korrekten XML-Mimetype application/xhtml+xml ausgeliefert, mehrere XML-Sprachen inline miteinander vermischt werden können. Z.B. inline-SVG in XHTML oder/und inline MathML (für Formeln zum Beispiel) eingebettet in XHTML etc.

Diese positiven Ansätze und Vorteile, die mit XHTML angedacht worden sind, werden übrigens auch im zukünftigen XHTML 5 (also der XHTML-Variante von HTML 5, abhängig vom verwendeten Namespace und Mimetype application/xhtml+xml) weitergeführt bzw. ausgebaut werden.

Das Thema XHTML wird Dich also noch eine ganze Weile begleiten bzw. so schnell wirst Du es nicht los, zumal die derzeitige XHTML2-Arbeitsgruppe ab Ende des Jahres zusätzlich noch ihre Know-How und ihre Erfahrungen zur derzeitigen HTML5-Arbeitsgruppe und zu HTML5/XHTML5 beisteuern wird.

Stranger29.08.0915:45

sierkb. Ich finds frech, dass du mir unterstellst, dass ich grundsätzlich mit Frames arbeite.

Wir nehmen einfach mal an, ich möchte mit XHTML 1.0 strict validieren und einen einen Link in einem neuen Fenster (Tab) öffnen lassen, wie mache ich das ohne Javascript?

sierkb29.08.0916:32

Stranger

sierkb. Ich finds frech, dass du mir unterstellst, dass ich grundsätzlich mit Frames arbeite.

Deinen entkräftigenden Smiley habe ich gesehen.
Zudem dürfte das noch der einzige stichhaltige Grund sein, das target-Attribut verwenden zu müssen.
Abgesehen von diesem von Dir genannten Grund:

und einen einen Link in einem neuen Fenster (Tab) öffnen lassen, wie mache ich das ohne Javascript?

Entweder so wie Du beschreibst (also mit JavaScript) oder eben unter zähneknirschender Nutzung der Transitional-DTD. Oder (theoretisch) mit der entsprechenden CSS3-Variante, die ebenfalls auch das Öffnen in neuen Tabs berücksichtigt. Diese Variante ist aber leider noch nicht zu Ende spezifiziert, intern nutzt aber bereits Firefox den Weg über CSS, um Links in neuen Tabs zu öffnen.

Im Allgemeinen wird aber abgeraten davon, vor den Augen des Nutzers immer irgendwelche zusätzlichen Fenster zu öffnen, weil den Nutzer das eigentlich nur verwirrt bzw. die Browser-Navigation (Vor- und Zurück-Buttons) außer Kraft setzt etc. Deshalb wird ein lineares Konzept insgesamt empfohlen und findet sich deshalb auch so in der Strict-Spezifikation von HTML 4/XHTML 1.x wieder nach dem Karma: "One Webpage, one URL".

In Zeiten von Tab-basierten Browsern ist das Konzept, für alle möglichen Dinge immer wieder ein neues Window aufzumachen, jedoch weitgehend überholt.

Die Diskrepanz zwischen Anspruch und Wirklichkeit ist der HTML-Arbeitsgruppe bzw. der WHATWG wohl bekannt, und deshalb wird's ja das target-Attribut in HTML5/XHTML5 auch wieder geben. Als Zugeständnis an diejenigen, die es unbedingt haben wollen und doch irgendwie benötigen. Und die Transitional-Varianten von HTML4.01 und XHTML 1.0 erlauben es ja auch noch und werden es auch in Zukunft noch erlauben. Nur solltest Du Dir eben auch der damit verbundenen (potentiellen oder auch ganz schnell spürbaren) Schwierigkeiten bewusst sein, wenn Du die Transitional-Variante wählst anstatt die Strict-Variante (letztere löst in den meisten Browsern den sog. "Full Standards"-Rendering-Modus aus). Den wichtigsten Nachteil mit den nicht selten spürbarsten Konsequenzen habe ich oben genannt, und der wird ganz wesentlich vom sog. Doctype-Switching bzw. Doctype-Sniffing beeinflusst bzw. getriggert, dessen sich die Browser-Hersteller (und zwar so ziemlich alle) seit längerem verschrieben haben. Das kann man verfluchen, doch leider sind das eben die gegebenen Fakten.

Siehe dazu auch: , ,

Stranger29.08.0917:57

Ja natürlich ist mir bewusst, dass User das nicht toll finden, wenn sich andauerend neue Fenster öffnen, aber ein Kunde findet es auch nicht toll, wenn ein externer Link seine Seite verschwindet lässt.

Hoffen wir einfach mal auf einen baldigen 100%igen CSS3 Support, was auch die Designer bei mir freuen würde, weil sie dann endlich ihre tollen Schriften einbinden könnten.

dom_beta30.08.0906:24

barbagianni

) ich hatte genau so: einfach "ohne Verstand" gemacht.

Aber mit bleibt das problem mit dem UTF-8 Warum will das W3C die seite nicht durchchecken?

sag mal, hast du die Datei auch als Unicode gespeichert? Wenn nein, dann kommt da nur Salat heraus.

„...“

Wie legen ich das DOCTYPE für eine Website fest?

Kommentare

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.