Dominik B.: Fenstersalat sortieren

Hallo alle Zusammen,

Vorweg ich bin Anfänger. Ich möchte in einem Text, der wiederum in einem Frame ist, mehrere Verweise haben, die beim Anklicken ein Fenster öffnen, welches Informationen(nur lesend) enthält. Weiter
möchte ich aber, daß das Frame mit den Verweisen aktiv bleibt aber
das geöffnete Fenster trotzdem lesbar bleibt(im Vordergrund). Bei dem was ich bisher habe verschwindet das Fenster in den Hintergrund.
Geht das? Kann mir jemand helfen?

<script language="JavaScript">
<!--
function testn(x) {
       testen1 = window.open(x, "NeuFenster", "width=250,height=250,left=300,top=320");
       }
//-->
</script>
</head>
<body>
<a href="javascript:testn('window.html#Adunakor')">Adunakor</a>
<a href="javascript:testn('window.html#Feanor')">Feanor</a>
<a href="javascript:testn('window.html#Arwen')">Arwen</a>
</body>

  1. Hallo, Dominik,

    Subject: Fenstersalat sortieren

    Glücklicherweise siehst du selbst ein, das dein Popup- und Frames-Gebräu ein ungenießbarer Fenstersalat ist und du ihn dir selbst eingebrockt hast (womit ich die Metapher doppelt gebrochen hätte ;)).

    Ich möchte in einem Text, der wiederum in einem Frame ist, mehrere Verweise haben, die beim Anklicken ein Fenster öffnen, welches Informationen(nur lesend) enthält.

    Diese Navigationsstruktur ist völlig benutzerunfreundlich, ein Frameset, welches zusätzlich Fenster öffnet...? Aber nun gut, wenn du es unbedingt willst und auf deine Besucher keine Rücksicht nimmst... es sind deine Besucher, die du verlierst.

    Du willst wahrscheinlich ein Glossar anbieten, in dem Falle kann ein Popup-Fenster sinnvoll sein, aber besser wäre eine "integrative" Lösung, vor allem wenn du sowieso schon alles mit Frames verbaust, einschränkst und zementierst.

    Weiter möchte ich aber, daß das Frame mit den Verweisen aktiv bleibt aber
    das geöffnete Fenster trotzdem lesbar bleibt(im Vordergrund).

    Das geht nicht, es kann immer nur ein Fenster aktiv sein, und auf die Größe eines Fensters hat nur der Anwender Zugriff, demnach kannst du dich zwar irgendwie verrenken und dem Benutzer vorschreiben, welches Fenster er anwählen darf und welches wo auf seinem Bildschirm sein soll, aber einen zuverlässigen Zugriff hast du nicht.
    Jetzt postet sicher jemand eine Hauruck-Lösung, die es mehr schlecht als recht löst, was aber nichts an der Tatsache ändert, dass es im Grunde genommen nicht möglich ist, und das ist auch gut so.

    Bei dem was ich bisher habe verschwindet das Fenster in den Hintergrund.

    Das ist die Grundlage einer fensterbasierten Benutzeroberfläche. Als Webautor kannst du darauf nicht bzw. nur sehr eingeschränkt Einfluss nehmen.
    Suchst du vielleicht http://selfhtml.teamone.de/javascript/objekte/window.htm#focus?

    Geht das? Kann mir jemand helfen?

    Nein.  Ja, bei der Erstellung eines Layouts bzw. Seitenaufbaus, welches das Problem löst, ohne Frames und Popup-Fenster verwenden zu müssen.

    <script language="JavaScript">

    Das script-Element hat kein Attribut namens language und hatte es auch nie. Einzig richtig ist type="text/javascript". (Das habe ich heute schon mindestens zweimal in diesem Forum gesagt.)

    <!--
    function testn(x) {
           testen1 = window.open(x, "NeuFenster", "width=250,height=250,left=300,top=320");

    width und height kannst du vielleicht noch relativ zuverlässig festlegen (auch wenn es ohne rezisable=yes sehr böse[tm] ist), aber left und top kann der Benutzer in jedem Fall vereiteln.
    Im Opera interessiere ich mich bspw. nie dafür, wie und wo eine Seite mir ein Popup-Fenster öffnet. Opera ignoriert resizable=no und schmiegt das Fenster vollkommen ins MDI ein.

    }
    //-->
    </script>
    </head>
    <body>
    <a href="javascript:testn('window.html#Adunakor')">Adunakor</a>
    <a href="javascript:testn('window.html#Feanor')">Feanor</a>
    <a href="javascript:testn('window.html#Arwen')">Arwen</a>
    </body>

    Wah! Sofort lesen: http://home.t-online.de/home/dj5nu/js-popup.html. Du darfst nicht href="javascript:..." verwenden, denn dadurch sind die verlinkten Seiten für alle Benutzer, welche JavaScript/das Öffnen von Fenstern deaktiviert haben oder Browser verwenden, welche kein JavaScript unterstützen (dies gilt genauso für Suchmaschinen), unzugänglich und dir gehen folglich diese Besucher flöten (schöne Redewendung, passt gut).

    Folgende Variante wäre richtiger:

    <a href="window.html#Adunakor" onclick="testn('this.href'); return false">Adunakor</a>

    Auf der verlinkten Seite wird alles erklärt.

    Grüße,
    Mathias

    1. Hallo Mathias,

      danke erst einmal. Ja ich wollte ein Fenster öffnen und nur kurze Infos eines Glossars über Namen, Gebiete usw, dem Anwender mitteilen.
      Aufgrund deiner Mail werde ich das nochmal überdenken.

      Íst eine 3 Frame Seite Benutzerunfreundlich? Was für sinnvoll Alternativen gibt es?

      Desweiteren bringe ich mir das alles selbst bei und habe mich bis zu Entdeckung des Forums auf ein Buch verlassen und da gibt es das.

      <script language="JavaScript"> "HTML 4.0 Handbuch"

      Für Tips bin ich gern zu haben.

      gruss Dominik

      1. Hallo,

        danke erst einmal. Ja ich wollte ein Fenster öffnen und nur kurze Infos eines Glossars über Namen, Gebiete usw, dem Anwender mitteilen.
        Aufgrund deiner Mail werde ich das nochmal überdenken.

        Íst eine 3 Frame Seite Benutzerunfreundlich? Was für sinnvoll Alternativen gibt es?

        Wenn ein Frame nur zur Anzeige eines Logos o.ä. benutzt wird, beschränkt sich das Navigationkonzept auf die Hauptnavigation im entsprechenden Navigationsframe und auf den Inhaltsframe, welcher i.d.R. als Zielframe für die Links des Navigationsframedokuments ist. Dass eine Hauptnavigation keinesfalls eine Art Sitemap, also eine Komplettübersicht über alle Unterrubriken, darstellen kann, habe ich in diesem Posting http://forum.de.selfhtml.org/archiv/2002/10/27370/#m149759 erläutert. Darin legte ich dar, wieso eine volle Navigation oder ein breadcrumb trail auf jeder Unterseite nötig ist, und zwar in jedem Fall und nicht nur in einem noframes-Element. Eine Hauptnavigation kann nun einmal nicht die Struktur der Seite offenbaren, bei einer framelosen Version hat man die Möglichkeit einer Hauptnavigation sowie mehreren Nebennavigationen, welche eine Verbindung mit allen "Eltern" in der Hierarchie und ggf. dem Wechseln zu "Geschwistern" der jeweiligen Ebene ermöglichen (oder Sprünge zum Impressum, Kontakt usw.).
        Wenn folglich eine Site *mehr* Dokumente beinhaltet, als über die Hauptnavigation erreichbar sind (das ist meist der Fall), schlägt das Frame-Navigationskonzept fehl, da der Benutzer die Orientierung verliert; aus diesem Grund existieren auch die Probleme mit dem Bookmarking von sich in Frameset befindenden Dokumenten, was man zwar durch eigene Framesets für jede Unterseite kompensieren könnte, dies wäre aber der absolute Overkill.  Da gibt es natürlich diese schrecklichen JavaScript-Lösungen, mit denen man zwei Frames ändern kann und somit eine Primär- und Sekundärnavigation auch mit Frames realisieren kann, aber diese funktionieren nur mit JavaScript und erzeugen ein heilloses Framechaos, welches man 1:1 auf eine framelose Version übertragen könnte, die Übersicht wäre um ein vielfaches besser, siehe z.B. Amazon.de.  Des weiteren könnte man alternativ für jede Unterrubrik eine eigene Seite für das Navigationsframe mit Links zu den Unterseiten entwerfen, sodass man sich erst im Navigationsframe voranklickt bzw. absteigt in der Seitenhierarchie und erst dann die Unterseiten im Inhaltsframe auftauchen. So etwas gefällt mir aber nur mäßig, da je nach dem Grad der Verschachtelung eine Art breadcrumb trail *sogar* *im* *Navigationsframe* nötig wird, siehe auch http://forum.de.selfhtml.org/archiv/2002/9/23902/#m132365 beginnend mit "1. Die Navigation desorientiert den Besucher...", es ging da um http://www.gil-marl.de/. (Übrigens sehr toll, dass man dort meine Vorschläge nicht beherzigt hat... :-/) Eine solche von mir dort dargestellte Navigation ist im Grunde genommen perfekt (weil hierarchisch!), aber das Schlechteste was man machen kann, ist dies mit einem *Framelayout* zu realisieren.

        Achja, bevor du fragst, ein breadcrumb trail ist eine Aneinanderreihung von Links, welche die Spur bzw. den Pfad bzw. die Abzweigungen in der Seitenhierarchie bzw. dem Dokumentbaum von der Startseite einer Site (sic) aus zum aktuellen Dokument kennzeichnen, das sieht meist so aus:
          Sie befinden sich hier: <a>[Sitename]</a> -> <a>[Rubrik X]</a> -> <a>[Unterrubrik Y]</a> -> <strong>[Dokument Z]</strong>
        Alle Selfhtml-Inhaltsseiten haben ausschließlich eine solche Hauptnavigation.

        Zurück zu unseren geliebten Frames: Die Problematik, dass auch immer eine zugängliche gleichwertige Alternativversion ohne Frames zur Verfügung, dürfte dir bekannt sein, denn Barrierefreiheit und die völlige Interoperabilität sind von Nöten. Eine Frames benutzende Seite sollte immer auch im noframes-Element die relevanten Links zu den Unterseiten haben, für gewöhnlich kann jedoch nur zu den Unterseiten gelinkt werden, welche natürlich keine eigene Navigation beinhalten, denn die wurde von den Inhaltsseiten getrennt und befindet sich in völlig anderen Dokumenten. Ohne das/die zugehörige(n) Navigationframe(s) ist ein solches Dokument unvollständig, was auch das Problem auslöst, dass das Frameset nachgeladen werden muss, wenn der Benutzer die Seite über Suchmaschinen oder direkte Links aufruft - dieses Nachladen geht wiederum nur mit JavaScript, wodurch manche Besucher die Navigation nie zu Gesicht bekämen. Eine naheliegende Möglichkeit ist, ein Frameset dadurch barrierefrei zu machen, dass auf jeder Unterseite eine zusätzliche für den Framesbenutzer unsichtbare Navigation in einem noframes-Element angeboten wird, aber oben habe ich bereits belegt, wieso eine Navigation (welche die Hierarchie wiederspiegelt) für *jeden* Besucher sichtbar sein muss.

        Das waren alles nur die Nachteile von Frames bezüglich der Navigation - bei näherer Betrachtung lassen sich die vermeintlichen Navigationsvorteile von Frames m.M.n. um Längen besser mit einer framelosen Seite realisieren.

        Hm, ich finde leider gerade keinen passenden Thread zu Frames im Archiv, es wäre unsinnig dass ich die hundertmal genannten Nachteile von Frames wieder aufrolle, ich habe die ersten 2200 Suchresultate durchgeschaut... ;) Eine gute Einführung in die weiteren Probleme stellt aber Michael Nahraths Artikel http://www.subotnik.net/html/frames.html dar.

        Desweiteren bringe ich mir das alles selbst bei und habe mich bis zu Entdeckung des Forums auf ein Buch verlassen und da gibt es das.

        <script language="JavaScript"> "HTML 4.0 Handbuch"

        Hm, ja, glaube mir, es ist sinnfrei, das languge-Attribut anzugeben. Wenn du einigermaßen standardkonformes HTML schreibst ist hingegen das type-Attribut Pflicht, denn AFAIK wird ein script-Element ohne jegliche Angabe des Mime-Types von einigen Browsern nicht als ECMAScript/JavaScript angenommen (ist mir AFAIR schon einmal untergekommen), denn es könnte theoretisch in jeder möglichen clientseitigen Scriptsprache verfasst sein, bspw. VBScript, wobei ich gar nicht weiß, wie man VBScript richtig einbinden, es muss schließlich auch ein Mime-Typ haben...

        Mathias

    2. Hi,

      <script language="JavaScript">

      Das script-Element hat kein Attribut namens language und hatte es auch nie. Einzig richtig ist type="text/javascript". (Das habe ich heute schon mindestens zweimal in diesem Forum gesagt.)

      Dann hast Du heute also schon mindestens 3 mal gelogen:
      http://www.w3.org/TR/html401/interact/scripts.html#adef-language

      Das language-Attribut ist zwar als deprecated eingestuft, aber damit auch als existent.

      Andreas

      1. Hallo, Andreas,

        <script language="JavaScript">

        Das script-Element hat kein Attribut namens language und hatte es auch nie. Einzig richtig ist type="text/javascript". (Das habe ich heute schon mindestens zweimal in diesem Forum gesagt.)

        Dann hast Du heute also schon mindestens 3 mal gelogen:
        http://www.w3.org/TR/html401/interact/scripts.html#adef-language

        Klugscheißer, Paragraphenreiter, ...! ;)
        Dass es als deprecated im Standard steht, war mir bewusst. Deprecated heißt mitunter, dass irgendein Browserhersteller es "erfunden" hat und das W3C keine andere Möglichkeit hatte, als es in den Standard zu übernehmen.

        Wenn du bitte einmal schauen würdest:
        http://www.w3.org/TR/REC-html32#script Dort gibt es kein language-Attribut, bzw. gar nichts zum script-Element.
        Hingegen die erste HTML >3.2-Veröffentlichung: http://www.w3.org/TR/WD-html40-970708/interact/scripts.html#adef-language Kaum ist es da, ist es nicht wirklich da, nämlich deprecated.

        Folglich stand es nie "wirklich" in einem *Standard*, war nie vom W3C geplant und war nur aufgenommen worden, weil es ein von Netscape (womöglich auch daraufhin von Mickeysoft) eingeführter und durch Marktbeherrschung durchgesetzter Quasistandart[tm] war.
        Über die Hintergründe darfst du in den Archiven von www-html und www-html-editor suchen, das erspare ich mir einmal. ;)

        Das language-Attribut ist zwar als deprecated eingestuft, aber damit auch als existent.

        Es ist seit es "existiert" deprecated, folglich gemacht, um entsorgt zu werden, deswegen hindert mich die Tatsache, dass es im Standard *aufgeführt* wird (als ein Attribut, welches niemand braucht und niemand will), nicht daran, es zu verleugnen und jedem hier auftauchenden zu raten, es schleunigst aus dem Markup auszumerzen.
        Ich wüsste nicht, ob überhaupt ein Browser language="Javascript1.2" usw. interpretiert. So oder so sind solche Angaben völlig sinnlos, es gab nie einen *offenen* "JavaScript"-Standard, alleinig Netscape hat diese Bezeichnung und Versionsnummern eingeführt. Deshalb ist sogar der Mime-Typ text/javascript eine Farce, vor allem der MSIE unterstützt teilweise ECMAScript und DOM, aber noch viel mehr eigenen Kram, der nirgendwo standardisiert ist.

        Mathias

        1. HAllo,

          <script language="JavaScript">

          Das script-Element hat kein Attribut namens language und hatte es auch nie. Einzig richtig ist type="text/javascript". (Das habe ich heute schon mindestens zweimal in diesem Forum gesagt.)

          Dann hast Du heute also schon mindestens 3 mal gelogen:
          http://www.w3.org/TR/html401/interact/scripts.html#adef-language

          Klugscheißer, Paragraphenreiter, ...! ;)
          Dass es als deprecated im Standard steht, war mir bewusst.

          [...]

          Nur so zur Info:
          Genau diese Art Ideologisches Gesülze war es das mich aus dem Usenet trieb. Dort gibt haufenweise Typen die meinen etwas sei "böse[tm]" ohne den Einsatzgebiet zu kennen, oder wissen genau das ein Frameset grundsätzlich nur "völlig benutzerunfreundlich" sein kann u.s.w.

          Ich hoffe das reißt nicht ein, sonst muss ich auch noch hier auf read-only stellen :-(

          By
          Reinhard

          1. Hallo, Reinhard,

            ich weiß wieder einmal nicht, was ich mit deinem Posting anfangen soll. Ich habe einige Behauptungen aufgestellt und diese argumentativ zu belegen versucht, du hingegen beschuldigst mich pauschal und nennst mein Geschriebsel ideologisches Gesülze, scherst mich mit Usenetmenschen[tm] über einen Kamm und sagst nichts zum Thema selbst, sondern machst einen Rundumschlag, zu dem ich im Grunde genommen keinen Kommentar abgeben kann, da dein Urteil bereits gefällt wurde.

            <script language="JavaScript">

            [...]

            Nur so zur Info:
            Genau diese Art Ideologisches Gesülze war es das mich aus dem Usenet trieb. Dort gibt haufenweise Typen die meinen etwas sei "böse[tm]" ohne den Einsatzgebiet zu kennen, oder wissen genau das ein Frameset grundsätzlich nur "völlig benutzerunfreundlich" sein kann u.s.w.

            1. Dass das language-Attribut schlichtweg keinen Sinn hat, dass es keine sinnvolle Anwendung gibt usw. habe ich belegt, es ist *nicht* böse[tm], es hat nicht einmal das Potenzial dazu, es ist einfach nutzlos. Falls du einer anderen Meinung bist oder ich mich irre bzgl. der Tatsachen[tm], führe dies bitte aus.

            2. Die von Frames ausgelösten Benutzbarkeitsprobleme sind evident und zur Genüge bekannt, die Konsequenzen daraus sind jedem Webautor überlassen; ich weiß nicht, wieso du dieses Thema wieder aufwärmst, da es überhaupt nichts mit dem language-Attribut oder meiner Meinung dazu zu tun hat. Diese Probleme von Frames sind in der Tat grundsätzlicher bzw. konzeptioneller Art, ich erspare mir dies noch weiter auszuführen. Auch bin ich der Letzte, der mit dem Frames sind böse[tm]-Dogma Sprüche klopft, ich versuche immer im Einzelfall die Vor- und Nachteile abzuwägen und dementsprechend meine Meinung kundzutun und sie zu untermauern. Wenn du meine Postings in diesem Forum bezüglich Frames gelesen hättest, wüsstest du, dass du mir nicht einfach ein Stempel aufdrücken kannst.

            Wie bitte soll ich reagieren, mit Verständnis? Gerne, aber was soll ich denn verstehen, dass du mir nicht zustimmst? Natürlich akzeptiere ich das, aber verstehen kann ich es nicht, wenn ich nicht ein Wort von dir höre, warum du anderer Meinung bist und was dich an meinen Ausführungen speziell stört (außer womöglich mein Tonfall) und bezüglich welchen Thesen Dissenz herrscht.

            Ich hoffe das reißt nicht ein, sonst muss ich auch noch hier auf read-only stellen :-(

            Ich denke, diesbezüglich brauchst du dir keine Sorgen zu machen.

            Grüße,
            Mathias