html 4.01 oder 5 verwenden ?
0 
niklaskamenisch
0 0 0
1 
Gunnar Bittersmann
0 0 molily
0 0 Gunnar Bittersmann
0
0 niklaskamenisch
0 
Matthias Apsel
html 4.01 oder 5 verwenden ?
MudGuardEinen schönen Tag den Experten,
ich komme zurück zu meiner Homepage
http://www.swiss-travel-hans.ch/index.de.html
(sie war zeitweilig nicht zugänglich, da mit einem Passwort serverseitig unabsichtlich geschützt)
und befasse mich mit den Vorschlägen von Matthias https://forum.selfhtml.org/?t=210471&m=1435172, um die Gestaltung à jour zu bringen.
(Andere Vorschläge habe ich erledigt, wie https://forum.selfhtml.org/?t=210471&m=1435176, um den Zugang zu Multiviews zu haben, und die korrekte Verlinkung zwischen den html-Dokumenten, auch die Speicherung unter UTF-8, damit die Umlaute nicht be- sonder geschrieben werden.)
Nun, bevor ich anfange zu basteln: soll ich mit html 4.01 oder 5 arbeiten?
A+
bari.
-
hi,
für den doctype kannst du einfach "html" nehmen, da alte browser das modernste dafür nehmen. Da tut dir html5 also nicht weg.
Anders sieht es dann bei den speziellen Unterstützungen aus. Manche Browser sind noch nicht html5 ready. Da ist die frage, ob dir das egal ist "ich hab nur moderne besucher" oder ob du eben auch die Windows 95-Rechner glücklich machen möchtest =P. Das hat dann aber nichts mit dem doctype sondern nur mit den funktionen/ Tags zutun. Da in HTML5 vieles genauer genommen wird (zumindest vom FF - ich sag nur inline-element IMG) wird das ganze bei html5 sauberer (meine Meinung), da man keine Definitionen vergisst.
Somit klares voting für html5!
Gruß Niklas
--
Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.-
danke für die raschen Antworten.
für den doctype kannst du einfach "html" nehmen, da alte browser das modernste dafür nehmen. Da tut dir html5 also nicht weg.
Anders sieht es dann bei den speziellen Unterstützungen aus. Manche Browser sind noch nicht html5 ready. Da ist die frage, ob dir das egal ist "ich hab nur moderne besucher" oder ob du eben auch die Windows 95-Rechner glücklich machen möchtest =P.
tendenziell eher "moderne" User, aber meine homepage richtet sich, nicht nur, aber auch an russisch-sprachige Leser, ich weiss es deshalb selbst nicht so recht.
Das hat dann aber nichts mit dem doctype sondern nur mit den funktionen/ Tags zutun. Da in HTML5 vieles genauer genommen wird (zumindest vom FF - ich sag nur inline-element IMG) wird das ganze bei html5 sauberer (meine Meinung), da man keine Definitionen vergisst.
Somit klares voting für html5!
ja, gut.
bestimmt à +,
bari.-
Da in HTML5 vieles genauer genommen wird [...]
i lol'd
-
Hi!
tendenziell eher "moderne" User, aber meine homepage richtet sich, nicht nur, aber auch an russisch-sprachige Leser, ich weiss es deshalb selbst nicht so recht.
Russland scheint gar nicht so schlimm zu sein, nur China ist pöse™.
Viele Grüße,
Alexander-
Om nah hoo pez nyeetz, Alex!
Russland scheint gar nicht so schlimm zu sein, nur China ist pöse™.
und die vielen unbekannten. Nachdem in Afrika der ganze Elektronikschrott aus Deutschland landet, kann ich mir nicht vorstellen, dass der IE6 dort keine Rolle spielt.
Matthias
--
1/z ist kein Blatt Papier.
-
Nachdem in Afrika der ganze Elektronikschrott aus Deutschland landet, kann ich mir nicht vorstellen, dass der IE6 dort keine Rolle spielt.
Der spielt dort de facto keine Rolle - wenn interessiert die Software, wenn er grade am Lagerfeuer ein paar PCBs auskocht?
-
-
-
-
@@niklaskamenisch:
nuqneH
Das hat dann aber nichts mit dem doctype sondern nur mit den funktionen/ Tags zutun.
Um auch in alten IEs denen unbekannte Elemente zu stylen, gibt’s html5shim.js
Ansonsten gibt’s jede Menge Polyfills. Und natürlich progressive enhancement.
Da in HTML5 vieles genauer genommen wird (zumindest vom FF - ich sag nur inline-element IMG)
?? Worauf willst du hinaus?
Somit klares voting für html5!
Und ganz klar polyglott, IMHO. Also in XML-kompatibler Syntax.
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
Und ganz klar polyglott, IMHO. Also in XML-kompatibler Syntax.
Und mit einer kleinen serverseiten Verzweigung als application/xhtml+xmloder application/xml an Clients die das wollen - dazu lässt sich HTTP_ACCEPT befragen.
-
Und mit einer kleinen serverseiten Verzweigung als application/xhtml+xmloder application/xml an Clients die das wollen - dazu lässt sich HTTP_ACCEPT befragen.
Mit welchem Vorteil?
Mathias
-
Und mit einer kleinen serverseiten Verzweigung als application/xhtml+xmloder application/xml an Clients die das wollen - dazu lässt sich HTTP_ACCEPT befragen.
Mit welchem Vorteil?
Damits gleich auffällt, wenn man ungültiges XML ausliefert und "niemand" meckert, wenn man z.B. RDFa in seinen Dokumenten verwendet.
Rich Snippets sind z.B. reicht interessant für Online-Shops oder Tourismusseiten.
-
@@suit:
nuqneH
Damits gleich auffällt, wenn man ungültiges XML ausliefert und "niemand" meckert, wenn man z.B. RDFa in seinen Dokumenten verwendet.
Was hätte die Verwendung von RDFa mit Tagsoup-Syntax vs. polyglottem „HTML“ zu tun?
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
Was hätte die Verwendung von RDFa mit Tagsoup-Syntax vs. polyglottem „HTML“ zu tun?
Keine Tagsoup-Syntax - gültiges X(HT)ML an unfähige Browser einfachach als text/html schicken funktioniert einwandfrei.
-
@@suit:
nuqneH
Was hätte die Verwendung von RDFa mit Tagsoup-Syntax vs. polyglottem „HTML“ zu tun?
Keine Tagsoup-Syntax - gültiges X(HT)ML an unfähige Browser einfachach als text/html schicken funktioniert einwandfrei.
Natürlich tut es das. Aber was hat das mit RDFa zu tun?
Qapla'
--
Wer möchte nicht lieber durch Glück dümmer als durch Schaden klüger werden? (Salvador Dalí)-
Natürlich tut es das. Aber was hat das mit RDFa zu tun?
Beim verarbeiten von Tagsoup + RDFa wird sich ein XML-Parser schwer tun - ich gehe zwar davon aus, dass das Google ziemlich egal sein wird, aber wie das z.B. mit Dienstleistern wie Trivago aussieht, kann ist schwer zu sagen - darum ist gültiges XML immer schlauer.
-
-
-
-
Damits gleich auffällt, wenn man ungültiges XML ausliefert
Erfahrungsgemäß fällt das dem Nutzer auf, zumindest bei einer dynamischen Site. Und eine Site mit 10 statischen Dokumenten kann man auch selbst validieren, dazu muss man des Nutzers Browser nicht herausfordern.
und "niemand" meckert, wenn man z.B. RDFa in seinen Dokumenten verwendet.
http://www.w3.org/TR/rdfa-in-html/
Mathias
-
und "niemand" meckert, wenn man z.B. RDFa in seinen Dokumenten verwendet.
Sag' das dem Validator :)
-
-
-
-
-
hi,
Da in HTML5 vieles genauer genommen wird (zumindest vom FF - ich sag nur inline-element IMG)
?? Worauf willst du hinaus?
Ganz einfach, in HTML4 kannst du ganz einfach das img auch für das Design nehmen ohne irgendwelche großen Anpassungen. Stellst du dann auf html5 um, wirst du merken, dass der FF das ganze als inline dar stellt und du unter dem Bild einen Abstand bekommen wirst. Kann man mit "display:block" beheben, ist aber eben eine Sache über die man unter anderem stolpern KANN.
Das Vieles mit JS nachgebaut werden kann, war logisch, dadrum gings im OT aber nicht!
Gruß Niklas
--
Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.-
Hallo,
Ganz einfach, in HTML4 kannst du ganz einfach das img auch für das Design nehmen ohne irgendwelche großen Anpassungen. Stellst du dann auf html5 um, wirst du merken, dass der FF das ganze als inline dar stellt und du unter dem Bild einen Abstand bekommen wirst. Kann man mit "display:block" beheben, ist aber eben eine Sache über die man unter anderem stolpern KANN.
Das ist Unsinn. Bilder waren schon immer Inline-Elemente (deshalb ist auch vertical-align eine Lösung).
Der einzige Unterschied zu vorher ist, dass die Autoren durch den HTML5-Doctype in den Full-Standards-Mode gezwungen werden. Das wäre auch bei HTML 4.01 Strict, XHTML 1.0 Strict oder XHTML 1.1 der Fall.
Das sind aber Standards, die bisher nur von einer vernachlässigbaren Anzahl von Autoren ernsthaft verwendet wurde. Die meisten Autoren haben das (mehr oder weniger) unzulässige (X)HTML Transitonal verwendet, das in den Browsern nur den Almost-Standards-Mode aktiviert.
Gruß, Daniel
-
hi,
Das ist Unsinn. Bilder waren schon immer Inline-Elemente (deshalb ist auch vertical-align eine Lösung).
Der einzige Unterschied zu vorher ist, dass die Autoren durch den HTML5-Doctype in den Full-Standards-Mode gezwungen werden. Das wäre auch bei HTML 4.01 Strict, XHTML 1.0 Strict oder XHTML 1.1 der Fall.
Das sind aber Standards, die bisher nur von einer vernachlässigbaren Anzahl von Autoren ernsthaft verwendet wurde. Die meisten Autoren haben das (mehr oder weniger) unzulässige (X)HTML Transitonal verwendet, das in den Browsern nur den Almost-Standards-Mode aktiviert.
ich habe auch nicht behauptet, dass sie es davor nicht waren!
das es am Strict usw. hing, war mir bisher nicht bekannt =)
Geht mir auch überhaupt nicht um details, sondern darum, DASS es unterschiede gibt bzw. geben KANN.Gruß Niklas
--
Man muss nicht alles wissen, man sollte aber wissen, wo das nicht gewusste zu finden ist.
-
-
Ganz einfach, in HTML4 kannst du ganz einfach das img auch für das Design nehmen ohne irgendwelche großen Anpassungen.
img-Elemente für Gestaltungszwecke zu verwenden ist in HTML 4.01 und HTML5 dämlich ;)
Stellst du dann auf html5 um, wirst du merken, dass der FF das ganze als inline dar stellt und du unter dem Bild einen Abstand bekommen wirst.
In den Firefox-Default-Stylesheets wird weder in html.css noch in quirk.css irgend eine Unterscheidung zwischen HTML 4.01 und HTML5 hinsichtlich der Bilder getroffen - da steht einfach "nichts" diesbezüglich drin, drum sollten alle Bilder einfach nur inline sein.
Kann man mit "display:block" beheben, ist aber eben eine Sache über die man unter anderem stolpern KANN.
img-Elemente haben in HTML 4.01 kein definiertes content model und in HTML5 kein definierten Gestaltungsregeln:
http://www.w3.org/TR/html4/sgml/dtd.html
<!ELEMENT IMG - O EMPTY -- Embedded image -->
-
Hi,
img-Elemente haben in HTML 4.01 kein definiertes content model
DOCH, das content model für img ist sehr klar definiert:
<!ELEMENT IMG - O EMPTY -- Embedded image -->
Das content model steht doch soger in dem von Dir zitierten Teil: EMPTY
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
Das content model steht doch soger in dem von Dir zitierten Teil: EMPTY
HTML 4.01 kennt nur %block, %inline und "nix" :) EMPTY ist nix
-
Hi,
Das content model steht doch soger in dem von Dir zitierten Teil: EMPTY
HTML 4.01 kennt nur %block, %inline und "nix" :) EMPTY ist nix
Aha. Seltsame Meinung ...
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-
-
-
-
-
-
Om nah hoo pez nyeetz, bari!
Nun, bevor ich anfange zu basteln: soll ich mit html 4.01 oder 5 arbeiten?
5
Wenn du ältere Browser berücksichtigen willst (IE < 9) musst die eine Javascript-Lösung basteln z.B. http://blog.weblogie.de/webentwicklung/html-5-tags-browserubergreifend-integrieren. Dafür gibt es auch fertige Scripte.
Matthias
--
1/z ist kein Blatt Papier.
-
Grüße dich, Matthias,
Wenn du ältere Browser berücksichtigen willst (IE < 9) musst die eine Javascript-Lösung basteln z.B. http://blog.weblogie.de/webentwicklung/html-5-tags-browserubergreifend-integrieren. Dafür gibt es auch fertige Scripte.
Ich bin da ganz deiner Meinung.
Allerdings hatte ich kürzlich den Fall "IE8 ohne JavaScript". Ich habe dann auf die neuen Elemente verzichtet.
Mich würde dein Standpunkt zu dieser Problematik interessieren. Immerhin handelt es sich bei dieser Methode nicht um "unobtrusive JS".Gruß, Daniel.
-
Om nah hoo pez nyeetz, Daniel.S!
Allerdings hatte ich kürzlich den Fall "IE8 ohne JavaScript". Ich habe dann auf die neuen Elemente verzichtet.
Mich würde dein Standpunkt zu dieser Problematik interessieren. Immerhin handelt es sich bei dieser Methode nicht um "unobtrusive JS".Ich trau mich es fast nicht zu sagen: Ich bin nicht von Wohl und Wehe eines Auftraggebers abhängig. Meine Projekte sind alle in 4.01 umgesetzt. Meine nächste Idee soll HTML5 werden, auch bzw. gerade weil in diesem Projekt nicht auf JS verzichtet werden kann (http://billiger-im-urlaub.de/test/, unvollständig, noch keine SMS-Funktionalität, bitte nicht verlinken, Feedback willkommen). In solchen Fällem verwende ich ein formatiertes noscript-Element. Stünde ich vor dem Problem auch alte Browser ohne JS unterstützen zu müssen, würde ich auf HTML5 verzichten.
Matthias
--
1/z ist kein Blatt Papier.
-
-