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](https://stackoverflow.com/questions/620896/access-contents-of-noscript-with-javascript). [Dieser Code](https://codepen.io/anon/pen/VpjOOO) 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

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. Allerdings scheint das Verhalten des noscript-Elements im Falle, dass JS zur Verfügung steht, [nicht genau definiert zu sein](https://stackoverflow.com/questions/620896/access-contents-of-noscript-with-javascript). [Dieser Code](https://codepen.io/anon/pen/VpjOOO) gibt nur in Firefox das gewünschte Resultat „Hallo **Welt**!“ aus. Die Chromioiden (Chromium, Opera, Vivaldi) geben nur „Hallo <b>Welt</b>!“ aus. Gruß Julius