javascript - example - js content editable
Contenteditable div vs. iframe en la creación de un editor de texto enriquecido/wysiwyg (2)
Razones para el iframe
Pros
- Aislamiento CSS
- Aislamiento de seguridad (no puedo detallar este punto, repito lo que leo)
contras
- Más pesado (pero no realmente significativo)
- Más difícil de acceder desde JavaScript.
Personalmente desarrollé mi propio editor y elijo ponerlo en un iframe .
Estoy tratando de sopesar los pros y los contras de usar un <div> frente a <iframe> para hacer mi propio editor de texto enriquecido / wysiwyg.
Al hacerlo, ¿por qué no puedo usar un <div> contenteditable y por qué tantas personas prefieren el <iframe> ?
Discusión de fondo: una forma común de hacer un editor de wysiwyg tal como lo entiendo es hacer que un div o iframe se execCommand en contenido y luego hacer execCommand en el documento que contiene el div o el cuerpo de iframe para que el texto execCommand en negrita o lo que sea.
Aquí está el HTML:
<html><!--parent doc-->
<body><button type="button" class="btn-bold">Bold</button>
<div contenteditable="true"></div>
</body>
</html>
vs .:
<html><!--parent doc-->
<body><button type="button" class="btn-bold">Bold</button>
<iframe>
<body contenteditable="true"></body>
</iframe>
</body>
</html>
y el JS:
$(document.body).on(''click'', ''.btn-bold'', function(){
document.execCommand(''bold'', false, null);
});
vs .:
$(document.body).on(''click'', ''.btn-bold'', function(){
window.frames[0].document.body.execCommand(''bold'', false, null);
});
Parece que la mayoría de los editores de texto enriquecido bien hechos usan un iframe. Si bien puedo conseguir fácilmente que este combo contenteditable / execCommand funcione en un div / iframe en los navegadores Webkit, estoy teniendo un tiempo infernal intentando que el iframe funcione en Firefox. Tengo que recurrir a cargar scripts y hojas de estilo en el iframe y todo tipo de tonterías para duplicar lo que puedo lograr fácilmente con la versión basada en div. Así que el método basado en <div> parece preferible. ¿Alguna razón fuerte que reconsidere?
En primer lugar ... No intentes crear tu propio editor WYSIWYG si estás pensando en un uso comercial. Es una buena idea para un proyecto personal, porque puedes aprender mucho , pero te llevará años crear un editor que podrás venderle a alguien que se preocupa por si realmente funciona, no solo por su apariencia. Recientemente he visto algunos editores realmente geniales, pero realmente no funcionan. De Verdad. Y eso no es porque sus desarrolladores apesten, es porque los navegadores apestan.
OK, esa fue una gran introducción, ahora algunos hechos:
- Soy uno de los desarrolladores de CKEditor.
- Se desarrolla desde hace unos 10 años.
- Todavía tenemos alrededor de 1 mil problemas activos en nuestro Trac.
- No aspiramos en el desarrollo web: p.
Ahora, la respuesta - además de lo que Tim Down escribió aquí al construir un editor de wysiwyg , puede leer lo que escribí bajo esta pregunta edtor HTML WYSIWYG: ¿por qué se mueve el contenido editable en un iFrame?
Básicamente, en un iframe usted está más seguro, tiene todo el documento, el contenido no se filtrará de su elemento editable, puede usar estilos, etc. También hay algunos inconvenientes de la aproximación del iframe: es más pesado, código bootstrap es ... realmente complicado, no puede heredar los estilos del sitio web al que está adjuntado el editor, supongo que la gestión del enfoque puede ser más difícil en este caso y debe prestar atención al documento en el que está creando nuevos elementos ( relevante solo en IE <8).
Y recuerde: no escriba su propio editor a menos que esté preparado para problemas como este. Pegar como texto simple Contenteditable div & textarea (word / excel ...) : D