Link im iframe soll parent-Dokument positionieren

[Linuchs]

Moin,

ein weiteres ungelöstes Problem in meinen Chor-Projekten.

Die Liederbücher bestehen aus einer Anzahl iframes. Jedes iframe ist eine Seite des Buchs und enthält auf Parent-Ebene einen Anker wie z.B.id=lied_03

<div class="a4">
<div id=lied_03 class="a4 ungerade">
  <p class=page_nr><a href="#top">03</a></p>
  <p class=page_nr><a href="#top">03</a></p>
  <iframe frameborder=0 src="ich_geh_mit_meiner_laterne.htm"></iframe>
  <button id=regie_button_03 onclick="regie_sende( '03' )" title="Nr. 3 an Slaves senden"></button>
</div></div>

Im ersten iframe ist das Inhaltsverzeichnis eines Projekts mit den Liedern. Jedes verlinkt auf die Parent-Seite. Parent (das Buch) soll also dorthin positionieren:

    <tr>
      <td>Ich geh mit meiner Laterne ♫</td>
      <td>Hal</td>
      <td><a href="#lied_03" target="_parent">03</a></td>
      <td>Ku</td>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
    </tr>

Das Problem ist, dass das ganze Buch neu geladen wird. Zwar werden die iframe-Inhalte aus dem Cache geholt, deshalb fällt die Ladzeit nicht auf. Aber es gehen die Parameter (Auswertung mit Javascript) verloren, die beim Erstaufruf mitgegeben wurden:

http://osmer.de/musik/liedtexte/testchor.htm?master

Aus dem master wird ein slave (siehe fixiertes Info-Feld)

Wie kann ich das Neuladen vermeiden?

Gruß, Linuchs

[Felix Riesterer]

Lieber Linuchs,

ein weiteres ungelöstes Problem in meinen Chor-Projekten.

Die Liederbücher bestehen aus einer Anzahl iframes.

vielleicht solltest Du dieses Problem entfernen? Die Verwendung von iframe-Elementen ist an sich schon problematisch. Was spricht denn dagegen, für jede Seite ein section- oder article-Element zu verwenden, welches dann "aktiv" geschaltet wird? Da Du von einem "Intranet"-Projekt ausgehst, bei dem die Clients sich die Resource nicht aus dem Internet, sondern von einem Webserver im lokalen Netzwerk holen, spräche nichts dagegen, gleich das gesamte Liederbuch auf einmal zu laden.

Liebe Grüße,

Felix Riesterer.

[Linuchs]

Lieber Felix,

Die Verwendung von iframe-Elementen ist an sich schon problematisch.

Wenn ich bei jedem Problem kneifen würde, wäre ich noch blutiger Anfänger.

Was spricht denn dagegen, für jede Seite ein section- oder article-Element zu verwenden, welches dann "aktiv" geschaltet wird?

Die iframe-Inhalte sind komplette HTML-Dokumente, die auch einzeln für eine Lose-Blatt-Sammlung gedruckt werden können.

Da Du von einem "Intranet"-Projekt ausgehst, bei dem die Clients sich die Resource nicht aus dem Internet, sondern von einem Webserver im lokalen Netzwerk holen, spräche nichts dagegen, gleich das gesamte Liederbuch auf einmal zu laden.

Warum mit Kanonen (Intranet-Server) auf Spatzen (einfache HTML-Anzeige/Druck) schießen? Keine gute Idee.

Nur weil ich jetzt als "Gag" diese Master/Slave Idee mit Ajax habe, mag ich nicht hunderte von Liedern "umschreiben".

Gruß, Linuchs

[JürgenB]

Hallo,

Nur weil ich jetzt als "Gag" diese Master/Slave Idee mit Ajax habe, mag ich nicht hunderte von Liedern "umschreiben".

musst du ja auch nicht.

Gruß
Jürgen

[JürgenB]

Hallo,

Die Verwendung von iframe-Elementen ist an sich schon problematisch.

Wenn ich bei jedem Problem kneifen würde, wäre ich noch blutiger Anfänger.

naja, wenn man eine veraltete Technik, die auch noch Probleme macht, durch etwas besseres ersetzt, zeugt das nicht von einem Anfänger.

Gruß
Jürgen

[Felix Riesterer]

