Bitte Code gegenlesen

[Frau Holle]

Hallo, bitte schlagt nicht gleich die Hände über den Kopf zusammen, wenn Ihr den Code seht. Er ist nicht doll, aber für mich recht logisch. Wo liegt der Fehler?

<script type="text/javascript">

if(screen.width == 1280) <img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation4">
      else
      if(screen.width == 1024) <img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation2">
       else
       if(screen.width == 1152) <img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation3">
        else
        if(screen.width = 800) <img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation1">
         else
         if(screen.width == 1600) <img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation5">;
      //-->
     </script>

Danke im vorraus :)

Gruß, Chris

[Cheatah]

Hi,

Hallo, bitte schlagt nicht gleich die Hände über den Kopf zusammen, wenn Ihr den Code seht. Er ist nicht doll, aber für mich recht logisch. Wo liegt der Fehler?

bei mir wird bereits in der ersten Codezeile eine Exception geschmissen, weil ich den Zugang zum für Dich in extremen Maße nutzfreien window.screen-Objekt unterbinde.

<script type="text/javascript">

Gut!

Benutzt Du XHTML? Andernfalls sehe ich keinen Grund, den JavaScript-Code nicht HTML-auszukommentieren.

if(screen.width == 1280) <img

Du hast da was falsch verstanden. Die Prüfung, ob irgendwas kleiner dem Wert der Variablen img ist, muss _in_ die Klammern. Außerdem musst Du jenes ominöse irgendwas auch spezifizieren.

src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation4">

All diese Zuweisungen musst Du entweder in eigene Zeilen schreiben (und ich vermute, Deinem if möchtest Du dann geschweifte Klammern verpassen), oder durch Semikolon voneinander trennen (und ebenfalls geschweifte Klammern setzen). Das "größer als" am Ende der Zeile ergibt hier keinen Sinn.

//-->

Ein Client, der <script> nicht kennt, wird diese Zeichen übrigens ausgeben.

Danke im vorraus :)

Wie lautet eigentlich die Fehlerbeschreibung?

Cheatah

P.S.: Das alt-Attribut ist im <img>-Tag *required*, *required*, *required*!

[Frau Holle]

Hi Cheatah,

bei mir wird bereits in der ersten Codezeile eine Exception geschmissen, weil ich den Zugang zum für Dich in extremen Maße nutzfreien window.screen-Objekt unterbinde.

Magst ja recht haben, aber eine andere Möglichkeit fällt mir nicht ein mein in folgendem Thread: [pref:t=38253&m=209431] beschriebenes Problem zu lösen. Danke, aber das Du weiter geschaut hast.

Benutzt Du XHTML? Andernfalls sehe ich keinen Grund, den JavaScript-Code nicht HTML-auszukommentieren.

Nein, benutze ich nicht. Html-auszukommentieren? Das schaue ich mir nochmal an, weiss jetzt nicht was gemeint ist, aber scheint relativ unwichtig für die Funktionalität zu sein.

Du hast da was falsch verstanden. Die Prüfung, ob irgendwas kleiner dem Wert der Variablen img ist, muss _in_ die Klammern. Außerdem musst Du jenes ominöse irgendwas auch spezifizieren.

Nein, der Wert, der verglichen werden soll ist screen.width. Wenn er 1280 ist, dann soll er das dahinter stehende img-tag laden. Also eine Deklaration von img brauche ich nicht, weil die zum tag gehört. Oder kann es sein, das ich hier nur ab src... ohne tag die Sachen reinschreiben muss? Probier ich gleich mal aus.

All diese Zuweisungen musst Du entweder in eigene Zeilen schreiben (und ich vermute, Deinem if möchtest Du dann geschweifte Klammern verpassen), oder durch Semikolon voneinander trennen (und ebenfalls geschweifte Klammern setzen). Das "größer als" am Ende der Zeile ergibt hier keinen Sinn.

ist tag-ende.

Ein Client, der <script> nicht kennt, wird diese Zeichen übrigens ausgeben.

Ja, das sind Feinheiten. Ich gehe erstmal aus, das Js zu 100% aktiviert ist.

Wie lautet eigentlich die Fehlerbeschreibung?

