No modo Markdown, digite:\n\n\nA B\n\nC D\n\n\nSelecione B e C, mas não A e D, em seguida, “Desfocar spoiler”.\n\nO resultado ficará assim:\n\n\nA [spoiler]\nB\n\nC\n[/spoiler] D\n\n\nE o resultado não será desfocado como spoiler.\n\n\u003e A \[spoiler\]\n\u003e B\n\u003e\n\u003e C\n\u003e \[/spoiler\] D\n\nAgora tente novamente no modo de rich text. Comece com isto:\n\n\nA B\n\nC D\n\n\nSelecione B e C e desfoque como spoiler.\n\nA quebra de parágrafo será excluída, e o resultado ficará assim:\n\n\u003e A BC D\n\nSe você voltar para o modo Markdown, o resultado ficará assim:\n\n\nA [spoiler]BC[/spoiler] D\n
1 curtida
Que resultado você esperaria neste caso, considerando que o spoiler não pode ser ao mesmo tempo inline e de bloco?
Acho que a ideia de que um spoiler não pode ser inline e de bloco ao mesmo tempo é um fato do CSS do qual o usuário não precisa ser informado.
Contexto: Como o HTML lida com isso?
Considere o negrito. Você pode escrever isso em bbcode do Discourse hoje:
A [b]B
C[/b] D
Ou você pode escrever isso em HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
Ele é renderizado exatamente como você esperaria:
A B
C D
Mas a representação do DOM se parece com isto:
<p>A <strong>B</strong></p>
<strong> </strong>
<p><strong>C</strong> D</p>
A especificação HTML exige que algo semelhante aconteça para hiperlinks de vários blocos. Se você escrever isso em HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
A especificação HTML exige que a representação do DOM se pareça com isto, com três hiperlinks:
<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>
Minha proposta: Spoilers vinculados
Você poderia imaginar renderizar spoilers inline de vários parágrafos de forma semelhante:
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
Mas os spoilers são diferentes do negrito, porque os spoilers são interativos. Quando você clica na parte B do spoiler, ele deve revelar as partes B e C do spoiler; ele deve parecer e se sentir como “um spoiler”.
Acho que a maneira de lidar com isso é suportar spoilers vinculados na representação do DOM. Talvez <spoiler> tivesse um atributo como name, e quando você clicasse em um spoiler, ele revelaria todos os spoilers com o mesmo nome. (Isso deve ser feito com atributos, propriedades ou algum outro sistema para vincular os três spoilers? Não sei, faça do jeito que quiser.)
Então, suponha que você tenha Markdown como este:
A B
C
D E
[spoiler]F[/spoiler]
E você seleciona B, C e D e os desfoca.
O Markdown ficaria assim:
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
E o DOM gerado ficaria assim:
<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>
Em JS, quando você clica em um dos três spoilers, todos os spoilers com o mesmo atributo “name” se revelariam juntos.
Assim, da perspectiva do usuário final, pareceria que você poderia misturar e combinar spoilers inline e de bloco.
Movi isto de Bug para Feature, pois o que estamos explorando aqui é uma funcionalidade atualmente não suportada.
@dfabulich Você poderia compartilhar o caso de uso que você está procurando suportar? Isso nos ajudará a entender como abordar melhor uma solução. Você pode nos contar sobre como o suporte a esta forma de spoilers inline + block seria útil em sua comunidade, ou quando eles surgem?
Acho que é um erro classificar isso como um “recurso”.
Eu poderia dizer: “este bug é muito difícil de corrigir; não faz sentido priorizá-lo em relação a outros trabalhos”.
Mas não acho que alguém defenderia o comportamento atual como correto.
Quanto à sua pergunta, não é realmente possível dar um “caso de uso” para a correção de um bug. Recursos têm casos de uso (Spoiler de Borrão: Os usuários querem borrar spoilers para poder discutir mídia sem estragar a surpresa), mas bugs residem dentro de recursos. Corrigir os bugs é como um recurso cumpre seu caso de uso.
Por que este bug importa? Porque usamos muitos spoilers!
Se eu tratar este problema como um “bug” e reconhecer que implementar minha solução proposta pode ser caro, o mais próximo que posso chegar de responder à sua pergunta sobre “caso de uso” é responder a uma pergunta diferente:
“Por que este bug importa? Concedendo que o comportamento atual está incorreto, a quem importa que você não possa borrar texto em linha em vários parágrafos? Você realmente precisa fazer isso?”
E a isso, acho que diria: a experiência atual é apenas confusa e mina a confiança do usuário no Discourse. Quando você seleciona um texto e clica em Borrar Spoiler e ele simplesmente não borra o texto que você selecionou, é simplesmente embaraçoso para todos os envolvidos.
Honestamente, seria uma melhoria modesta em relação ao comportamento atual exibir uma mensagem de erro quando um usuário tenta colocar em spoiler partes de dois parágrafos, educando o usuário sobre a natureza do problema. A mensagem de erro poderia dizer: “No Discourse, você pode colocar em spoiler parte de um parágrafo, ou pode colocar em spoiler um ou mais parágrafos inteiros, mas você não pode criar um spoiler que contenha partes de dois ou mais parágrafos.”
Mas agora imagine se você tivesse que mostrar um erro como esse para texto em negrito? Ou itálico?
E isso chega ao motivo pelo qual os spoilers importam para mim: o fórum que opero (e outros fóruns do Discourse nos quais participo) são fóruns de jogadores, onde falar sobre mídia, e especialmente sem estragar as soluções para quebra-cabeças, é um grande negócio.
Posso entender por que alguém diria: “O desfoque de spoiler não é tão importante quanto o texto em negrito. Corrigiremos o bug para negrito criando várias seções em negrito, mas para o desfoque de spoiler, temos peixes maiores para fritar; vamos deixar o bug do spoiler sem correção. Nós simplesmente não nos importamos tanto com spoilers. Os usuários encontrarão uma solução alternativa.”
Mas para mim e meu fórum, e os fóruns em que vivo, o desfoque de spoiler é marginalmente mais importante do que o texto em negrito. É por isso que tenho insistido nesses bugs de desfoque de spoiler!
Qual é o “caso de uso?” O caso de uso é: usamos spoilers para falar sobre mídia sem estragar a surpresa. E, portanto, o recurso de desfoque de spoiler deve funcionar, e funcionar corretamente, para satisfazer essa necessidade.
1 curtida
Do meu lado, acho que há um bug e um recurso aqui. Podemos discordar sobre semântica, mas quero explicar como estamos vendo isso para que você entenda o que vem a seguir, dada a importância dos spoilers para você e sua comunidade.
O bug é que, ao tentar aplicar um spoiler inline e entre blocos, as quebras de parágrafo são removidas (no modo de texto rico) e adicionadas (no modo Markdown):
Texto rico:
Markdown:
Concordo que esta não é uma experiência agradável. Podemos corrigir esse bug, mas o que isso implicará será:
- Dois spoilers separados, um em cada linha, que precisam ser clicados separadamente para revelar
- Um único spoiler, mas o conteúdo selecionado será forçado em seu próprio bloco
A solicitação de recurso é para suportar um único spoiler que possa começar inline e abranger vários blocos, e então ser revelado com um único clique. Não é assim que os spoilers foram projetados para funcionar.
O motivo pelo qual perguntei sobre seu caso de uso é para ajudar a corrigir o bug e entender a importância do recurso. Normalmente, vemos spoilers inline ou como blocos, então estou imaginando se há situações particulares em que o spoiler inline + bloco entra em jogo. Isso nos ajuda a entender como você usa o Discourse e como a solução para isso pode ajudá-lo (e a outros que reconhecem as necessidades de suas próprias comunidades no que você compartilha aqui).
1 curtida
Dadas essas duas opções, acho que escolheria “Um único spoiler, mas o conteúdo selecionado será forçado em seu próprio bloco.”
Não consigo realmente dar um motivo baseado em caso de uso para isso; acho que o comportamento de bloco forçado ainda seria problemático.
Mas a opção de bloco forçado parece “menos problemática” para mim porque “apenas” afeta como o spoiler se parece: adicionando uma quebra de linha extra no início e no final do spoiler.
Ter vários spoilers não vinculados afeta como o spoiler funciona. Os leitores teriam que clicar em até três vezes para revelar todo o spoiler: uma vez para o spoiler inline inicial, depois novamente para N spoilers de bloco e, em seguida, novamente no spoiler inline final.
Com spoilers de bloco forçado, isso se torna um Bug Difícil cosmético, o tipo de coisa que talvez ninguém nunca trabalhe.
2 curtidas
Essa estrutura faz sentido para mim:
Trabalharemos para corrigir isso; não tenho um prazo para você, mas atualizarei aqui assim que resolvermos isso.
1 curtida