Lieber Linuchs,

Wenn ich bei jedem Problem kneifen würde, wäre ich noch blutiger Anfänger.

wenn Du ohne Not iframes verwendest, vielleicht auch..?

Die iframe-Inhalte sind komplette HTML-Dokumente, die auch einzeln für eine Lose-Blatt-Sammlung gedruckt werden können.

Aha, Du willst Dir die Mühe nicht machen, diese "lose Blattsammlung" anders zu arganisieren. Jetzt verstehe ich. Nun, da ist vielleicht die bisherige Lösung für die Blattsammlung nicht gut!

Warum mit Kanonen (Intranet-Server) auf Spatzen (einfache HTML-Anzeige/Druck) schießen? Keine gute Idee.

Nur weil ich jetzt als "Gag" diese Master/Slave Idee mit Ajax habe, mag ich nicht hunderte von Liedern "umschreiben".

Wie kommt man denn an die "einfache HTML-Anzeige"? Und mit JavaScript und CSS kann man die Druckausgabe eines Dokumentes wunderbar beeinflussen:

<!doctype html>
<html>
 <head>
  <meta charset="utf-8">
  <title>Liederbuch</title>
  <style>
   article:not(.current) {
    display: none;
   }
   @media print {
    .screen {
     display: none;
    }
   }
   @media screen {
    .print {
     display: none;
    }
   }
  </style>
 </head>
 <body>
  <main>
   <h1 class="screen">Liederbuch</h1>
   <p class="screen">
    Blättern Sie:
    <button id="prev">« vorherige Seite</button>
    <button id="next">nächste Seite »</button>
   </p>
   <article class="current">
    <h2>Ich geh' mit meiner Laterne</h2>
    <p>...</p>
   </article>
   <article>
    <h2>Sankt Martin</h2>
    <p>...</p>
   </article>
  </main>
 </body>
</html>

Wenn Du nun mit JavaScript die Klasse current von einem article zu einem anderen überträgst, dann wird nur dieses angezeigt und gedruckt. Obendrein kannst Du Elemente vor der Druck- oder Bildschirmausgabe "verstecken", indem Du die Klassen print und screen analog verwendest.

Liebe Grüße,

Felix Riesterer.

[Felix Riesterer]

Hallo Ingrid,

Wenn Du nun mit JavaScript die Klasse current von einem article zu einem anderen überträgst, dann wird nur dieses angezeigt und gedruckt. Obendrein kannst Du Elemente vor der Druck- oder Bildschirmausgabe "verstecken", indem Du die Klassen print und screen analog verwendest.

Beispiel zum anschauen

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

die Klasse current

… ist ein Fall, wo man anstelle eines class-Attributs besser ein anderes einsetzt: aria-current. Wenn keiner der speziellen Werte wie "page" passt, dann mit "true". ☞ Using the aria-current attribute (Léonie Watson)

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

die Klasse current

… ist ein Fall, wo man anstelle eines class-Attributs besser ein anderes einsetzt: aria-current.

welchen Sinn hat ein Screenreader bei Musiknoten, die auch noch als JPEG vorliegen? Da reißt es das aria-current auch nicht mehr.

Liebe Grüße,

Felix Riesterer.

[Matthias Apsel]

Hallo Felix Riesterer,

die Klasse current

… ist ein Fall, wo man anstelle eines class-Attributs besser ein anderes einsetzt: aria-current.

welchen Sinn hat ein Screenreader bei Musiknoten, die auch noch als JPEG vorliegen? Da reißt es das aria-current auch nicht mehr.

Keinen. aria-current ist in diesem Fall gleichwertig zur Klasse. In vielen anderen Fällen nicht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Felix Riesterer

welchen Sinn hat ein Screenreader bei Musiknoten, die auch noch als JPEG vorliegen? Da reißt es das aria-current auch nicht mehr.

Ich wollte aria-current="…" anstatt class="current" allgemein in den Raum stellen.

Und da wären wir wieder bei der Frage, welchen Sinn es macht, bei einer speziellen Anwendung von Webtechnologien plötzlich andere Regeln gelten zu lassen als bei einer Webseite.

Und es ist ja auch kein höherer Aufwand damit verbunden: im Markup oben Gesagtes, im Stylesheet [aria-current] anstatt .current.

