¿Veremos alguna vez compatibilidad con texto en color?
Gracias, esto se ve increíble. He notado un problema. En mi teléfono, el interruptor no funciona (cuando lo toco, no pasa nada, se mantiene en Markdown).
iPhone 6s
iOS 15.8.3
Este es el error que aparece en la consola cuando lo toco.
15 y 18.3. algo funciona.
Se ha fusionado una corrección y se implementó aquí en Meta – por favor, avísanos si todavía no te funciona.
Gracias Renato, pero desafortunadamente no parece funcionar para mí ![]()
Estamos planeando mejoras en la barra de herramientas y el contenedor del compositor, específicamente enfocadas en hacer la escritura más agradable y familiar en el móvil (además de las mejoras en el escritorio).
Por favor, mantengamos los comentarios centrados en los propios cambios del editor, que no solucionarán todos los problemas relacionados con la escritura en Discourse, pero es el área para la que estamos buscando activamente comentarios en este momento.
No estoy muy seguro… tal vez me gusta más con la vista previa porque en este momento puedo ver dónde, qué y cómo cambiarlo. Pero… no está mal de todos modos ![]()
Una cosa que irrita mucho en el nuevo editor WYSIWYG es que Intro ahora crea un nuevo párrafo.
Lo apoyo.
Si quieres mantenerlo tan pequeño, como mínimo, alinearía la publicación dentro del editor con las publicaciones existentes:
Sí… ya tuvimos una batalla similar sobre Enter/Shift+Enter en la función de Chats:
… Apoyo la opinión de que Enter debería hacer un solo salto de línea en el nuevo editor wysiwyg.
LAS tres comunidades que administro, incluida una utilizada por desarrolladores de software para todos los flujos de trabajo de gestión y desarrollo de proyectos, han estado expresando sus comentarios/opiniones a lo largo de los años de uso de que lo único extraño en Discourse que las hace entrar en pánico (y hace que a algunas les disguste activamente todo Discourse solo por esta única cosa) es el editor de markdown.
Personalmente, estoy muy contento de que al final prevaleciera la comprensión de la necesidad de un editor WYSIWYG.
Tan pronto como salga, estableceré el editor WYSIWYG como el modo de editor predeterminado en las tres comunidades.
Por cierto, aquí está mi solicitud de dos configuraciones más:
-
Permitir que el editor WYSIWYG sea el modo de editor predeterminado
-
Permitir desactivar el editor de markdown por completo (si no, aún lo desactivaré deshabilitando el conmutador a través de CSS, pero por favor considere hacer de esto una configuración adecuada).
P.D. Puede ser una idea extraña, pero animo a quienes apuestan mucho por el WYSIWYG a comparar las métricas de cuántas personas publican y responden en sus comunidades, antes y después de implementar el nuevo editor WYSIWYG. Mi instinto me dice que la métrica verá un aumento.
es muy extraño que no pueda editar un hipervínculo (si edito uno, aparece en blanco)
probé con Firefox y Chrome
aparte de eso, si mantienes un selector de modo fuente / markdown, es perfecto
No tengo tiempo para probar esta nueva funcionalidad. Pero el soporte para licencias Creative Commons podría ser apropiado. De tal manera que un sitio pueda optar por obtener el consentimiento explícito para CC-BY-4.0 o similar antes de cada guardado. Y especialmente para cada carga de imagen. Discourse podría incluso probar metadatos adecuados. No estoy seguro si esto encaja con tu diseño, pero podría ser útil para mí. ¡Por favor, ignora si no es relevante aquí!
Lo que describes no está relacionado en absoluto con este nuevo compositor. Y es poco probable que se implemente en el núcleo de Discourse. Podrías hacer algo en un plugin si es realmente importante para ti, o buscar a alguien que lo haga por ti en Marketplace.
La licencia Creative Commons pertenece a los términos de uso y la aplicación es manejada por los moderadores. Si tienes infractores reincidentes, puedes advertirles y luego silenciarles.
Si quieres seguir hablando de ello, por favor, inicia un nuevo tema o busca un tema relacionado existente usando la búsqueda.
Estoy de acuerdo con esto. El nuevo editor es genial y será mucho más fácil de usar para los miembros de nuestra comunidad. Definitivamente queremos que los nuevos usuarios lo vean como el editor predeterminado y no queremos confundirlos con el conmutador. La pérdida de algunas capacidades de usuario avanzado a través del editor de markdown para un subconjunto muy pequeño de miembros de la comunidad es un pequeño precio a pagar. Idealmente, creo que el editor predeterminado debería establecerse a nivel del sitio, pero con la capacidad de los miembros individuales para elegir el editor ‘antiguo’ a través de su configuración (no con un conmutador en la ventana del compositor).
Estoy de acuerdo en que la alineación parece extraña. No estoy 100% seguro de por qué el compositor necesita aparecer. El ‘antiguo’ lo necesitaba porque era un entorno bastante pesado con los dos paneles. Ahora que es mucho más elegante, creo que podría aparecer en línea debajo de las publicaciones. Creo que esa es una convención más ampliamente entendida. La flecha de redimensionar podría sacarlo a un tamaño mayor para aquellos que están componiendo una publicación más épica.
Por favor, no eliminen la opción de usar solo Markdown. Una configuración predeterminada y un interruptor de Markdown serían ideales y mantendrían contentos a todos los usuarios.
Creo que solo WYSIWYG sería un desastre para algunos usuarios, incluyéndome a mí. Probablemente no habría elegido Discourse si solo tuviera un editor WYSIWYG, y preferiría encarecidamente que no hubiera WYSIWYG en el sitio para ningún usuario a que me obligaran a usar WYSIWYG.
El editor actual es una de las mejores características de Discourse. Varias veces en el pasado, incluso he verificado si es un paquete de código abierto independiente, porque lo habría usado yo mismo en proyectos (y todavía lo haría).
Para las personas que han pasado décadas en texto sin formato y son muy rápidas con el teclado, hay muchas molestias con WYSIWYG. Pequeñas fricciones mientras se edita pueden ser especialmente frustrantes.
No quiero decir nada negativo sobre el editor WYSIWYG, porque está muy bien construido y a la mayoría de los usuarios les gustará, pero no quiero que me obliguen a usarlo, y sé que también recibiré quejas de algunos usuarios al respecto.
Slack intentó eliminar su editor de Markdown en los primeros días y hubo tal gran protesta que rápidamente agregaron una configuración de usuario para restaurarlo.
Aquí hay otro tema con argumentos en contra de WYSIWYG con una pista de cuál será la reacción de algunos usuarios si se les impone:
Este tema solo tiene comentarios de unas 30 personas, pero una vez que la función esté activa, esperaría una gama más amplia de reacciones. Imagina cómo reaccionaría la gente si las incidencias de GitHub se volvieran repentinamente WYSIWYG. Esa es la base de usuarios de muchos foros de Discourse, y probablemente serán muy ruidosos.
Hay personas con diferentes tipos de flujos de trabajo. Si escribes contenido Markdown fuera de Discourse y lo pegas en WYSIWYG, y luego necesitas editar el Markdown externamente de nuevo, no puedes copiar Markdown para volver a insertarlo en el editor externo.
Con el editor Markdown, es fácil copiar/pegar de un lado a otro entre Discourse y cosas como otros sitios, editores de código, documentación y archivos README.md.
Cuando inspecciono lo que la gente publica en el foro, quiero poder ver cada carácter con un solo clic, sin tener que ir a la base de datos.
Por ejemplo, esta publicación contiene un enlace de spam (simulado) que no se puede ver a menos que inspecciones la entrada sin formato. Si los moderadores no pueden ver el texto sin formato fácilmente, los spammers aprenderán rápidamente a explotarlo. Regularmente hago clic en el icono “editar” en las publicaciones de usuarios nuevos sospechosos para verificar si hay enlaces ocultos como ese antes de bloquear la edición de las publicaciones.
Hay otras situaciones en las que se pegan cosas ocultas en los editores WYSIWYG, como al copiar/pegar de correos electrónicos que tienen píxeles de seguimiento. ![]()
(Cuanto más lo pienso, más preferiría simplemente desactivar WYSIWYG en todo el sitio para evitar la carga adicional de moderación, pero entiendo si eso no es posible. Esta publicación también contiene un píxel de seguimiento remoto simulado de 1x1, solo para demostrar. Edición: el foro acaba de descargar una copia del píxel remoto, por lo que eso probablemente no sería un problema en los sitios que tienen esa configuración activada).
Preferiría tener un interruptor, incluso si se coloca debajo del icono del engranaje (además de una configuración por usuario), pero una configuración por usuario sola sería tolerable, siempre que no se elimine.
Muchos editores WYSIWYG (como tinymce) tienen un interruptor de HTML, porque cuando las cosas van mal con WYSIWYG y el cursor se queda atascado dentro de una etiqueta de formato, es más fácil entrar en el texto sin formato para arreglarlo que tener que cortar la sección problemática en el portapapeles, pegarla en un editor de texto sin formato, copiarla de nuevo en el WYSIWYG y luego reformatearla.
No tenemos planes de eliminar el modo exclusivo de Markdown.
Inicialmente, esto se controlará mediante una configuración del sitio, donde los administradores podrán activar el interruptor para alternar entre el editor de texto enriquecido / editor exclusivo de Markdown, o dejarlo desactivado para mantener su editor exclusivo de Markdown. En este momento, no tenemos detalles sobre cómo se admitirán ambas versiones del editor a largo plazo (por ejemplo, si el tipo de editor seguirá controlándose mediante la configuración del sitio, se dejará a preferencia del usuario o algo más).
Suena genial. Gracias por dejar una configuración.
¡También me alegra que Markdown haya llegado para quedarse! Poder formatear mi texto de una manera amigable con el teclado es algo que hace que sea notablemente más agradable para mí escribir publicaciones en Discourse (especialmente al compararlo con software más antiguo con BBCode).
A dos pequeñas cosas que encontré después de la última prueba:
-
Al intentar crear segmentos de código a través de acentos graves, ingresar los acentos graves primero y luego escribir algo en el medio no activa el formato automático (hacer acento grave espacio código acento grave espacio funciona).
-
Los segmentos de código creados a través de acentos graves tienen el mismo problema que las tablas informadas anteriormente (incapacidad para ingresar un espacio en blanco sin formato).
9 publicaciones se dividieron en un nuevo tema: Fuente monoespaciada en el editor solo con Markdown

