Editores de texto editables de contenido

He probado varios editores HTML, incluidos TinyMCE, CKEditor y ahora NicEdit. NicEdit es bueno en un aspecto: es muy fácil de personalizar. Sin embargo, he descubierto que todos tienen una tendencia a producir HTML muy pobre. No necesariamente, sino porque no hacen mucho para interpretar correctamente las acciones de usuario no válidas, como intentar diseñar algo sin haber hecho una selección.

Es demasiado fácil terminar con HTML que contiene algo así como

Red 

¿Estoy en lo cierto al pensar que esto es más o menos una limitación del concepto de contenido editable? El HTML pobre no importa mucho si el propósito es el correo electrónico o las publicaciones en foros como este, pero se vuelve bastante incómodo de vivir si el HTML generado se tiene que usar en el contexto de una página web. Si todo esto es correcto, ¿cuáles son las alternativas? ¿Tal vez un editor de complementos basado en Flash que produce mejores HTML y trabaja más duro para interpretar lo que el usuario quiere hacer?

Supongo que, en principio, sería posible estudiar la producción generada y limpiar todo entre tramos concertados si fuera necesario, pero que es probable que sea una empresa.

Al principio debo mencionar que soy un desarrollador central de CKEditor, por lo que mi opinión puede no ser totalmente objetiva :).

El estado de la edición de HTML AFAIK no ha cambiado en los últimos años. Los proveedores de navegadores han invertido poco tiempo corrigiendo errores, tan poco que la mayoría de los errores más antiguos en CKEditor trac causados ​​por problemas con el navegador siguen siendo válidos y la mayoría de los hacks que hemos creado aún son necesarios. Y no solo me refiero a IE 7 u 8, que aún apoyamos, porque de hecho, los IE pueden no ser los peores. No lo he comprobado con precisión, pero creo que gracias a las mejoras generales para las DOM API en las versiones recientes de IEs, es posible que requieran menos ataques que otros navegadores, ya que su soporte de edición parece ser el más estable y completo. Por ejemplo, el truco más feo que se necesita para los navegadores Webkit (consulte: error de Webkit y el ticket de CKEditor cerrado ) y este error tiene 5 años . Además, este no es un caso marginal o un escenario poco probable, este problema hace que sea imposible crear toda una gama de selecciones, por ejemplo, dentro de un elemento vacío en línea IIRC.

Por lo tanto, a diferencia de las tecnologías web en general, la edición de HTML se encuentra donde se dejó hace 10 años. Los mismos errores, las mismas características que faltan, el mismo … marcado. ¿Adivina qué se crea con el comando fontName ? – sí, no es broma. Al menos los navegadores son muy consistentes aquí … Pero la consistencia desaparece muy rápidamente.

¿Qué hay de la especificación? Hay un borrador , pero no ayuda en absoluto, simplemente estandariza el estado actual, que como sabemos no se ve muy bien. Y AFAICS, el draft está muerto.

Y hay una cosa más que me preocupa: la dirección en la que va la edición. Google usa contenteditable en Gmail (no, Google Docs no está basado en contenteditable ), por lo que no le importa la salida de HTML. Apple reutiliza el componente de edición de HTML en su aplicación de correo electrónico para iOS y quizás en Mail for MacOS (porque veo los mismos comportamientos específicos). Mozilla vuelve a utilizar Gecko en Thunderbird y yo no me sorprendería si Microsoft hace lo mismo en Outlook. A todos ellos no les importa la salida de HTML. Estos motores están hechos para comprender cada mierda en lugar de solucionarlo y el borrador de Edición de HTML se trata de eso.

Gracias a todo eso, podemos ver nuevos problemas como este . En el informe de fallas de Blink / Webkit resumí toda la gama de resultados incorrectos (de nuestros POV – desarrolladores que se preocupan por HTML) al presionar el retroceso. Está diseñado para verse bien (aunque no es así), pero las API de edición y HTML no son importantes.

No me importa esto Necesito un editor!

La solución a todo eso es arreglar todo después de los navegadores y / o reemplazar sus implementaciones nativas por las nuestras. Durante los últimos 1.5 años he estado trabajando casi exclusivamente en el filtrado y la normalización de entrada y salida. En CKEditor 4.0 reescribimos procesos completos de pegado e inserción de HTML y en CKEditor 4.1, recientemente lanzado, presentamos el filtro de contenido avanzado que adapta los datos de entrada a la configuración del editor. De modo que cuantas menos funciones estén habilitadas, menos se permitirá en HTML. Verifique esta muestra : intente pegar / escribir / crear un HTML malo.

Por supuesto, todavía hay espacio para mejoras. Por ejemplo, no podemos filtrar datos de inmediato durante la edición. Si el navegador (como Webkit) crea un lío, podemos solucionarlo en la salida, pero de hecho no hemos decidido hacerlo porque el filtrado es un proceso realmente complejo y podría arruinar el rendimiento. Limitamos las acciones de entrada y de usuario, así que un día implementaremos nuestros propios manejadores de backspace / delete para evitar que los navegadores dañen nuestro HTML. Esa es la única solución y es por eso que solo hay 2 o 3 buenos editores WYSIWYG.

De todos modos, casi nada ha cambiado en las implementaciones de edición de HTML de los navegadores, pero muchas cosas han cambiado en el mundo de los editores WYSIWYG. Te aconsejo que los revises nuevamente si te basas en tu experiencia de hace unos años.

Después de haber pasado una gran cantidad de tiempo tratando de encontrar formas de garantizar que obtengo HTML de producción de un editor WYSIWYG, pensé que debería compartir mis resultados aquí para el beneficio de cualquiera que se encuentre con este hilo.

Recomendación muy breve: deja de perder tu tiempo. Los editores editables de contenido nunca entregarán nada ni remotamente cercano al HTML de calidad de producción. Personas como Reinmar han hecho un gran trabajo para minimizar esto, pero es demasiado fácil para el usuario tirar el código del navegador subyacente que maneja el contenido editable en un tizzy.

Es mejor utilizar el marcado BBCode. La opción 100% a prueba de balas es hacer que el usuario edite el BBCode y mantenga un estricto control de lo que puede hacer en cualquier momento. He hecho esto en mi propio proyecto, pero el problema de hacer que los usuarios no expertos jueguen con el marcado de cualquier descripción es complicado. Poner su propia interfaz WYSIWYG para la edición de BBCode es un trabajo que no debe emprenderse a la ligera. Afortunadamente, la ayuda está a la mano en forma de SCEditor . Sam ha hecho un trabajo excelente aquí. Tenga en cuenta que lo que sale puede contener algunos bits “espesos” ya que el bit WYSIWYG aún depende del contenido editable. Sin embargo, es relativamente fácil de limpiar.

Para la edición de texto, podemos utilizar el atributo contenteditable de HTML5 a través de este podemos hacer que cualquier elemento editable https://plus.google.com/114254873085584811912/posts/LqpzvvzoMYc