Gibt es einen Compiler für JS? Sry. Das ist so ziemlich das erste was ich in JS mache :(

P.S.: Das alt-Attribut ist im <img>-Tag *required*, *required*, *required*!

Funktioniert aber auch ohne. Warum sollte ich das hereinnehmen? Und warum wiederholst Du Dich? Ist Dir das so wichtig?

Danke für die schnelle Antwort

[benji]

Gibt es einen Compiler für JS? Sry. Das ist so ziemlich das erste was ich in JS mache :(

Glaub' ich auch. Du musst deinen Tag so etwa schreiben:

if(deine Bildschirmsachen)
{
document.write("<img src="blablabla">");
}

du kannst NICHT einfach so nen Tag schreiben !

P.S.: Das alt-Attribut ist im <img>-Tag *required*, *required*, *required*!
Funktioniert aber auch ohne. Warum sollte ich das hereinnehmen? Und warum wiederholst Du Dich? Ist Dir das so wichtig?

Nach den neusten HTML-4-Deklarationen wird das ALT-Attribut benötigt.

Zu den HTML-Kommentaren: <!-- und // --> sollte man machen, damit NO-JavaScript-Browser diesen Text NICHT abdrucken :|

Viel Spaß noch mit deinem "Baby" ...

PS: "Frau Holle" für ein Motorrad hört sich an wie ne schwangere Frau .... -> verdammt blöd

[Frau Holle]

if(deine Bildschirmsachen)
{
document.write("<img src="blablabla">");
}

So in etwa?
if(screen.width == 1280)
      { document.write("<img src="Images/Navigation_oben.jpg" width="810" height="94" border="0" usemap="#navigation4" alt="">"); }

else

Leider mault er noch rum, weil da ein } fehlen soll. Habe nirgends ein offenes. Kannst mir nochmal helfen?

Viel Spaß noch mit deinem "Baby" ...

PS: "Frau Holle" für ein Motorrad hört sich an wie ne schwangere Frau .... -> verdammt blöd

Mein Baby heißt ja nicht "Frau Holle", sondern "Baby". Und das ist ein schöner Name, find ich :) Danke, aber den Spass werd ich erst in 10 Tagen 1 Stunde und 53 Minuten haben. Aber dann ... :)

Danke an den, der die Überschrift in Ordnung gebracht hat. Sogar mühsames umkopieren. Danke.

[Cheatah]

Hi,

So in etwa?

ja; nur hast Du jetzt die Anführungszeichen sehr ungünstig geschachtelt.

{ document.write("<img src="

Aus Sicht eines Interpreters ist der String hiermit beendet. Nutze Singlequotes bzw. (bei tieferen Schachtelungsebenenen) das Escape-Zeichen "".

Cheatah

[Frau Holle]

ja; nur hast Du jetzt die Anführungszeichen sehr ungünstig geschachtelt.

{ document.write("<img src="

Aus Sicht eines Interpreters ist der String hiermit beendet. Nutze Singlequotes bzw. (bei tieferen Schachtelungsebenenen) das Escape-Zeichen "".

So ein blöder Fehler. Oh Gott. Schon .zig mal in der selfhtml gelesen. Vielen Dank Cheatah. Jetzt läuft es. Ich mach mich dann mal an eine Anpassung des Codes an die Browserfenster. Danke.

Gruß Chris

[Cheatah]

Hi,

Magst ja recht haben, aber eine andere Möglichkeit fällt mir nicht ein mein in folgendem Thread: [pref:t=38253&m=209431] beschriebenes Problem zu lösen.

ehrlich gesagt sehe ich dort spontan nichts, was die Verwendung des bekanntermaßen völlig nutzfreie Daten liefernden Objekts window.screen nötig machen würde. Such bitte im Archiv danach, welche Vielzahl absolut handelsüblicher Faktoren die gelieferten Werte "verfälschen", also von dem unterscheiden lassen, was Du gerne hättest. Nebenbei bemerkt ist es bereits als Zufall einzuordnen, wenn ausgerechnet einer der von Dir vorgesehenen Werte zurückkommt.

Html-auszukommentieren? Das schaue ich mir nochmal an, weiss jetzt nicht was gemeint ist, aber scheint relativ unwichtig für die Funktionalität zu sein.

Du hast das Kommentar-Ende in Deinem Code stehen, jedoch nicht den Kommentar-Anfang.

Du hast da was falsch verstanden. Die Prüfung, ob irgendwas kleiner dem Wert der Variablen img ist, muss _in_ die Klammern. Außerdem musst Du jenes ominöse irgendwas auch spezifizieren.
Nein, der Wert, der verglichen werden soll ist screen.width. [...]

Ich habe aus Sicht des JavaScript-Interpreters gesprochen. Für ihn ist "<" ein Vergleich auf "kleiner als", "img" der Name einer Variablen, "src" ebenfalls, 'src="..."' eine Zuweisung usw. Oder anders gesagt: JavaScript kennt kein HTML, Du hast aber versucht, HTML-Code als JavaScript-Anweisung zu notieren. Das klappt genausowenig wie

if (screen.width==1280) anweisungen1280.wav

wenn in dem Wave-File weitere Anweisungen vorgelesen werden.

Also eine Deklaration von img brauche ich nicht, weil die zum tag gehört. Oder kann es sein, das ich hier nur ab src... ohne tag die Sachen reinschreiben muss? Probier ich gleich mal aus.

Nein, Du sollst JavaScript-Code schreiben. Beispielsweise alert('<img src="..." usw.>'), wobei ich stark vermute, dass Du etwas leicht anderes suchst.

ist tag-ende.

Nicht für JavaScript, welches insbesondere keine Tags kennt.

Ja, das sind Feinheiten. Ich gehe erstmal aus, das Js zu 100% aktiviert ist.

Für Testzwecke reicht diese Annahme, weil Du sie auf dem Testsystem (Deinem Rechner) garantieren kannst. In der Realität hast Du hiermit jedoch ein Problem.

Wie lautet eigentlich die Fehlerbeschreibung?
Gibt es einen Compiler für JS? Sry. Das ist so ziemlich das erste was ich in JS mache :(

Für clientseitiges JavaScript sicher nicht; bei exotischeren Varianten bin ich mir da nicht sicher. Das ist für eine Fehlerbeschreibung jedoch nicht relevant.

P.S.: Das alt-Attribut ist im <img>-Tag *required*, *required*, *required*!
Funktioniert aber auch ohne.

"Funktioniert" ist kein Argument. Das W3C hat sich etwas dabei gedacht, dieses Attribut als required zu deklarieren - nämlich dass keinesfalls vorausgesetzt werden kann und _darf_, dass ein Client (nicht nur "Browser") (alle) Bilder anzeigt. Der ALTernative Text ist für genau diese Fälle von höchster Brisanz.

Und warum wiederholst Du Dich? Ist Dir das so wichtig?

Ich wiederhole mich deshalb, weil das ein nur allzu gern gemachter Fehler ist, der *ständig* korrigiert werden muss, was mir zeigt, dass sich kaum jemand die Mühe macht, meine (oder die anderer) früher gemachten - oft sehr umfangreichen - Ausführungen nachzurecherchieren und ich also mehr oder minder gegen Mauern rede. Für jemanden, der in vielen mühsamen Stunden seine Fachkompetenz und sein Herzblut in Postings presst, ist das nicht unwesentlich frustrierend.

Cheatah

[molily]

Hallo,

Benutzt Du XHTML? Andernfalls sehe ich keinen Grund, den JavaScript-Code nicht HTML-auszukommentieren.

Welchen Grund gäbe es denn, den JavaScript-Code auszukommentieren? Welche praktische Relevanz hat diese Methode noch, welche auf sieben Jahre alte, ohne Zweifel absolut antiquierte Browser (MSIE 2 und Netscape 1) abzielt?

Meiner Meinung nach keine. Selbst bei Inline-Styles über das style-Element verwende ich diese Methode nicht, wenngleich hier bereits Netscape 3 problematisch wird.

In Anbetracht der Tatsache, dass Diskussionen geführt werden, ob der Steinzeitbrowser Netscape 4.x noch aktiv unterstützt werden soll, halte ich es für reichlich absurd, für die (wenn auch passive) Unterstützung von Netscape 1 zu plädieren. (Von Browser Upgrade-Kampagnen à la »To hell with bad browsers« ganz zu schweigen.)

Sicherlich ist es nicht mit Aufwand verbunden, Scripts und Styles auszukommentieren, dennoch würde ich eher dazu umschwenken, Gründe *dafür* zu suchen anstatt es als selbstverständliche Konvention hinzunehmen. (Wie lange dauert die »Verjährungsfrist«, vielleicht noch einmal 5-6 Jahre? ;))

//-->

Ein Client, der <script> nicht kennt, wird diese Zeichen übrigens ausgeben.

Wieviel Prozent (Promille?) seiner Besucher verwenden wohl Netscape 1 als regulären Browser? Wieviel Prozent davon sind sich nicht bewusst, dass sie einen aus heutiger Sicht rundum vermurksten Browser verwenden?

Grüße,
Mathias

[Frau Holle]

Da ich den anderen Thread weder hier noch im Archiv finde, will ich mich hier für Deine Hilfe bedanken.
Also, Danke molily

[Cheatah]

Hi,

Benutzt Du XHTML? Andernfalls sehe ich keinen Grund, den JavaScript-Code nicht HTML-auszukommentieren.
Welchen Grund gäbe es denn, den JavaScript-Code auszukommentieren? Welche praktische Relevanz hat diese Methode noch, welche auf sieben Jahre alte, ohne Zweifel absolut antiquierte Browser (MSIE 2 und Netscape 1) abzielt?

welchen Grund gibt es, die Existenz dieser und ähnlicher Browser zu ignorieren? Tut die Kommentierung weh? Schadet sie? Beide Fragen können IMHO verneint werden.

Meiner Meinung nach keine. Selbst bei Inline-Styles über das style-Element verwende ich diese Methode nicht, wenngleich hier bereits Netscape 3 problematisch wird.

Das ist ganz allein Deine Entscheidung. Ich würde sie keinen Moment teilen.

In Anbetracht der Tatsache, dass Diskussionen geführt werden, ob der Steinzeitbrowser Netscape 4.x noch aktiv unterstützt werden soll,

Solche Diskussionen werden vorwiegend von Leuten geführt, deren Erfahrungsschatz noch zu wünschen übrig lässt. Ich habe nur selten erlebt, dass Fachleute darüber ernsthaft nachgedacht haben.

halte ich es für reichlich absurd, für die (wenn auch passive) Unterstützung von Netscape 1 zu plädieren.

Warum redest Du eigentlich nur von Browsern, zudem nur von solchen mit einer graphischen Darstellung? Es gibt andere Clients. Wie verhalten die sich, kannst Du das mit Gewissheit sagen?

Ein Client, der <script> nicht kennt, wird diese Zeichen übrigens ausgeben.
Wieviel Prozent (Promille?) seiner Besucher verwenden wohl Netscape 1 als regulären Browser?

Ich rede bewusst von Clients, nicht von Browsern. Hast Du eigentlich schon mal einen Blindenbrowser gesehen? Das sind meist vorwiegend mechanische Geräte - dort sollte nicht wirklich mit aktueller Software gerechnet werden.

Wieviel Prozent davon sind sich nicht bewusst, dass sie einen aus heutiger Sicht rundum vermurksten Browser verwenden?

Muss man es denen bewusst erschweren, wenn *vier Bytes* das Problem beheben?

Cheatah

[molily]

Hallo Cheatah,

Benutzt Du XHTML? Andernfalls sehe ich keinen Grund, den JavaScript-Code nicht HTML-auszukommentieren.

Welchen Grund gäbe es denn, den JavaScript-Code auszukommentieren? Welche praktische Relevanz hat diese Methode noch, welche auf sieben Jahre alte, ohne Zweifel absolut antiquierte Browser (MSIE 2 und Netscape 1) abzielt?

welchen Grund gibt es, die Existenz dieser und ähnlicher Browser zu ignorieren?

Mir ging es darum, die reale Verbreitung und Benutzung anzuzweifeln, nicht die »Existenz« zu ignorieren, das heißt zu ignorieren, dass es irgendwann in grauer Vorzeit einen Browser gab, der script-Elemente nicht verstand. Mosaic, der line mode browser und Co. existieren deiner Definition nach auch, dennoch wird man mit ihnen nur durchs Web stolpern können, da sie nicht einmal Virtual Hosts verstehen. Es ist sicher keine annehmbare Konsequenz, nur noch eine Domain pro IP zu verwenden, selbst wenn wissentlich diese und ähnliche Browser nicht berücksichtigt werden werden.

Tut die Kommentierung weh? Schadet sie?

Nein, wie gesagt, bei HTML nicht. Dennoch würde ich es heute nicht mehr als obligatorisch darstellen (darum ging es mir). Viele Sites verwenden außerdem XHTML produktiv - Vom skeptischen »man kann nie wissen«-Standpunkt wäre schon HTML 3.2 problematisch.

In Anbetracht der Tatsache, dass Diskussionen geführt werden, ob der Steinzeitbrowser Netscape 4.x noch aktiv unterstützt werden soll,

Solche Diskussionen werden vorwiegend von Leuten geführt, deren Erfahrungsschatz noch zu wünschen übrig lässt.

Wieso? Ich würde das Gegenteil behaupten, es sind eher diejenigen, die eine Site rationalisiert mit CSS layouten wollen und trotz intensiver Auseinandersetzung mit den unzähligen Browserbugs unter anderem an Netscape 4.x scheitern, sodass sie den Schritt wagen wollen, dem NS 4.x und anderen alten Browsern nur ein abgespecktes Stylesheet zu liefern, da die Alternative konventionelles Layout wäre, was durch HTML-Formatierungen schlecht zu pflegen ist.

Ich habe nur selten erlebt, dass Fachleute darüber ernsthaft nachgedacht haben.

Ich sehe hier ständig Diskussionen und sehe vor allem auch ständig Sites, welche oben genannte Techniken anwenden, sicher nicht aufgrund von Faulheit oder Unkenntnis über mögliche Wege. Deine Definition von »Fachleute« kenne ich nicht, ich weiß aber nicht, welche Relevanz dies haben soll.

halte ich es für reichlich absurd, für die (wenn auch passive) Unterstützung von Netscape 1 zu plädieren.

Warum redest Du eigentlich nur von Browsern,

Was gibt es außer HTTP/HTML-Benutzeragenten sonst noch für Webseiten darstellende Software, welche kein script-Element kann? ;)

zudem nur von solchen mit einer graphischen Darstellung?

Ich finde keine zuverlässigen Angaben darüber, ab welcher Version Lynx script versteht (und dann ignoriert). Diesbezüglich muss ich leider darauf vertrauen, dass der Rest der Site zugänglich genug ist, sodass ein paar unauskommentierte lokale Styles den Besucher nicht an der grundlegenden Benutzung der hindern. Theoretisch dürfte es auch nicht schwer sein, dass er sich sofern darüber beschwert, da Kontaktformular usw. nicht weit sind. Darauf sollte man natürlich nicht vertrauen und diesem Ärger vorher begegnen, soweit stimme ich dir zu. Dennoch brauche ich vielleicht noch Hunderttausend Besucher mehr, damit dieser Fall zum ersten Mal eintritt und kein hypothetisches Gedankenspiel bleibt, was es momentan m.E. ausschließlich ist.

Es gibt andere Clients. Wie verhalten die sich, kannst Du das mit Gewissheit sagen?

Dieses Argument ist hinfällig, da es diese Gewissheit nicht geben kann und nicht geben wird. Diesen Einwand kannst du bezüglich jeder im Web verwendeten (clientseitigen) Technik bringen. Ich kann auch nicht mit Gewissheit sagen, ob mein Markup oder meine Styles nicht bei einem nicht kalkulierbaren Browser einen Absturz verursachen (schlechter Vergleich, denn die von mir genannten Browser sind mehr oder weniger kalkulierbar, aber du sprachst ausdrücklich andere Clients an). Ich kann lediglich die mir bekannten beziehungsweise verfügbaren Browser im Auge behalten und mich soweit es geht über andere wichtige informieren. Und nicht einmal das ist möglich, ich werde beispielsweise wahrscheinlich nie erfahren beziehungsweise »mit Gewissheit (voraus-)sagen« können, wie meine Sites im OmniWeb oder iCab (oder ...) aussehen. Insofern ist es weder möglich noch sinnvoll, über Browser mit nicht messbarer Relevanz zu spekulieren geschweige denn sie zu »berücksichtigen«.
Man wird auch, wie ich sagte, in fünf oder sechs Jahren nicht mit Gewissheit sagen können, ob sich alle Browser entsprechend verhalten. Diese Tatsache lässt dennoch keine Schlüsse zu, wie man handeln soll.

Ein Client, der <script> nicht kennt, wird diese Zeichen übrigens ausgeben.

Wieviel Prozent (Promille?) seiner Besucher verwenden wohl Netscape 1 als regulären Browser?

Ich rede bewusst von Clients, nicht von Browsern.

»Browser« definiere ich im WWW-Kontext als ein Programm, welches den Inhalt von Hypertextseiten ausgibt beziehungsweise durch Interaktion navigierbar macht, wozu sich dann meist auch die Unterstützung der Übertragungsprotokolle gesellt. »Browsing« ist in Hypertextsystemen klar definiert.

Hast Du eigentlich schon mal einen Blindenbrowser gesehen? Das sind meist vorwiegend mechanische Geräte - dort sollte nicht wirklich mit aktueller Software gerechnet werden.

Der Microsoft Internet Explorer ist beispielsweise ein unter Blinden weit verbreiteter Browser, die Transformation übernimmt eine Zusatzsoftware. Mechanische Geräte werden eher zur Aus- und Eingabe verwendet.

Wieviel Prozent davon sind sich nicht bewusst, dass sie einen aus heutiger Sicht rundum vermurksten Browser verwenden?

Muss man es denen bewusst erschweren, wenn *vier Bytes* das Problem beheben?

Wieso vier, ich denke mindestens acht, wenn man von acht Bit pro Byte ausgeht. ;) Hinzu kommen die beiden Newlines, nicht auszumalen, wieviel zusätzlicher Speicher verquast wird! Du handelst im Auftrag eines Webhosters, gestehe! ;)

Grüße,
Mathias

[Cheatah]

Hi,

Welchen Grund gäbe es denn, den JavaScript-Code auszukommentieren? Welche praktische Relevanz hat diese Methode noch, welche auf sieben Jahre alte, ohne Zweifel absolut antiquierte Browser (MSIE 2 und Netscape 1) abzielt?
welchen Grund gibt es, die Existenz dieser und ähnlicher Browser zu ignorieren?
Mir ging es darum, die reale Verbreitung und Benutzung anzuzweifeln, nicht die »Existenz« zu ignorieren,

genau darum geht es aber: Wenn man für das Internet entwickelt, entwickelt man für _alles_, was dort eine wie auch immer geartete Daseinsberechtigung hat. 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. Die vielen nicht-Browser-Clients natürlich ebenfalls nicht zu vergessen.

Mosaic, der line mode browser und Co. existieren deiner Definition nach auch, dennoch wird man mit ihnen nur durchs Web stolpern können, da sie nicht einmal Virtual Hosts verstehen.

Es gibt Clients, die in Sachen HTTP auf dem neuesten Stand sind, nicht jedoch in Sachen HTML.

Tut die Kommentierung weh? Schadet sie?
Nein, wie gesagt, bei HTML nicht. Dennoch würde ich es heute nicht mehr als obligatorisch darstellen (darum ging es mir).

In HTML ist es IMHO noch immer obligatorisch.

Viele Sites verwenden außerdem XHTML produktiv

In XHTML nicht mehr. Ich bin mir nicht sicher, ob es dort Empfehlung ist, auf HTML-Kommentare innerhalb von <script> zu verzichten, oder sogar Pflicht.

• Vom skeptischen »man kann nie wissen«-Standpunkt wäre schon HTML 3.2 problematisch.

Nein, keinesfalls. HTML ist abwärtskompatibel. XHTML hingegen ist problematisch, sollte daher mit Vorsicht genossen werden. In dem Moment, wo man sich für XHTML entscheidet, ist jedoch klar, dass man dies konsequent macht.

In Anbetracht der Tatsache, dass Diskussionen geführt werden, ob der Steinzeitbrowser Netscape 4.x noch aktiv unterstützt werden soll,
Solche Diskussionen werden vorwiegend von Leuten geführt, deren Erfahrungsschatz noch zu wünschen übrig lässt.
Wieso?

Weil es dem Profi egal ist, welchen Browser sein Kunde verwendet. Es lässt sich ohne weiteres Code so erzeugen, dass er kompatibel zu _allem_ ist - ohne die jeweiligen Systeme überhaupt zu kennen. Es erfordert _aktives Eingreifen_, diese Kompatibilität zu unterminieren. 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.

Ich würde das Gegenteil behaupten, es sind eher diejenigen, die eine Site rationalisiert mit CSS layouten wollen und trotz intensiver Auseinandersetzung mit den unzähligen Browserbugs unter anderem an Netscape 4.x scheitern,

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. Um auf weniger guten Systemen optisch ansprechende Ergebnisse zu erzielen, muss man diese in der Tat kennen und an den Unwägbarkeiten vorbeischiffen - _das_ ist etwas, was man sich gerne sparen darf. Nicht aber, JavaScript-Code als Inhalt zu präsentieren, nur weil man nicht daran gedacht hat, dass manche Clients kein <script> kennen.

Ich habe nur selten erlebt, dass Fachleute darüber ernsthaft nachgedacht haben.
Ich sehe hier ständig Diskussionen

Das steht in keinem Widerspruch zu meiner Aussage.

und sehe vor allem auch ständig Sites, welche oben genannte Techniken anwenden, sicher nicht aufgrund von Faulheit oder Unkenntnis über mögliche Wege.

Moment. Der Einsatz von CSS (o.ä.) unter Nichtberücksichtigung nicht-CSS-fähiger Systeme ist _kein_ Problem - CSS ist darauf ausgerichtet, genau hierfür eingesetzt zu werden. Auf einem Netscape 3 sieht es dann eben einfach anders aus. Na und? Trotzdem funktioniert alles einwandfrei, der Inhalt ist voll und ganz zugänglich.

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. Das W3C erstellt die Standards _bewusst_ so, dass sie abwärtskompatibel sind. Nur begehen viele Leute den Irrtum zu glauben, Seiten müssen unbedingt auf allen Browsern identisch aussehen - das ist aber Unsinn. Praktisch keine Seite sieht mit einem aktuellen lynx (und ja, lynx _ist_ aktuell) so aus wie mit Mozilla oder einem IE. Das geht gar nicht! Und es braucht auch nicht zu gehen. Das Internet ist keine graphische Präsentation, wie es etwa bei einer Zeitschrift der Fall ist. Es kennt eine Vielzahl absolut gültiger, aber völlig unterschiedlicher Darstellungen identischer Inhalte. Nicht umsonst gibt es bei CSS die Möglichkeit, eine akustische Darstellung zu empfehlen.

halte ich es für reichlich absurd, für die (wenn auch passive) Unterstützung von Netscape 1 zu plädieren.
Warum redest Du eigentlich nur von Browsern,
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? Übrigens geht es hier ausschließlich um HTTP/HTML-Benutzeragenten - aber nicht eben nur um Browser (und schon gar nicht nur um graphische Browser).

Ich finde keine zuverlässigen Angaben darüber, ab welcher Version Lynx script versteht (und dann ignoriert).

Das kann ich Dir auch nicht mitteilen. Jedoch ist lynx keinesfalls der einzige nicht-graphische Browser. Warst Du jemals blind und hast Dir Webseiten mit den Fingern angesehen? Oder vorlesen lassen?

Dennoch brauche ich vielleicht noch Hunderttausend Besucher mehr, damit dieser Fall zum ersten Mal eintritt und kein hypothetisches Gedankenspiel bleibt, was es momentan m.E. ausschließlich ist.

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. Und komm mir jetzt bitte nicht mit dem Argument, Du würdest auf Deiner Homepage nichts verkaufen :-)

Es gibt andere Clients. Wie verhalten die sich, kannst Du das mit Gewissheit sagen?
Dieses Argument ist hinfällig, da es diese Gewissheit nicht geben kann und nicht geben wird.

Doch, die 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. Es mögen einzelne sein, nur einer unter Millionen - aber wenn ausgerechnet dieser _der_ Kunde hätte werden wollen, hätte sich die Aufwandseinsparung (ja, sich an Standards&Co. zu halten _spart_ Aufwand) absolut gelohnt.

Diesen Einwand kannst du bezüglich jeder im Web verwendeten (clientseitigen) Technik bringen.

Nein. Clientseitige Techniken, die einem (W3C-, IETF-)Standard unterliegen, lassen sich _immer_ optional einsetzen. Sie sind absolut kompatibel mit Systemen, die sie nicht beherrschen.

Ich kann auch nicht mit Gewissheit sagen, ob mein Markup oder meine Styles nicht bei einem nicht kalkulierbaren Browser einen Absturz verursachen (schlechter Vergleich, denn die von mir genannten Browser sind mehr oder weniger kalkulierbar, aber du sprachst ausdrücklich andere Clients an).

Ja, es kann immer Programme/Systeme geben, die auf völlig normale und korrekte Dinge absurd reagieren. 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. Auch auf Text. Und das ist zugegebenermaßen Blödsinn :-)

