In Markdown mode, type this:
A B
C D
Select B and C but not A and D, then “Blur spoiler.”
The result will look like this:
A [spoiler]
B
C
[/spoiler] D
And the result will not be spoiler-blurred.
A [spoiler]
BC
[/spoiler] D
Now try it again in rich-text mode. Start with this:
A B
C D
Select B and C and spoiler blur.
The paragraph break will be deleted, and the result looks like this:
A BC D
If you switch back to Markdown mode, the result looks like this:
A [spoiler]BC[/spoiler] D
Quale risultato ti aspetteresti in questo caso, considerando che lo spoiler non può essere sia inline che block?
Penso che l’idea che uno spoiler non possa essere sia inline che block sia un fatto del CSS di cui l’utente non dovrebbe essere a conoscenza.
Considera il grassetto. Oggi puoi scriverlo in bbcode di Discourse:
A [b]B
C[/b] D
Oppure puoi scriverlo in HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <strong>B</p>
<p>C</strong> D</p>
</body>
</html>
Viene visualizzato esattamente come ti aspetteresti:
A B
C D
Ma la rappresentazione del DOM appare così:
<p>A <strong>B</strong></p>
<p><strong>C</strong> D</p>
La specifica HTML richiede che accada qualcosa di simile per i collegamenti ipertestuali multi-block. Se scrivi questo in HTML:
<!DOCTYPE html>
<html>
<body>
<p>A <a href="https://example.com.">B</p>
<p>C</a> D</p>
</body>
</html>
La specifica HTML richiede che la rappresentazione del DOM appaia così, con tre collegamenti ipertestuali:
<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>
Potresti immaginare di visualizzare spoiler inline multi-paragrafo in modo simile:
<p>A <spoiler>B</spoiler></p>
<p><spoiler>C</spoiler> D</p>
Ma gli spoiler sono diversi dal grassetto, perché gli spoiler sono interattivi. Quando fai clic sulla parte B dello spoiler, dovrebbe rivelare sia la parte B che la parte C dello spoiler; dovrebbe apparire e sentirsi come “un unico spoiler”.
Penso che il modo per gestire questo sia supportare spoiler collegati nella rappresentazione del DOM. Forse <spoiler> avrebbe un attributo come name, e quando fai clic su uno spoiler, rivelerebbe tutti gli spoiler con lo stesso nome. (Dovrebbe essere fatto con attributi, proprietà o qualche altro sistema per collegare i tre spoiler? Non lo so, fallo come preferisci.)
Quindi, supponiamo che tu abbia un Markdown come questo:
A B
C
D E
[spoiler]F[/spoiler]
E selezioni B, C e D e li sfocassi.
Il Markdown apparirebbe quindi così:
A [spoiler]B
C
D[/spoiler] E
[spoiler]F[/spoiler]
E il DOM generato apparirebbe così:
<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>
In JS, quando fai clic su uno qualsiasi dei tre spoiler, tutti gli spoiler con lo stesso attributo “name” si rivelerebbero insieme.
Pertanto, dal punto di vista dell’utente finale, sembrerebbe che si potessero mescolare e abbinare spoiler inline e block.
Ho spostato questo da Bug a Feature poiché ciò che stiamo esplorando qui è una funzionalità attualmente non supportata.
@dfabulich Potresti condividere il caso d’uso che stai cercando di supportare? Questo ci aiuterà a capire come affrontare al meglio una soluzione. Puoi dirci quanto sarebbe utile nella tua community supportare questa forma di spoiler inline + blocco, o quando si presentano?
Penso che sia sbagliato classificare questo come una “funzionalità”.
Potrei immaginare di dire “questo bug è troppo difficile da correggere; non ha senso dare priorità ad esso rispetto ad altro lavoro”.
Ma non credo che nessuno difenderebbe il comportamento attuale come corretto.
Per quanto riguarda la tua domanda, non è davvero possibile fornire un “caso d’uso” per la correzione di un bug. Le funzionalità hanno casi d’uso (Sfocatura Spoiler: gli utenti vogliono sfocare gli spoiler in modo da poter discutere i media senza rovinare la sorpresa), ma i bug risiedono all’interno delle funzionalità. Correggere i bug è il modo in cui una funzionalità soddisfa il suo caso d’uso.
Se tratto questo problema come un “bug”, e riconosco che l’implementazione della mia soluzione proposta potrebbe essere costosa, il modo più vicino per rispondere alla tua domanda sul “caso d’uso” è rispondere a una domanda diversa:
“Perché questo bug è importante? Dato che il comportamento attuale è errato, a chi importa che non si possa sfocare il testo inline su più paragrafi? Hai davvero bisogno di farlo?”
E a questo, penso che direi: l’esperienza attuale è semplicemente confusa e mina la fiducia dell’utente in Discourse. Quando selezioni del testo, fai clic su Sfocatura Spoiler e questo semplicemente non sfoca il testo che hai selezionato, è semplicemente imbarazzante per tutti i soggetti coinvolti.
Onestamente, sarebbe un miglioramento rispetto al comportamento attuale visualizzare un messaggio di errore quando un utente tenta di spoilerizzare parti di due paragrafi, educando l’utente sulla natura del problema. Il messaggio di errore potrebbe dire: “In Discourse, puoi spoilerizzare parte di un paragrafo, oppure puoi spoilerizzare uno o più paragrafi interi, ma non puoi creare uno spoiler contenente parti di due o più paragrafi”.
Ma ora immagina se dovessi mostrare un errore del genere per il testo in grassetto? O in corsivo?
E questo porta al motivo per cui gli spoiler sono importanti per me: il forum che gestisco (e altri forum Discourse in cui partecipo) sono forum di gamer, dove parlare di media, e soprattutto senza rovinare le soluzioni agli enigmi, è una cosa molto importante.
Posso capire perché qualcuno direbbe “La sfocatura dello spoiler non è importante quanto il testo in grassetto. Correggeremo il bug per il grassetto creando sezioni multiple in grassetto, ma per la sfocatura dello spoiler, abbiamo solo questioni più importanti da affrontare; lasciamo il bug dello spoiler irrisolto. Non ci interessano molto gli spoiler. Gli utenti troveranno una soluzione alternativa.”
Ma per me e il mio forum, e i forum in cui vivo, la sfocatura dello spoiler è marginalmente più importante del testo in grassetto. Ecco perché ho insistito su questi bug di sfocatura dello spoiler!
Qual è il “caso d’uso?” Il caso d’uso è: usiamo gli spoiler per parlare di media senza rovinare la sorpresa. E quindi, la funzionalità di sfocatura dello spoiler dovrebbe funzionare, e funzionare correttamente, per soddisfare tale esigenza.
Per quanto mi riguarda, penso che qui ci sia un bug e una funzionalità. Possiamo non essere d’accordo sulla semantica, ma voglio spiegare come stiamo affrontando la questione in modo che tu capisca cosa succederà in seguito, data l’importanza degli spoiler per te e la tua community.
Il bug è che quando si tenta di applicare uno spoiler inline e attraverso blocchi, le interruzioni di paragrafo vengono rimosse (in modalità rich text) e aggiunte (in modalità Markdown):
Rich text:
Markdown:
Concordo sul fatto che non sia un’esperienza piacevole. Possiamo correggere quel bug, ma l’aspetto sarà uno dei seguenti:
La richiesta di funzionalità è di supportare uno spoiler singolo che possa iniziare inline e estendersi su più blocchi, per poi essere rivelato con un singolo clic. Non è così che gli spoiler sono stati progettati per funzionare.
Il motivo per cui ti ho chiesto del tuo caso d’uso è per assistere sia nella correzione del bug sia nella comprensione dell’importanza della funzionalità. Di solito vediamo gli spoiler o inline o come blocchi, quindi mi chiedo se ci siano situazioni particolari in cui lo spoiler inline + blocco entra in gioco. Questo ci aiuta a capire come utilizzi Discourse e come la risoluzione di questo problema potrebbe aiutarti (e altri che riconoscono le esigenze della propria community in ciò che condividi qui).
Date le due opzioni, penso che sceglierei “Un singolo spoiler, ma il contenuto selezionato verrà forzato nel proprio blocco”.
Non posso davvero fornire una motivazione basata su un caso d’uso; penso che il comportamento del blocco forzato sarebbe comunque difettoso.
Ma l’opzione del blocco forzato mi sembra “meno difettosa” perché “influenza solo” l’aspetto dello spoiler: aggiungendo un’interruzione di riga aggiuntiva all’inizio e alla fine dello spoiler.
Avere più spoiler non collegati influisce sul funzionamento dello spoiler. I lettori dovrebbero fare clic fino a tre volte per rivelare l’intero spoiler: una volta per lo spoiler inline iniziale, poi di nuovo per N spoiler di blocco e poi di nuovo nello spoiler inline finale.
Con gli spoiler a blocco forzato, diventa un bug estetico difficile, il tipo di cosa su cui forse nessuno lavorerà mai.
Questa cornice ha senso per me:
Ci lavoreremo; non ho una tempistica da comunicarti ma ti aggiornerò qui una volta risolto il problema.