編集可能なHTMLがiFrameに移動されるのはなぜですか?さまざまなエディター(TinyMce、CKEditorなど)を分析し、編集可能なコンテンツをすべて、元のテキストの上に配置された別のiFrameに移動しました。
これの技術的な理由は何ですか。このすべてのエディターのベースでもあるを試してみましたがcontenteditable="true"
、これを行う理由はまだ見つかりませんでした。
私はCKEditorのコア開発者です。長い間ではありません-今年の後半だけですが、なぜiframededitableを使用するのかについて多くのことを学びました:)
スタイリング-iframedエディターのコンテンツはページのスタイルを継承しません。スタイルをリセットできないため、これは非常に重要です(sic!CSSは本当にひどいです)。さらに、iframeでは独自のスタイルを自由に追加できるので便利です。
iframed編集可能でのみ、ヘッド、メタ、ボディスタイル、タイトルなどを使用してページ全体を操作できます。一部のユーザーはこれを必要としています。
ブラウザには、コンテンツ編集可能な非常にバグのある(そして不完全な)実装があります。たとえば、Firefoxの要素である編集可能要素にリストを貼り付けるとどうなるかを推測します<h1>
(このエディターで確認できます-http://createjs.org/demo/hallo/)?編集可能領域から漏れ出し、編集不可の要素になります。これらのケースはエディターで手動で処理する必要があり、これは本当に大変な作業です:)。
これについてはよくわかりませんがdesignMode
、ドキュメント全体を編集可能領域に切り替えることができるのは最初で、contenteditable
後で来たと思います。したがって、その理由も歴史的なものである可能性があります。あるアプローチから別のアプローチに切り替えるのは困難です。
おそらく、iframedの編集可能ファイルを使用する理由は他にもあります。私はそれらを学ぶときに私の答えを更新します:)
こんにちはザッピーノ!
TinyMCEのようなエディターがIFrameを使用するのは、フレーム内でメインページのドキュメントを壊すことなく、ニーズに合わせてHTMLドキュメントの任意の部分を変更できるためです。特に、その間の部分を含む完全なHTMLドキュメントを編集したい場合、IFrameなしでは編集できません。
TinyMCEのファイルを、エディターを埋め込んだページとは異なる(サブ)ドメインに保存すると、クロスドメインスクリプティングが発生します。あなたが問題を抱えていて、誰かがあなたを助けることができるかもしれないあなたのインストールのテストシナリオを私たちに見せてください!
ドイツからのご挨拶(ドイツに戻る)
フェリックス・リーステラー。