Ich kann lediglich die mir bekannten beziehungsweise verfügbaren Browser im Auge behalten

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! Die Betrachtung, welcher Browser jetzt wie sehr verbreitet ist, wie viele was können etc., ist vollkommen überflüssig, sie hilft Dir nicht. 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.

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.

Ich rede bewusst von Clients, nicht von Browsern.
»Browser« definiere ich im WWW-Kontext als ein Programm, welches den Inhalt von Hypertextseiten ausgibt beziehungsweise durch Interaktion navigierbar macht,

Ja, das ist korrekt. Gerade der letzte Teilsatz impliziert jedoch einen Menschen, der das Programm bedient - und das ist nur bei einem relativ geringen Teil der Clients der Fall.

Muss man es denen bewusst erschweren, wenn *vier Bytes* das Problem beheben?
Wieso vier, ich denke mindestens acht, wenn man von acht Bit pro Byte ausgeht. ;) Hinzu kommen die beiden Newlines, nicht auszumalen, wieviel zusätzlicher Speicher verquast wird! Du handelst im Auftrag eines Webhosters, gestehe! ;)

*g* Verdammt, ich bin erkannt ;-)

Cheatah

[molily]

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.

[Orlando]

Hi Mathias,

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

Muss ich ein Layout so umsetzen,

