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*)

[molily]

Hallo Orlando,

• 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.

Schon wieder definierst den blanken Text als »Inhalt« und leugnest, dass Form per se inhaltsbestimmend ist. Wenn die Gestaltung sowieso Beiwerk ist, dann hat sie keinen Existenzgrund und der Autor hat das Ziel vollends verpasst.

Die Wirkung definiert sich als Summe aller ausgelösten (»evozierten«) Assoziationen. Deine Trennung zwischen objektiven und subjektiven Inhalten (was soll das sein?) ist mir absolut unklar, ich verstehe nicht, worauf du hinaus willst und welche Relevanz für die weitere Argumentation es hätte, falls man diese Theorie als wahr gegeben annimmt. Einen falschen Schein von Objektivität sollte man nicht zu erwecken versuchen, auch der blanke unformatierte Text geizt in der Regel nicht mit in dem Fall sprachlichen gestalterischen Mitteln, welche mit den visuellen Gestaltungmitteln prinzipiell nicht unähnlich sind.

Auch der nackte Text erfüllt eine Funktion, auch ohne spezielle Formatierungen sind die ausgelösten Gefühle und Stimmungen nicht vollends determinierbar, aber grundsätzlich sind ist diese Wirkung keinesfalls von anderer Substanz, sodass sie sich nicht durch ihre »Objektivität« von den primär visuellen Eindrücken absetzen lässt.

Es geht darum, dass die Komposition dadurch definiert wird, dass alle Gestaltungselemente harmonieren beziehungsweise bewusste Spannungen erzeugen. Die Grundannahme ist, dass diese Komponenten die Gesamtwirkung in ihrer speziellen Weise entscheidend beeinflussen können. In der Art und Weise, wie du es ausdrückst, kann keine Komposition existieren, da »Inhalt« vorweg festgelegt wird. Ich sehe Parallelen zur Design vs. Styling-Diskussion, [pref:t=38874&m=213105] ff.

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.

Möglich, aber nicht verallgemeinerbar. Mit dieser Praxis wird auf anderen Sites Essentielles fehlen, da der Kontext fehlt.

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?

Beide, zunächst aber die des Autors/Anbieters. Der Autor sollte sich den Erwartungen des Lesers bewusst sein und dementsprechend Informationen zugänglich machen.

Mein Ziel ist die Extraktion der für mich relevanten Information - und das mit so wenig Zeitaufwand wie möglich.

Dieses Benutzeranliegen ist eines der im Web vorkommenden, vielleicht das wichtigste, aber mit Sicherheit nicht das einzige. In solchen Fällen, in welchen ich abstrakte Textinformationen suche, ist die konkrete Darstellung tatsächlich für mich in den meisten Fällen nicht relevant, weshalb ich aus Gründen der Effektivität ebenfalls Autorenstylesheet und Grafiken deaktiviere, aber wissentlich, dass die Präsentation der Information, welche für mich viel über die Information selbst aussagt (medienanalytisch gesehen), verloren geht.

So viel zum title-Attribut.

Wie meinen? Plädierst du für die Vermeidung von Abkürzungen? Genau genommen würde ich Abkürzungen beim ersten Vorkommen im Dokument auch ausschreiben und die Abkürzung anhängen, so ist es auch üblich und auch in den WCAG empfohlen.

»... Generalsekretär der Vereinten Nationen (<abbr>UN</abbr>) Kofi Annan ... ... <abbr>UN</abbr>-Sicherheitsrat ...«

Dass alle abbr-Elemente die Auflösung der Abkürzung im title-Attribut enthalten müssen, möchte ich bezweifeln. Ich handhabe es aber dennoch auf meiner privaten Seite in dieser Form (... oder vermeide Abkürzungen).

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 ging es um unterschiedliche gleichberechtigte Kommunikationsebenen, welche ihren Teil zum Gesamteindruck beitragen.

Mir geht's eher darum, die Radios der Besucher nicht um eine Bildröhre erweitern zu wollen.

Den Vergleich verstehe ich wiederum nicht, es sollen lediglich immanente Möglichkeiten verwendet werden. Ich formatiere abbr-Elemente auch immer mit einem Fragezeichen-Cursor und einer Unterstreichung, wie Mozilla und Opera 7 es von Haus aus tun.

• 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?

Häh? Ich sagte doch, ich möchte die wichtige Information in jedem Fall kommunizieren. Die logische Folge wäre, nicht MSIE zu vernachlässigen, sondern eine grundlegend andere, kompatiblere Möglichkeit zu suchen.

Oder umgekehrt (s. unten).

