@@Camping_RIDER

Gründe dafür, das nicht noch offener zu handhaben hat @Matthias Apsel schon genannt.

Und dass das allerhöchstens die zweitbeste Lösung ist, hatte ich schon gesagt.

Andererseits ist es so, dass gewisse fleißige Heinzelmännchen sowieso ein Auge auf die Änderungshistorie der Artikel haben und im Zweifel (oder spätestens dann, wenn man ihnen eine Notiz hinterlässt) die Änderungen im Beispiel-Code auch ins statische Beispiel übertragen. Gerade bei gelegentlichen Änderungen durch Einmal-Bearbeiter ist das ein gut funktionierender Mechanismus.

Von „gut funktionierend“ ist der Mechanismus weit entfernt (zumal es kein „Mechanismus“ ist), denn das wird einem so nicht vermittelt. Das heißt, ich hätte meine Änderung einfach machen und darauf vertrauen sollen, dass ein Berechtigter die Änderung zeitnah(!!) ins Beispiel übernimmt‽ Woher soll man’s wissen?

Vielleicht sollte man das mit dem selbstgefrickelten Frickler sein lassen und Beispiele von CodePen einbetten?

Das löst die Vandalismus-Problematik auch nicht, genauso wenig wie ein Sichtungs-Mechanismus.

?? Was hat das speziell mit den Beispielcodes zu tun? Die Problematik besteht auch allgemein für die Texte im Wiki.

Bei CodePen-Einbettungen muss die manuelle Überprüfung genauso stattfinden. Gleichzeitig setzen wir dabei auf einen externen Dienst, dem sowohl unsere Nutzer (externer Seitenzugriff) als auch wir (keine Kontrolle über Verfügbarkeit) als auch unsere Autoren (Rechteabtretung nicht nur an uns, sondern auch an Codepen) vertrauen müssen

Ja, man begibt sich in eine Abhängigkeit. Was, wenn CodePen morgen ankündigt, übermorgen dicht zu machen?

Vorteil wäre: fremder Code läuft in einer Sandbox, CodePen hat sich darum schon gekümmert.

und ich glaube zu spüren, dass es dabei vor allem darum ging, einen Nebenkriegsschauplatz zu eröffnen - nix für ungut

Bullshit.

LLAP 🖖