• dass Lynx Elemente positioniert? Nein, weil die Seite trotzdem funktionieren wird.
• dass Netscape 4 das gleiche Ergebnis zeigt, wie moderne Browser? Nein, weil... (s. oben).
• dass <abbr> im M$IE das gleiche Ergebnis zeigt, wie in modernen Browsern? Nein, weil... (s. oben).

Ich bin selbstverständlich ein Befürworter korrekten Markups, aber muss ich tatsächlich alles, was gute Browser beherrschen in weniger guten bis sehr schlechten Browsern mit Gewalt *nachbilden*?

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.

Verstecken ist manchmal notwendig, um die Funktionalität zu gewährleisten, die Fehler der Browser auszubessern ist es dagegen nicht.

LG Roland

[molily]

Hallo Orlando,

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

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

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

Die Wirkung der Seite wird unter Umstände massiv leiden, je nachdem, mit welchem Mitteln bzw. über welche Faktoren sie »funktioniert«, was Hintergründe und Ziele sind. 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.

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

Strukturelles/semantisches Markup zugunsten von Zugänglichkeit ist sinnlos, wenn es nicht kommuniziert wird. 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. 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 bin selbstverständlich ein Befürworter korrekten Markups, aber muss ich tatsächlich alles, was gute Browser beherrschen 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. Ich kann nicht guten Gewissens mit dem Bewusstsein, dass die eingebauten Zugänglichkeitsfunktionen sowieso niemandem helfen, meine Seiten WCAG-konform nennen.

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.

Verstecken ist manchmal notwendig, um die Funktionalität zu gewährleisten, die Fehler der Browser auszubessern ist es dagegen nicht.

Unsere Definitionen von »Funktionalität« divergieren, diese Diskussion hatten wir schon öfters. 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.  Gemäß dem Beispiel funktioniert eine Seite, falls der Text trotz eventuellen Stolperstellen wie Abkürzungen et cetera kommuniziert(»herübergebracht«) wird. 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 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. 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). 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. 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. Ich verstehe nicht, wieso du dich gerade am genannten simplen Workaround störst.

Grüße,
Mathias

[Calocybe]

Moin!

Mosaic, der line mode browser und Co. existieren deiner Definition nach auch, dennoch wird man mit ihnen nur durchs Web stolpern können, da sie nicht einmal Virtual Hosts verstehen. Es ist sicher keine annehmbare Konsequenz, nur noch eine Domain pro IP zu verwenden, selbst wenn wissentlich diese und ähnliche Browser nicht berücksichtigt werden werden.