Ja.

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.

Wie ich sagte, mir geht es um den konkreten Nutzen, auch sagte ich, dass von den in den WCAG propagierten Zugänglichkeitsfunktionen nur ein Bruchteil von assistiven Techniken wie Screenreadern unterstützt wird (ebenso gibt es viele Richtlinien mit der Einschränkung »until user agents ...«). Dem möchte ich begegnen.

Ich biete alles, was dafür nötig ist - der Ball liegt also beim Besucher.

Auch darauf habe ich bereits geantwortet, es geht mir um die praktische Zugänglichkeit, welche ich nur dadurch erreichen kann, dass ich den Unzulänglichkeiten der Browser und Zusatztechniken begegne.

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?

Die praktische Umsetzung von Accessibility-Empfehlungen ist für mich ein besonders legitimer Zweck.

Würden alle Seitenersteller ihre kostbare Zeit nicht mit diffusen Hacks vergeuden,

Worauf du  anspielst, weiß ich nicht, aber dieser spezielle Workaround ist meiner Meinung nach absolut transparent und später einfach entfernbar.

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.

Ich werde sicherlich jedem raten, einen benutzbaren Browser zu verwenden, dennoch geht es darum, dass jemand mit einem Browser auf meine Seiten kommt und ich damit arbeiten muss. Aus demselben Grund werden Extrastyles für Netscape 4 eingebaut und - um zum Thema zurückzukommen - Inline-Scripts und -Styles auskommentiert. Dem Anwender soll meiner Meinung nach unter Berücksichtigungen der Browserunzulänglichkeiten ein Optimum geboten werden, welches ein Mittelweg zwischen rücksichtsloser Minimalversion, welche nach obiger Definition inhaltlich stark eingeschränkt ist, und zeitraubendem Extraufwand ist.

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.

Von dem Standpunkt möchte ich gar nicht argumentieren.
Komplexität ist in vielen Fällen nötig, dies ist nicht immer mit dem Wunsch zu vereinbaren, dass der Text auf einen Blick verständlich ist, auch wenn es eine Aufgabe von Hypertext wäre, durch Gliederungen und Zusammenfassungen sukzessiven Einstieg zu bieten. Sofern ein Text komplex genug ist, um zentrale, wichtige Fachbegriffe beziehungsweise Abkürzungen zu enthalten, ist bei der nötigen detaillierten Auseinandersetzung auch wichtig, dass die nicht kürzbaren Abkürzungen verständlich werden.

[->]

[molily]

[<-]

Das soll natürlich nicht bedeuten, auf sinnvolle Auszeichnung zu verzichten, doch das ist auch ohne Workaround gewährleistet,

Aber nicht die Möglichkeit des tieferen Einstiegs in den Text. Sofern der Text blitzschnell zugänglich sein soll, sind Abkürzungen sowieso deplatziert - aber auch gewissermaßen ein bestimmter Grad der Differenziertheit unmöglich, je nachdem.

wenn man vom worst case (bezüglich der Software) ausgeht

Dem kann auch unter annehmbaren Bedingungen begegnet werden, siehe oben.

und sich nichtmal darauf verlässt, dass eine Abkürzung als solche wahrgenommen wird.

Ein Text kann naturgemäß nicht jeder oberflächlichen Auseinandersetzung gerecht werden - das ist meiner Meinung nach auch keine Frage der Zugänglichkeit, denn in dem Falle ist Verständnis möglich, nur anscheinend vom Leser nicht gewollt. Höchstens Nachrichten, welche formal streng darauf ausgerichtet sind, die Kerninformation in einem vorgefertigten und bewährten Schema präzise herüberzubringen, werden dem gerecht. In ausschließlich diesem Stil möchte ich keine Webseiten lesen geschweige denn verfassen.

[...] 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).

