Re: Bugs und Hacks

[Orlando]

Hi Mathias,

da schreibe ich mal mehr als nur einen Dreizeiler, schon kommt mir das Archiv in die Quere. Also hier die Fortsetzung:

[...] Den Großteil der Zeit verbringt man ausschließlich mit solchen Workarounds.

Muss ich ein Layout so umsetzen,

• dass Lynx Elemente positioniert? Nein, weil die Seite trotzdem funktionieren wird.

Ich sehe keinen Zusammenhang zwischen dieser rhetorischen Frage und meinen Ausführungen.

Ich schon, schließlich versuchst du (ich sitze im Glashaus, ich weiß, aber es macht Spaß, dich zu pieksen, du Fundi *g*), die Schwächen einer Software zu umgehen bzw. fehlende Möglichkeiten nachzubilden.

In einem anderen Thread habe ich von der Verdeutlichung von Beziehungen durch das Nebeneinanderstellen von Einheiten geschrieben, angesichts dessen kannst nicht behauptet werden, dass die Positionierung für die Wirkung und die dadurch erzielte Bedeutung irrelevant ist.

Nein, das behaupte ich keineswegs. Aber Positionierung ist nicht Voraussetzung, sondern schmuckes Beiwerk. Klar kann sie die Präsentation unterstützen, aber darum geht es hier nicht.

• dass Netscape 4 das gleiche Ergebnis zeigt, wie moderne Browser? Nein, weil... (s. oben).

Die Wirkung der Seite wird unter Umstände massiv leiden,

Das mag sein, wenn du "Gefühl" und "Stimmung" oder ähnlich subjektive Dinge vermitteln willst, der Transport des "Inhalts" wird auch ohne diese Dreingaben in den meisten Fällen funktionieren. Ich unterscheide hier wohl wesentlich strenger als der Durchschnittsbesucher, weil ich meist CSS und Bilder gänzlich deaktiviere bzw. ein Benutzer-Stylesheet einsetze. Was sich der Ersteller der Seiten gedacht haben könnte (im Regelfall nichts Sinnvolles, ich bessere selbst nach...), berührt mich daher wenig.

je nachdem, mit welchem Mitteln bzw. über welche Faktoren sie »funktioniert«, was Hintergründe und Ziele sind.

Eben, aber wessen Ziele? Meine oder die des Erstellers? Mein Ziel ist die Extraktion der für mich relevanten Information - und das mit so wenig Zeitaufwand wie möglich. So viel zum title-Attribut.

Pauschal lässt sich dazu gar nichts sagen; sonst könntest du auch behaupten, dass die Grundfunktionalität des Fernsehens auch gegeben sei, wenn man den Ton nicht hören könne, schließlich sähe man das Bild, worauf generell das Hauptaugenmerk läge.

Nicht alles, was hinkt ist ein Vergleich. Mir geht's eher darum, die Radios der Besucher nicht um eine Bildröhre erweitern zu wollen.

• dass <abbr> im M$IE das gleiche Ergebnis zeigt, wie in modernen Browsern? Nein, weil... (s. oben).

Nein - das abbr-Element hat im genannten Kontext definitiv mit »funktionieren« zu tun, denn dessen title-Attribut enthält mitunter wichtige Informationen, ansonsten würde ich einerseits keine Abkürzung verwenden, sofern sie nicht von zentralem Wert wäre, und andererseits kein abbr-Element verwenden.

Schon richtig, aber warum akzeptierst du nicht, dass einige Useragents damit nichts anfangen können, wenn du auf zusätzliche Auszeichnungen verzichtest? Oder umgekehrt (s. unten).

Strukturelles/semantisches Markup zugunsten von Zugänglichkeit ist sinnlos, wenn es nicht kommuniziert wird.

Aber das wird es doch, eine entsprechend fähige Anwendung vorausgesetzt. Ich biete alles, was dafür nötig ist - der Ball liegt also beim Besucher.

Es geht darum, die Abkürzung mit einem title-Attribut auszuzeichnen, und wenn der MSIE das abbr-Element nicht versteht, ist das im Grunde genommen nicht ausschlaggebend, um ihn zu ignorieren, da ein zusätzliches span-Element denselben Zweck erfüllt.

Aber heiligt der Zweck die Mittel? Wo würdest du die Grenze ziehen? Würden alle Seitenersteller ihre kostbare Zeit nicht mit diffusen Hacks vergeuden, sondern ihren Besuchern erklären, welche Vorteile sie von einem modernen Browser zu erwarten hätten, wäre der Zugänglichkeit in Summe eher gedient.

Da die Mehrheit den MSIE verwendet, ist die straighte Auszeichnung in diesem Punkt solange ohne große Wirkung, bis sie auch den MSIE-Nutzern einen Vorteil bringt. Sofern der Aufwand der Umgehungslösung tolerabel ist, werde ich ihn anwenden, wenn ich dadurch die Zugänglichkeit der Seite signifikant erhöhen kann.