Gilt uebrigens auch fuer IE2. ;-)

Was gibt es außer HTTP/HTML-Benutzeragenten sonst noch für Webseiten darstellende Software, welche kein script-Element kann? ;)

Es gibt sicherlich einen Haufen Scripte da draussen, die Webseiten abziehen und in einer Weise weiterverarbeiten, die an sich nicht erfordert, mehr zu tun als alles zwischen den Tags zu extrahieren und dann noch Kommentare rauszuschmeissen. (Hab selbst vor langer Zeit einiges in der Art geschrieben.) Nur wegen Script und Style muss man dann doch noch einen richtigen Parser anwerfen. Ja gut, die Inhalte von ALT und TITLE gehen ohne Parser floeten, aber naja. Den Leuten wuerde es schon entgegenkommen, wenn man diese Bereiche auskommentiert. Bei XHTML werden die dann aber auch nicht mehr um die ganze Arbeit herumkommen.

Wieso vier, ich denke mindestens acht, wenn man von acht Bit pro Byte ausgeht. ;) Hinzu kommen die beiden Newlines, nicht auszumalen, wieviel zusätzlicher Speicher verquast wird! Du handelst im Auftrag eines Webhosters, gestehe! ;)

Newlines kommen doch ziemlich viele in HTML-Seiten vor, daher muessten die sich mit gzip eigentlich recht gut wegkomprimieren lassen. ;-)

So long

[Calocybe]

Hi!

Also ich weiss nicht, vielleicht bin ich ja blind geworden, aber ich kann ums Verrecken nicht finden, wo gesagt wird, dass der Inhalt von <SCRIPT>-Elementen nicht gerendert werden darf. (Das bezieht sich jetzt auf HTML4-konforme Browser, nicht irgendwelche aelteren.) http://www.w3.org/TR/html40/interact/scripts.html Ich dachte bisher, nicht-script-faehige Browser muessten den <SCRIPT>-Inhalt ignorieren, wenn sie HTML4-konform sein wollen. Aber so duerfte ja jeder Browser mit ausgeschaltetem JS den Inhalt anzeigen, wenn er nicht auskommentiert ist.

Fuer <STYLE>-Elemente steht das Verbot aber in eindeutigen Worten da: http://www.w3.org/TR/html40/present/styles.html#h-14.2.3.

So long

[Joachim]

hi,

Wo liegt der Fehler?

Darin, dass Du annimmst, Screen und Browserfenstergroesse sind das Gleiche. Deine Abfrage sollte also die Browserfenstergroesse betreffen:

(nc) window.innerWidth, (ie) document.body.clientWidth, (dom) document.documentElement.clientWidth

Ansonsten: was soll das? if(bedingung) <img src="...">

Wenn Du per JS was ins Dokument schreiben willst nutze die Methoden des Dokumentes, z. B. document.write(string)

Grundsaetzlich wuerde ich Dein Konzept noch mal ueberdenken. Es gibt unzaehlige Moeglichkeiten, sein Browserfenster zu oeffnen, die Du nicht alle abdecken kannst. Lerne, was Screen-Design vom Print-Design unterscheidet: die Flexibilitaet des Layoutes!

Gruesse  Joachim

[Frau Holle]

hallo joachim

Darin, dass Du annimmst, Screen und Browserfenstergroesse sind das Gleiche. Deine Abfrage sollte also die Browserfenstergroesse betreffen:

(nc) window.innerWidth, (ie) document.body.clientWidth, (dom) document.documentElement.clientWidth

Das nehme ich nicht an. Aber es ist ersteinmal einfacher das anzunehmen um ein Grundgerüst zuschaffen. Wenn ich hier noch browserspezifische Entscheidungen reinstelle, dann wächst der Code und damit auch die Fehlerwahrscheinlichkeit. Ziel ist es den Code erst einmal zu minimieren und dann Schritt für Schritt drauf aufzubeuen. So habe ich das in allen Sprachen (Assembler, Cobol, C++) gelernt. Ich bin da halt noch neu. Und je weniger Code, desto weniger Fehler.

Ansonsten: was soll das? if(bedingung) <img src="...">

Wenn Du per JS was ins Dokument schreiben willst nutze die Methoden des Dokumentes, z. B. document.write(string)

Grundsaetzlich wuerde ich Dein Konzept noch mal ueberdenken. Es gibt unzaehlige Moeglichkeiten, sein Browserfenster zu oeffnen, die Du nicht alle abdecken kannst. Lerne, was Screen-Design vom Print-Design unterscheidet: die Flexibilitaet des Layoutes

Ich möchte gerne auf meiner Seite: http://www.chrisgideon.com/ alles skalierbar machen (Naja, also images, Tabellen, Frames, Border, Schriftartengröße,..). Nun habe ich ein Problem bei dem oberen Frame. Dort wird eine Grafik geladen. Aber ich möchte gerne dort [b]verschiedene[/b] Links anbringen. Das mache ich zur Zeit mit maps. Leider haben die ja feste Koordinaten. Also wenn ich das Bild mitskalieren lasse, dann bleiben die Koordinaten fix, und die Links funktionieren nicht. Wie kann ich das umgehen?

Meine bisherigen Lösungsansätze:

• Bild als Hintergrundbild: Funktioniert nicht, weil nicht die Größe des Bildes angepasst wird, sondern der Hintergrund mit 100% aufgefüllt wird. Also wird bleibt das Bild in Originalauflösung, wird aber wiederholt.Das wiederholen kann ich ausstellen, aber dann passt sich das Bild trotzdem nicht an.

• Mit DIV: ich habe in der css:
  [Code]
  html,body,div { height:100%; width:100%; margin:0; padding:0; }
  div { position:absolute; }
  [/Code]

und in der html:

[Code]
<table border="2" align="center" width="80%" height="100%">
     <tr>
       <td height="80%"><a href="../../index.html">
       <div style="z-index:1;"><img src="Bildadresse.jpg" width="100%" height="100%" border="0" alt=""></div>
 <div style="z-index:2;">Linktext</div>
     </tr>
[/Code]

Da passt sich das Bild auch nicht gerade sehr gut an. Wenn das mal einer sehen möchte, dann lade ich es schnell up. Danke für die Hilfe. Und bitte fragt, wenn irgendetwas unklar ist. Wenn das nämlich in Ordnung ist, dann sind nur noch kleinere Fehler zu beseitigen :)

Und dafür ist die Javascript Entscheidung. Wenn eine bestimmte Auflösung, dann sollen die Maße des Bildes verändert werden und ein anderes Map geladen werden. Ich weiss leider keine andere Möglichkeit und würde gerne auf Js verzichten. Auch gefällt mir nicht, das es nicht 100% dynamisch ist. Aber es ist erstmal besser als gar nichts.

Gruß, Chris

[Cheatah]

Hi,

Das nehme ich nicht an. Aber es ist ersteinmal einfacher das anzunehmen um ein Grundgerüst zuschaffen.

ja.

Wenn ich hier noch browserspezifische Entscheidungen reinstelle, dann wächst der Code und damit auch die Fehlerwahrscheinlichkeit.

Grundsätzlich ist das nicht falsch. In diesem Fall sorgst Du mit einer "umfangreicheren" Abfrage jedoch dafür, dass es funktioniert - während bei Deinem jetzigen Stand das Ergebnis stark vom Zufall abhängt und ganz nebenbei bemerkt selbst bei richtigem Ergebnis höchst selten den Wunsch des Users treffen dürfte.

Insgesamt betrachtet behaupte ich übrigens, dass allein die Existenz Deines Problems auf einen starken Konzeptfehler hindeutet. Warum zwischen unterschiedlichen clientseitigen Begebenheiten unterscheiden?

Ziel ist es den Code erst einmal zu minimieren und dann Schritt für Schritt drauf aufzubeuen.

Wie gesagt: Im Prinzip richtig. Allerdings steht _vor_ jedem Code ein Konzept - wenn bereits dieses fehlerhaft ist, bringt Dir der schönste Code nichts.

Ich möchte gerne auf meiner Seite: http://www.chrisgideon.com/ alles skalierbar machen (Naja, also images, Tabellen, Frames, Border, Schriftartengröße,..).

Das braucht der User nicht. Er hat sich sein System so eingerichtet, dass er, wenn Du nicht aktiv seine Einstellungen missachtest (etwa durch feste Schriftgrößen), alles ideal erkennen kann. Vertraue ihm einfach.

