Mistrzowskie listy Markdown: Standardy wcięć CommonMark i GitHub Flavored Markdown (GFM)
Podstawy techniczne renderowania list Markdown
Markdown ugruntował swoją pozycję jako standardowy język znaczników dla nowoczesnej dokumentacji oprogramowania, dokumentów specyfikacji technicznych, prywatnych baz wiedzy i komunikacji programistów. Podczas gdy jednopoziomowe listy punktowane (- element) i listy numerowane (1. element) wydają się proste, tworzenie głęboko zagnieżdżonych, wielopoziomowych planów dokumentów wprowadza znaczną złożoność formatowania. Różne parsery Markdown — takie jak CommonMark, GitHub Flavored Markdown (GFM), Python-Markdown i Pandoc — egzekwują surowe, subtelne zasady dotyczące wyboru znaczników list, stosunku tabulatorów do spacji i wcięć podbloków.
Gdy listy są wklejane między różnymi edytorami tekstu (takimi jak VS Code, Sublime Text, Xcode, Apple Notes lub Microsoft Word), pojawiają się ciche błędy wcięć. Pojedyncza brakująca spacja w pod-elemencie powoduje, że kompilator Markdown interpretuje zagnieżdżony węzeł potomny jako główny element najwyższego poziomu lub wyizolowany blok akapitu. Formater zagnieżdżonych list i wcięć Utiliome eliminuje te anomalie parsowania, analizując drzewo AST (Abstract Syntax Tree) wprowadzonego tekstu i ponownie generując standaryzowany, zgodny ze specyfikacją Markdown.
Zasady wcięć: Wytyczne dotyczące 2 i 4 spacji
Jedną z najczęstszych debat w projektowaniu dokumentacji technicznej jest to, czy stosować wcięcia podlist za pomocą 2 spacji, czy 4 spacji na poziom hierarchii. Wybór zależy od specyfikacji docelowego parsera Markdown:
Zasada wcięcia 2 spacji (Standard GFM i Prettier): W nowoczesnych ekosystemach dokumentacji internetowej, takich jak GitHub, Docusaurus, Nextra i Obsidian, 2 spacje na poziom wcięcia to uznany standard. Konwencja 2 spacji wyrównuje zawartość potomną pod początkiem tekstu elementu nadrzędnego:
- Top-level item 1 - Nested child item 1.1 - Nested child item 1.2 - Deeply nested grandchild item 1.2.1 - Top-level item 2Zasada wcięcia 4 spacji (Rygorystyczny CommonMark i Python-Markdown): Rygorystyczne implementacje CommonMark wymagają, aby bloki potomne, fragmenty kodu i zagnieżdżone listy wewnątrz list uporządkowanych miały wcięcie o 4 spacje (lub 1 pełny tabulator), aby zagwarantować prawidłowe zawieranie się w bloku nadrzędnym:
1. First ordered step in workflow - Associated sub-bullet A - Associated sub-bullet B 2. Second ordered step in workflowPułapki tabulatorów i spacji: Mieszanie fizycznych znaków tabulacji (
\t) ze znakami spacji ASCII (\x20) jest główną przyczyną błędnego renderowania dokumentacji Markdown. Silniki renderowania sieciowego tłumaczą tabulatory niespójnie (często jako 4 lub 8 kolumn wyświetlania), powodując wizualne przesunięcie zagnieżdżonych elementów. Utiliome automatycznie konwertuje wszystkie znaki tabulacji na jednolite ciągi spacji zgodnie z Twoimi preferencjami konfiguracyjnymi.
Ujednolicanie znaczników punktatorów i naprawianie sekwencji numerowanych
Markdown obsługuje trzy różne znaki punktatorów dla list nieuporządkowanych: łączniki (-), gwiazdki (*) i plusy (+). Chociaż wszystkie trzy generują prawidłowe elementy HTML list nieuporządkowanych (<ul>), mieszanie typów znaczników w tym samym dokumencie tworzy bałagan wizualny i powoduje błędy w automatycznych linterach (takich jak reguła MD004 w markdownlint).
Ponadto numeracja list uporządkowanych często ulega uszkodzeniu podczas edycji. Autorzy często wklejają elementy w środek sekwencji numerowanych lub polegają na automatycznie zwiększanej składni 1.:
<!-- Unformatted / Broken Input -->
* Feature A
- Feature B
+ Feature C
1. Initial step
1. Second step (copied from draft)
4. Out-of-order step
Formater Utiliome ujednolica wszystkie znaczniki list nieuporządkowanych do wybranego znaku (np. zmieniając każdy element na -) i przenumerowuje sekwencje uporządkowane kolejno (1., 2., 3.) lub standaryzuje je do jednocyfrowych przyrostów (1., 1., 1.) w zależności od wytycznych stylu zespołu.