Mir ist grundsätzlich in Hinblick auf meine Absichten gleichgültig, aus welcher Unwissenheit heraus ein Browser verwendet wird, ich habe dies meiner Meinung nach zu respektieren. Vielleicht werde ich einen berechtigten Hinweis einbauen, dass die Spielerei XYZ nicht verfügbar ist, aber die Lesbarkeit des Textes und weitesgehend auch die grafische Präsentation (zumindest im Falle MSIE) sollten dadurch nicht grundlegend negativ beeinflusst werden. Sicherlich würde ich dem Benutzer auch durch Ratschläge assistieren, um ihm die Benutzung des Browsers zu erläutern oder gegebenenfalls den Umstieg zu vereinfachen, mehr aber nicht. In den meisten Fällen lassen sich solche Hinweise durch weitsichtige Gestaltung vermeiden, sodass sich Verluste weitesgehend im Rahmen der Möglichkeiten umgehen lassen, alles andere fände ich nicht weniger problematisch als »Optimiert für«. Dass ein Textbrowser keine Pixelgrafiken anzeigen kann, lässt sich natürlich nicht kompensieren, aber das ist genau der Punkt, an welchen die Strategie der möglichst äquivalenten Alternativinhalte greifen sollte. Im Falle des Falles würde ich eher die bodenständigere, unelegante Methode verwenden, damit auch die weniger entwickelten Browser mitmachen. CSS-Layout ist beispielsweise weit davon entfernt, gängige anspruchsvolle Tabellenlayouts flexibel und vor allem interoperabel ersetzen zu können, das heißt, die Browser sind vornehmlich nicht in der Lage.

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*.

Meine Rede, das wäre sicherlich der empfehlenswerte und elegantere »Workaround«. Darum ging es aber nicht primär.

Ich weiß nicht, ob und wie Screenreader/Textbrowser solche Auszeichnungen unterstützen,

Eher nicht. Ebenso wie beispielsweise das lang-Attribut. Zu letzterem gab es kürzlich eine Diskussion auf W3C-WAI-DE, siehe http://access.fit.fraunhofer.de/waide/SummarizeList?listId=1.

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.

Ja.

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...

Das hängt davon ab, wie die Seite diese Funktionen vermittelt. Sofern sie selbsterklärend ist, beispielsweise durch Tipps zur Benutzung am Rande, ist ein solches Zusatzkonzept sicherlich erfolgreich, wenngleich es von vielen dennoch nicht aktiv genutzt wird.

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?

Dezüglich dem Einwand muss ich dir Recht geben - sofern man es zuverlässig verständlich hinbekommen möchte, sollte man generell von diesen wenig unterstützten Mitteln absehen.
Dennoch erachte ich die abbr/title-Technik weiterhin als generell benutzerfreundlich und passende Möglichkeit, erklärende Zusatzinformationen in den Text zu streuen.

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.

Ebenso wie bei Fachbegriffen sollte sicherlich zuerst über die Notwendigkeit dieser nachgedacht werden. In vielen Fällen ist eine präzise Sprache die Grundbedingung, um den Inhalt angemessen zu transportieren. Von diesen Fällen wollte ich sprechen.

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.

Über welchen Fall sprichst du? Sofern ein Text informieren soll, sind diejenigen, die mit dem Thema eingehend vertraut sind, sicherlich nicht Kernbestandteil der Zielgruppe. Auch in einem Text, welcher sich an Einsteiger wendet, sind eindeutige Begriffe nötig, sofern sie Zusammenhänge treffend bezeichnen/vermitteln.

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?

Je nachdem, um welches Problem es sich handelt. Sofern ich Netscape 4 ein unproblematisches Stylesheet mit ein paar simplen Regeln bieten kann, welche dennoch den Formatierungen des Hauptstylesheets im Hinblick auf die Wirkung nicht unähnlich sind, werde ich ein solches erstellen. Den Box model-Bug beachte ich auch.

Sie alle haben ihre Problemchen, die man in Summe gar nicht abdecken kann.

Die absolute Perfektion ist weder möglich noch strebe ich sie an.

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 -

Privilegien ziehen Benachteiligung nach sich, welche in den meisten verwandten Fällen nicht nötig ist. Sicherlich hast du recht, aber sofern annehmbare Mittel und Wege existieren, diese Differenz zu minimieren, würde ich sie nutzen.

und auch das nur geringfügig, weil wir uns auf *nichts* verlassen können.

Sofern der Browser umgebungsbedingt nur ein Teil des Inhalts, beispielsweise den Textinhalt, darstellen kann, liegt natürlich kein Fehlverhalten des Autors vor.

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*.

Bezüglich einigen aufwändigen Markupkonstrukten stehe ich vollkommen hinter dem momentanen Konzept, da sich beispielsweise Symbolgrafiken nicht durch CSS-generierten Inhalt ersetzen lassen - eine Grafik kann Alternativtexte und Titel enthalten und Teil des Links sein.

Sicherlich geht mir auf die Nerven, dass jede farbige beziehungsweise umrahmte Box mit Tabellen gelöst wird, obschon ich verstehen kann, dass hier die Präsentation *extrem* zur Vermittlung der Bedeutung beiträgt (Beispiele, Code, Navigationskonventionen, eben die wiederkehrenden Schemen, welche Selfhtml schnell begreifbar machen).

Grüße,
Mathias