Und dafür ist die Javascript Entscheidung.

Wenn Du im Internet agierst, _muss_ Dein Konzept deaktiviertes JavaScript beachten. Solange Du also keine Lösung für ein (beliebiges) Problem hast, die ohne JS funktioniert, brauchst Du auch gar nicht an einer JS-Variante zu arbeiten. Schrittweises Vorgehen ist absolut richtig; Du beginnst jedoch mit dem falschen Schritt.

Wenn eine bestimmte Auflösung,

Die Auflösung ist irrelevant. Was window.screen Dir liefert, hat zudem mit der Auflösung nichts zu tun. Siehe auch Archiv.

Cheatah

[Frau Holle]

Grundsätzlich ist das nicht falsch. In diesem Fall sorgst Du mit einer "umfangreicheren" Abfrage jedoch dafür, dass es funktioniert - während bei Deinem jetzigen Stand das Ergebnis stark vom Zufall abhängt und ganz nebenbei bemerkt selbst bei richtigem Ergebnis höchst selten den Wunsch des Users treffen dürfte.

Stark vom Zufall? Meine Breite ist 1280. Ich kann an meinen Browsern machen was ich will, sie bleibt auf 1280. Und das Ergebnis trifft also zu 100% zu, wenn die 1280 in der Abfrage definiert werden.

Insgesamt betrachtet behaupte ich übrigens, dass allein die Existenz Deines Problems auf einen starken Konzeptfehler hindeutet. Warum zwischen unterschiedlichen clientseitigen Begebenheiten unterscheiden?

Weil ich nicht weiss, wie ich das Bildchen auf meiner Seite sonst anpassen soll. Ich will, dass es dynamisch ist, aber die Links auf dem Bild funktionieren.
Das ist meine erste Seite. Also war mein Konzept eher so:" ".
Ich habe angefangen mit Frontpage, und mal geguckt, was ich schön finde. Dann habe ich das per Editor bereinigt. Danach alles auf Frames umgestellt. Dann alles auf css. Und jetzt ist halt die Dynamik dran. Das ist soweit fertig. Fehlt nur noch die Schriftgrösse (in der css) und das Bild. Also der Konzeptfehler bei mir war, das ich kein Konzept hatte. Aber ich finde persönlich die bisherige Arbeit nicht gerade übel, und das ist die Hauptsache.

Wie gesagt: Im Prinzip richtig. Allerdings steht _vor_ jedem Code ein Konzept - wenn bereits dieses fehlerhaft ist, bringt Dir der schönste Code nichts.

Also ich denke, das alles in der IT-Welt mit Code umsetzbar ist. Gerade in Assembler wird das fast auf jedem Lehrgang gelehrt. Man muss nur wissen mit welchen Werkzeugen, oder diese sich selber basteln.

Das braucht der User nicht. Er hat sich sein System so eingerichtet, dass er, wenn Du nicht aktiv seine Einstellungen missachtest (etwa durch feste Schriftgrößen), alles ideal erkennen kann. Vertraue ihm einfach.

Hmm, das bringt mich echt zum Nachdenken. Aber wie heißt es: "Vertrauen ist gut, Kontrolle ist besser"

Wenn Du im Internet agierst, _muss_ Dein Konzept deaktiviertes JavaScript beachten. Solange Du also keine Lösung für ein (beliebiges) Problem hast, die ohne JS funktioniert, brauchst Du auch gar nicht an einer JS-Variante zu arbeiten. Schrittweises Vorgehen ist absolut richtig; Du beginnst jedoch mit dem falschen Schritt.

Nein, ich habe ja schon eine Lösung für eine Darstellung ohne Js. Da wird das Bild einfach mit Standardwerten (für 800x600) ausgeliefert. Fertig. Sieht nicht genial aus, wenn der Benutzer eine 1600er Auflösung und Vollbild hat, aber es sieht dann auch nicht anders aus, als jetzt.

Wenn eine bestimmte Auflösung,

Die Auflösung ist irrelevant. Was window.screen Dir liefert, hat zudem mit der Auflösung nichts zu tun. Siehe auch Archiv.

? Also ich habe mir den Wert von dem verwendeten "screen.width" per alert-box ausgeben lassen und er passt.

Gruß Chris

[Cheatah]

Hi,

Grundsätzlich ist das nicht falsch. In diesem Fall sorgst Du mit einer "umfangreicheren" Abfrage jedoch dafür, dass es funktioniert - während bei Deinem jetzigen Stand das Ergebnis stark vom Zufall abhängt und ganz nebenbei bemerkt selbst bei richtigem Ergebnis höchst selten den Wunsch des Users treffen dürfte.
Stark vom Zufall? Meine Breite ist 1280.

meinetwegen. Sagt das auch window.screen.width? - Wenn ja, dann ist das Zufall. Bitte recherchiere, worum ich bereits in [pref:t=38284&m=209764] bat, nach den Faktoren, die diesen Wert verfälschen.

Ich kann an meinen Browsern machen was ich will, sie bleibt auf 1280.

Und Du schließt von Deinem System auf andere? Das ist ein Fehler.

Und das Ergebnis trifft also zu 100% zu, wenn die 1280 in der Abfrage definiert werden.

Sowas nennt sich übrigens "Laborbedingungen".

Warum zwischen unterschiedlichen clientseitigen Begebenheiten unterscheiden?
Weil ich nicht weiss, wie ich das Bildchen auf meiner Seite sonst anpassen soll.

Ich spezifiziere meine Frage: Warum willst Du dieses Bildchen anpassen?

Ich will, dass es dynamisch ist,

Regel Nummer Eins für gutes Webdesign: Was _Du_ willst, ist völlig egal. Was wollen Deine _Besucher_?

Das ist meine erste Seite. Also war mein Konzept eher so:" ".

Naja, ich halte Dir dann schon mal Deine Fehler vor, bevor Du sie mühsam selbst erkennen musst :-)

Ich habe angefangen mit Frontpage, und mal geguckt, was ich schön finde. Dann habe ich das per Editor bereinigt.

Das ist schon mal ein großer Schritt nach vorne.

Danach alles auf Frames umgestellt.

Dieser Schritt geht dann wieder zurück.

Dann alles auf css.

Und wieder vor.

Und jetzt ist halt die Dynamik dran.

Und zur Seite. Cha cha cha! ;-)

Fehlt nur noch die Schriftgrösse (in der css)

Richte Dich nach den Einstellungen, die der User vorgenommen hat. Er weiß um einiges besser als Du, welche Schriftgröße ihm genehm ist.

und das Bild.

Auch das wird, sofern es nicht allzu "gedrängt" erstellt wurde, im Rahmen seiner Systemeinstellungen für ihn ideal dargestellt werden.

Also der Konzeptfehler bei mir war, das ich kein Konzept hatte. Aber ich finde persönlich die bisherige Arbeit nicht gerade übel, und das ist die Hauptsache.

Ja, da stimme ich Dir zu.

Wie gesagt: Im Prinzip richtig. Allerdings steht _vor_ jedem Code ein Konzept - wenn bereits dieses fehlerhaft ist, bringt Dir der schönste Code nichts.
Also ich denke, das alles in der IT-Welt mit Code umsetzbar ist.

Nicht wirklich. Wenn Du ein Problem mit JavaScript lösen willst, der User es aber deaktivert hat - was dann?

Gerade in Assembler wird das fast auf jedem Lehrgang gelehrt.

Hier _weißt_ Du aber, welche Systembedingungen vorherrschen. Im Internet musst Du mit _allen_ denkbaren Fällen gleichzeitig rechnen. Das ist die große Herausforderung.

Man muss nur wissen mit welchen Werkzeugen, oder diese sich selber basteln.

Im Internet existiert für Dich zudem nur eine Applikation: der Browser. Und selbst bei diesem weißt Du nicht, welcher es sein wird - oder ob es überhaupt ein Browser ist, und nicht etwa ein anderer Client, wie z.B. ein Suchmaschinen-Robot.

Das braucht der User nicht. Er hat sich sein System so eingerichtet, dass er, wenn Du nicht aktiv seine Einstellungen missachtest (etwa durch feste Schriftgrößen), alles ideal erkennen kann. Vertraue ihm einfach.
Hmm, das bringt mich echt zum Nachdenken. Aber wie heißt es: "Vertrauen ist gut, Kontrolle ist besser"