Ich bezweifle, dass der Inhalt des title-Attributs wirklich wahrgenommen wird, meist werden Seiten ohnehin nur gescannt. Das soll natürlich nicht bedeuten, auf sinnvolle Auszeichnung zu verzichten, doch das ist auch ohne Workaround gewährleistet, wenn man vom worst case (bezüglich der Software) ausgeht und sich nichtmal darauf verlässt, dass eine Abkürzung als solche wahrgenommen wird.

[...] in weniger guten bis sehr schlechten Browsern mit Gewalt *nachbilden*?

Mir ging es in dem Beispiel nur um abbr/acronym. Dem Benutzer bringt das bis auf der kleinstmöglichen Ebene angereicherte Markup überhaupt nichts, wenn er davon kein bisschen profitiert.

Er hat doch die Wahl. Offenbar legen M$IE-Benutzer darauf keinen Wert (weil sie es nicht besser wissen, können, bla... irrelevant).

Ich kann nicht guten Gewissens mit dem Bewusstsein, dass die eingebauten Zugänglichkeitsfunktionen sowieso niemandem helfen, meine Seiten WCAG-konform nennen.

Du siehst das title-Attribut nicht als Barriere? Das halte ich durchaus für eine gewagte Behauptung, darauf würde ich mich nicht verlassen. Besser, der Text kommt ohne aus und erläutert weniger leicht Verständliches *selbst*. Ich weiß nicht, ob und wie Screenreader/Textbrowser solche Auszeichnungen unterstützen, aber auf die Gefahr hin, dass dies nicht der Fall ist, sollte der "normale" (<p>) Text selbst alle Informationen enthalten. Andernfalls baust du mit dem an sich korrekten Markup zusätzlich eine Barriere auf.

Unsere Definitionen von »Funktionalität« divergieren, diese Diskussion hatten wir schon öfters.

Tja, nichtmal HTML "funktioniert" und wir diskutieren über CSS-Spitzfindigkeiten, die in jedem zehnten Browser möglich sind und jeder hundertste Besucher beachtet...

Selbst wenn wir das selbe meinten, wäre »Funktionalität« dennoch ein unpassender Begriff. Welche Funktion eine Webseite verfolgt und wie sie diese erfüllt, ist schlichtweg eine auf der jeweiligen Situation basierende Entscheidung.

Schön, dass wir trotzdem eine Grundsatzdiskussion führen ;)

Gemäß dem Beispiel funktioniert eine Seite, falls der Text trotz eventuellen Stolperstellen wie Abkürzungen et cetera kommuniziert (»herübergebracht«) wird.

Das heißt, auch ohne title, span usw. muss alles transportiert werden können. Wozu sind diese dann trotzdem nötig?

Sofern ich dem Browserfehler in diesem Punkt nicht begegne, kann die Erfüllung dieser Funktion beziehungsweise dieser Absicht je nach Fall stark in Mitleidenschaft gezogen werden. Ergo: Die Funktionalität ist nicht gewährleistet.

Die Funktionalität wird aber auch unter der gehäuften Verwendung von Abkürzungen leiden, die deinen Workaround erst notwendig machen. Abgesehen davon kannst du davon ausgehen, dass deine Zielgruppe mit den Begriffen vertraut ist, denn Einsteiger (und für diese sind offenbar die Zusatzinformationen vorgesehen) sprichst du nicht an.

Die Essenz einer Antwort auf die Frage eines $BROWSER-Benutzers, warum die Seite im Bezug auf $FEATURE »nicht funktioniert« (sic!), kann im Grunde nicht anders als folgendermaßen lauten: »Du bist selbst Schuld, dass du einen (alten|standardinkompatiblen|...) Browser benutzt.

Na bitte, es geht doch *g*

Ich weiß zwar, wie ich dem vergleichsweise einfach begegnen könnte, will es aber nicht«, selbst wenn die Ausdrucksweise blumiger wäre (Arbeitsaufwand et cetera).

Ja, so sehe ich das.

Ich erachte es auch weiterhin für die sogenannte Funktionalität einer Seite von Fall zu Fall für wichtig, dass ein Autor solchen Browserproblemen weitsichtig begegnet.

Wo liegt deine Schmerzgrenze? Bei Netscape 4 oder 6? Beim M$IE 5 oder 6? Opera 6? Mozilla 0.9.x? Sie alle haben ihre Problemchen, die man in Summe gar nicht abdecken kann.

Komisch nur, dass ständig davon geredet wird, den Besuchern die größtmögliche technische Funktionalität zu bieten (siehe Ursprungsdiskussion) und dass es grundsätzlich nötig ist, den Browserunzulänglichkeiten nicht diskriminierend zu begegnen.

Moment, wir diskriminieren niemanden, wir bevorzugen allenfalls - und auch das nur geringfügig, weil wir uns auf *nichts* verlassen können.

Ich verstehe nicht, wieso du dich gerade am genannten simplen Workaround störst.

Das Beispiel stört mich keineswegs, es ist nur Anlass genug, um zu diskutieren. Er ist vielleicht der erste Schritt auf dem Weg zu einer Struktur, die ich so nicht haben will. Bis zu den SELFHTML-Tabellen ist es dann nicht mehr weit und diese hast du ja mitterlweile von ihrer besten Seite kennengelernt *g*.

LG Roland

(Ein fehlender PC kann eine heftige Barriere sein. *seufz*)