Spoilerizar partes de dos párrafos no funciona bien

En modo Markdown, escribe esto:

A B

C D

Selecciona B y C pero no A y D, luego “Difuminar spoiler”.
El resultado se verá así:

A [spoiler]
B

C
[/spoiler] D

Y el resultado no estará difuminado como spoiler.

A [spoiler]
B

C
[/spoiler] D

Ahora inténtalo de nuevo en modo texto enriquecido. Empieza con esto:

A B

C D

Selecciona B y C y difumina como spoiler.
El salto de párrafo se eliminará y el resultado se verá así:

A BC D

Si vuelves al modo Markdown, el resultado se verá así:

A [spoiler]BC[/spoiler] D
1 me gusta

¿Qué resultado esperarías en este caso, considerando que el spoiler no puede ser a la vez en línea y de bloque?

Creo que la idea de que un spoiler no puede ser a la vez en línea y de bloque es un hecho de CSS del que el usuario no debería tener conocimiento.

Antecedentes: ¿Cómo maneja HTML esto?

Considera la negrita. Hoy puedes escribir esto en bbcode de Discourse:

A [b]B

C[/b] D

O puedes escribir esto en HTML:

<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>

<p>C</strong> D</p>
</body>
</html>

Se renderiza exactamente como esperarías:

A B

C D

Pero la representación del DOM se ve así:

<p>A <strong>B</strong></p>
<p><strong> </strong></p>
<p><strong>C</strong> D</p>

La especificación HTML exige que algo similar ocurra con los hipervínculos de varios bloques. Si escribes esto en HTML:

<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>

<p>C</a> D</p>
</body>
</html>

La especificación HTML exige que la representación del DOM se vea así, con tres hipervínculos:

<body>
<p>A <a href="https://example.com.">B</a>
</p><a href="https://example.com."> </a>
<p><a href="https://example.com.">C</a> D</p>
</body>

Mi propuesta: Spoilers enlazados

Podrías imaginar renderizar spoilers de varios párrafos en línea de manera similar:

<p>A <spoiler>B</spoiler></p>

<p><spoiler>C</spoiler> D</p>

Pero los spoilers son diferentes de la negrita, porque los spoilers son interactivos. Cuando haces clic en la parte B del spoiler, se supone que debe revelar tanto la parte B como la parte C del spoiler; se supone que debe verse y sentirse como “un solo spoiler”.

Creo que la forma de manejar esto es admitir spoilers enlazados en la representación del DOM. Quizás <spoiler> tendría un atributo como name, y cuando haces clic en un spoiler, revelaría todos los spoilers con el mismo nombre. (¿Debería hacerse esto con atributos, propiedades o algún otro sistema para enlazar los tres spoilers? No lo sé, hazlo como quieras).

Así que, supón que tienes Markdown como este:

A B

C

D E

[spoiler]F[/spoiler]

Y seleccionas B, C y D y los difuminas.
El Markdown se vería así:

A [spoiler]B

C

D[/spoiler] E

[spoiler]F[/spoiler]

Y el DOM generado se vería así:

<p>A <inline-spoiler name="x">B</inline-spoiler></p>

<block-spoiler name="x"><p>C</p></block-spoiler>

<p><inline-spoiler name="x">D</inline-spoiler> E</p>

<block-spoiler name="y"><p>F</p></block-spoiler>

En JS, cuando haces clic en cualquiera de los tres spoilers, todos los spoilers con el mismo atributo “name” se revelarían juntos.

Por lo tanto, desde la perspectiva del usuario final, parecería que podrías mezclar y combinar spoilers en línea y de bloque.

He movido esto de Bug a Feature, ya que la funcionalidad que estamos explorando actualmente no está soportada.

@dfabulich ¿Podrías compartir el caso de uso que buscas soportar? Eso nos ayudará a entender la mejor manera de abordar una solución. ¿Puedes contarnos cómo el soporte para esta forma de spoilers en línea + de bloque sería útil en tu comunidad, o cuándo surgen?

Creo que es un error clasificar esto como una “característica”.

Podría decir: “este error es demasiado difícil de corregir; no tiene sentido priorizarlo sobre otros trabajos”.

Pero no creo que nadie defienda el comportamiento actual como correcto.

En cuanto a tu pregunta, no es realmente posible dar un “caso de uso” para la corrección de un error. Las características tienen casos de uso (Spoiler de desenfoque: los usuarios quieren desenfocar spoilers para poder discutir medios sin arruinar la sorpresa), pero los errores residen dentro de las características. Corregir los errores es cómo una característica cumple su caso de uso.

¿Por qué importa este error? ¡Porque usamos muchos spoilers!

Si trato este problema como un “error” y reconozco que implementar mi solución propuesta podría ser costoso, lo más cercano que puedo hacer para responder a tu pregunta de “caso de uso” es responder a una pregunta diferente:

“¿Por qué importa este error? Suponiendo que el comportamiento actual es incorrecto, ¿a quién le importa que no puedas desenfocar texto en línea en varios párrafos? ¿Realmente necesitas hacer eso?”

Y a eso, creo que diría: la experiencia actual es simplemente confusa y socava la confianza del usuario en Discourse. Cuando seleccionas texto, haces clic en Desenfoque de spoiler y simplemente no desenfoca el texto que seleccionaste, es simplemente embarazoso para todos los involucrados.

Honestamente, sería una mejora leve sobre el comportamiento actual mostrar un mensaje de error cuando un usuario intenta aplicar spoiler a partes de dos párrafos, educando al usuario sobre la naturaleza del problema. El mensaje de error podría decir: “En Discourse, puedes aplicar spoiler a parte de un párrafo, o puedes aplicar spoiler a uno o más párrafos completos, pero no puedes crear un spoiler que contenga partes de dos o más párrafos”.

Pero ahora imagina si tuvieras que mostrar un error así para texto en negrita. ¿O en cursiva?

Y eso lleva a por qué los spoilers son importantes para : el foro que opero (y otros foros de Discourse en los que participo) son foros de jugadores, donde hablar de medios, y especialmente sin arruinar las soluciones a los acertijos, es algo muy importante.

Puedo entender por qué alguien diría: “El desenfoque de spoilers no es tan importante como el texto en negrita. Arreglaremos el error para el texto en negrita creando múltiples secciones en negrita, pero para el desenfoque de spoilers, tenemos cosas más importantes que hacer; dejemos el error de spoilers sin arreglar. Simplemente no nos importan tanto los spoilers. Los usuarios encontrarán una solución alternativa”.

Pero para mí y mi foro, y los foros en los que vivo, el desenfoque de spoilers es marginalmente más importante que el texto en negrita. ¡Por eso he estado insistiendo en estos errores de desenfoque de spoilers!

¿Cuál es el “caso de uso”? El caso de uso es: usamos spoilers para hablar de medios sin arruinar la sorpresa. Y por lo tanto, la característica de desenfoque de spoilers debería funcionar, y funcionar correctamente, para satisfacer esa necesidad.

1 me gusta

Por mi parte, creo que aquí hay un error y una característica. Podemos discrepar sobre la semántica, pero quiero explicar cómo estamos viendo esto para que entiendas lo que viene a continuación, dada la importancia de los spoilers para ti y tu comunidad.

El error es que cuando intentas aplicar un spoiler en línea y entre bloques, las interrupciones de párrafo se eliminan (en modo de texto enriquecido) y se agregan (en modo Markdown):

Texto enriquecido:

Markdown:

Estoy de acuerdo en que esta no es una experiencia agradable. Podemos corregir ese error, pero lo que parecerá es:

  • Dos spoilers separados, uno en cada línea, que deben hacerse clic por separado para revelarse
  • Un solo spoiler, pero el contenido seleccionado se verá obligado a tener su propio bloque

La solicitud de característica es admitir un solo spoiler que pueda comenzar en línea y abarcar varios bloques, y luego revelarse con un solo clic. Así es como se diseñó que funcionaran los spoilers.

La razón por la que pregunté sobre tu caso de uso es para ayudar a corregir el error y comprender la importancia de la característica. Normalmente vemos los spoilers en línea o como bloques, así que me pregunto si hay situaciones particulares en las que el spoiler en línea + bloque entra en juego. Eso nos ayuda a conocer cómo usas Discourse y a comprender cómo resolver esto podría ayudarte (y a otros que reconozcan las necesidades de su propia comunidad en lo que compartes aquí).

1 me gusta

Dadas esas dos opciones, creo que elegiría “Un solo spoiler, pero el contenido seleccionado se forzará en su propio bloque”.

Realmente no puedo dar una razón basada en un caso de uso para esto; creo que el comportamiento de bloque forzado seguiría teniendo errores.

Pero la opción de bloque forzado se siente “menos errónea” para mí porque “solo” afecta a cómo se ve el spoiler: agregando un salto de línea adicional al principio y al final del spoiler.

Tener múltiples spoilers no enlazados afecta a cómo funciona el spoiler. Los lectores tendrían que hacer clic hasta tres veces para revelar todo el spoiler: una vez para el spoiler en línea inicial, luego otra vez para los spoilers de bloque N, y luego otra vez en el spoiler en línea final.

Con los spoilers de bloque forzado, se convierte en un error grave cosmético, el tipo de cosa en la que tal vez nadie trabajará nunca.

2 Me gusta

Este planteamiento tiene sentido para mí:

Trabajaremos en solucionarlo; no tengo una fecha estimada para darte, pero te actualizaré aquí una vez que lo hayamos resuelto.

1 me gusta