Du kannst nicht im voraus prüfen, welche Systemeinstellungen jemand nächste Woche macht. Eines musst Du schlichtweg voraussetzen, denn der gesunde Menschenverstand diktiert es: Der User hat sein System so eingerichtet, dass er damit klarkommt. Er wird beispielsweise die Schrift lesen können, die ihm seine Programme präsentieren. Da diese Bedingung notwendigerweise herrscht, kannst Du Dich genausogut auf sie verlassen - und hast damit mit ziemlicher Sicherheit genau das Ergebnis erzielt, das dem (_jedem_) User am besten gefällt.

Wenn Du im Internet agierst, _muss_ Dein Konzept deaktiviertes JavaScript beachten. Solange Du also keine Lösung für ein (beliebiges) Problem hast, die ohne JS funktioniert, brauchst Du auch gar nicht an einer JS-Variante zu arbeiten. Schrittweises Vorgehen ist absolut richtig; Du beginnst jedoch mit dem falschen Schritt.
Nein, ich habe ja schon eine Lösung für eine Darstellung ohne Js. Da wird das Bild einfach mit Standardwerten (für 800x600) ausgeliefert. Fertig.

Und warum ist dieses Ergebnis für Leute mit JavaScript schlecht?

Sieht nicht genial aus, wenn der Benutzer eine 1600er Auflösung und Vollbild hat,

Wenn (im Sinne von falls) er das tut, dann hat er nicht nur mit Deiner Seite Probleme. Glaub mir, er hat seinen Browser _bewusst_ auf die Größe gestellt; ihm sind die Ergebnisse bekannt, und er möchte sie so haben. Andernfalls gibt es für ihn keinen Grund, ein so großes Browserfenster aufzumachen.

Die Auflösung ist irrelevant. Was window.screen Dir liefert, hat zudem mit der Auflösung nichts zu tun. Siehe auch Archiv.
? Also ich habe mir den Wert von dem verwendeten "screen.width" per alert-box ausgeben lassen und er passt.

Bei Dir. Wie ist es bei mir? Wie viele Monitore habe ich angeschlossen? Wie viele Taskleisten offen? Wie viele virtuelle Bildschirme eingestellt? ... Naja, bei mir ist es eh egal, weil Dein gesamter JavaScript-Code mit einer Exception abgebrochen wird ;-)

Cheatah

[Frau Holle]

Hi,

meinetwegen. Sagt das auch window.screen.width? - Wenn ja, dann ist das Zufall. Bitte recherchiere, worum ich bereits in [pref:t=38284&m=209764] bat, nach den Faktoren, die diesen Wert verfälschen.

Nein, wenn ich das richtig verstehe, ist window... die Breite des Browserfensters. Diese ändert sich ja ständig. Oder könnte sich ständig ändern. Aber die Auflösung ist recht fix. Aber danke für den Link. Klingt sehr interessant für das kommende Update auf die Browserbreite. Vielleicht finden wir ja gemeinsam eine Lösung, dann wirst Du sogar für Deine Hilfe belohnt :)

Und Du schließt von Deinem System auf andere? Das ist ein Fehler.

Vergeß nicht, dass ich nur .screen... und nicht window.screen... anspreche.

Sowas nennt sich übrigens "Laborbedingungen".

siehe letzte Antwort.

Ich spezifiziere meine Frage: Warum willst Du dieses Bildchen anpassen?

Guck Dir bitte meine Seite unter 800 oder 1600 an. Dann siehst Du warum. Furchtbar.

Regel Nummer Eins für gutes Webdesign: Was _Du_ willst, ist völlig egal. Was wollen Deine _Besucher_?

Klingt gut. Aber ich biete Content an. Wer in dem Genuß kommen möchte, der hat sich an die Regeln zu halten. Klingt ein bissel hart. Aber es ist ja eine kleine, private Seite, die in keiner Suchmaschine vermerkt ist. Mir geht es beim Design um das Ausleben MEINER Vorstellungen von einer idealen Webseite.

Naja, ich halte Dir dann schon mal Deine Fehler vor, bevor Du sie mühsam selbst erkennen musst :-)

Hey, das ist ja auch hammergenial! Über manche Dinge mache ich mir einfach keinen Kopf, die eigentlich sehr wichtig sind. Du hast schon weitaus mehr Erfahrung, von Deinen Beanstandungen kann ich nur lernen.

Danach alles auf Frames umgestellt.

Dieser Schritt geht dann wieder zurück.

Okay, wenn ich das Bildchen-Problem gelöst habe, nehme ich mir mal eine dieser Frame vs. Table Diskussionen vor. Aber die sind immer so tierisch lang. Als ich das mit frames gelesen habe, fand ichs genial, wegen geringerer Ladezeit, besserer Wartung. Aber ich denke es ist geschmackssache.

Richte Dich nach den Einstellungen, die der User vorgenommen hat. Er weiß um einiges besser als Du, welche Schriftgröße ihm genehm ist.

hmm. Ich glaube, die lasse ich fix. Hast mich überzeugt.

Auch das wird, sofern es nicht allzu "gedrängt" erstellt wurde, im Rahmen seiner Systemeinstellungen für ihn ideal dargestellt werden.

Leider nicht, siehe mit 800 auf meine Seite.

Also ich denke, das alles in der IT-Welt mit Code umsetzbar ist.

Nicht wirklich. Wenn Du ein Problem mit JavaScript lösen willst, der User es aber deaktivert hat - was dann?

Dann gibt es andere mächtige Instrumente, wie php, xsl.

Du kannst nicht im voraus prüfen, welche Systemeinstellungen jemand nächste Woche macht. Eines musst Du schlichtweg voraussetzen, denn der gesunde Menschenverstand diktiert es: Der User hat sein System so eingerichtet, dass er damit klarkommt. Er wird beispielsweise die Schrift lesen können, die ihm seine Programme präsentieren. Da diese Bedingung notwendigerweise herrscht, kannst Du Dich genausogut auf sie verlassen - und hast damit mit ziemlicher Sicherheit genau das Ergebnis erzielt, das dem (_jedem_) User am besten gefällt.

Okay, okay. Die Schrift lasse ich ihm. Aber bei dem Rest muss ich ihn unterstützen. Ansonsten kann ich auch eine html ohne jegliches Design anbieten und ihm sagen er soll mit Opera 7 eine css auswählen.

Und warum ist dieses Ergebnis für Leute mit JavaScript schlecht?

siehe meine Seite mit 800x600.

Wenn (im Sinne von falls) er das tut, dann hat er nicht nur mit Deiner Seite Probleme. Glaub mir, er hat seinen Browser _bewusst_ auf die Größe gestellt; ihm sind die Ergebnisse bekannt, und er möchte sie so haben. Andernfalls gibt es für ihn keinen Grund, ein so großes Browserfenster aufzumachen.

Geschmackssache. Ich möchte gerne die gleiche Optik unter allen Auflösungen. Das ist mein Ziel.

Bei Dir. Wie ist es bei mir? Wie viele Monitore habe ich angeschlossen? Wie viele Taskleisten offen? Wie viele virtuelle Bildschirme eingestellt? ... Naja, bei mir ist es eh egal, weil Dein gesamter JavaScript-Code mit einer Exception abgebrochen wird ;-)

Vergiß nicht, dass ich nur .screen... und nicht window.screen... anspreche.

Gruß Chris

[Joachim]

hi,

Darin, dass Du annimmst, Screen und Browserfenstergroesse sind das Gleiche.
Das nehme ich nicht an. Aber es ist ersteinmal einfacher das anzunehmen um ein Grundgerüst zuschaffen.

Um es Dir einfach zu machen würde ich mal einfach von 800 x 600 px ausgehen ;-)
Im Ernst: es ist sinnlos! Ich wuerde bei Dir immer ein Scrollbalken sehen, denn mein Browserfenster ist fast nie auf Vollbild - Deine Abfrage geht aber davon aus.

Wenn ich hier noch browserspezifische Entscheidungen reinstelle, dann wächst der Code

Das ist lediglich Userspezifisch. Soviele User - soviele Möglichkeiten, sein Fenster zu oeffnen.

lso wenn ich das Bild mitskalieren lasse, dann bleiben die Koordinaten fix, und die Links funktionieren nicht. Wie kann ich das umgehen?

Lass die Grafik farblich in die Hintergrundfarbe eines Tables uebergehen, der sich an die Fensterbreite anpasst. Dann umgehst Du eine aufwändige und nutzlose Konstruktion.

Gruss  Joachim

[Frau Holle]

