Ho utenti che modificano la sintassi delle citazioni in modo scorretto, causando il fallimento della funzione di citazione. Ad esempio, ecco un caso tratto da un argomento corrente. Questo non è escapato:
[quote=“CFO.Digest.Input, post:1, topic:3258”]
ha suggerito di rimettere l’olio minerale. [/quote]
Il problema è che il tag di chiusura [/quote] si trova nella stessa riga del contenuto, mentre il tag di apertura [quote] è su una riga separata. Ho scoperto che è possibile utilizzare entrambi gli stili, ma devono essere coerenti. Ad esempio, questo funziona (’ aggiunto per escapare la funzione):
'[quote=“CFO.Digest.Input, post:1, topic:3258”]
ha suggerito di rimettere l’olio minerale.
'[/quote]
e questo funziona:
'[quote=“CFO.Digest.Input, post:1, topic:3258”]ha suggerito di rimettere l’olio minerale.[/quote]
… ma non è possibile mescolare i due stili.
So che qualcuno dirà “allora non farlo” o “Usa il pulsante di citazione”, ma abbiamo ancora utenti che non lo fanno correttamente.
Non esiste un modo per analizzare questo caso in modo che i due stili possano essere mescolati?
Oh mio Dio… quindi in pratica stiamo imponendo standard di codifica ai nostri clienti e utenti?
Sebbene io concordi con l’analisi di Sam sul formato, c’è una differenza tra rendere difficile la lettura per lo scrittore e rendere difficile la lettura per tutti coloro che visualizzano il post. Sembra quasi che stiamo punendo i lettori per i peccati dello scrittore…
Immagino che continuerò a pianificare la modifica dei post quando qualcuno li rovina.
Modifica: Un’altra opzione sarebbe forzare un’interruzione di riga dopo [/quote] se non è presente… correggere automaticamente il formato per migliorare la leggibilità.
Non mi sembra una cattiva idea, ma se semplicemente selezionano il testo e usano il pulsante citazione funziona. Stanno tornando indietro, modificando la citazione e rompendo la formattazione?
Sì, lo sono! Veramente notevoli… e senza nemmeno accorgersi di stare violando il formato nel frattempo. Immagino che l’anteprima non sia ancora attiva? O forse lo stanno facendo da mobile…
E la persona che ha fatto questa cosa è uno dei principi dell’azienda… sono contento di non averlo reso un editore!
Aha! Mobile è una buona opzione. È difficile selezionare esattamente il giusto, e poi rischieresti di essere goffo e non avresti alcuna anteprima quando provi a “correggerlo”.
Ho modificato il post inserendo un ritorno a capo dopo il tag di chiusura della citazione, ma trovo comunque sorprendente che il flusso di testo non venga analizzato come l’HTML, dove i ritorni a capo e i carriage return non influenzano il funzionamento dei tag. Sembra un bug…
L’ordine non è casuale, va benissimo. Ma a differenza dell’HTML, in questo sistema conta dove vanno a capo le righe.
Per riparare quel post rotto è bastato aggiungere un ritorno a capo / CR dopo il tag di chiusura.
Sono disposto a continuare a modificare manualmente i post quando gli utenti non rispettano la struttura richiesta, ma mi sembra ancora strano che i ritorni a capo abbiano importanza per il parser…
Dai un’occhiata alla specifica Markdown. A differenza dell’HTML, Markdown dipende interamente da interruzioni di riga posizionate correttamente.
Un’interruzione di riga errata in un elemento <h1> non avrebbe alcun impatto sul rendering, ma:
qui nel mondo
Markdown fa la differenza
Questo vale per molti elementi: le tabelle Markdown si rompono terribilmente a causa di interruzioni di riga aggiuntive. Le tabelle HTML, d’altro canto, no.
Non sono sicuro che l’analogia con l’HTML sia efficace o utile: agli utenti non viene chiesto di scrivere HTML. Potete immaginare il dolore di dimenticare <p></p> e <br>? Pareti di testo letterali.
Se si pensa a “Markdown prima”, che è l’approccio di Discourse, piuttosto che a “HTML prima”, che Discourse assolutamente non è, allora le sfide poste dall’inserimento di tag senza rispettare la struttura iniziano a avere senso.
Per me va bene orientarmi in queste acque, come qualsiasi programmatore, ma i nostri utenti sono civili e penserebbero che il markdown abbia a che fare con i prezzi al Walmart.
Come dici tu, per fortuna non stiamo chiedendo loro di scrivere HTML! Cosa si guadagna costringendoli a implementare la formattazione markdown? Sembra che un po’ di astuzia nel codice potrebbe proteggerli da queste realtà del nostro mondo.
Non so quanto sarebbe complicato forzare automaticamente un’a capo dopo un [/quote] (purché non si trovi all’interno di un blocco di codice o qualcosa di simile…) e capisco che ci sia una struttura da rispettare quando si utilizza il markdown.
Ma capisco anche quanto possa essere frustrante quando appare una citazione malformata in un messaggio utente a causa di un così piccolo “errore” come scrivere del testo sulla stessa riga di un [/quote] (non sono sicuro che si possa definire un errore).
Esiste qualche caso intenzionale in cui il testo verrebbe scritto sulla stessa riga di un [quote]?
Se non esiste, allora ritengo che non ci sia alcun motivo per cui il testo esista sulla stessa riga e un’a capo forzata dopo il tag di chiusura della citazione potrebbe essere vantaggiosa sia per gli utenti che per lo staff. Ma sono anche certo che non sia così semplice come sembra.
Esatto. La natura di base del Markdown è che un ritorno a capo (o due) equivale al tag di paragrafo. Per questo motivo, alcuni tag richiedono la presenza di ritorni a capo prima o dopo di essi per essere interpretati correttamente. Credo che faccia parte della specifica.
