Esempio: * 1932.
Questi funzionano sorprendentemente: * 1917-32.
- 1917-32.
Sto usando la versione più recente 3.3.0.beta3-dev senza plugin.
2 Mi Piace
-
- testing
-
- second-line test
Markup used
* 1932. test smth
* 1933. again now then
Sì, riesco a vedere il problema, ma questo non sembra essere un markup Markdown valido. Ho testato quanto sopra con un altro editor Markdown e vedo un problema simile:
Puoi evitarlo omettendo il punto dopo il numero. Ad esempio:
- 1932 - testing
- 1933 - second-line test
oppure escludendo il * all’inizio:
- testing
- second-line test
1932. testing
1933. second-line test
1 Mi Piace
Ma questo funziona solo per anni consecutivi
- first
- second
- third
2008. first
2014. second
2015. third
Forse usare HTML invece di Markdown funziona anche come alternativa:
- 1997. first
- 2000. second
- 2015. third
<ul>
<li> 1997. first</li>
<li> 2000. second</li>
<li> 2015. third</li>
</ul>
1 Mi Piace
Anche questa è una limitazione di Markdown. Ho testato Github e alcuni altri editor Markdown, tutti impostano di default elenchi sequenziali.
3 Mi Piace
Rimuovere questo margine con css lo normalizza.
li>ul, li>ol, .cooked li>ul, .cooked li>ol, .d-editor-preview li>ul, .d-editor-preview li>ol {
margin: 0; /* Rimuovere questo */
}
1 Mi Piace
12983298. uno
2. test
- uno
- test
Sì, l’ho già visto, facciamo cose elaborate in CSS che lo rompono visivamente per casi anomali.
Penso che il motivo fosse che poteva essere sfruttato, forse @awesomerobot se lo ricorda.
2 Mi Piace
hmmm, un altro test:
- 12983298\. uno
- 2\. test
- 12983298. uno
- 2. test
* 12983298\. uno
* 2\. test
- 12983298. uno
- 2. test
Evidentemente un numero seguito da un punto, anche se non è il primo token sulla riga, verrà visto come un elenco numerico.
1 Mi Piace
Questo accade perché in markdown, quando un . viene posizionato dopo un numero, si presume che sia un elenco ordinato.
Quindi, utilizzando una formattazione come * 1932. stai generando l’HTML:
<ul>
<li>
<ol start="1932">
<li><!-- item content --></li>
</ol>
</li>
<li>
<ol start="1933">
<li><!-- item content --></li>
</ol>
</li>
</ul>
Tecnicamente valido, ma strano e non intenzionale.
Questo accade perché quando introduci un -, non è più un numero sequenziale, quindi non è un elenco ordinato e il . viene ignorato.
Per evitare questo, idealmente dovresti usare:
* 1932 (elenco non ordinato se i numeri non sono sequenziali)
oppure
1932. (elenco ordinato se i numeri sono sequenziali)
Se il . è necessario e non si tratta di un elenco ordinato, puoi eseguire l’escape del . con un \ come questo:
* 1932\.
Questo è un problema separato e si verifica anche con il CSS predefinito del browser:
Il marcatore dell’elemento in un elenco HTML è un pseudo-elemento che viene posizionato prima che vengano considerati il padding/margin, quindi appare sempre al di fuori della “scatola” del contenuto. Anche quando si rimuove il margin/padding da un elenco, i marcatori tracimeranno.
Ad esempio, con il margin/padding rimossi dall’elenco e overflow: hidden sul contenitore padre, non vedi affatto i marcatori dell’elenco:
Quindi, poiché il padding applicato a sinistra dell’elenco è un valore statico e i marcatori dell’elenco sono posizionati in modo da rientrare nel padding, a un certo punto i numeri tracimeranno.
Il nostro CSS rende gli elenchi un po’ più compatti orizzontalmente rispetto al predefinito, e abbiamo sia margin sinistro che padding… ma il risultato è essenzialmente lo stesso:
C’è del CSS… list-style-position: inside che può sovrascrivere il posizionamento del marcatore, questo posiziona il marcatore all’interno della scatola del contenuto. Ma questo significa che non otterresti più un bell’allineamento dei numeri:
list-style-position: outside; (predefinito):
list-style-position: inside; (il marcatore dell’elenco occupa spazio nel contenuto)
Quindi, per supportare correttamente elenchi ordinati di qualsiasi lunghezza ed evitare di influire sull’allineamento del contenuto, dovremmo fare qualcosa come… usare JS per rilevare il numero di cifre nel marcatore (partire dal primo numero nell’elenco, quindi contare tutti gli elementi dell’elenco per determinare la lunghezza) e applicare un padding sufficiente per accogliere il numero più grande.
4 Mi Piace
Grazie per la segnalazione. Abbiamo fornito una soluzione alternativa che riteniamo possa essere d’aiuto. Al momento, non siamo in grado di risolvere ogni caso limite e chiuderemo questo report per ora.
2 Mi Piace