Linuchs: Im iframe blättern

0 62

Im iframe blättern

Linuchs
  • javascript
  • sonstiges
  1. 0
    Matthias Apsel
    1. 0
      Linuchs
      1. 2

        Warum überhaupt ein Workaround?

        Camping_RIDER
        1. 0
          Linuchs
  2. 0
    beatovich
    1. 0
      Linuchs
      1. 0
        Linuchs
  3. 0
    TS
  4. 0
    MudGuard
    1. 0
      TS
  5. 1
    JürgenB
    1. 1
      Camping_RIDER
      1. 0
        Julius
        1. 0
          Camping_RIDER
          1. 0
            beatovich
            1. 0
              Camping_RIDER
              1. 0
                beatovich
                1. 0
                  Camping_RIDER
              2. 0
                JürgenB
                1. 0
                  Julius
                  • browser
                  • html
                  • javascript
                  1. 0
                    beatovich
                    1. 0
                      Julius
                      1. 0
                        beatovich
                        1. 0
                          Julius
                          1. 0
                            beatovich
                            1. 0
                              Julius
                            2. 1
                              Camping_RIDER
                              • javascript
                              • menschelei
                              • zu diesem forum
                            3. 1
                              JürgenB
                              1. 0
                                beatovich
                                1. 0
                                  Camping_RIDER
                                  1. 0
                                    beatovich
                                    1. 0
                                      Camping_RIDER
                                      1. 0
                                        beatovich
                                        1. 0
                                          Camping_RIDER
                                          1. 0
                                            beatovich
                                            1. 0
                                              Matthias Apsel
                                              • meinung
                                              1. 0
                                                beatovich
                                                1. 0
                                                  Matthias Apsel
                                                2. 0
                                                  Julius
                                              2. 0
                                                Julius
                                                1. 0
                                                  beatovich
                                            2. 1
                                              Camping_RIDER
                                              1. 0
                                                beatovich
                                                1. 0
                                                  Camping_RIDER
                                2. 0
                                  JürgenB
                                  1. -3
                                    beatovich
                                    1. 1
                                      JürgenB
                  2. 0
                    JürgenB
                    1. 0
                      Julius
          2. 0
            Julius
            • browser
            • html
            • javascript
            1. 0
              Camping_RIDER
          3. 0
            Camping_RIDER
            1. 0
              JürgenB
              1. 0
                Camping_RIDER
                1. 0
                  Julius
                  • menschelei
                  • politik
                  1. 0
                    Camping_RIDER
                    1. 0
                      Julius
                      1. 0
                        Camping_RIDER
    2. 0
      Linuchs
      1. 1
        Camping_RIDER
  6. 0
    Julius
    • php

problematische Seite

Moin,

Kalender werden gerne per iframe in Webseiten eingebunden.

Einmalig nach dem Laden kann ich die Mutter-Seite per .js überreden, die Höhe des iframes an den tatsächliche Inhalt anzupassen.

Wenn ich aber nun im iframe nach unten scrolle (und damit die Mutterseite scrollend mitnehme) und die nächste Seite des Kalenders anklicke, hätte ich gerne, dass deren oberer Rand wieder sichtbar wird. Es muss also die Mutter-Seite zurück scrollen.

Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?

Geht das irgendwie?