Ich würde die Nützlichkeit von aria-current auch gar nicht auf Screenreader beschränken wollen. Weiß der Geier, welche Anwendungen das noch für sich nutzen können. Das ist ja das Schöne an HTML: es ist eine deklarative Sprache. HTML beschreibt die Inhalte und deren Struktur. HTML kümmert sich nicht darum, was Anwendungen aus den Beschreibungen machen.

Und ich würde die Bedienbarkeit der Anwendung auch gar nicht mit dem Sehvermögen für die Noten in Verbindung bringen. Warum sollte nicht ein Blinder/Sehschwacher die Anwendung bedienen und die Noten für die anderen Chormitglieder umschalten können?

LLAP 🖖

[JürgenB]

Hallo Linuchs,

ich würde, wie Felix schon vorgeschlagen hat, auch auf die iframes verzichten. Wenn du nicht alle Liederbücher auf einmal ausliefern willst, kannst du sie ja per xmlhttprequest nachladen. Aus dem kompletten html musst du natürlich den Inhalt des Elements mit dem Lied noch extrahieren.

Gruß
Jürgen

[Linuchs]

Aus dem kompletten html musst du natürlich den Inhalt des Elements mit dem Lied noch extrahieren.

Das Liederbuch soll lokal ohne PHP-Server druckbar bleiben.

Das jetzige Parent-Dokument mit den iframes müsste sich also per Javascript die Lieder greifen. Soweit mir bekannt, kann Javascript nicht auf Dateien zugreifen.

Aber dein Vorschlag bringt mich auf die Idee, zumindest das Inhaltsverzeichnis ins Parent-Dokument zu setzen anstatt in einen iframe.

Das kann ich dann zwar nicht mehr einzeln aufrufen zum Drucken, aber ich kann ja vom gesamten Liederbuch nur Seite 1 drucken.

[JürgenB]

Hallo,

Das jetzige Parent-Dokument mit den iframes müsste sich also per Javascript die Lieder greifen. Soweit mir bekannt, kann Javascript nicht auf Dateien zugreifen.

natürlich kann Javascript auf Dateien auf dem Server zugreifen: xmlhttprequest. Alles, was du über url-Eingabe im Browser laden kannst, kannst du auch per xmlhttprequest abrufen.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Soweit mir bekannt, kann Javascript nicht auf Dateien zugreifen.

natürlich kann Javascript auf Dateien auf dem Server zugreifen: xmlhttprequest.

Warum sollte man damit noch rumfuhrwerken wollen? Es gibt das Fetch-API.

Falls nötig: Polyfill.

LLAP 🖖

[JürgenB]

Hallo Gunnar,

natürlich kann Javascript auf Dateien auf dem Server zugreifen: xmlhttprequest.

Warum sollte man damit noch rumfuhrwerken wollen? Es gibt das Fetch-API.

ist das nicht auch ein xmlhttprequest?

Falls nötig: Polyfill.

Wobei man erwähnen sollte, das dieser noch einen Polyfill für Promise benötigt.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

Warum sollte man damit noch rumfuhrwerken wollen? Es gibt das Fetch-API.

ist das nicht auch ein xmlhttprequest?

Was immer sich dahinter verbirgt, es ist weggekapselt. Und das ist auch gut so, das Fetch-API ist einfacher handhabbar.

LLAP 🖖

[Felix Riesterer]

Lieber Linuchs,

Das Liederbuch soll lokal ohne PHP-Server druckbar bleiben.

und was hat Dir an meiner Antwort inklusive ausgearbeiteten online-Beispiel nicht genügt, dass Du noch nicht einmal eine Antwort gegeben hast?

Das jetzige Parent-Dokument mit den iframes müsste sich also

Es müsste sich rest- und ersatzlos entfernen lassen. Den Beweis habe ich dazu bereits erbracht.

Soweit mir bekannt, kann Javascript nicht auf Dateien zugreifen.

Richtig. Aber per XMLHttpRequest-Objekt (AJAX) kann es das doch... auch auf andere HTML-Dokumente im selben Festplattenverzeichnis bzw. auf andere Seiten im Netz.

Liebe Grüße,

Felix Riesterer.

[Linuchs]

Lieber Felix,