Um es Dir einfach zu machen würde ich mal einfach von 800 x 600 px ausgehen ;-)
Im Ernst: es ist sinnlos! Ich wuerde bei Dir immer ein Scrollbalken sehen, denn mein Browserfenster ist fast nie auf Vollbild - Deine Abfrage geht aber davon aus.

Einen vertikalen Scrollbalken wirst Du bei mir nie sehen, da das Frame, wo scrollen erlaubt ist schon zu 100% dynamisch ist. Du kannst es mal ausprobieren, siehe Link. Die Abfrage geht davon aus, richtig. Mir ist auch bewußt, dass ich nur nach der Auflösung frage und nicht nach der Fenstergröße. Das kann ich ändern, wenn der Code für die Auflösung funktioniert, und das tut er leider nicht.

Lass die Grafik farblich in die Hintergrundfarbe eines Tables uebergehen, der sich an die Fensterbreite anpasst. Dann umgehst Du eine aufwändige und nutzlose Konstruktion.

Kannst Dir mal die Grafik angucken. Das Anpassen würde aufwendiger sein, als eine Entscheidung. Und so ganz gkücklich wäre ich dann trotzdem nicht. Aber gute Idee, Danke.

Gruß Chris

[Wilhelm Turtschan]

Moin

if(screen.width == 1280
      if(screen.width == 1024)
       if(screen.width == 1152
        if(screen.width = 800)
         if(screen.width == 1600)

Ueber Sinn und Unsinn einer solchen Abfrage wurde ja schon einiges gesagt, ueber die Syntax auch. Nur soviel noch: Ich sitze hier mit einer Aufloesung von 1400x1050. Faellt Dir was auf?

Gruesse
Wilhelm

[Sven Rautenberg]

Moin!

if(screen.width == 1280
      if(screen.width == 1024)
       if(screen.width == 1152
        if(screen.width = 800)
         if(screen.width == 1600)

Ueber Sinn und Unsinn einer solchen Abfrage wurde ja schon einiges gesagt, ueber die Syntax auch. Nur soviel noch: Ich sitze hier mit einer Aufloesung von 1400x1050. Faellt Dir was auf?

Genau.

Die Statistik einer Website mit insgesamt 5248 Messwerten ergab:

kein Javascript:     190 Hits

Bildschirmbreite:
Breite Stück    Anteil
0      1        0.0%
640    3        0.1%
720    1        0.0%
800    304      5.8%
832    1        0.0%
1013   1        0.0%
1024   2807     53.5%
1152   454      8.7%
1280   554      10.6%
1344   1        0.0%
1400   810      15.4%
1408   2        0.0%
1600   99       1.9%
1920   1        0.0%
2048   18       0.3%
2560   1        0.0%

Tatsache ist also, dass es, trotz der recht geringen Anzahl von nur 5000 Meßwerten schon etliche exotische Auflösungen gibt, die in der Statistik auftauchen. Und für die muß man natürlich auch was anbieten, wenn man denn unbedingt skalieren muß.

Außerdem sind die Auflösungen 2048 und 2560 ziemlich verdächtig. Sie könnten sehr gut von einem System mit zwei Bildschirmen stammen, bei dem die Grafikkarte aus Kompatibilitätsgründen mit eingesetzten Programmen eine doppelt breite Auflösung vorgaukelt (also statt 2x 1024*768 einfach 2048*768) und das Bild dann auf die zwei Monitore verteilt. Bei solchen Konstellationen dürfte es ungünstig sein, wirklich anzunehmen, die volle Bildschirmbreite stünde zur Verfügung.

- Sven Rautenberg

[Frau Holle]

Ueber Sinn und Unsinn einer solchen Abfrage wurde ja schon einiges gesagt, ueber die Syntax auch. Nur soviel noch: Ich sitze hier mit einer Aufloesung von 1400x1050. Faellt Dir was auf?

Ja, das Du wahrscheinlich der einzige Benutzer mit dieser Auflösung auf meine Seite warst und sein wirst. Nein, natürlich kommt dann noch ein "else" rein, für die Auflösungen, die nicht definiert sind. Du sollst Dich ja nicht ausgeschlossen fühlen :) Ich glaube ich hätte Pre-Code im Pre-Alpha-Status dazu schreiben sollen. Mir geht es momentan echt mehr um die Syntax, als um den Sinn, aber gut das Du mich dran erinnerst, vielleicht hätte ich den letzten "else" Pfad sonst vergessen.

Gruß Chris

[Cheatah]

Hi,

Ueber Sinn und Unsinn einer solchen Abfrage wurde ja schon einiges gesagt, ueber die Syntax auch. Nur soviel noch: Ich sitze hier mit einer Aufloesung von 1400x1050. Faellt Dir was auf?
Ja, das Du wahrscheinlich der einzige Benutzer mit dieser Auflösung auf meine Seite warst und sein wirst.

gut möglich. Der nächste hat dann 956x702. Und das bei einem Monitor, der nicht mehr als 640x480 Pixel darstellt.

Nein, das ist nicht konstruiert, sondern absolut möglich und wahrscheinlich.

Cheatah

[Frau Holle]

gut möglich. Der nächste hat dann 956x702. Und das bei einem Monitor, der nicht mehr als 640x480 Pixel darstellt.

Nein, das ist nicht konstruiert, sondern absolut möglich und wahrscheinlich.

Im Anschluss habe ich aber auch geschrieben, dass ich ein weiteres else drin habe, welches alle anderen Fälle gearbeitet.

Gruß Chris

[Tim Tepaße]

Hallo Chris,

Im Anschluss habe ich aber auch geschrieben, dass ich ein weiteres else drin
habe, welches alle anderen Fälle gearbeitet.

Hast Du auch an so verstockte Typen wie mich gedacht, wie Javascript einfach
ausgestellt lassen und es nur anschalten, wenn sie erkennen können, daß sie
dafür einen Mehrwert kriegen? ;-)

• Tim

[Frau Holle]

Hallo Chris,

Im Anschluss habe ich aber auch geschrieben, dass ich ein weiteres else drin
habe, welches alle anderen Fälle gearbeitet.

Hast Du auch an so verstockte Typen wie mich gedacht, wie Javascript einfach
ausgestellt lassen und es nur anschalten, wenn sie erkennen können, daß sie
dafür einen Mehrwert kriegen? ;-)

• Tim

Natürlich Tim,
Du bekommst bei der noscript definition ein Bild, was für 800x600 gedacht ist. Anders geht es nicht, darum will ich das mit Js machen.

Gruß Chris

[Wilhelm Turtschan]

Moin

Ueber Sinn und Unsinn einer solchen Abfrage wurde ja schon einiges gesagt, ueber die Syntax auch. Nur soviel noch: Ich sitze hier mit einer Aufloesung von 1400x1050. Faellt Dir was auf?

Ja, das Du wahrscheinlich der einzige Benutzer mit dieser Auflösung auf meine Seite warst und sein wirst.

Nein, ich war definitiv nicht auf Deiner Seite. Bei solchen Fragen verzichte ich generell auf einen Klick. Ich kann erahnen, was mich in der Regel erwartet.[1]

Die von mir genutzte Aufloesung ist allerdings eine ziemlich weit verbreitete Einstellung fuer Notebooks, bei den 1600 zu wuselig aussieht. Ich kenne eine Firma im Muenchen, die allen Aussendienstlern ACER-Travelmates zur Verfuegung[2] stellten. Die laufen alle mit 1400.

Gruesse
Wilhelm

[1] wobei es ja Ausnahmen geben soll
[2] sind aber nur ca. 150 ;-)

[Frau Holle]

Nein, ich war definitiv nicht auf Deiner Seite. Bei solchen Fragen verzichte ich generell auf einen Klick. Ich kann erahnen, was mich in der Regel erwartet.[1]

Die von mir genutzte Aufloesung ist allerdings eine ziemlich weit verbreitete Einstellung fuer Notebooks, bei den 1600 zu wuselig aussieht. Ich kenne eine Firma im Muenchen, die allen Aussendienstlern ACER-Travelmates zur Verfuegung[2] stellten. Die laufen alle mit 1400.

Ist auch schon geändert, Wilhelm. Und wenn nicht, dann spätestens nach dem: "Seit 1994 im Netz unterwegs (Roadrunner), Mitarbeit in Foren zum Thema HTML und Scripting." Du hast mit html zu tun, wo ich noch nicht mal einen Internet-Anschluss hatte. :)

Gruß, Chris