Linuchs

  1. problematische Seite

    Hallo Linuchs,

    Wenn ich aber nun im iframe nach unten scrolle (und damit die Mutterseite scrollend mitnehme) und die nächste Seite des Kalenders anklicke, hätte ich gerne, dass deren oberer Rand wieder sichtbar wird. Es muss also die Mutter-Seite zurück scrollen.

    Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?

    Geht das irgendwie?

    Ich denke nicht. Du möchtest auf ein event reagieren, dass nicht innerhalb deiner Seite stattfindet. Die SOP dürfte dies verhindern.

    Bis demnächst
    Matthias

    --
    Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    1. problematische Seite

      Hallo Matthias,

      Ich denke nicht. Du möchtest auf ein event reagieren, dass nicht innerhalb deiner Seite stattfindet. Die SOP dürfte dies verhindern.

      Also, nach dem Laden meldet der Kalender im iframe per Ajax seine Höhe an seinen "Chef", meinen Server. Der generiert ein Bild mit dieser Höhe. Etwas zeitverzögert holt sich "meine" .js Datei in der Mutterseite dieses Bild und liest die Höhe. Das ist die Höhe des iframes. SOP (Same-Origin-Policy) überlistet.

      So einen Trick brauche ich nochmal.

      Linuchs

      1. problematische Seite

        Aloha ;)

        Also, nach dem Laden meldet der Kalender im iframe per Ajax seine Höhe an seinen "Chef", meinen Server. Der generiert ein Bild mit dieser Höhe. Etwas zeitverzögert holt sich "meine" .js Datei in der Mutterseite dieses Bild und liest die Höhe. Das ist die Höhe des iframes. SOP (Same-Origin-Policy) überlistet.

        So einen Trick brauche ich nochmal.

        Mehrere Dinge:

        1.: Falls du es nicht weißt; irgendwo läuft ein Skript von dir ins Leere - nur zur Info:

        XMLHttpRequest cannot load http://remso.de/css/gif_create.php?gif_name=img593825&hoehe=1411. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://remso.eu' is therefore not allowed access.
        

        2.: Was hindert dich daran, das Bild immer wieder abzufragen und die Breite des Bildes so viele Pixel breit zu machen wie die Nummer der Tabellenseite, die gerade geladen ist? Dein Skript auf der Seite des iframes könnte selbst anfangs eine interne Variable auf "1" setzen und dann Änderungen des Bildes registrieren.

        Bedeutender Nachteil dabei: wenn die Zeitverzögerung zuschlägt springt die Seite dadurch vielleicht unerwartet für den User.

        3.: Warum willst du überhaupt das Pferd von hinten aufzäumen? Du bist der Inhaber der Seite, die im iframe geladen wird und es handelt sich dabei um ein Dokument, das offensichtlich von dir zum Laden im iframe konzipiert wurde. Was hindert dich daran, auf dieser Ressource einen Access-Control-Allow-Origin-Header für die betreffende Domain, die deinen Content einbindet, mitzuschicken?

        Den Header solltest du dabei entweder „on the fly“ jeweils für den Referrer ausstellen können oder durch dein Skript, was ja auch auf der Seite eingebunden wird, an deinen Server schicken lassen können (und dort dann für eine gewisse Zeit zwischenspeichern). Zweiteres hätte den Vorteil, dass du sicher sein kannst, dass dein Werk nur dort eingebunden wird, wo dein Skript auch vorhanden ist.

        Sobald dein Dokument einen entsprechenden CORS-Header mitsendet kannst du ja durch dein in der Seite eingebundenes Skript entsprechend auf den Inhalt des iframe zugreifen, weil die Same-Origin-Policy damit abgeschaltet wird. Dann ist keinerlei Workaround mehr notwendig, weder fürs hochscrollen noch für die Länge der Seite.

        Grüße,

        RIDER

        --
        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
        1. problematische Seite

          Hallo Rider,

          1.: Falls du es nicht weißt; irgendwo läuft ein Skript von dir ins Leere - nur zur Info:

          XMLHttpRequest cannot load http://remso.de/css/gif_create.php?gif_name=img593825&hoehe=1411. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://remso.eu' is therefore not allowed access.
          

          Herzlichen Dank für die Fehlermeldung. Ich habe drei Domains remso.de .eu und .org und muss die vom Leser einmal gewählte Startseite von Programm zu Programm weiterreichen. Hier ist mir der Fehler unterlaufen, .de zu nennen:

          function reportIframeHeight( HOST, gif_name ) {
          ..
          //var url = "http://remso.de/css/gif_create.php?gif_name=" +gif_name +"&hoehe=" +gif_hoehe;
            var url = "http://"+HOST+"/css/gif_create.php?gif_name=" +gif_name +"&hoehe=" +gif_hoehe;
          ..
          }
          

          Mit deinen anderen Anregungen befasse ich mich morgen, wenn ich ausgeschlafen habe.

          Linuchs

  2. problematische Seite

    hallo

    Einmalig nach dem Laden kann ich die Mutter-Seite per .js überreden, die Höhe des iframes an den tatsächliche Inhalt anzupassen.

    nicht wirklich. Du beanspruchst doppelt so viel Platz😉

    Also der iframe mit scrollbar gefällt mir besser. Da muss ich auch kein JS-Recht vergeben.

    1. problematische Seite

      nicht wirklich. Du beanspruchst doppelt so viel Platz😉

      Ja, habe ich gerade gesehen. Ist ein neues Programm im iframe. Ich suche den Fehler.

      Hier klappt das mit demselben Programm prima.

      Linuchs

      1. problematische Seite

        Hier klappt das mit demselben Programm prima.

        Ist zwar dasselbe Programm, aber eine andere Platzhalter-Datei. Habe versehentlich gar kein neues Bild mit der aktuellen Höhe erzeugt, es wurde immer ein altes Bild abgefragt.

        Ist behoben, danke dir.

        Linuchs

  3. problematische Seite

    Hello,

    Wenn ich aber nun im iframe nach unten scrolle (und damit die Mutterseite scrollend mitnehme) und die nächste Seite des Kalenders anklicke, hätte ich gerne, dass deren oberer Rand wieder sichtbar wird. Es muss also die Mutter-Seite zurück scrollen.

    Ich sehe da in den Links im iFrame zu Seite 1 2 3 4 gar keinen Fragment-Anteil. Hast Du das schon mal ausprobiert?

    Im übrigen könntest Du es - sofern der einbindende Betreiber auch mitspielt - auch durchparametrisieren. [Mehr dazu bei Interesse, ist mir sonst zu stressig]. Beim Aufruf der Top-Seite aus dem iFrame heraus per aktiver Userbeteiligung (klicken auf einen Link) wird dies durchaus auch mit Target-Attribut im Link ausgeführt. Dann würde also die Hauptseite neu geladen und das iFrame auch, aber mit einer Fragment-Angabe. Diese Angabe muss der Hauptseitenbetreiber ebn nur mitgeben. Das kann er per aktivem Backend (PHP) oder per JavaScript.

    Ich habe das eben übrigens extra nachgebaut, um es auszuprobieren...

    Liebe Grüße
    Tom S.

    --
    Die Krawatte ist das Kopftuch des Westens
  4. problematische Seite

    Hi,

    Einmalig nach dem Laden kann ich die Mutter-Seite per .js überreden, die Höhe des iframes an den tatsächliche Inhalt anzupassen.

    Der iframe ist also groß genug für seinen Inhalt.

    Wenn ich aber nun im iframe nach unten scrolle

    Das geht ja nicht, denn der iframe ist ja, siehe oben, groß genug, daß kein Scrollen erforderlich ist.

    cu,
    Andreas a/k/a MudGuard

    1. problematische Seite

      Hello,

      Einmalig nach dem Laden kann ich die Mutter-Seite per .js überreden, die Höhe des iframes an den tatsächliche Inhalt anzupassen.

      Der iframe ist also groß genug für seinen Inhalt.

      Wenn ich aber nun im iframe nach unten scrolle

      Das geht ja nicht, denn der iframe ist ja, siehe oben, groß genug, daß kein Scrollen erforderlich ist.

      und die vertikale Neupositionierung soll damit nicht im iFrame, sondern in der Hauptseite erfolgen. Das wird nur sicher möglich sein, indem man in der Hauptseite die Anker setzt, und diese mit Parametern für das Fragemnt im iFrame neu aufruft. Das kann man entweder mittels aktiven Serverbackend, aber bei verteilten Hoheitsrechten wohl eher mittles JavaScript in der Hauptseite. Dieses muss dann (anstelle oder zusätzlich des/zum iFrame-Element) vom Hauptseitenbetreiber eingebunden werden.

      Liebe Grüße
      Tom S.

      --
      Die Krawatte ist das Kopftuch des Westens
  5. problematische Seite

    Hallo Linuchs,

    schon mal dran gedacht, den Kalender über http-Request und CORS einzulesen und dann per innerHTML ins Dokument zu schreiben?

    Gruß
    Jürgen

    1. problematische Seite

      Aloha ;)

      schon mal dran gedacht, den Kalender über http-Request[1] und CORS einzulesen und dann per innerHTML ins Dokument zu schreiben?

      Ungefähr in die Richtung ging meine Idee auch, wobei du natürlich Recht hast - wenn CORS, dann kann man sich den iframe sparen und das gleich elegant lösen. Das löst dann auch noch gleich die mögliche Race-Condition, die sich in meinem Ansatz versteckt hält[2], mit auf.

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

      1. Du meinst http-Request Sinne von xmlHttpRequest / AJAX, oder? ↩︎

      2. Will man nicht den Referrer benutzen wäre es in meinem Beispiel möglich, dass der iframe abgerufen wird, bevor das Javascript das Setzen des CORS-headers initial auslöst. ↩︎

      1. problematische Seite

        Hallo RIDER,

        Ungefähr in die Richtung ging meine Idee auch, wobei du natürlich Recht hast - wenn CORS, dann kann man sich den iframe sparen und das gleich elegant lösen.

        Braucht man einen Fallback, falls CORS oder JS nicht funktioniert? Einen Link? Oder ein iFrame in einem noscript-Element?

        Gruß
        Julius

        1. problematische Seite

          Aloha ;)

          Braucht man einen Fallback, falls CORS oder JS nicht funktioniert? Einen Link? Oder ein iFrame in einem noscript-Element?

          Guter Einwand. Auch die Idee mit dem iframe ist gut; immerhin ist das mit dem Scrollen und der Höhenbestimmung unterm Strich nur Luxus; der iframe bietet ja die Funktionalität für den Fallback-Fall komplett.

          Allerdings würde ich in dem Fall nicht (allein) auf <noscript> setzen. Es mag Browser geben, die JS erlauben und CORS nicht unterstützen.

          Wie wärs mit:

          • Fallback-iframe in noscript-Element
          • Feature Detection zu CORS (z.B. via Try...Catch am XMLHttpRequest)
          • im Fehlerfall (bei Catch): iframe aus noscript lösen und via innerHTML statt dem, was der XMLHttpRequest im Erfolgsfall geliefert hätte, an der gewünschten Stelle einfügen.

          So fängt man sowohl nicht-funktionierendes JS als auch nicht funktionierendes CORS ab ohne redundantes Fallback-Markup.

          Grüße,

          RIDER

          P.S.: Statt dem „Umhängen“ des iframe könnte man auch den noscript-Bereich irgendwie sichtbar machen - falls das geht. Mir fiel im Moment keine Möglichkeit ein, deshalb das „umhängen“. Korrigiert mich, falls ich da was nicht weiß.

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          1. problematische Seite

            • im Fehlerfall (bei Catch): iframe aus noscript lösen und via innerHTML statt dem, was der XMLHttpRequest im Erfolgsfall geliefert hätte, an der gewünschten Stelle einfügen.

            ... und hoffen dass es keine CSS Nebenwirkungen gibt.

            1. problematische Seite

              Aloha ;)

              • im Fehlerfall (bei Catch): iframe aus noscript lösen und via innerHTML statt dem, was der XMLHttpRequest im Erfolgsfall geliefert hätte, an der gewünschten Stelle einfügen.

              ... und hoffen dass es keine CSS Nebenwirkungen gibt.

              Darauf muss man nicht hoffen, dafür kann man schon im Vorhinein sorgen 😉

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
              1. problematische Seite

                hallo

                Darauf muss man nicht hoffen, dafür kann man schon im Vorhinein sorgen 😉

                Trotzdem unglaublich, zu welcher Strecke man hier jemandem für etwas Lippenstift rät. Etwas Besinnung täte gut.

                1. problematische Seite

                  Aloha ;)

                  Darauf muss man nicht hoffen, dafür kann man schon im Vorhinein sorgen 😉

                  Trotzdem unglaublich, zu welcher Strecke man hier jemandem für etwas Lippenstift rät. Etwas Besinnung täte gut.

                  Du sprichst in Rätseln. Zumindest verstehe ich nicht, was genau du mir damit sagen möchtest 😉

                  Grüße,

                  RIDER

                  --
                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                  # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
              2. problematische Seite

                Hallo,

                ich antworte mal hier.

                Ja, ich meine einen "normalen http-Request / Ajax. Wenn IE8/9 nicht unterstützt werden müssen, reicht das für CORS. IE8/9 haben hierfür eine eigene Methode. Zusätzlich muss natürlich der Header Access-Control-Allow-Origin "*" gesendet werden.

                Der Fall "kein Javascript" interessiert mich nicht mehr. Wer Javascript abschaltet, muss mit den Nebenwirkungen leben.

                Das Risiko von Kollisionen im CSS kann man durch eine vernünftige Namenswahl auf ein vertretbates Maß reduzieren.

                Gruß
                Jürgen

                1. problematische Seite

                  Hallo Jürgen,

                  Ja, ich meine einen "normalen http-Request / Ajax. Wenn IE8/9 nicht unterstützt werden müssen, reicht das für CORS. IE8/9 haben hierfür eine eigene Methode.

                  Wenn der generische Fallback mit dem iFrame funktioniert, braucht man sich um den alten IE imho nicht mehr kümmern.

                  Der Fall "kein Javascript" interessiert mich nicht mehr. Wer Javascript abschaltet, muss mit den Nebenwirkungen leben.

                  Ich sehe das etwas anders: Wenn es für mich mit minimalem Aufwand umsetzbar ist, dann wird ein Fallback eingebaut. Außerdem könnte ein Werbeblocker oder ein Privatssphäreschutz auf die Idee kommen, das Script von der fremden Domain zu blocken.

                  Mein Markup würde etwa so aussehen:

                  <section>
                    <h2>Veranstaltungskalender</h2>
                    <a href="https://kalender.example.org/12345" id="calendar" data-target="12345">Zum Veranstaltungskalender</a>
                    <script src="https://kalender.example.org/script.js" async></script>
                  </section>
                  

                  Das Attribut data-target brauchen wir, damit das Script weiß, welche Seite es einbinden muss. Wir haben dann drei sogar Fallback-Ebenen:

                  1. Link (kein JS)
                  2. iFrame (kein CORS)
                  3. per Ajax eingebetteter Inhalt (Ziel)

                  Bei den beiden letzten Punkten wird der Link durch das iFrame bzw. den Inhalt ersetzt.

                  Das Risiko von Kollisionen im CSS kann man durch eine vernünftige Namenswahl auf ein vertretbates Maß reduzieren.

                  Andererseits könnte man ja mit den „Kollisionen“ auch dafür sorgen, dass der Inhalt sich besser dem Design der Seite anpasst. Linuchs hatte damit ja schon mal zu tun.

                  Gruß
                  Julius

                  1. problematische Seite

                    hallo

                    id="calendar"

                    remso bietet Inhalt, der in host-content eingebaut wird. Deshalb darfst remso keine ids reservieren, die der Hostcontent bereits benutzen könnte.

                    1. problematische Seite

                      Hallo beatovich,

                      id="calendar"

                      remso bietet Inhalt, der in host-content eingebaut wird. Deshalb darfst remso keine ids reservieren, die der Hostcontent bereits benutzen könnte.

                      Dieses Snippet baut der Seitenautor bei sich ein. Das kann man sicher noch so anpassen, das man die ID vorgeben kann. Sonst mit (konfigurierbaren) Prefixen à la remso_ arbeiten.

                      Und wenn der Webmaster und Linuchs eventuell etwas Arbeit investieren müssen – für den Nutzer wird es sicher ein Mehrwert sein[1], wenn das iFrame weg kommt.

                      Gruß
                      Julius



                      1. Obwohl Linuchs Workaround sich von der Nutzerseite recht gut (für ein iFrame) anfühlt... ↩︎

                      1. problematische Seite

                        hallo

                        für den Nutzer wird es sicher ein Mehrwert sein[^1], wenn das iFrame weg kommt.

                        ... aber sicher, nur werde ich für diesen Mehrwert, Temperaturen und CO2 nicht NoScript deaktivieren.

                        1. problematische Seite

                          Hallo beatovich,

                          für den Nutzer wird es sicher ein Mehrwert sein[^1], wenn das iFrame weg kommt.

                          ... aber sicher, nur werde ich für diesen Mehrwert, Temperaturen und CO2 nicht NoScript deaktivieren.

                          ... aber du kommst dennoch an die Information, weil du ja den Link anklicken kannst!

                          Gruß
                          Julius

                          1. problematische Seite

                            hallo

                            ... aber du kommst dennoch an die Information, weil du ja den Link anklicken kannst!

                            Der jetzige Zustand ist ja gut. Ich wüsste wirklich nicht, welche essentielle Verbesserung da javascript überhaupt leisten soll. Wie gesagt, stinkt nach unnötigem CO2 Ausstoss. 😉

                            1. problematische Seite

                              N’ Abend beatovich!

                              ... aber du kommst dennoch an die Information, weil du ja den Link anklicken kannst!

                              Der jetzige Zustand ist ja gut. Ich wüsste wirklich nicht, welche essentielle Verbesserung da javascript überhaupt leisten soll.

                              Steht doch im Eröffnungsposting: Linuchs will dafür sorgen, dass bei einer Aktion (hier: andere Seite aufrufen) im iFrame die Höhe des iFrames angepasst wird, was aber nur beim kompletten Neuladen der Seite mit dem iFrame drauf möglich ist. Diese Lösung ist in modernen Browser mit eingeschaltetem JavaScript eine Verbesserung und ermöglicht aufgrund größerer Flexibilität Erweiterungen.

                              Ob Linuchs das einbaut, ist seine Sache.

                              Gruß
                              Julius

                            2. problematische Seite

                              Aloha ;)

                              Der jetzige Zustand ist ja gut. Ich wüsste wirklich nicht, welche essentielle Verbesserung da javascript überhaupt leisten soll. Wie gesagt, stinkt nach unnötigem CO2 Ausstoss. 😉

                              Das kannst du irgendwie dann von dem Standpunkt aus zu ungefähr jeder (oder zu mindest fast jeder) Diskussion sagen, die wir hier jemals zu JavaScript geführt haben.

                              Oder du lässt es, weil es nichts Konstruktives zur Diskussion beiträgt und die Diskussionen nur unnötig aufbläht. 😉

                              Wir sind nicht hier, um Funktionalitäten oder den Wunsch danach zu verurteilen, nur weil man sie nicht braucht. Wir raten ab, wenn sie schädlich sind. Wir raten zu Nachbesserung, wenn sie Benutzergruppen ohne deren Eigenverschulden benachteiligten. Aber wir stellen nicht ihren grundlegenden Sinn in Frage, wenn sie jemand haben will und seine (gerne auch persönlichen) Gründe dafür hat.

                              Unnötiger CO2-Ausstoß ist übrigens in dem Umfang nicht per se schädlich - außer für mein armes Brain, wenn er als Argument missbraucht wird 😝

                              Grüße,

                              RIDER

                              --
                              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                            3. problematische Seite

                              Hallo

                              Ich wüsste wirklich nicht, welche essentielle Verbesserung da javascript überhaupt leisten soll. Wie gesagt, stinkt nach unnötigem CO2 Ausstoss. 😉

                              wir wissen inzwischen ja, dass du Javascript doof findest. Du musst jetzt nicht auch noch die Umweltkeule rausholen. Obwohl, vielleicht magst du ja mal begründen, warum die Reduzierung der Serveranfragen und des zu übertragenden Datenvolumens den CO2-Ausstoß erhöhen soll.

                              Gruß
                              Jürgen

                              1. problematische Seite

                                hallo

                                Sei mal ganz ehrlich. Würdest du

                                • ein Javascript von einer Site einbinden, die mit deinem Inhalt machen kann, was immer gerade die Site tun kann?
                                • würdest du dazu auch noch extra Rechte geben?
                                • und das für eine Site die selber Inhalte von unbekannten Quellen akzeptiert?
                                1. problematische Seite

                                  Aloha ;)

                                  Sei mal ganz ehrlich.

                                  Bin ich immer.

                                  Würdest du

                                  • ein Javascript von einer Site einbinden, die mit deinem Inhalt machen kann, was immer gerade die Site tun kann?
                                  • würdest du dazu auch noch extra Rechte geben?
                                  • und das für eine Site die selber Inhalte von unbekannten Quellen akzeptiert?

                                  Ja. Tu ich ständig. Ohne schlechtes Gewissen. Unter anderem weil:

                                  • ein Javascript von einer Site einbinden, die mit deinem Inhalt machen kann, was immer gerade die Site tun kann?

                                  Mit was für einem Inhalt kann JavaScript was machen? Mit dem, was ich in meinem Browserfenster sehe? Ja, dafür ist JavaScript da. Mit meinen persönlichen Daten? Mit meinen Daten aus anderen Seiten? Mit meiner Browser-History? Nein, darauf hat JavaScript keinen speziellen Zugriff.

                                  • würdest du dazu auch noch extra Rechte geben?

                                  Ich muss für JavaScript keine Rechte geben. JavaScript wird abgeschottet im Kontext meines Browsers ausgeführt und im Vergleich zu vielen anderen Dingen, die noch so kreuchen und fleuchen ist JavaScript hervorragend isoliert und gesichert.

                                  • und das für eine Site die selber Inhalte von unbekannten Quellen akzeptiert?

                                  Jede Seite kann Inhalte von überall nachladen. Auch das kann man verhindern (Stichwort uBlock/uMatrix) ohne einen JavaScript-Blocker zu verwenden und das ist auch noch konsequenter (Script-Ausführung blockst du, aber Bilder und Videos lässt du von Fremdquellen zu⁉️).

                                  Ohne dir persönlich auf den Schlipps treten zu wollen: Ich bekomme (aufgrund deiner Argumentationsweise) mehr und mehr den Eindruck, dass du hier einen argumentationslosen Rant hinlegst ohne wirklich zu wissen wovon du sprichst.

                                  Grüße,

                                  RIDER

                                  --
                                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                  # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                  1. problematische Seite

                                    hi du darfst natürlich auch antworten 😉

                                    Aber du hast natürlich ein paar Dinge vergessen: keine deiner Browser-Instrumente kann entscheiden, welche Teile von remso geprüft und welche kompromitiert sind. Im Kontext der Frage meine ich auch nicht dich als Browser-Benutzer sondern dich als Domain-Betreiber der Inhalte so und so vielen Nutzern und deren Browsern anvertraut.

                                    Und hier gilt die Frage: würdest du als Domainbetreiber Inhalte von Schadsoftwarevebreitern einbinden?

                                    1. problematische Seite

                                      Aloha ;)

                                      Im Kontext der Frage meine ich auch nicht dich als Browser-Benutzer sondern dich als Domain-Betreiber der Inhalte so und so vielen Nutzern und deren Browsern anvertraut.

                                      Und hier gilt die Frage: würdest du als Domainbetreiber Inhalte von Schadsoftwarevebreitern einbinden?

                                      Nein. Aber: Ich prüfe meine eigene Seite (und selbstverständlich die Einbindung) regelmäßig. Ich vertraue dem Betreiber der Seite, die ich einbinde, aus Gründen (zum Beispiel, weil er selbst einen Ruf zu verlieren hat, oder, weil ich ihn kenne, oder, weil ich andere Gründe dafür habe, ihm zu vertrauen, dass er aktiv auf seiner Seite keinen Schadcode verbreitet).

                                      Dementsprechend kann ich davon ausgehen, dass dort kein Schadcode vertrieben wird.

                                      Das nennt man Vertrauen, und das ist (nicht im Übermaß, aber im Mindestmaß) absolut notwendig, wenn man im Internet (und auch überall sonst in der IT-Welt) nicht vollständig sein eigenes Ding machen will.

                                      Schon mal von PGP (Pretty Good Privacy) gehört? Auch das basiert auf einem Konzept von Vertrauen und ist eine effektive Methode zur Zertifizierung ohne Certificate Authority.

                                      Vertrauen ist kein Konzept, das man ablehnen sollte, sondern ein Konzept, das man mit Augenmaß nutzen sollte. Ansonsten kann man sich im Endeffekt gleich im eigenen Garten vergraben.

                                      Das betrifft mich als Seitenbetreiber, von dessen Vertrauensverteilung auch seine Nutzer abhängen, im gleichen Maß wie die Nutzer, die dem Seitenbetreiber durch ihren Besuch ihr Vertrauen (oft als Vertrauensvorschuss) ausdrücken.

                                      Und noch mehr: Wenn ein Benutzer mir und meiner Seite keinen Vertrauensvorschuss geben will (zum Beispiel, indem er uBlock/uMatrix nutzt) kann ein Benutzer meine Seite trotzdem aufrufen, ohne sich auf mich verlassen zu müssen! Er kann dann auf meiner Seite anhand der Daten, was meine Seite gerne angefordert hätte (und danach, was das dann wieder nachgeladen hätte) sogar im Nachhinein entscheiden, ob ich vertrauenswürdig bin oder nicht.

                                      Grüße,

                                      RIDER

                                      --
                                      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                      1. problematische Seite

                                        hallo

                                        Im Kontext der Frage meine ich auch nicht dich als Browser-Benutzer sondern dich als Domain-Betreiber der Inhalte so und so vielen Nutzern und deren Browsern anvertraut.

                                        Und hier gilt die Frage: würdest du als Domainbetreiber Inhalte von Schadsoftwarevebreitern einbinden?

                                        Nein. Aber: Ich prüfe meine eigene Seite (und selbstverständlich die Einbindung) regelmäßig. Ich vertraue dem Betreiber der Seite, die ich einbinde, aus Gründen (zum Beispiel, weil er selbst einen Ruf zu verlieren hat, oder, weil ich ihn kenne, oder, weil ich andere Gründe dafür habe, ihm zu vertrauen, dass er aktiv auf seiner Seite keinen Schadcode verbreitet).

                                        Ach und wie kommst du auf die Idee, dass jemand "aktiv" Schadcode verbreiten muss, damit Schadcode verbreitet wird? http genügt.

                                        Das nennt man Vertrauen, und das ist (nicht im Übermaß, aber im Mindestmaß) absolut notwendig, wenn man im Internet (und auch überall sonst in der IT-Welt) nicht vollständig sein eigenes Ding machen will.

                                        Man kann das Vertrauen aber auch überstrapazieren. Und dieser Fall ist hier gegeben, wo eine iframe-Lösung abgelöst werden soll (wenn es nach den Meinungen der Ratgeber gehen soll) durch etwas, das noch mehr Vertrauen beansprucht.

                                        Schon mal von PGP (Pretty Good Privacy) gehört? Auch das basiert auf einem Konzept von Vertrauen und ist eine effektive Methode zur Zertifizierung ohne Certificate Authority.

                                        Das ist ein gutes Beispiel für geringstes Misstrauen, nicht für Vertrauen.

                                        Aber ich möchte mal auf einer ähnlichen Ebene diskutieren. Ich verwende derzeit auf meiner Site google fonts. Kein Problem, wenn die nicht geladen werden, da eine Ersatzglyphe auf jeden Fall existiert. Aber denoch, im Grunde vertraue ich darauf dass die Fonts nicht kompromitiert sind. Es gab in der Vergangenheit mehr als einen Fall wo Webfonts mehr Rechte beansprucht haben, als vorgesehen waren. Soll ich mich nun zurücklehnen und sagen: Ach google hat so einen Ruf zu verlieren… Google chrome hat auch für eine Weile ungefragt über das Mikrophon gelauscht.

                                        Die Sache ist, es stört mich und ich bin hin und her gerissen. Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.

                                        Vertrauen ist einfach nur ein schlechtes Argument. Die Wirklichkeit ist nämlich eine ganz andere. Wir sehe heute das Vorantreiben von Security-Guidelines, allen voran, https als default aber keineswegs dort endend.

                                        Ich akzeptiere deine Meinung, und deine ausführlichere Antwort, die ja nicht selbstverständlich ist. Aber ich stehe hier eben für ein etwas anderes Bewusstsein.

                                        Und damit können wir die Frage angehen: Unter welchen Umständen wäre ich bereit, remso in meine Website einzubinden? Denn wenn ich jemandem Rat erteile, dann soll das ja mein eigenes Bewusstsein richtig wiedergeben und fair sein.

                                        • Der Inhalt ist als iframe einzubinden (Trennung von Document-Structur)
                                        • Der zu ladende Inhalt muss via https ausgeliefert werden und muss sich auf eine domain beschränken.
                                        • optional darf die Ressource mit einem Parameter aufgerufen werden, der zur Folge hat, dass das CSS des iframes farblich und anderweitig zu meinem eigenen Site-Theme passt.
                                        • natürlich auch Datenbank-relevante Parameter.
                                        • Der Inhalt darf nicht über eine Funktionalität verfügen, die Abfragen darstellt, für die ich nicht gerade stehe (Abfragen zu Events, die ich nicht befürworte).

                                        Aber eventuell würde ich auch einen server-server Datenaustausch vorziehen, indem mein Server selber eine API auf remso.de benutzt, und das Resultat selber cacht. Für den Client wäre ich da selber verantwortlich, und könnte somit selbstverantwortlich bezüglich der Datenintegrität vorgehen.

                                        mfg

                                        1. problematische Seite

                                          Aloha ;)

                                          Nein. Aber: Ich prüfe meine eigene Seite (und selbstverständlich die Einbindung) regelmäßig. Ich vertraue dem Betreiber der Seite, die ich einbinde, aus Gründen (zum Beispiel, weil er selbst einen Ruf zu verlieren hat, oder, weil ich ihn kenne, oder, weil ich andere Gründe dafür habe, ihm zu vertrauen, dass er aktiv auf seiner Seite keinen Schadcode verbreitet).

                                          Ach und wie kommst du auf die Idee, dass jemand "aktiv" Schadcode verbreiten muss, damit Schadcode verbreitet wird?

                                          Naja, davon gehe ich nicht per se aus. Aber es sind nunmal zwei Fälle, von denen einer gravierender ist als der andere, und der gravierendere liegt nicht vor. Mein gesamtes Posting plädiert dafür, dass es eben keine vollständige Sicherheit gibt, sondern dass immer ein Restrisiko bleibt, das einzuschränken, aber nicht notwendigerweise auszumerzen ist.

                                          http genügt.

                                          Ich will dir nicht per se widersprechen, weil ich nicht davon ausgehe, die Weisheit mit Löffeln gefressen zu haben - aber das musst du mir näher erläutern. HTTPS ist im Prinzip ja nur eine verschlüsselte HTTP-Verbindung. Die einzige Art und Weise, wie man da jetzt an Schadcode kommen könnte, (die mir einfällt), wäre ein Man-in-the-Middle-Angriff.

                                          Nur, dass HTTPS da auch nicht immer schützt.

                                          Man kann das Vertrauen aber auch überstrapazieren. Und dieser Fall ist hier gegeben, wo eine iframe-Lösung abgelöst werden soll (wenn es nach den Meinungen der Ratgeber gehen soll) durch etwas, das noch mehr Vertrauen beansprucht.

                                          Nein. Du hast das originale Posting offensichtlich nicht ansatzweise gut genug gelesen! Ich zitiere daraus:

                                          Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?

                                          Die Einbindung von JavaScript in die Seite bestand also sowieso schon, das war nichts, was von uns ins Spiel gebracht wurde.

                                          Genausowenig soll die iframe-Lösung abgelöst werden (als Fallback soll sie nach unserer Meinung vorhanden bleiben), sondern sie soll für die, die kein JS aktivieren wollen, vorhanden bleiben. Es macht also niemand bestehende Funktionalität kaputt.

                                          Schon mal von PGP (Pretty Good Privacy) gehört? Auch das basiert auf einem Konzept von Vertrauen und ist eine effektive Methode zur Zertifizierung ohne Certificate Authority.

                                          Das ist ein gutes Beispiel für geringstes Misstrauen, nicht für Vertrauen.

                                          Nein. Das ist ein Beispiel für Vertrauen. PGP basiert auf der Idee des Web of Trust. Dabei geht es im wesentlichen darum, dass Vertrauen in Zertifikate bekannter (und selbst vertrauter) Kommunikationsteilnehmern an unbekannte Kommunikationsteilnehmer vererbt wird, und das ist ziemlich genau das, was hier auch passiert.

                                          Aber ich möchte mal auf einer ähnlichen Ebene diskutieren. Ich verwende derzeit auf meiner Site google fonts. Kein Problem, wenn die nicht geladen werden, da eine Ersatzglyphe auf jeden Fall existiert. Aber denoch, im Grunde vertraue ich darauf dass die Fonts nicht kompromitiert sind. Es gab in der Vergangenheit mehr als einen Fall wo Webfonts mehr Rechte beansprucht haben, als vorgesehen waren. Soll ich mich nun zurücklehnen und sagen: Ach google hat so einen Ruf zu verlieren… Google chrome hat auch für eine Weile ungefragt über das Mikrophon gelauscht.

                                          Die Sache ist, es stört mich und ich bin hin und her gerissen.

                                          Das kann ich nachvollziehen, aber…

                                          Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.

                                          …das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert. Damit bleibt man vielleicht (an dieser Front!) unangreifbar, kann sich dann aber doch irgendwann im Garten vergraben, weil man so nicht in der Lage ist, mit Bedürfnissen und Möglichkeiten, sowohl von Kunden (allgemeiner: Benutzern) als auch von Konkurrenten, mitzuhalten.

                                          Vertrauen ist einfach nur ein schlechtes Argument.

                                          Nein, ist es nicht. Man darf Vertrauen nur nicht mit Sicherheit verwechseln. Aber jeder, der sich auch nur ein bisschen damit auskennt, weiß, dass absolute Sicherheit in IT-Systemen gar kein Maßstab sein kann. Fakt ist, dass sich Sicherheit immer nach den Anforderungen richten muss. Das bedeutet aber auch, dass man als Webseitenbetreiber ein gewisses, auf Vertrauen beruhendes Rechtrisiko in Kauf nehmen darf, ja regelrecht muss.

                                          Die Wirklichkeit ist nämlich eine ganz andere. Wir sehe heute das Vorantreiben von Security-Guidelines, allen voran, https als default aber keineswegs dort endend.

                                          https als default ist nicht so sehr eine Frage der Sicherheit allgemein als vielmehr der Datensicherheit im Speziellen. Die Sicherheit gegenüber Schadcode muss an ganz anderer Stelle gewährleistet werden: Nicht da, wo der potenzielle Schadcode ins Web gelangt, sondern da, wo der Schadcode aus dem Browser ausbricht. Und in diesem Bereich wird wirklich sicherheitsrelevanter Fortschritt gemacht. Stichwort Sandboxing von Flash, Sandboxing von JavaScript, usw. usf…

                                          Und damit können wir die Frage angehen: Unter welchen Umständen wäre ich bereit, remso in meine Website einzubinden? Denn wenn ich jemandem Rat erteile, dann soll das ja mein eigenes Bewusstsein richtig wiedergeben und fair sein.

                                          • Der Inhalt ist als iframe einzubinden (Trennung von Document-Structur)
                                          • Der zu ladende Inhalt muss via https ausgeliefert werden und muss sich auf eine domain beschränken.
                                          • optional darf die Ressource mit einem Parameter aufgerufen werden, der zur Folge hat, dass das CSS des iframes farblich und anderweitig zu meinem eigenen Site-Theme passt.
                                          • natürlich auch Datenbank-relevante Parameter.
                                          • Der Inhalt darf nicht über eine Funktionalität verfügen, die Abfragen darstellt, für die ich nicht gerade stehe (Abfragen zu Events, die ich nicht befürworte).

                                          Das security-plus hier möchte ich gar nicht abstreiten…

                                          Aber eventuell würde ich auch einen server-server Datenaustausch vorziehen, indem mein Server selber eine API auf remso.de benutzt, und das Resultat selber cacht. Für den Client wäre ich da selber verantwortlich, und könnte somit selbstverantwortlich bezüglich der Datenintegrität vorgehen.

                                          …ebensowenig hier.

                                          Aber mit beidem gibst du jeweils auch Dinge auf, vorrangig: Komfort, auch in der User Experience (sogar gar nicht so wenig), und das dürfte den meisten Webentwicklern dieses security-plus begründeterweise nicht wert sein.

                                          Es ist genausowenig umsichtig, sich überhaupt nicht um security zu kümmern, wie security über alles Andere zu stellen. Und selbst wenn du das für dich so halten möchtest: anderen ohne driftige Gründe dasselbe raten oder sogar Leute, die das anders sehen, anzugreifen ist sicher nicht gerechtfertigt (und im Rahmen dieses Forums auch nicht erwünscht!).

                                          Grüße,

                                          RIDER

                                          --
                                          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                          1. problematische Seite

                                            hallo

                                            Naja, davon gehe ich nicht per se aus. Aber es sind nunmal zwei Fälle, von denen einer gravierender ist als der andere, und der gravierendere liegt nicht vor. Mein gesamtes Posting plädiert dafür, dass es eben keine vollständige Sicherheit gibt, sondern dass immer ein Restrisiko bleibt, das einzuschränken, aber nicht notwendigerweise auszumerzen ist.

                                            Vollständig Sicherheit ist eine Illusion, das ist klar. Wir reden hier in den meisten Fällen von http/https Kontext. Dass Server oder Browser an sich kompromitiert sein können sollten wir im Hinterkopf behalten.

                                            http genügt.

                                            Ich will dir nicht per se widersprechen, weil ich nicht davon ausgehe, die Weisheit mit Löffeln gefressen zu haben - aber das musst du mir näher erläutern. HTTPS ist im Prinzip ja nur eine verschlüsselte HTTP-Verbindung. Die einzige Art und Weise, wie man da jetzt an Schadcode kommen könnte, (die mir einfällt), wäre ein Man-in-the-Middle-Angriff.

                                            Über man-in-the-middle müssen wir glaube ich heute nicht mehr diskutieren. Die Frage ist lediglich, in welchem Kontext diese auch wahrscheinlich und aussichtsreich ist.

                                            Im Fall von remso.de ist nicht nur die Datenauslieferung, sondern auch die Datenerstellung an sich für solche Angriffe offen.

                                            Nur, dass HTTPS da auch nicht immer schützt.

                                            https muss man natürlich abhärten. Das kann man mit entsprechenden Headern erreichen insofern diese die Header verstehen.

                                            Nein. Du hast das originale Posting offensichtlich nicht ansatzweise gut genug gelesen! Ich zitiere daraus:

                                            Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?

                                            ist dir aufgefallen, dass dieses Datei nicht im geringsten relevant ist fr Abfragen, die innerhalb des iframes getätigt werden (das heisst, Abfragen funktionieren bei blockiertem Javascript).

                                            Die Einbindung von JavaScript in die Seite bestand also sowieso schon, das war nichts, was von uns ins Spiel gebracht wurde.

                                            Nein, sie besteht nur aus kosmetischen Gründen, um einen nicht essentiellen Fix durchzuführen.

                                            Genausowenig soll die iframe-Lösung abgelöst werden (als Fallback soll sie nach unserer Meinung vorhanden bleiben), sondern sie soll für die, die kein JS aktivieren wollen, vorhanden bleiben. Es macht also niemand bestehende Funktionalität kaputt.

                                            Der wunsch wurde schon mal geäussert: https://forum.selfhtml.org/self/2017/mar/5/im-iframe-blaettern/1689017#m1689017

                                            Schon mal von PGP (Pretty Good Privacy) gehört? ... Nein. Das ist ein Beispiel für Vertrauen. PGP basiert auf der Idee des Web of Trust. Dabei geht es im wesentlichen darum, dass Vertrauen in Zertifikate bekannter (und selbst vertrauter) Kommunikationsteilnehmern an unbekannte Kommunikationsteilnehmer vererbt wird, und das ist ziemlich genau das, was hier auch passiert.

                                            Die Grundlage von PGP ist Misstrauen. Es existiert weil die Vertrauenswürdigkeit bezüglich Sender und Empfänger so essentiell ist.

                                            Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.

                                            …das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert.

                                            warum nicht?

                                            Damit bleibt man vielleicht (an dieser Front!) unangreifbar,

                                            also funktioniert es an dieser Front.

                                            kann sich dann aber doch irgendwann im Garten vergraben, weil man so nicht in der Lage ist, mit Bedürfnissen und Möglichkeiten, sowohl von Kunden (allgemeiner: Benutzern) als auch von Konkurrenten, mitzuhalten.

                                            Kannst du bitte genauer ausführen, wo sich jemand, der selber Ressourcen hostet, Nachteile aufbürdet, oder Usern Nachteile bietet?

                                            Und damit können wir die Frage angehen: Unter welchen Umständen wäre ich bereit, remso in meine Website einzubinden? Denn wenn ich jemandem

                                            Das security-plus hier möchte ich gar nicht abstreiten…

                                            Aber eventuell würde ich auch einen server-server Datenaustausch vorziehen, indem mein Server selber eine API auf remso.de benutzt, und das Resultat selber cacht. Für den Client wäre ich da selber verantwortlich, und könnte somit selbstverantwortlich bezüglich der Datenintegrität vorgehen.

                                            …ebensowenig hier.

                                            Aber mit beidem gibst du jeweils auch Dinge auf, vorrangig: Komfort, auch in der User Experience (sogar gar nicht so wenig), und das dürfte den meisten Webentwicklern dieses security-plus begründeterweise nicht wert sein.

                                            Bitte nochmals ausführen: Wenn ich also Usern nur Inhalte biete, für die ich auch rechtlich und inhaltlich einstehe, gebe ich also eine schlechtere user-experience… Wenn ich (server-server Variante) also Inhalt so ausgebe, dass er als von mir selber gehostet erscheint, gebe ich eine schlechtere User-experience…

                                            Kannst du das bitte genauer erklären?

                                            1. problematische Seite

                                              Hallo beatovich,

                                              geh mal davon aus, dass einen Vertrag zwischen "Mutterseite" und remsö gibt, in dem genau geregelt ist, welche – z.B. nur die eigenen – Veranstaltungen auf der "Mutterseite" erscheinen.

                                              Ich würde auf meiner Seite keinen Iframe wollen, da ich die Termine aber bei Remsö melde, könnte ich sie auch gleich selbst in meine Seite integrieren. Offenbar übersteigt das jedoch die Fähigkeiten des Seitenbetreibers.

                                              Bis demnächst
                                              Matthias

                                              --
                                              Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                              1. problematische Seite

                                                hallo

                                                da ich die Termine aber bei Remsö melde, könnte ich sie auch gleich selbst in meine Seite integrieren. Offenbar übersteigt das jedoch die Fähigkeiten des Seitenbetreibers.

                                                Vielleicht wärst du eher mit mit einem remso-crawler einverstanden, der Fragmente deiner Veranstaltungsseite dann auf seiner eigenen Site spiegelt?

                                                Viele offzielle Domaininhaber sind im übrigen nicht erfahrene Webpublizisten.

                                                1. problematische Seite

                                                  Hallo beatovich,

                                                  Vielleicht wärst du eher mit mit einem remso-crawler einverstanden, der Fragmente deiner Veranstaltungsseite dann auf seiner eigenen Site spiegelt?

                                                  auch das wäre denkbar.

                                                  Bis demnächst
                                                  Matthias

                                                  --
                                                  Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
                                                2. problematische Seite

                                                  Hallo beatovich,

                                                  da ich die Termine aber bei Remsö melde, könnte ich sie auch gleich selbst in meine Seite integrieren. Offenbar übersteigt das jedoch die Fähigkeiten des Seitenbetreibers.

                                                  Vielleicht wärst du eher mit mit einem remso-crawler einverstanden, der Fragmente deiner Veranstaltungsseite dann auf seiner eigenen Site spiegelt?

                                                  Du brauchst keinen Crawler, es gibt eine API dafür.

                                                  Viele offzielle Domaininhaber sind im übrigen nicht erfahrene Webpublizisten.

                                                  Das stimmt und nicht jeder Erfahrene will alles selber machen.

                                                  Gruß
                                                  Julius

                                              2. problematische Seite

                                                Hallo Matthias,

                                                Ich würde auf meiner Seite keinen Iframe wollen, da ich die Termine aber bei Remsö melde, könnte ich sie auch gleich selbst in meine Seite integrieren.

                                                Vergiss nicht, dass remso die Termine zusätzlich zum Einbinden zentral sammelt und zugänglich macht und du dir damit einen Mehraufwand ersparst, weil du sie nicht zweimal eintragen musst. Außerdem bietet Linuchs eine API an, du bist also nicht gezwungen, das iFrame oder das JS-Skript zu benutzen.

                                                Wie man das macht, kann ja jeder für sich selbst entscheiden. Ich fände die API Datenschutz-freundlicher für die Besucher meiner Website als ein (externes) iFrame oder JavaScript.

                                                Offenbar übersteigt das jedoch die Fähigkeiten des Seitenbetreibers.

                                                Oder die technischen Möglichkeiten ihrer Website bzw. ihres Webspaces. Einige können in ihr CMS zwar HTML einbinden, aber keine PHP-Scripte einbinden. Ich finde es gar nicht mal so schlecht, eine einfache Lösung (Link, iFrame) anzubieten und eine etwas kompliziertere (API).

                                                Gruß
                                                Julius

                                                1. problematische Seite

                                                  hallo

                                                  Außerdem bietet Linuchs eine API an, du bist also nicht gezwungen, das iFrame oder das JS-Skript zu benutzen.

                                                  Also die API gibt hier offensichtlich Fehler zurück. Da sollte nachgebessert werden.

                                            2. problematische Seite

                                              Aloha ;)

                                              Nein. Du hast das originale Posting offensichtlich nicht ansatzweise gut genug gelesen! Ich zitiere daraus:

                                              Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?

                                              ist dir aufgefallen, dass dieses Datei nicht im geringsten relevant ist fr Abfragen, die innerhalb des iframes getätigt werden (das heisst, Abfragen funktionieren bei blockiertem Javascript).

                                              Klar.

                                              Die Einbindung von JavaScript in die Seite bestand also sowieso schon, das war nichts, was von uns ins Spiel gebracht wurde.

                                              Nein, sie besteht nur aus kosmetischen Gründen, um einen nicht essentiellen Fix durchzuführen.

                                              Richtig. Und um einen solchen nicht essentiellen Fix ging es auch im weiteren Verlauf.

                                              Genausowenig soll die iframe-Lösung abgelöst werden (als Fallback soll sie nach unserer Meinung vorhanden bleiben), sondern sie soll für die, die kein JS aktivieren wollen, vorhanden bleiben. Es macht also niemand bestehende Funktionalität kaputt.

                                              Der wunsch wurde schon mal geäussert: https://forum.selfhtml.org/self/2017/mar/5/im-iframe-blaettern/1689017#m1689017

                                              Nur weil sich das Feature ändert heißt das nicht, dass der Fallback wegfällt.

                                              Schon mal von PGP (Pretty Good Privacy) gehört? ... Nein. Das ist ein Beispiel für Vertrauen. PGP basiert auf der Idee des Web of Trust. Dabei geht es im wesentlichen darum, dass Vertrauen in Zertifikate bekannter (und selbst vertrauter) Kommunikationsteilnehmern an unbekannte Kommunikationsteilnehmer vererbt wird, und das ist ziemlich genau das, was hier auch passiert.

                                              Die Grundlage von PGP ist Misstrauen. Es existiert weil die Vertrauenswürdigkeit bezüglich Sender und Empfänger so essentiell ist.

                                              Nur, wenn du es unbedingt so drehen möchtest. Dann ist aber auch die Grundlage für https Misstrauen. Und für Verschlüsselung allgemein und und... es ging hier aber nicht darum, was die Grundlage für Verschlüsselung ist, sondern es ging darum, was die Grundlage der Arbeitsweise von PGP ist, und die ist nunmal Vertrauen.

                                              Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.

                                              …das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert.

                                              warum nicht?

                                              Aufgrund allerlei Gründen. Rechtliche Beschränkungen, Ressourcenfrage (Manpower / Kosten) usw. usf. Aktuelle Systeme sind heutzutage oft derart komplex, dass man nicht mehr umhinkommt, eben nicht mehr alles selbst zu machen.

                                              Das ist auch der Grund für…

                                              kann sich dann aber doch irgendwann im Garten vergraben, weil man so nicht in der Lage ist, mit Bedürfnissen und Möglichkeiten, sowohl von Kunden (allgemeiner: Benutzern) als auch von Konkurrenten, mitzuhalten.

                                              Kannst du bitte genauer ausführen, wo sich jemand, der selber Ressourcen hostet, Nachteile aufbürdet, oder Usern Nachteile bietet?

                                              …diese Aussage. Es geht nicht darum, dass man Nachteile hätte, wenn man Ressourcen selber hostet. Wenn man fixe Ressourcen hat, die man entweder einbinden oder selbst hosten kann, bin ich (bis auf eventuelle Argumente bzgl. Caching, die aber nicht entscheidungsrelevant sind) vollkommen bei dir, wenns darum geht, das selber zu hosten.

                                              Es geht darum, dass man komplexere Dienste oder aufwändige Ressourcen, die man entweder einbinden kann oder selber erstellen oder unterhalten muss, heutzutage aufgrund der Fülle an Dingen, die man für ein optimales Nutzererlebnis benötigt, eben nicht mehr alles selber erstellen oder unterhalten kann.

                                              Wenn ich also Usern nur Inhalte biete, für die ich auch rechtlich und inhaltlich einstehe, gebe ich also eine schlechtere user-experience… Wenn ich (server-server Variante) also Inhalt so ausgebe, dass er als von mir selber gehostet erscheint, gebe ich eine schlechtere User-experience…

                                              Kannst du das bitte genauer erklären?

                                              Potenziell ja. Du kannst eine Dienstleistung, wie remso sie dir bietet, nicht ohne großen Aufwand selbst machen und anbieten - nur als Beispiel. Also bist du für eine optimale User Experience darauf angewiesen, das einzubinden. Hier musst du dann den Weg nehmen, der sicherheitstechnisch akzeptabel ist und von remso auch angeboten wird.

                                              Wir argumentieren hier auf zwei Ebenen. Du hast Recht - optimalerweise gibt es eine API für den serverseitigen Zugriff auf die blanke Information. Wenns die aber nicht gibt (oder ich nicht das Know-How habe, sie zu benutzen und auch nicht die Bereitschaft, jemanden zur Einrichtung zu bezahlen), muss ich mich mit etwas anderem zufrieden geben.

                                              Und sofern ich remso vertraue wähle ich dann eben die js-Lösung mit iframe-Fallback, die dort angeboten wird.

                                              remso wiederum möchte einen Service bieten, der möglichst gut aussieht, und verwendet dafür dann eben für die js-Nutzer keinen iframe, weil sich der nicht schick in die Seite integriert.

                                              Nochmal: Du darfst das gerne anders sehen und anders halten, aber ich erwarte diese Toleranz auch gegenüber den genannten Standpunkten von remso, seinem „Kunden“, und uns, die remso bei einer technischen Fragestellung beraten.

                                              Es wäre übrigens sehr sinnvoll gewesen, wenn du einfach deine Kritik inhaltlich vollständig auf den Punkt gebracht und irgendwo angebracht hättest - denn ganz offensichtlich hast du ja doch etwas sinnvolles beizutragen. Darüber war ich mir lange nicht im Klaren beim Lesen deiner Beiträge. Es bringt nichts, wenn du immer wieder nur kryptische Zweizeiler raushaust, in denen niemand was versteht außer blinden Rant! Es ist auch nicht wirklich sinnvoll, sich das aus der Nase ziehen zu lassen 😉 aber ich finde deine wortreicheren Beiträge jetzt gut und würde die in Zukunft lieber gleich lesen als nach mehrmaligem Nachfragen.

                                              Auf dass wir uns hier konstruktiv auseinandersetzen können 😉

                                              Grüße,

                                              RIDER

                                              --
                                              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                              1. problematische Seite

                                                hallo

                                                …das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert.

                                                warum nicht?

                                                Aufgrund allerlei Gründen. Rechtliche Beschränkungen, Ressourcenfrage (Manpower / Kosten) usw. usf. Aktuelle Systeme sind heutzutage oft derart komplex, dass man nicht mehr umhinkommt, eben nicht mehr alles selbst zu machen.

                                                Eine Ressource selber zu erstellen ist rechtlich weit unbedenklicher als eine Ressource zu verwenden. Eine Ressource selber zu hosten ist unbedenklicher als zu beten, dass die Site deren Content man einbindet, auch nächstes Jahr noch existiert. Ich gebe dir durchaus Recht, dass man nicht alles selber erfinden muss oder gar soll. Aber im Sinne des Risikomanagements soll man auch Abhängigkeiten möglichst reduzieren.

                                                Es geht darum, dass man komplexere Dienste oder aufwändige Ressourcen, die man entweder einbinden kann oder selber erstellen oder unterhalten muss, heutzutage aufhgrund der Fülle an Dingen, die man für ein optimales Nutzererlebnis benötigt, eben nicht mehr alles selber erstellen oder unterhalten kann.

                                                Sehr gute Aussage:

                                                Remso verspricht jetzt also quasi mehr zu können, als du gerade für Nutzer empfiehlst. Remso ist aber auch nur Menschen, auch nur Nutzer.

                                                Ich möchte deine Aussage ideal umzusetzen anhand von Remso.

                                                Remso operiert als Crawler der auf Wunsch website-Fragmente indexiert und in einem Remso eigenen Veranstaltungskalender präsentiert.

                                                Dazu dokumentiert Remso eine eine HTML-Syntax für Webadmins, die erfolgreiches Parsen der Veranstaltungen ermöglicht.

                                                Das wäre die ideale Umsetzung. Falls jetzt Remso eingeht, leidet kein Webadmin mehr darunter. Und die Macher von Remso können auch gut schlafen.

                                                1. problematische Seite

                                                  Aloha ;)

                                                  Aufgrund allerlei Gründen. Rechtliche Beschränkungen, Ressourcenfrage (Manpower / Kosten) usw. usf. Aktuelle Systeme sind heutzutage oft derart komplex, dass man nicht mehr umhinkommt, eben nicht mehr alles selbst zu machen.

                                                  Eine Ressource selber zu erstellen ist rechtlich weit unbedenklicher als eine Ressource zu verwenden. Eine Ressource selber zu hosten ist unbedenklicher als zu beten, dass die Site deren Content man einbindet, auch nächstes Jahr noch existiert.

                                                  I rest my case…

                                                  Grüße,

                                                  RIDER

                                                  --
                                                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                                                  # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                                2. problematische Seite

                                  Hallo,

                                  Sei mal ganz ehrlich. Würdest du

                                  • ein Javascript von einer Site einbinden, die mit deinem Inhalt machen kann, was immer gerade die Site tun kann?

                                  wenn ich den Dienst, den die Site bietet, als sinnvoll ansehe und ich ihn gerne auf meiner Seite haben möchte: ja. Und nicht „würde“, ich mache es und ich leiste anderen Hilfestellung dabei.

                                  • würdest du dazu auch noch extra Rechte geben?

                                  warum?

                                  • und das für eine Site die selber Inhalte von unbekannten Quellen akzeptiert?

                                  tut die Seite von Linuchs das?

                                  Gruß
                                  Jürgen

                                  1. problematische Seite

                                    hallo

                                    würdest du dazu auch noch extra Rechte geben? warum?

                                    Also ungeschützer Verkehr ist dein Standard...

                                    • und das für eine Site die selber Inhalte von unbekannten Quellen akzeptiert? tut die Seite von Linuchs das?

                                    Also Ignoranz ist dein Standard...

                                    Ohne bösen Verdacht: Remso erlaubt was ungeschütztes http ermöglicht. Und der Glaube, dass da ein Admin 24/7 für die Integrität seiner Daten steht, ist naiv.

                                    1. problematische Seite

                                      Hallo,

                                      Also ungeschützer Verkehr ist dein Standard...

                                      Also Ignoranz ist dein Standard...

                                      irgendwie wird mir dein Gefasel jetzt doch zu dumm. Keine Ahnung vom Thema aber rumlästern. Plonk

                                      Gruß
                                      Jürgen

                  2. problematische Seite

                    Hallo Julius,

                    1. Link (kein JS)

                    Gute Idee.

                    1. iFrame (kein CORS)

                    Tät ich mir nicht an, aber wenns schon da ist …. Übrigens, "Kein CORS" betrifft Weltweit etwa 5%, in D etwa 2,5% der User.

                    1. per Ajax eingebetteter Inhalt (Ziel)

                    Gruß
                    Jürgen

                    1. problematische Seite

                      Hallo Jürgen,

                      1. iFrame (kein CORS)

                      Tät ich mir nicht an, aber wenns schon da ist …. Übrigens, "Kein CORS" betrifft Weltweit etwa 5%, in D etwa 2,5% der User.

                      Die Umsetzung scheint sich ja vom Aufwand her noch in Grenzen zu halten. Damit hilft man aber nur 1% der Nutzer, wenn ich richtig gerechnet habe.

                      Gruß
                      Julius

          2. problematische Seite

            Hallo Camping_RIDER,

            Braucht man einen Fallback, falls CORS oder JS nicht funktioniert? Einen Link? Oder ein iFrame in einem noscript-Element?

            Guter Einwand. Auch die Idee mit dem iframe ist gut; immerhin ist das mit dem Scrollen und der Höhenbestimmung unterm Strich nur Luxus; der iframe bietet ja die Funktionalität für den Fallback-Fall komplett.

            Allerdings würde ich in dem Fall nicht (allein) auf <noscript> setzen. Es mag Browser geben, die JS erlauben und CORS nicht unterstützen.

            Deshalb ja der Link :-) Den hätte man ja in ein Blockelement packen können und dann per JS entscheiden, ob man den Seiteninhalt reinschreibt oder den Link drinlässt.

            • Fallback-iframe in noscript-Element
            • Feature Detection zu CORS (z.B. via Try...Catch am XMLHttpRequest)
            • im Fehlerfall (bei Catch): iframe aus noscript lösen und via innerHTML statt dem, was der XMLHttpRequest im Erfolgsfall geliefert hätte, an der gewünschten Stelle einfügen.

            So fängt man sowohl nicht-funktionierendes JS als auch nicht funktionierendes CORS ab ohne redundantes Fallback-Markup.

            Klingt praktikabel und elegant. Allerdings scheint das Verhalten des noscript-Elements im Falle, dass JS zur Verfügung steht, nicht genau definiert zu sein. Dieser Code gibt nur in Firefox das gewünschte Resultat „Hallo Welt!“ aus. Die Chromioiden (Chromium, Opera, Vivaldi) geben nur „Hallo <b>Welt</b>!“ aus.

            Nachtrag:
            IE11 und Edge verhalten sich genauso wie die Chromioiden. Entweder einen Link (dort könnte das JS ja auch die Info auslesen, welche Seite bzw. Information eingefügt werden soll) als Fallback oder das HTML fürs iFrame müsste man im JS speichern bzw. generieren – oder ist das eine schlechte Idee?

            Gruß
            Julius

            1. problematische Seite

              Aloha ;)

              Klingt praktikabel. Allerdings scheint das Verhalten des noscript-Elements im Falle, dass JS zur Verfügung steht, nicht genau definiert zu sein. Dieser Code gibt nur in Firefox das gewünschte Resultat „Hallo Welt!“ aus. Die Chromioiden (Chromium, Opera, Vivaldi) geben nur „Hallo <b>Welt</b>!“ aus.

              Stimmt. Demnach vielleicht dann doch eher ein block-Element, das durch JavaScript sofort unsichtbar (display:none) geschaltet wird statt dem noscript.

              Übrigens: Das liegt nicht daran, dass das Verhalten nicht genau definiert ist. Die Spec ist hier sehr präzise. Leider ist das Element ziemlich verdorben, historisch bedingt. Das führt dazu, dass das Verhalten der Chromioiden, wie du so schön sagtest, das Richtige ist, denn falls JS aktiviert ist, gilt:

              „The noscript element must contain only text“

              Was erklärt, warum die Chromioiden hier Spec-konform die Zeichen < und > zu &lt; bzw. &gt; umwandeln.

              Andere Möglichkeit, vielleicht sauberer als das möglicherweise blinkende Blockelement-Experiment:

              Den iframe falls Javascript funktioniert einfach schnell mit Javascript erzeugen. So viel Code ist das nun auch wieder nicht, und immerhin tritt dann trotzdem keine Redundanz im HTML auf.

              @edit: ich hab das mal so zusammengefasst.

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          3. problematische Seite

            Aloha ;)

            Für Linuchs die Zusammenfassung eines geeigneten Fallbacks aus unserer Diskussion:

            • Fallback-iframe in noscript-Element
            • Feature Detection zu CORS (z.B. via Try...Catch am XMLHttpRequest)
            • im Fehlerfall (bei Catch): via JavaScript einen iframe erzeugen und statt dem, was der XMLHttpRequest im Erfolgsfall geliefert hätte, an der gewünschten Stelle einfügen.

            So fängt man sowohl nicht-funktionierendes JS als auch nicht funktionierendes CORS ab ohne redundantes Fallback-Markup im HTML zu haben.

            Grüße,

            RIDER

            --
            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
            # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
            1. problematische Seite

              Hallo Janosch,

              • Feature Detection zu CORS (z.B. via Try...Catch am XMLHttpRequest)

              mit Try...Catch kommst du nicht weit, da fast alle Browser XMLHttpRequest unterstützen. Hier reicht ìf(XMLHttpRequest). Und wenn CORS fehlschlägt, erfährt man das über den Error-Handler.

              Gruß
              Jürgen

              1. problematische Seite

                Aloha ;)

                • Feature Detection zu CORS (z.B. via Try...Catch am XMLHttpRequest)

                mit Try...Catch kommst du nicht weit, da fast alle Browser XMLHttpRequest unterstützen. Hier reicht ìf(XMLHttpRequest). Und wenn CORS fehlschlägt, erfährt man das über den Error-Handler.

                So wars gemeint.[1]

                Grüße,

                RIDER

                --
                Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

                1. Ich war mir nur mangels Erfahrung mit try...catch in Javascript nicht sicher, wo der Fehler abfangbar ist und bin davon ausgegangen, dass ein typischer SOP-Fehler am XMLHttpRequest irgendwo direkt geworfen wird... bei nährerer Betrachtung ergibt das nichtmal mehr für mich Sinn; immerhin wird XMLHttpRequest ja asynchron ausgeführt, also kann ein Fehler, der durch die Antwort ausgelöst wird, gar nicht beim Aufruf von send(...) o.ä. geworfen werden. Aber so is es halt, wenn man nur weiß, dass es irgendwie so funktionieren muss, aber nicht genau weiß, wie 😉 ↩︎

                1. problematische Seite

                  Hallo RIDER,

                  Aber so is es halt, wenn man nur weiß, dass es irgendwie so funktionieren muss, aber nicht genau weiß, wie 😉

                  So könnte man auch die Aussagen einiger Politiker zu Problemen und deren möglichen Lösungen deuten 😄

                  Gruß
                  Julius

                  1. problematische Seite

                    Aloha ;)

                    Aber so is es halt, wenn man nur weiß, dass es irgendwie so funktionieren muss, aber nicht genau weiß, wie 😉

                    So könnte man auch die Aussagen einiger Politiker zu Problemen und deren möglichen Lösungen deuten 😄

                    tru dat xD

                    Ich sollte Politiker werden; da wird man für sowas wenigstens bezahlt 😝

                    Grüße,

                    RIDER

                    --
                    Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                    # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                    1. problematische Seite

                      Hallo RIDER,

                      Aber so is es halt, wenn man nur weiß, dass es irgendwie so funktionieren muss, aber nicht genau weiß, wie 😉

                      So könnte man auch die Aussagen einiger Politiker zu Problemen und deren möglichen Lösungen deuten 😄

                      tru dat xD

                      Ich sollte Politiker werden; da wird man für sowas wenigstens bezahlt 😝

                      Dann hast du aber definitiv keine Zeit mehr fürs Internet (und SELFHTML), wäre doch auch schade...

                      Gruß
                      Julius

                      1. problematische Seite

                        Aloha ;)

                        Ich sollte Politiker werden; da wird man für sowas wenigstens bezahlt 😝

                        Dann hast du aber definitiv keine Zeit mehr fürs Internet (und SELFHTML), wäre doch auch schade...

                        Ach was, ich lass stattdessen einfach das studieren sein xD

                        Wobei... ohne studieren hab ich auch keine Prüfungen mehr und damit keinen so effektiven Anlass heftigster Prokrastination, demnach... haste wohl Recht 😉

                        Grüße,

                        RIDER

                        --
                        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
                        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
    2. problematische Seite

      Hallo Jürgen,

      schon mal dran gedacht, den Kalender über http-Request und CORS einzulesen und dann per innerHTML ins Dokument zu schreiben?

      Das Konzept ist aus einer Zeit, als Javascript nicht eingeschaltet sein musste. Ganz besonders hier bei SelfHTML galt es als stümperhaft, Seiten auszuliefern, die man ohne Javascript nicht sehen konnte.

      Wenn Javascript ausfällt, hat man eben einen Scrollbalken, aber der Inhalt wird angezeigt.

      Linuchs

      1. problematische Seite

        Aloha ;)

        schon mal dran gedacht, den Kalender über http-Request und CORS einzulesen und dann per innerHTML ins Dokument zu schreiben?

        Das Konzept ist aus einer Zeit, als Javascript nicht eingeschaltet sein musste. Ganz besonders hier bei SelfHTML galt es als stümperhaft, Seiten auszuliefern, die man ohne Javascript nicht sehen konnte.

        Richtig. In dieser Zeit bin ich auch mit der Thematik groß geworden 😉

        Die Zeiten haben sich geändert; heutzutage kann man Javascript in den meisten Browsern nicht mal mehr ausschalten, ohne sich extra dafür Plugins zu installieren oder an den Innereien rumzupfuschen. Aber der „Geist von damals“ ist, wenn auch weniger relevant, heute immer noch nicht zu verachten, denn...

        Wenn Javascript ausfällt, hat man eben einen Scrollbalken, aber der Inhalt wird angezeigt.

        ...das ist unter dem neuen Stichwort progressive enhancement bzw. graceful degradation immer noch wichtig. Dem wird allerdings durch ein Fallback, wie von Julius und mir vorgeschlagen (Zusammenfassung hier), auch schon ausreichend gedient, unter zusätzlicher Verwendung von CORS und JavaScript, falls das Eine oder Andere jeweils unterstützt wird.

        Grüße,

        RIDER

        --
        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  6. problematische Seite

    Hallo Linuchs,

    mal etwas Anderes. Mir sind auf deiner Seite Fehler aufgefallen:

    1. Auf dieser Seite scheint bei Hörproben das ersetzen deiner Platzhalter nicht funktioniert zu haben.
    2. Auf dieser Seite gibt es eine Fehlermeldung Fatal error: Call to undefined function send_mail() in /home/osmer/domains/remso.de/public_html/include/_info.php on line 73
      Allgemein gehören die nicht ausgegeben, sondern ins Error-Log.
    3. Auf dieser Seite hagelt es im Seitenfuß Fehlermeldungen.

    Gruß
    Julius