nicht angemeldet
Hallo Cheatah,
Wenn man für das Internet entwickelt, entwickelt man für alles, was dort eine wie auch immer geartete Daseinsberechtigung hat.
Ja, aber ein Netscape 3-Benutzer wird aus seiner Sicht sicherlich dennoch denken, er habe das Recht, nicht mit einer abgespeckten, optisch-gestalterisch vergleichsweise öden Seite abgespeist zu werden. Genauso könnte er anführen, dass ein konventionelles HTML-Layout die höchste Interoperabilität erreichen würde. Diese Überzeugung von Existenzberechtigung teile ich jedoch nicht.
Benutzt also jemand, aus welchen Gründen auch immer, einen Netscape 1, einen lynx, ein PDA, einen Blindenbrowser oder sonstwas, das kein <script> kennt, dann hat der doch bitteschön trotzdem das bestmögliche Ergebnis zu erhalten. Das ist Professionalität; nicht das Sparen von vier Bytes.
Ja. Das ist Professionalität.
Ich bin mir nicht sicher, ob es dort [in XHTML] Empfehlung ist, auf HTML-Kommentare innerhalb von <script> zu verzichten, oder sogar Pflicht.
Sofern XHTML als text/html ausgeliefert wird, sollte es sowieso gleich sein.
[...] In dem Moment, wo man sich für XHTML entscheidet, ist jedoch klar, dass man dies konsequent macht.
Sicherlich, man bürdet den Browsern unter Umständen sogar mehr Arbeit auf, da diese Pseudo-Kompatibilität zu einem großen Teil auf Fehlertoleranz beziehungsweise Ungenauigkeit der prä-XHTML-Browser basiert.
Es lässt sich ohne weiteres Code so erzeugen, dass er kompatibel zu allem ist - ohne die jeweiligen Systeme überhaupt zu kennen.
Theoretisch; weiterhin handelt es sich um eine grundlegende Kompatibilität.
[...] Ich sehe keinen Grund dafür, unter Mühen Probleme zu verursachen, während simple Nutzung der Standards und einiger Styleguides allen Bedürfnissen gerecht wird.
Dies trifft leider nur im konkreten Fall zu. »Allen Befürfnissen«, welche jenseits der simplen Benutzbarkeit liegen, wird aber sicherlich nicht gerecht werden können.
Dass manche Systeme Probleme mit der Darstellung haben, ist bekannt - und weitgehend egal. Das Aussehen ist zweitrangig, auf die einschränkungsfreie Funktionalität und den Inhalt kommt es vorwiegend an. [...]
Das sehe ich im Grunde genauso. Weiter gefasst ist aber bedauerlicherweise der Wunsch nach gleicher Darstellung in der der Praxis zweifelsfrei immer wieder Argument für Layout und Formatierungen mit quasi HTML 3.2-Techniken. Dass die Site auch im NS 4.x und Konsorten gut aussehen soll, ist zunächst einmal ein berechtigter Wunsch, denke ich.
Das ist ein weit verbreiteter Irrtum: An "alte" (mit dem Alter hat es keinesfalls direkt zu tun) Programme zu denken heißt beim besten Willen nicht, auf neue Techniken zu verzichten oder alles doppelt machen zu müssen. [...]
Ja, das ist mir alles geläufig. Mit »alt« meine ich auch tatsächlich den Entwicklungsstand beziehungsweise die Version. Dass ein Browser mit anderer Ausgabetechnik unabhängig davon, dass diese Ausgabetechnik heute nicht mehr die weit verbreitetste ist, nicht »veraltet« ist, kann ich nur unterstreichen.
Was gibt es außer HTTP/HTML-Benutzeragenten sonst noch für Webseiten darstellende Software, welche kein script-Element kann? ;)
Suchmaschinen-Robots? Site-Grabber? Proxies?
Suchmaschinen-Robots müssen Websites in der Regel parsen und sie gewissermaßen intern darstellen, insofern ist es hier tasächlich entscheidend, dass der Robot script versteht. Dennoch, die praktische Relevanz von Suchmaschinen, welche in 2003 immer noch kein script-Element verstehen, geht gegen null. Sicherlich lohnt es sich dennoch, auf Nummer sicher zu gehen, nur sehe ich nicht ein, wie lange man diese Spielchen noch treiben soll. Auf meinen Einwand, dass auch noch in Jahren jeder <script>-unkundige Browser seine Daseinsberechtigung hat und auch dann noch gemäß deinen Ausführungen eine grundsätzliche Beachtung nötig wäre, obwohl er in freier Wildbahn längst ausgestorben beziehungsweise schon längst versteinert ist, hast du leider nicht geantwortet. Site-Grabber und Proxies sind keine »Webseiten darstellende Software«, sie fungieren nur als Vermittler. Hier sehe ich wenig Problempotenzial.
[Lynx und <script>] Jedoch ist lynx keinesfalls der einzige nicht-graphische Browser. Warst Du jemals blind und hast Dir Webseiten mit den Fingern angesehen?
Nur der Neugier wegen ist mir eine Braillezeile zu teuer ;) (und auch leider vielen Blinden).
Oder vorlesen lassen?
Ja, aber meine Screenreader beziehungsweise die zugrunde liegenden Browser können script. Alle anderen mir bekannten Textbrowser auch, vielleicht sollte ich noch einmal vier oder fünf Jahre alte Versionen suchen...
Dennoch brauche ich vielleicht noch Hunderttausend Besucher mehr, damit dieser Fall zum ersten Mal eintritt [...]
Wenn dieser Fall zum ersten Mal eintritt, und es sich zufällig um den (blinden) Leiter der Einkaufsabteilung von $WELTKONZERN handelt, welcher bei Dir ein paar Millionen Euro lassen wollte, wirst Du es vermutlich ebenfalls nicht erfahren, weil er einfach weggeht und sich eine bessere Site sucht.
Mich brauchst du diesbezüglich nicht zu überzeugen, beziehungsweise höchstens im Bezug auf Auskommentierung von Scripts und Styles. Ich wollte auch eher darauf hinaus, dass solche kleinen Unzulänglichkeiten einer Seite nicht die komplette Zugänglichkeit versauen (im Falle des Falles lagere ich Scripts und Styles sowieso extern aus). Bei vielen anderen lässt es sich vermutlich nicht einfach verhindern, denn leider unterstützen viele Browser und Zusatzprogramme die Zugänglichkeitsfeatures von HTML nicht. Insofern kann ich beispielsweise brav und stur alle fremdsprachlichen Begriffe im <span lang="en">Markup</span> auszeichnen, aber viele Screenreader lesen dennoch alles in der Dokumenthauptsprache. Dito bei dutzenden anderen Web-Zugänglichkeitsrichtlinien. Der Definition nach wären das schwerwiegende Barrieren, welche ich soweit es mir möglich ist zu umgehen versuche. In dem übertragenen Beispielfall würde der Abteilungsleiter meine Seite wahrscheinlich verlassen, weil sein Screenreader diese grundlegenden Techniken nicht beherrscht, aber ich in diesem Fall nichts machen kann. Ein anderes Beispiel: Der MSIE interpretiert abbr- beziehungweise acronym-Elemente nicht; um Abkürzungen ein title-Element zu verpassen, muss man Konstrukte wie <abbr><span title="World Wide Web Consortium">W3C</span></abbr> einsetzen. Den Großteil der Zeit verbringt man ausschließlich mit solchen Workarounds.
Doch, die [Gewissheit, wie sich Clients verhalten] gibt es: Halte Dich an die Standards und einige wenige Styleguide-Regeln, und Du wirst auf jedem Client die dort bestmöglichen Ergebnisse erzielen. Gehst Du jedoch nach dem Prinzip "hat eh keiner mehr, der Fall wird schon nicht auftreten", schließt Du bereits im Vorfeld Besucher aus. [...]
Sicherlich; von der Warte der absoluten Professionalität will ich auch nicht in jedem Fall diskutieren, im allgemeintheoretischen hat dies sicher seine Berechtigung. Ich glaube nicht, dass sich der Betreiber einer rein privaten Site, wie in diesem Thread Frau Holle, um auf das Beispiel zurückzukommen, durch solche Argumentationen beeindrucken lässt (leider?). Das ist meiner Auffassung nach sogar nachvollziehbar.
Clientseitige Techniken, die einem (W3C-, IETF-)Standard unterliegen, lassen sich immer optional einsetzen. Sie sind absolut kompatibel mit Systemen, die sie nicht beherrschen.
Schön wäre es - ich setze auf einer (validen) Site bewusst die Zugänglichkeitsfeatures von HTML ein. Und Netscape 4.x crasht wegen den label-Elementen, welche ich just aus dem Grund eingefügt habe, um die Bedienung zu vereinfachen. Das Markup ist an sich makellos.
Ich kann auch nicht mit Gewissheit sagen, ob mein Markup oder meine Styles nicht bei einem nicht kalkulierbaren Browser einen Absturz verursachen [...]
Ja, es kann immer Programme/Systeme geben, die auf völlig normale und korrekte Dinge absurd reagieren.
Ja, siehe oben. Auf solche Zwickmühlen trifft man in der Praxis leider ständig.
Wenn man sie kennt, kann man versuchen, dies zu umgehen - aber darüber hinaus lohnen sie wirklich keine Sonderbehandlung, denn dann müsstest Du vorsichtshalber auf alles verzichten.
»Zurück zum Beton!« ;) Soweit stimme ich dir zu, dennoch sehe ich nicht ein, wieso und wie lange noch ich (im beschriebenen Beispiel) lückenlose Abwärts-Kompatibilität über Zugänglichkeit stellen soll. Das Auskommentieren von Styles und Scripts hat im Gegensatz dazu nahezu keine negativen Auswirkungen und ist eher das kleinste Problem von dutzenden.
Was ich Dir die ganze Zeit sagen will: Es ist schön, wenn Du Deine Ergebnisse soweit verbesserst, dass sie mit handelsüblichen Browsern nach dem 80/20-Prinzip (oder von mir aus 95/5) noch besser aussehen. Aber - um auf jedem System problemfrei nutzbare Ergebnisse zu erzielen, brauchst Du kenntnisse über kein System, sondern nur über die Standards und ein wenig Styleguide. Das ist alles!
Das ist mir bekannt, darum ging es mir auch nicht. Das Markup, welches ich einsetze und für welches ich plädiere, entspricht abgesehen von den Fällen, in welchen wie oben genannt aufgrund von massiven Browserbugs kein rechter Weg möglich ist, auch diesen Anforderungen.
Die Betrachtung, welcher Browser jetzt wie sehr verbreitet ist, wie viele was können etc., ist vollkommen überflüssig, sie hilft Dir nicht.
Das gilt vielleicht für einige Bereiche des Webauthorings, für andere aber überhaupt nicht. Ein CSS-Layout zu erstellen ist vergleichswese leicht, wenn man davon ausgeht, dass die Browser sich an die Standards halten, denn gemäß dem Standard ist die Darstellung determinierbar, wenn man gewollte browsertypische Unterschiede und Benutzereinstellungen außer Acht lässt, welche hier nur sekundär problematisch werden könnten, was aber leicht zu handhaben ist, da konzeptionell anpassungsfähige Layouts möglich sind, aber eben nur sofern der Browser die vom Autor eingebauten Skalierungsmechanismen versteht. Wahrscheinlich würde dieses perfekte Layout nur im Mozilla zu dem gewünschten Ergebnis führen, oder nicht einmal darin. Folglich muss man sich auf alle potenziellen Browser zubewegen, indem man ihre speziellen Bugs und Unzulänglichkeiten berücksichtigt. Bei allen anderen vertraut man darauf, dass die eingebauten Abwärts-Kompatibilitätsfähigkeiten greifen - aber mehr kann man nicht. Das ist zwangsweise in vielen Fällen, welche per se nicht berücksichtigt werden können, nicht genug.
Sie führt höchstens zu Fehlentscheidungen, indem Du nämlich Dinge tust, die bei 99% aller Fälle toll sein mögen, aber im verbleibenden Prozent (oder meinetwegen auch einem Bruchteil davon) das Gegenteil, nämlich Probleme verursachen.
Beispielsweise bei CSS-Layout ist es zwanghaft notwendig, zahlreiche Hacks zum browserspezifischen Verstecken und Zuordnen von Styles anzuwenden, weil sonst die grundlegende Darstellung vermurkst wird. Ich halte auch nichts von diesen CSS-Workarounds, dennoch sind sie nötig, siehe auch /archiv/2003/1/36474/#m201363.
ich werde beispielsweise wahrscheinlich nie erfahren beziehungsweise »mit Gewissheit (voraus-)sagen« können, wie meine Sites im OmniWeb oder iCab (oder ...) aussehen.
Das ist ja auch egal. Wie sie funktionieren kannst Du jedoch sehr gut vorhersehen.
Nein, das kann ich nicht voraussehen. Gewisse CSS-Eigenschaften und -Kombinationen sprengen beispielsweise im Netscape 4 das komplette Layout - die Seite wird komplett unlesbar und unbedienbar, das heißt sie funktioniert tatsächlich nicht. Nichts und niemand kann mir garantieren, dass andere Browser nicht ähnlich reagieren - ich kann nur mit Bordmitteln und vorausschauendem Denken dagegen vorgehen. Folglich: s/aussehen/funktionieren/ und meine These gilt m.M.n. nichtsdestoweniger.
Grüße, Mathias P.S. Die Kürzungen beruhen darauf, dass das Posting zu lang wurde.