und was hat Dir an meiner Antwort inklusive ausgearbeiteten online-Beispiel nicht genügt, dass Du noch nicht einmal eine Antwort gegeben hast?

sorry, ich habe eine Weile nicht nachgeschaut, weil ich eine Sortierfunktion geschrieben und getestet habe.

Die hatte ich bisher nur für Tabellen. Jetzt also auch für Listen.

article:not(.current)

Kannte ich bisher nicht, muss ich mal in Ruhe ausprobieren.

per XMLHttpRequest-Objekt (AJAX) kann es das doch

Missverständnis? Wenn ich das Liederbuch lokal auf dem Rechner habe ohne Server ? Soweit ich weiss, muss AJAX einen PHP-Ansprechpartner haben.

Liebe Grüße, Linuchs

[Felix Riesterer]

Lieber Linuchs,

Missverständnis? Wenn ich das Liederbuch lokal auf dem Rechner habe ohne Server ? Soweit ich weiss, muss AJAX einen PHP-Ansprechpartner haben.

nö. Mir ist es im Firefox gelungen via XMLHttpRequest eine simple Textdatei zu "laden" (Inhalt stand in der Eigenschaft responseText "einfach so" drin). Probier's mal aus! Aber noch finde ich die Lösung in einer einzigen HTML-Datei besser. Zu meinem Beispiel hast Du ja noch immer nichts gesagt...

Liebe Grüße,

Felix Riesterer.

[Rolf B]

Hallo Linuchs,

Soweit ich weiss, muss AJAX einen PHP-Ansprechpartner haben.

es muss einen Ansprechpartner haben. Das MUSS ein http-/https-Server sein, aber nicht zwingend PHP. Nur XMLHttpRequest auf file:/// geht aus naheliegenden Gründen nicht. Und den hat auch Felix nicht gebaut. Wenn Du deine Dateien von file:/// lädst, greift seine Lösung nicht.

D.h. wenn du auf localhost irgendwas bereitstellen kann, das statische HTML Inhalte ausliefern kann, dann kannst Du Ajax und Felix' Idee nutzen.

Rolf

[JürgenB]

Hallo Rolf,

... Nur XMLHttpRequest auf file:/// geht aus naheliegenden Gründen nicht.

die Gründe scheinen (noch) nicht für alle naheliegend zu sein. Der Firefox unterstützt XMLHttpRequest auch von der lokalen Festplatte. Allerdings darf man da nicht auf Status 200 warten.

Gruß
Jürgen

[Gunnar Bittersmann]

@@Rolf B

es muss einen Ansprechpartner haben. Das MUSS ein http-/https-Server sein, aber nicht zwingend PHP. Nur XMLHttpRequest auf file:/// geht aus naheliegenden Gründen nicht

Wieso nicht? Ist es an Request gekoppelt?

LLAP 🖖

[Rolf B]

Hallo Gunnar,

weiß nicht wieso nicht - FF zeigt ja dass es gehen könnte. Man kann in das Verzeichnis der HTML Datei und Unterverzeichnisse hineingreifen.

Chrome sagt: Enä, dat is Cross Origin und das machst Du nicht mit file:///. Wobei es doch gar nicht kreuzweise ist, wenn ich aus file:///d:/temp/hugo.html auf file:///d:/temp/otto.dat zugreifen will.

Ich hatte das Verhalten von Chrome da als "isso" klassifiziert; dass FF das anders macht, wusste ich nicht. Aber offenbar kann man das in Chrome über einen Kommandozeilenschalter auch möglich machen; aber darauf will ich nun nicht eingehen. Offenbar wollen die Spec-ialisten es nicht. shrug

Rolf

[JürgenB]

Hallo,

als ich vor ca. 10 Jahren mit xmlhttprequests angefangen habe, konnte man noch in allen Browsern auf file://... zugreifen. So nach und nach wurde es dann als gefährlich eingestuft, und heute kann es nur noch der FF.

Gruß
Jürgen

[Linuchs]

Das Problem ist, dass das ganze Buch neu geladen wird.

Ich stelle das Inhaltsverzeichnis direkt (anstatt per iframe) ins HTML-Dokument. Dadurch kann man zu den einzelnen Liedern und zurück springen, ohne dass das Dokument neu geladen wird.

Danke für eure Begleitung und Anregungen.

Linuchs