nicht angemeldet
Hallo Daniel,
ich bleibe jetzt einfach mal bei meiner Meinung, dass du noch immer nicht ganz verstanden hast, was wir dir mitteilen wollen.
Ich hab das schon verstanden, auch wenn es nicht bei dir so ankommt.
Somit klingt es für mich absurd, zu wissen, daß es CSS gibt, das auch von CSS-fähigen Browsern angewendet werden könnte, aber aus Rücksicht auf Clients, die CSS nicht verstehen, dann dieses hervorragende Mittel nicht anzuwenden.
Variante B erlaubt CSS-fähigen Clients _genau das gleiche_ wie Variante A. Du kannst ....... Somit hat der Blinde die Möglichkeit, mehr Informationen aus dem ihm vorgelesenen Text zu entnehmen - er weiss nämlich, dass du den Begriff hervorheben wolltest.
Summa summarum bietest du dem "normalen", sehenden, einen modernen Browser benutzenden Besucher genau den gleichen Wert. Darüber hinaus hast du aber die Möglichkeit, weiteren Benutzergruppen ohne Mehraufwand erheblichen Mehrwert zu bieten! Gibt es einen plausiblen Grund, auf diese Möglichkeit zu verzichten?!
So kann Ich kann auf Javascript nicht verzichten, eine Navigation von mehr als 1300 Menüeinträgen, dazu noch hierachisch unter purem HTML zu gestalten, kommt einem aussichtslosem Vorhaben gleich.
Das ist wiederum eine falsche Perspektive. Es geht nicht darum, so etwas _entweder_ mit Javascript _oder_ mit HTML zugänglich zu machen - du hast die Möglichkeit, beides auf einen Schlag zu erledigen! Schau dir z.B. dieses Beispiel von Gernot an - einmal mit aktiviertem Javascript, einmal mit deaktiviertem.
If you are going to do something twice, you should think about ist and do it one time less.....
Hier bleibe ich bei meiner Meinung: 75 Menueinträge gegenüber 1300. Das fehlerfrei in HTML zu coden, oh weh!!!
Da stehen in HTML 15536 Bytes in 157 Zeilen und das für 75 Einträge!!!!! Help, help, das umgerechnet auf 1300 macht etwa 269290 Bytes. Dem gegenüber stehen bei meiner Lösung real in Javascript 68430 Bytes in 1400 Zeilen. Ich komme netto auf etwa 38 Bytes an Nutzdaten pro Eintrag, der ganze Overhead mit Javascript hat etwa 19000 Bytes, d.h. etwa 28% der zu transportierenden Daten sind Overheaddaten. In den 19000 Bytes stecken aber auch noch andere Javascript-Funktionen, die nicht unbedingt direkt mit dem Navigationsverzeichnis zusammenhängen, hier sind noch Navigationshilfen drin, die zur Kapitel- und Abschnittweiterschaltung dienen, die Navigationsfunktionen liegen bei insgesamt 5800 Bytes. Gernots Beispiel dürfte etwa nur 2850 Bytes an Nutzdaten haben, der Overhead beträgt satte 82% das Verhältnis würde sich auch nicht ändern, wenn man die Anzahl der Menueinträge verdoppeln würde. Bei meinem System kämen pro Eintrag 10 Bytes Overhead dazu. Nöö, brauch ich nicht weiter drüber nachzudenken, wo die bessere Lösung ist. Allein die Pflege eines solchen Inhaltsverzeichnis in HTML wäre absoluter Wahnsinn. Nööö, wirklich nöö, das wäre falscher Ehrgeiz.
Aber danke für den Hinweis, werd ich mir nochmal unter die Lupe nehmen, getreu dem Motto: Lieber schauen und klauen als selber bauen :-)... sofern es was zu klauen gibt... ;-)
Gruß f
MudGuard
Struppi