"Ältere" Befehle
0 0 0 0 
niklaskamenisch
0
0
0 0
"Ältere" Befehle
Hallo zusammen,
es gibt ja noch ältere html Editoren, die html Kommandos "produzieren", die heute wohl nicht mehr genutzt werden sollen, bsp. <font face>. Trozdem laufen die Seiten prima in Browsern.
Abgesehen davon, das es viele Gründe gibt, die dagegensprechen, aber solange es Browser gibt, die solche Tags darstellen kann man Sie doch eigentlich auch verwenden.
Viele nutzen Software, die vielleicht noch mit Visual Basic6 programmiert ist, ohne zu sagen "oh gott das ist veraltet". Im Webbereich, aber ist das anders.
Natürlich sind Tabellen als Designgrundlage Mist und CSS bietet unendliche Möglichkeiten. Manchmal aber hat man mit seinem liebgewonnenen wysiwyg Editor schnell ein Ergebnis produzieren.
Wie gesagt mir geht es jetzt nicht so sehr darum, das ich unbedingt html Code produzieren will, der 1999 "in" war, sondern um die Frage, wann solche html Codes aus den Browsern entnommen werden. Denn bislang wird ja jeder Browser immer "größer", weil neue Tags dazukommen, die alten aber drinnenbleiben.
Vielleicht sollte es im html Bereich so sein wie im Windows Bereich...Irgendwann läuft die alte Software einfach nicht mehr.
-
Wie gesagt mir geht es jetzt nicht so sehr darum, das ich unbedingt html Code produzieren will, der 1999 "in" war, sondern um die Frage, wann solche html Codes aus den Browsern entnommen werden. Denn bislang wird ja jeder Browser immer "größer", weil neue Tags dazukommen, die alten aber drinnenbleiben.
Das kann jederzeit passieren - entsprechende Dinge sind schon länger als "deprecated" markiert - das bedeutet in der Softwareentwicklung allgemein, dass solche Features ohne Vorwahrung einfach mal rausfliegen können und sich die Entwickler drauf vorbereiten können. Das kann eine Version später sein oder auch "nie" sein. In manchen Fällen kommt auch irgend ein Pfosten auf die Idee bereits als deprecated markierte Elemente doch wieder zu unterstützen - so in HTML5, wo die formatierungsbezogenen Markup-Elemente wie etwa b oder i einfach umdefiniert wurden. Das bricht die Abwärtskompatiblität und verwirrt fachkundige Entwickler - gemacht wurde es aber trotzdem.
Vielleicht sollte es im html Bereich so sein wie im Windows Bereich...Irgendwann läuft die alte Software einfach nicht mehr.
Ja - wobei es in HTML klar definierte Regeln gibt, wie "unbekantes Markup" handzuhaben ist :)
-
Hallo,
In manchen Fällen kommt auch irgend ein Pfosten auf die Idee bereits als deprecated markierte Elemente doch wieder zu unterstützen - so in HTML5, wo die formatierungsbezogenen Markup-Elemente wie etwa b oder i einfach umdefiniert wurden. Das bricht die Abwärtskompatiblität und verwirrt fachkundige Entwickler - gemacht wurde es aber trotzdem.
b und i waren nie deprecated. Abwärtskompatibilität wird in der Regel immer zum Teil gebrochen, wenn eine neue Version von etwas erscheint.
Gruß, Daniel
-
b und i waren nie deprecated.
Du hast ja recht, hatte das Falsch im Kopf :)
http://www.w3.org/TR/html401/index/elements.htmlAbwärtskompatibilität wird in der Regel immer zum Teil gebrochen, wenn eine neue Version von etwas erscheint.
Die Kompatiblität sollte man bestmöglich beibehalten und es möglichst vermeiden irgendwas komplett umzudefinieren.
-
Solange man alles gleich lässt passiert ja nichts. Wenn man aber eine Sache erneuert, dann zieht das eben vieles hinterher.
Neuer Browser => Probleme mit der Webseite wenn diese nicht mitzieht.
Neue Webseite => Problem mit den Benutzern alter Browser.Den neuesten Standart kann man sicher nicht als das beste ansehen, da die browser noch zu alt sind dafür.
Ich halte mich aktuell an den Standart der ab IE6 möglich ist. Je nach Zielgruppe darfs aber natürlich auch mal extrem CSS3 und HTML5 sein. Junge leute haben meist aktuelleres!
-
Ich halte mich aktuell an den Standart der ab IE6 möglich ist. Je nach Zielgruppe darfs aber natürlich auch mal extrem CSS3 und HTML5 sein. Junge leute haben meist aktuelleres!
Die Standart des IE6 ist momentan recht niedrig. Er steht bei ca. 0,7% Marktanteil in Deutschland. Siehe http://www.ie6countdown.com
Es ist daher nicht verkehrt, sich zumindest an die Standardunterstützung von IE7 (oder wie ich empfehle IE8) anzupassen :)
-
Standart
Standart
Macht mich nicht beide schwach :)
-
Standart
Standart
Macht mich nicht beide schwach :)
Ist dir nicht aufgefallen, dass ich tatsächlich die Standart und nicht den Standard meinte? ;-)
-
Ist dir nicht aufgefallen, dass ich tatsächlich die Standart und nicht den Standard meinte? ;-)
Nein, ich dachte ich hab's wieder mit zwei Preißn zu tun die weder Standard richtig schreiben noch Artikel korrekt anwenden können :D
-
-
-
-
-
Abwärtskompatibilität wird in der Regel immer zum Teil gebrochen, wenn eine neue Version von etwas erscheint.
Die Kompatiblität sollte man bestmöglich beibehalten und es möglichst vermeiden irgendwas komplett umzudefinieren.
Das widerspricht sich ja zum Glück nicht :)
-
-
-
-
Hallo dzallik,
es gibt ja noch ältere html Editoren, die html Kommandos "produzieren", die heute wohl nicht mehr genutzt werden sollen, bsp. <font face>. Trozdem laufen die Seiten prima in Browsern.
font ist ein veraltetes Element.
Browser sind rückwärtskompatibel so gut sie können, d.h. auch Kram aus der Entstehungszeit des Webs wird teilweise noch verarbeitet (z.B. das image-Element).
Abgesehen davon, das es viele Gründe gibt, die dagegensprechen, aber solange es Browser gibt, die solche Tags darstellen kann man Sie doch eigentlich auch verwenden.
Man kann auch aus dem Fenster springen, dennoch ist es eine eher schlechte Idee.
Der Sinn der Rückwärtskompatibilität besteht darin, altes weiterhin darstellen zu können ohne dass dafür ein extra Modus oder ein Extra Programm benötigt wird.
Das alte gilt aber gerade deswegen als missbilligt (und ist in den modernen Spezifikationen daher auch verboten), weil es bessere Lösungsansätze gibt.
Viele nutzen Software, die vielleicht noch mit Visual Basic6 programmiert ist, ohne zu sagen "oh gott das ist veraltet". Im Webbereich, aber ist das anders.
Aus Sicht der Benutzer sagt niemand etwas. Schau dich in ein paar Unternehmen um.
Aus Autorensicht kann man lediglich sagen ob Code effizient und sauber ist oder nicht. Darstellungsbezogene Attribute und Elemente sind ineffizient und unsauber.
Natürlich sind Tabellen als Designgrundlage Mist und CSS bietet unendliche Möglichkeiten. Manchmal aber hat man mit seinem liebgewonnenen wysiwyg Editor schnell ein Ergebnis produzieren.
Wer mit CSS kein schnelles Ergebnis produzieren kann ist unfähig mit CSS umzugehen.
Wie gesagt mir geht es jetzt nicht so sehr darum, das ich unbedingt html Code produzieren will, der 1999 "in" war, sondern um die Frage, wann solche html Codes aus den Browsern entnommen werden. Denn bislang wird ja jeder Browser immer "größer", weil neue Tags dazukommen, die alten aber drinnenbleiben.
Fast alles, was heute in einem Webbrowser funktioniert, wird auch in 10 Jahren noch funktionieren. Davon Ausgenommen sind proprietäre Funktionen (z.B. Conditional Comments, herstellerspezifisches CSS, etc.)
Vielleicht sollte es im html Bereich so sein wie im Windows Bereich...Irgendwann läuft die alte Software einfach nicht mehr.
Die aktuelle Zielsetzung lautet, dass so viel wie möglich so lange wie möglich unterstützt werden soll, mit einem gmeinsamen Nenner versteht sich.
Gruß, Daniel
-
Hi,
Wie gesagt mir geht es [...] um die Frage, wann solche html Codes aus den Browsern entnommen werden. Denn bislang wird ja jeder Browser immer "größer", weil neue Tags dazukommen, die alten aber drinnenbleiben.
wenn sie (quasi) keiner mehr benutzt. *Auch* darum sollte man diese veralteten Elemente (nicht Befehle) unter allen Umständen meiden - andernfalls wird man sie nämlich nie los. Das ist vergleichbar damit, dass heute neben dem Euro noch die D-Mark akzeptiert würde. Und die Reichsmark. Und die Rentenmark. Und die Alliierte Militärmark. Und die Mark. Und die Ostmark. Und der Heller, der Silberling, die Ziege und die Miesmuschelschale. Eines weiß ich sicher:
Kassierer möchte ich dann nicht sein.
Vielleicht sollte es im html Bereich so sein wie im Windows Bereich...Irgendwann läuft die alte Software einfach nicht mehr.
Für uns Entwickler wäre das gut. Für den Internet-Surfer nicht[1], und somit auch nicht für den Browser-Hersteller.
Cheatah
[1] Bzw. nur langfristig, jedenfalls nicht direkt.
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes