nicht angemeldet
Und das soll jetzt besser sein...?
0
Und das soll jetzt besser sein...?
Hallo,
also erst mal Danke für die konstruktiven Diskussionen der letzten Tage. Da es immer noch mein Ziel war xhtml 1.0 strict zu programmieren habe ich nach einer Lösung für mein targer Problem gesucht. Und wie heisst es so schön, viele Wege führen nach Rom. Und es gibt einen, den das W3C sogar akzeptiert, wobei ich jetzt aber zur Diskussion stellen würde ob das besser ist als direkt ein target im Source einzubinden:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../../resourcen/dtd/xhtml1-strict.dtd">
[...]
<script src="../../resourcen/scripte/scripte.js" type="text/javascript"></script>
[...]
<a class="c3" href="javascript:anzeige('../paragrafen/baunvo_01.html')">
[...]
Wobei der Inhalt von scripte.js folgendes ist:
function anzeige(URI) {
parent.anzeige.location.href=URI
}
Dann alles durch den Validator jagen und das Ergebnis bewundern:
Congratulations, this document validates as XHTML 1.0 Strict!
Meine Meinung: Das könnte man auch einfacher haben...
Gruss, Lars
-
Moin!
also erst mal Danke für die konstruktiven Diskussionen der letzten Tage. Da es immer noch mein Ziel war xhtml 1.0 strict zu programmieren habe ich nach einer Lösung für mein targer Problem gesucht.
Eine akademische Lösung für ein akademisches Ziel, wie ich hier mal anmerken möchte.
Und wie heisst es so schön, viele Wege führen nach Rom. Und es gibt einen, den das W3C sogar akzeptiert, wobei ich jetzt aber zur Diskussion stellen würde ob das besser ist als direkt ein target im Source einzubinden:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "../../resourcen/dtd/xhtml1-strict.dtd">
[...]
<script src="../../resourcen/scripte/scripte.js" type="text/javascript"></script>
[...]
<a class="c3" href="javascript:anzeige('../paragrafen/baunvo_01.html')">
[...]Wobei der Inhalt von scripte.js folgendes ist:
function anzeige(URI) {
parent.anzeige.location.href=URI
}Du programmierst augenscheinlich irgendwas mit Frames. Frames stehen (auch) auf der Abschußliste des W3C. Warum versuchst du also, XHTML 1.0 Strict zu schreiben, wenn du Frames benutzt?
Für die Seiten in Frames gibt es eine gute DTD: XHTML 1.0 Transitional. Die hat das W3C für alle diejenigen produziert, die noch "alte" Features von HTML benutzen wollen, sich aber schon mal an XML gewöhnen möchten.
Das Problem deiner Lösung ist nämlich auch, daß sie so garnicht kompatibel ist. Nicht kompatibel zu javascript-losen Browsern nämlich. Und genau das sollte doch vorrangiges Ziel der ganzen Seitenerstellung sein.
Ich würde sagen: Deine Lösung ist geschummelt. :)
Valides XHTML hättest du auch einfacher haben können - einfach die zu den Anforderungen des Dokuments passende DTD anbinden. ;)
- Sven Rautenberg
-
Du programmierst augenscheinlich irgendwas mit Frames. Frames stehen (auch) auf der Abschußliste des W3C. Warum versuchst du also, XHTML 1.0 Strict zu schreiben, wenn du Frames benutzt?
Weil ich das Problem darin sehe, das in Transitional auch Elemente enthalten sein dürfen, die wegfallen sollen. So kann man nicht mehr wirklich erkennen ob ein Dokument bis auf target sauber ist, d.h. z.B. das alles was man mit CSS erledigen kann per CSS erschlagen wurde, oder ob man (unbewusst) irgendwo ein Tag vergessen hat. Transitional sieht das nicht so locker, weil erlaubt. Und das würde ich gerne verhindern.
Für die Seiten in Frames gibt es eine gute DTD: XHTML 1.0 Transitional. Die hat das W3C für alle diejenigen produziert, die noch "alte" Features von HTML benutzen wollen, sich aber schon mal an XML gewöhnen möchten.
Eben, ich will ja die alten Features nicht benutzen. Nur scheint es ja keine Lösung dafür zu geben das eine Webseite in einen Bereich den Inhalt einer anderen nachladen kann. Das können aber Frames. Deshalb ist meiner Meinung nach die ganze DHTML und XHTML 1.1 Geschichte nicht wirklich in allen Punkten ein Fortschritt. Denn diese Varianten sorgen dafür das man bei gleichbleibenden Menues auf vielen Seiten das Rad immer neu erfinden muss. Das Problem habe ich z.B. bei dem Bestand, der vor meiner Zeit entstanden ist, der Webseite vom Lehrstuhl, an dem ich arbeite. Dort wurde die Navigation per Tabelle in jede HTML Seite eingefügt. Jetzt ergänze mal einen Menüpunkt oder nimm einen Weg (musste ich alles schon machen), dann ist man aber eine gute Zeit beschäftigt.
Das Problem deiner Lösung ist nämlich auch, daß sie so garnicht kompatibel ist. Nicht kompatibel zu javascript-losen Browsern nämlich. Und genau das sollte doch vorrangiges Ziel der ganzen Seitenerstellung sein.
Hmm, nicht wirklich. Denn ein Browser der nicht Javascript kann, kann auch nicht xhtml 1.0 sauber umsetzen, und mein Ziel ist es in xhtml 1.0 so sauber wie möglich zu schreiben. Noch nicht mal der IE 6.0 kann z.B. den hover Effekt komplett richtig darstellen. Ich habe ihn spasseshalber mal eingeschaltet, und bei manchen Links verschluckt er sich und zeigt nichts an, Opera aber sehr wohl. Tippfehler, etc, konnte ich nicht finden. Also mal wieder MS...
Ich würde sagen: Deine Lösung ist geschummelt. :)
Aber nur ein klein bischen O:)
Valides XHTML hättest du auch einfacher haben können - einfach die zu den Anforderungen des Dokuments passende DTD anbinden. ;)
s.o. Transitional ist irgendwie nicht mein Fall... :o)
Gruss, Lars
-
Moin nochmal!
Eben, ich will ja die alten Features nicht benutzen. Nur scheint es ja keine Lösung dafür zu geben das eine Webseite in einen Bereich den Inhalt einer anderen nachladen kann. Das können aber Frames. Deshalb ist meiner Meinung nach die ganze DHTML und XHTML 1.1 Geschichte nicht wirklich in allen Punkten ein Fortschritt. Denn diese Varianten sorgen dafür das man bei gleichbleibenden Menues auf vielen Seiten das Rad immer neu erfinden muss. Das Problem habe ich z.B. bei dem Bestand, der vor meiner Zeit entstanden ist, der Webseite vom Lehrstuhl, an dem ich arbeite. Dort wurde die Navigation per Tabelle in jede HTML Seite eingefügt. Jetzt ergänze mal einen Menüpunkt oder nimm einen Weg (musste ich alles schon machen), dann ist man aber eine gute Zeit beschäftigt.
Richtig. Aber das zeugt eigentlich nur davon, daß zur Verfügung stehende Techniken nicht genutzt werden. Es ist ja nun wirklich kein Problem (höchstens das des Aufwandes), Seiten so zu gestalten und dynamisch zusammensetzen zu lassen, daß man mit geringem Aufwand maximalen Erfolg hat. Also z.B. das Menü einer Einzelseite dynamisch dazuladen. Mit der passenden Serverfunktionalität kein Thema.
Und wenn der Webserver das nicht kann oder soll: Niemand wird daran gehindert, die dynamische Einbindung von Menüs vorher zu erledigen. Es gibt genug Tools, die bestehende HTML-Dateien nach speziellen Kommentaren durchforsten und andere HTML-Fragmente an diesen Stellen einsetzen. Änderungen am Fragment erfordern dann zwar, daß alle HTML-Dateien neu erstellt und hochgeladen werden, aber der Arbeitsaufwand ist gering.
Klar sagt sich das aus einer fernen Perspektive sehr leicht. Aber gerade mit CSS und vernünftig geschriebenem (X)HTML werden die Seiten ziemlich flexibel - der Schritt dorthin wird irgendwann fällig, und er kostet Zeit und dadurch auch Geld. Und danach spart er dann eine Menge Geld. Je eher also der Schritt, desto weniger Zeit und Geld wird für das alte System herausgeworfen und versandet praktisch. :)
Hmm, nicht wirklich. Denn ein Browser der nicht Javascript kann, kann auch nicht xhtml 1.0 sauber umsetzen, und mein Ziel ist es in xhtml 1.0 so sauber wie möglich zu schreiben.
Definiere "sauber umsetzen".
Lynx kann HTML. Und mit dem "Leerzeichen-XHTML" (<br />) kann jeder alte Browser was anfangen, obwohl es valide ist. Nur wenn Javascript-Links ins Spiel kommen, wird's kritisch.
Besser ist da, den Javascript-Code in den onclick-Eventhandler zu packen ("return false" nicht vergessen) und die aufzurufende Seite ins href. Mit der Angabe eines Targets wäre die Kompatibilität dann perfekt - aber das willst du ja nicht.
Es spricht übrigens nichts dagegen, die Seiten zu Testzwecken vorläufig als Strict zu deklarieren, die target-Fehlermeldungen zu ignorieren und dann auf transitional zurückzustufen. :)
- Sven Rautenberg
-
Moin allerseits,
ich kann überhaupt nicht nachvollziehen, was man nur gegen Frames haben kann. Ich finde daran nichts schlimmes - im Gegenteil. Ich halte sie für ein einfaches Mittel, die Darstellung in Bereiche, wie Titel, Menü, Sponsoren-leiste und Inhaltsfläche zu unterteilen.
Manchmal suche ich z.B. in selfhtml nach einem bestimmten Beispiel-code, der mehrere Tags oder Funktionen benutzt. Dann empfinde ich persönlich es ein wenig lästig, daß man von einer Befehlsbeschreibung oft recht weit zum Seitenanfang scrollen muß, um wieder zur Menüführung zu gelangen.
Klingt vielleicht nicht weiter spannend, aber wenn man eben alle die Befehle absucht, die - der Erinnerung nach - im Beispiel vorkamen, und man sich dann vielleicht auch noch bei einem - dem entscheidenden Befehl irrt, dann kann das schon ein paar mal scrollen bedeuten.
Was also ist z.B. gegen ein Menü-Frame einzuwenden?
Und überhaupt, es mag ja unschön sein, daß Netscape und MS so einen Browser-Krieg führen. Es mag ja Sinn machen, daß man das HTML, CSS und Javascript standardisiert - mag ja Sinn machen. Aber warum muß man da nun gleich bewährte Dinge verbieten oder als unerwünscht deklarieren?
Ich meine nur: ich kann kein Esperando. Grund: Ich bin dort noch nie gewesen. Und warum soll man eigentlich versuchen, W3C-strict zu schreiben, wer setzt denn diesen Browser ein?
Ich habe nur Netscape und IE, gut - Opera würde sicher noch Sinn machen oder vielleicht Lynx. Aber ich kenne keinen Strict-Browser der "Firma W3C". Und den wirds wohl auch nie geben. Und meine Kunden haben mich noch nie gefragt:
"Warum bringt denn der W3C-Validator soviele Fehlermeldungen."
und wenn ich denen das mit w3c erklären will, heißt es nur
"Ja, ja. Du machst das schon"
aber wenn sie die Seite sehen, dann muß sie meinen Kunden gefallen und nicht dem w3C-Validator. Sicher bin ich aus Eigenverantwortung bemüht, daß die Seite wenigstens überall lesbar ist. Aber wer schaut sich schon Seiten mit dem Validator an?
Oder habt Ihr schonmal ein Auto mit Hilfe des deutschen oder internationalen Normenwerkes (DIN oder ISO) begutachtet? Ich nicht, ich habe mich an anderen Dingen orientiert (Fahrbarkeit, Komfort, Ausstattung, Verbrauch, Platz).
Gruß,
Andreas-
Hi, Andreas
ich kann überhaupt nicht nachvollziehen, was man nur gegen Frames haben kann. Ich finde daran nichts schlimmes - im Gegenteil. Ich halte sie für ein einfaches Mittel, die Darstellung in Bereiche, wie Titel, Menü, Sponsoren-leiste und Inhaltsfläche zu unterteilen.
Frames sind nur auf den ersten Blick 'einfach'. Bei deinem Beispiel gibt es schon vier Frames. Warst du das mit der Vier-Frames-Frage? *scnr* Du weißt, was ich damit sagen will.
Manchmal suche ich z.B. in selfhtml nach einem bestimmten Beispiel-code, der mehrere Tags oder Funktionen benutzt. Dann empfinde ich persönlich es ein wenig lästig, daß man von einer Befehlsbeschreibung oft recht weit zum Seitenanfang scrollen muß, um wieder zur Menüführung zu gelangen.
[Pos 1] gibt es AFAIK auf allen Keyboards.
Klingt vielleicht nicht weiter spannend, aber wenn man eben alle die Befehle absucht, die - der Erinnerung nach - im Beispiel vorkamen, und man sich dann vielleicht auch noch bei einem - dem entscheidenden Befehl irrt, dann kann das schon ein paar mal scrollen bedeuten.
[Ctrl-F] (oder [F3]) ebenso.
Was also ist z.B. gegen ein Menü-Frame einzuwenden?
Nichts, wenn du es richtig machst und alle Eventualitäten bedenkst. Da kannst du allerdings gleich auf Frames verzichten, das macht schlussendlich weniger Arbeit und funktioniert _immer_.
Weiters hat position:fixed das Potential, Frames abzulösen, sobald es der SubStandard-Browser beherrscht.
Und überhaupt, es mag ja unschön sein, daß Netscape und MS so einen Browser-Krieg führen.
Die wahren Krieger sind die Freunde der Drachen und Wikinger, sag' ich dir :)
Es mag ja Sinn machen, daß man das HTML, CSS und Javascript standardisiert - mag ja Sinn machen. Aber warum muß man da nun gleich bewährte Dinge verbieten oder als unerwünscht deklarieren?
Du verwechselst 'bewährt' mit 'proprietär'. Zweiteres widerspricht Standards. Verbieten lässt sich leider nichts, aber 'unerwünscht' ist eindeutiger als lediglich eine 'Empfehlung'.
Ich meine nur: ich kann kein Esperando. Grund: Ich bin dort noch nie gewesen.
Dort war auch noch keiner *g*, aber im W3C-Land solltest du schon mal gewesen sein. Habe übrigens gerade http://www.8ung.at/w3c-trans-de/xhtml11/ entdeckt, eine deutsche Übersetzung zu XHTML1.1 [1]
Und warum soll man eigentlich versuchen, W3C-strict zu schreiben, wer setzt denn diesen Browser ein?
Die Codierung einer Seite kann als 'strict' definiert sein, es handelt sich nicht um einen Browser! http://www.google.com/search?q=strict+site%3Aw3.org
Ich habe nur Netscape und IE, gut - Opera würde sicher noch Sinn machen oder vielleicht Lynx. Aber ich kenne keinen Strict-Browser der "Firma W3C". Und den wirds wohl auch nie geben. Und meine Kunden haben mich noch nie gefragt:
Nochmal, es gibt keinen strict-Browser.
"Warum bringt denn der W3C-Validator soviele Fehlermeldungen."
Falsch, es muss heissen: Warum machst du so viele Fehler?
und wenn ich denen das mit w3c erklären will, heißt es nur
"Ja, ja. Du machst das schon"Will ich solche Kunden haben? :)
aber wenn sie die Seite sehen, dann muß sie meinen Kunden gefallen und nicht dem w3C-Validator.
Eine Seite funktioniert nicht, weil sie gefällt. Sie gefällt, weil sie funktioniert.
Sicher bin ich aus Eigenverantwortung bemüht, daß die Seite wenigstens überall lesbar ist. Aber wer schaut sich schon Seiten mit dem Validator an?
Vielleicht ein Kunde, weil eines deiner Produkte in seinem Browser auseinanderfällt?
Oder habt Ihr schonmal ein Auto mit Hilfe des deutschen oder internationalen Normenwerkes (DIN oder ISO) begutachtet? Ich nicht, ich habe mich an anderen Dingen orientiert (Fahrbarkeit, Komfort, Ausstattung, Verbrauch, Platz).
Wenn sich mein Auto nicht an Standards hält, kann ich den Hersteller verklagen. Bei Browsern klage ich zwar auch laufend, aber leider nicht vor Gericht.
Übrigens: Ich orientiere mich an dem, was ich durch die Scheiben sehe, und die sollten die Realität nicht interpretieren, sondern korrekt 'anzeigen'. Das setzt allerdings voraus, dass es in besagter Realität keine Fehler gibt, was in der Netzwelt derzeit nicht Realität ist. Pfff... nicht schlecht für die Uhrzeit *g*
LG Orlando
[1] Zitat: "Mit der Einführung der XHTML-Familie in Form von Modulen und Dokumenttypen hat das W3C geholfen, die Internet- Entwicklergemeinschaft weg von missgebildetem, nicht den Standards entsprechendem Markup in die Welt wohlgeformten, gültigen XMLs zu führen." Besser kann man es nicht ausdrücken.
-
Hi, Orlando
Frames sind nur auf den ersten Blick 'einfach'. Bei deinem Beispiel gibt es schon vier Frames. Warst du das mit der Vier-Frames-Frage? *scnr* Du weißt, was ich damit sagen will.
Das war ich nicht, das fand ich auch ziemlich wirr, eine Seite muß auch ein wenig Ruhe ausstrahlen. Soviel Geflimmer - naja.
Es mag ja Sinn machen, daß man das HTML, CSS und Javascript standardisiert - mag ja Sinn machen. Aber warum muß man da nun gleich bewährte Dinge verbieten oder als unerwünscht deklarieren?
Du verwechselst 'bewährt' mit 'proprietär'. Zweiteres widerspricht Standards.
Jain! Auch proprietäre Dinge können sich bewähren. Z.B. das GIF-Format der Firma Compuserve. Oder DXF von Autodesk's AutoCAD. Solche proprietären Definitionen werden dann oft zu Standards erklärt oder wenigstens als solche behandelt (sog. Quasistandards).
Übrigens meinte ich mit meinem Vergleich strict - Esperando, daß ein Standard noch lange keinen Sinn machen muß. Diese Sprache hat sich nie durchgesetzt und wird das auch nie schaffen, eben weil sie keiner "von Haus aus" lernt. Und strict nutzt auch kein Surfer, weil es keinen strict-Browser gibt, mit dem er bewußt "strict" surfen kann.
Und meine Kunden haben mich noch nie gefragt:
"Warum bringt denn der W3C-Validator soviele Fehlermeldungen."
Falsch, es muss heissen: Warum machst du so viele Fehler?Nein, sie sehen die Seite richtig, weil ich sie natürlich in erster Linie für ihren Browser schreibe. Dann erst schaue ich, ob die Seite auch in anderen funzt.
und wenn ich denen das mit w3c erklären will, heißt es nur
"Ja, ja. Du machst das schon"
Will ich solche Kunden haben? :)Ja! Weil, wenn jemand das w3c kennt und versteht worum es da geht, dann hat er 90%ig auch Ahnung von HTML und dann braucht er micht nicht. Nein, meine Kunden wissen, daß es HTML gibt und zu mehr Verständnis haben sie keine Zeit. Sie machen das, was sie können, und ich mach das was ich kann. Es geht auch nicht drum, Unwissenheit auszunutzen, sondern schlicht um Aufgabenteilung.
aber wenn sie die Seite sehen, dann muß sie meinen Kunden gefallen und nicht dem w3C-Validator.
Eine Seite funktioniert nicht, weil sie gefällt. Sie gefällt, weil sie funktioniert.Falsch und fälscher.
Richtig: Wenn eine Seite nicht funktioniert, dann gefällt sie nicht.
Richtig: Wenn eine Seite funktioniert, dann muß sie noch lange nicht gefallen.
Richtig: Wenn eine Seite gefällt, dann funzt sie UND das Layout ist passend gewählt. Doch wenn ich in den Layout-Möglichkeiten zu sehr eingeschränkt werde, kann die Seite nicht mehr gefallen.Sicher bin ich aus Eigenverantwortung bemüht, daß die Seite wenigstens überall lesbar ist. Aber wer schaut sich schon Seiten mit dem Validator an?
Vielleicht ein Kunde, weil eines deiner Produkte in seinem Browser auseinanderfällt?Bei keinem Kunden fällt meine Seite auseinander, wenn überhaupt, dann höchstens bei seinen Kunden. Ist natürlich nicht gewollt. Aber da sie ja bei meinem Kunden funzt, kann er dadurch die Schwierigkeit der Angelegenheit verstehen.
Oder habt Ihr schonmal ein Auto mit Hilfe des deutschen oder internationalen Normenwerkes (DIN oder ISO) begutachtet? Ich nicht, ich habe mich an anderen Dingen orientiert (Fahrbarkeit, Komfort, Ausstattung, Verbrauch, Platz).
Wenn sich mein Auto nicht an Standards hält, kann ich den Hersteller verklagen. Bei Browsern klage ich zwar auch laufend, aber leider nicht vor Gericht.Also jetzt wirds bunt! Du willst mir doch nicht erzählen, daß Du am Auto Deiner Begierde nachschaust, ob die verwendeten Schrauben der DIN entsprechen. Oder ob das angewendete Schweißverfahren in der DIN steht. Oder ob die Zahnkränze im Getriebe nach DIN gebaut worden sind. Oder ob die Lagerung der Kurbelwelle DIN-gerecht ausgelegt ist?
Und genauso hat mich noch kein Kunde gefragt, ob ich eine Animation mit Javascript oder eine dynamische Rechnung mit PHP oder PERL gemacht habe, geschweige denn, daß sie noch interessiert, auf welcher PHP-Version.
[1] Zitat: "Mit der Einführung der XHTML-Familie in Form von Modulen und Dokumenttypen hat das W3C geholfen, die Internet- Entwicklergemeinschaft weg von missgebildetem, nicht den Standards entsprechendem Markup in die Welt wohlgeformten, gültigen XMLs zu führen." Besser kann man es nicht ausdrücken.
Zu einem Zitat gehört übrigens immer die Quelle.
Aber mal ne Frage, nur mal angenommen:
In 10 Jahren konstruiere und baue ich eine fliegende Untertasse.
Kurz darauf baust Du eine fliegende Suppenschüssel.Nu fangen wir beide an, uns gegenseitig Marktanteile zu erkämpfen, in dem wir sie mit immer mehr Features ausstatten:
Schiebetüren, Multimediaeinheiten, Schwerkraftsimulation, Neutrino-Photonen-Warpkern, Schubumkehr-Verstärker-Bremssystem, Galaxienebel-Beleuchtung und ach weiß der Geier was alles noch.Jeder weiß es besser als der andere. Das was ich toll finde, findest Du nicht toll und umgekehrt und das was wir beide toll finden, wird grundsätzlich andersrum eingebaut, als es der andere tut.
Und jetzt kommt jemand daher und legt in einem Stück Papier (oder einem holographisch visualisierten Pergament) fest, daß unser Kampf um Marktanteile aufhören muß und legt deshalb folgendes fest:
Standard ist ein fliegender Abendbrotteller - mit einem süßen kleinem Teddy-Bildchen drauf. Außerdem verzichten wird auf die Multimediaeinheiten, die Schwerkraftsimulation und den Neutrino-Photonen-Warpkern.
Und die Schiebetüren müssen nach links aufgehen und zwar manuell und die Galaxienebel-Beleuchtung muß mit runden Lampen erfolgen.
Was würdest Du davon halten? Würdest Du Deine fliegende Suppenschüssel gegen einen Abendbrotteller eintauschen? Und dazu eine komplette Neuentwicklung durchführen? Also ich bau in meine Untertasse noch ein paar Features mehr ein und steigere erstmal damit meinen Marktanteil.
Wenn Du Deinen standardiersten Abendbrotteller fertig hast, dann habe ich nahezu 100% Marktanteil und Dein Abendbrotteller ist abgegessen. Du wirst dann nur noch in Marktnischen Platz finden und ständig ums Überleben kämpfen, während irgendwelche Staaten und Kartellämter um die Teilung meines Unternehmens kämpfen.
Gruß,
Andreas-
Moin! Oh, ein Glaubenskrieg, da mach ich mit. <freu>
Falsch, es muss heissen: Warum machst du so viele Fehler?
Nein, sie sehen die Seite richtig, weil ich sie natürlich in erster Linie für ihren Browser schreibe. Dann erst schaue ich, ob die Seite auch in anderen funzt.Das zweite, was ich mit dem erstmals abgespeicherten, rudimentären Code einer Neuentwicklung mache ist, ihn im Internet Explorer zu laden. Das erste ist, ihn in Opera zu betrachten. Und das dritte, ihn in Netscape 4 zu betrachten. Und danach werden diese Browser bis zum Feierabend auch nicht mehr geschlossen - und am nächsten Tag wieder geöffnet. :)
Nummer 4 in der Aktionsliste wäre dann übrigens, den Validator zu befragen. ;)
Vielleicht ein Kunde, weil eines deiner Produkte in seinem Browser auseinanderfällt?
Bei keinem Kunden fällt meine Seite auseinander, wenn überhaupt, dann höchstens bei seinen Kunden. Ist natürlich nicht gewollt. Aber da sie ja bei meinem Kunden funzt, kann er dadurch die Schwierigkeit der Angelegenheit verstehen.Tja, und dann wird er auf die Gewährleistung verweisen und Abhilfe verlangen. Dumm für dich: Extra-Arbeit ohne Bezahlung. Oder du redest dich raus - wenn du den Kunden von deiner Sichtweise überzeugt hast, wird er natürlich auch auf diejenigen seiner Besucher schimpfen, die angeblich den falschen Browser benutzen.
In 10 Jahren konstruiere und baue ich eine fliegende Untertasse.
Kurz darauf baust Du eine fliegende Suppenschüssel.Nu fangen wir beide an, uns gegenseitig Marktanteile zu erkämpfen, in dem wir sie mit immer mehr Features ausstatten:
Schiebetüren, Multimediaeinheiten, Schwerkraftsimulation, Neutrino-Photonen-Warpkern, Schubumkehr-Verstärker-Bremssystem, Galaxienebel-Beleuchtung und ach weiß der Geier was alles noch.Solange der Monitor mit dem Bild von draußen (du weißt schon, das Teil, was Captain Picard immer meint, wenn er "Auf den Schirm" ruft!) die Realität ohne Abweichung darstellt, ist alles ok. Und darauf bezieht sich der Standard des W3C: Ein kleiner, aber sehr entscheidender Ausschnitt aus den Möglichkeiten, die die Browser bieten: Die einheitliche Darstellung von elektronisch übermittelten Informationen. Einheitlich aber nicht im Sinne von "pixelgenau identisch", sondern im Sinne von "dokumentenlogisch identisch und im Rahmen der Möglichkeiten des Darstellungsgeräts präsentiert".
Was würdest du denn machen, wenn plötzlich Puppenuntertassen modern würden, und alle Welt die benutzt, weil man damit viel schneller und individueller von A nach B kommt. Zwar hat nur eine Person Platz, und etwas wacklig ist die Angelegenheit auch, aber es funktioniert und macht einen Riesenspaß. Nur Multimediaeinheiten und Schiebetüren wird man da nicht einbauen können, und statt eines 210"-Flachbildschirms hat man nur eine kleine Virtual-Reality-Brille auf.
Standard ist ein fliegender Abendbrotteller - mit einem süßen kleinem Teddy-Bildchen drauf. Außerdem verzichten wird auf die Multimediaeinheiten, die Schwerkraftsimulation und den Neutrino-Photonen-Warpkern.
Das W3C definiert NICHT, was ein Browser sonst noch alles haben darf. Es definiert, was korrektes HTML ist und wie ein Browser das darzustellen hat. Der IE versagt in dieser Beziehung immer noch reichlich und häufig, zum Beispiel bei der Interpretation von Breitenangaben in Verbindung mit Padding.
Beim IE ist dieses Element 100 Pixel breit:
<div style="width:100px; padding:10px;"></div>In korrekten Browsern ist es 120 Pixel breit. Denn Width gibt die Breite des Innenraumes an, der von Inhalt genutzt werden kann, aber nicht die Breite _inklusive_ Padding (das ist der Rand zwischen Inhalt und Grenze des Elements).
Mag sein, daß einige IE-Versionen mit dem "standards-compatible mode" mittlerweile gelernt haben, wie man es richtig macht. Die Probleme werden dadurch aber nicht unbedingt kleiner, weil man sich mittlerweile beim IE auf nichts mehr verlassen kann. Irgendwelche schlauen Leute haben zum Beispiel rausgekriegt, wie man dem IE eine "falsche" Breite unterjubeln kann, und dann hinterher für die anderen Browser die korrekte Breite angibt. Und schon kommt IE 6 und versteht diesen CSS-Hack nicht mehr. ;)
Da ist es doch besser, einfach nur nach Standard zu schreiben und dann den Browsern zu überlassen, was sie daraus machen.
- Sven Rautenberg
-
Hallo Andreas,
Also jetzt wirds bunt! Du willst mir doch nicht erzählen, daß Du am Auto Deiner Begierde nachschaust, ob die verwendeten Schrauben der DIN entsprechen. Oder ob das angewendete Schweißverfahren in der DIN steht. Oder ob die Zahnkränze im Getriebe nach DIN gebaut worden sind. Oder ob die Lagerung der Kurbelwelle DIN-gerecht ausgelegt ist?
Wenn dem nicht so wäre, dann würde das Auto auseinanderfallen oder Du gegen den nächsten Baum fahren.
Für Firmen gibt's übrigens das Pendant zum "Valid XHTML 1"-Bildchen. Das nennt sich dann "ISO 9001" ;-)
http://www.google.com/search?hl=de&q="iso+9001+certification"&btnG=Google-Suche&lr=
Tausende Firmen zeigen stolz, daß Sie würdig sind, dieses Zertifikat zu tragen...
Viele Grüße
Carsten-
Hallo Carsten,
Also jetzt wirds bunt! Du willst mir doch nicht erzählen, daß Du am Auto Deiner Begierde nachschaust, ob die verwendeten Schrauben der DIN entsprechen. Oder ob das angewendete Schweißverfahren in der DIN steht. Oder ob die Zahnkränze im Getriebe nach DIN gebaut worden sind. Oder ob die Lagerung der Kurbelwelle DIN-gerecht ausgelegt ist?
Wenn dem nicht so wäre, dann würde das Auto auseinanderfallen oder Du gegen den nächsten Baum fahren.
Für Firmen gibt's übrigens das Pendant zum "Valid XHTML 1"-Bildchen. Das nennt sich dann "ISO 9001" ;-)
http://www.google.com/search?hl=de&q="iso+9001+certification"&btnG=Google-Suche&lr=
Tausende Firmen zeigen stolz, daß Sie würdig sind, dieses Zertifikat zu tragen...
Wenn eine Firma ein besseres Schweißverfahren entwickelt hat oder eine bessere Schraubverbindung oder weiß der Geier was, dann tun die das patentieren und einsetzen. Wenn die warten würden, bis die ISO nachzieht, dann wäre ja der Marktvorteil futsch.
Und wenn ich als Hersteller merke, daß eine Schraube mit einer Gewindesteigung von 1,5 mm sich lockern kann, aber eine Schraube mit einer Steigung von 1 mm rausreißen kann, weil das Gewinde zu fein ist, dann stelle ich eben eine Schraube mit 1,3 mm Steigung her, weil die eben die Bedürfnisse erfüllt. Und deshalb bleibt das Auto genau aus dem Grunde zusammen, weil man sich mal nicht an die ISO gehalten hat.
Beste Grüße zurück und immer gute Fahrt
Andreas
-
-
-
-
ich kann überhaupt nicht nachvollziehen, was man nur gegen Frames haben kann. Ich finde daran nichts schlimmes - im Gegenteil. Ich halte sie für ein einfaches Mittel, die Darstellung in Bereiche, wie Titel, Menü, Sponsoren-leiste und Inhaltsfläche zu unterteilen.
Man kann zu Frames stehen wie man will. Aber wenn es um HTML strict geht, haben sie da nichts zu suchen. Denn HTML strict ist die reine Lehre, eigentlich die *verdammt* reine Lehre. Es beschreibt den Aufbau von *Dokumenten*, das ist eine rein logische Ebene und hat nichts mit einer bestimmten Darstellung zu tun. Frames sind Anweisungen, die Dinge in einer bestimmten Weise darzustellen. Wer Frames will, nimmt HTML Frames/Transitional. Das ist sozusagen die infiltrierte Lehre.
Ich habe nur Netscape und IE, gut - Opera würde sicher noch Sinn machen oder vielleicht Lynx. Aber ich kenne keinen Strict-Browser der "Firma W3C". Und den wirds wohl auch nie geben.
Doch, den gibt's. Er heisst Amaya. Ist aber auch nicht gerade ein Stabilitaetswunder, wie man hoert. Und jetzt, wo die OpenSource-Browser immer mehr in Richtung Standard compliance gehen, verliert er wohl auch langsam seine Daseinsberechtigung.
So long
-
-
-
Moin!
Eben, ich will ja die alten Features nicht benutzen.
Doch, willst Du. Oder um genauer zu sein, nicht "alte" Features, sondern Dinge, die genaugenommen nicht zu HTML gehoeren. Und genau dafuer gibt es Transitional HTML. Also beluege Deine Besucher nicht und mach nicht solche halbfunktionierenden Spielchen mit JS, sondern trag die richtige DTD ein. (Kannst ja, wie Sven sagte, vorher mit strict testen und die target-Meldungen uebergehen.)
Nur scheint es ja keine Lösung dafür zu geben das eine Webseite in einen Bereich den Inhalt einer anderen nachladen kann. Das können aber Frames. Deshalb ist meiner Meinung nach die ganze DHTML und XHTML 1.1 Geschichte nicht wirklich in allen Punkten ein Fortschritt.
Es ist nicht sinnvoll, HTML nur deswegen zu verbiegen, weil Frames an einer bestimmten Stelle gewisse Vorteile bringen (aber auch nur dann, wenn man keine Standardtechniken wie SSI einsetzt). Mit Fortschritt hat das nichts zu tun. HTML hat einen bestimmten Zweck, naemlich die *logische* Struktur von Dokumenten zu beschreiben. Wenn Du etwas anderes willst, dann ist HTML einfach nicht das richtige fuer Dich (dummerweise hast Du aber auch nicht fuer alles eine richtige Alternative - das ist mir schon klar).
Das Problem habe ich z.B. bei dem Bestand, der vor meiner Zeit entstanden ist, der Webseite vom Lehrstuhl, an dem ich arbeite. Dort wurde die Navigation per Tabelle in jede HTML Seite eingefügt. Jetzt ergänze mal einen Menüpunkt oder nimm einen Weg (musste ich alles schon machen), dann ist man aber eine gute Zeit beschäftigt.
Das rechtfertigt den Einsatz von Frames nun wirklich noch nicht! Dafuer gibt es spezielle Techniken, insbesondere SSI (siehe Selfhtml), falls Dir das auf Serverseite zur Verfuegung steht. Falls nicht, gibt es noch entsprechende Nachbildungen auf der Offlineseite. Z.B. kann der HTML Editor Phase 5 das angeblich. Oder Du schaust Dir mal http://aktuell.de.selfhtml.org/artikel/html/wml/index.htm an. (Wieso steht das in der Rubrik HTML und nicht bei Projektverwaltung?)
Hmm, nicht wirklich. Denn ein Browser der nicht Javascript kann, kann auch nicht xhtml 1.0 sauber umsetzen
Das ist ja nun Quatsch. Was hat das eine mit dem anderen zu tun? Sieh Dir Lynx an. Ich weiss nicht, ob er XHTML kann, aber wenn nicht, wird er's sicher in naechster Zukunft. JavaScript wird der aber (fast) garantiert niemals koennen.
So long
-
-