Aby wyświetlić kilka wierszy w jednej komórce tabeli Markdown, zapisz cały wiersz w jednym wierszu źródłowym i wstaw <br> między frazami. Działa to tam, gdzie obsługiwane są tabele i wbudowany HTML; zanim na tym polegasz, sprawdź Obsidian oraz renderer docelowy.

Ten przewodnik opisuje praktyczne zadanie na komputerze Mac: utworzenie małej tabeli w Obsidianie, sprawdzenie jej wyglądu i przygotowanie tego samego Markdowna dla GitHuba lub innego renderera. Przykłady zawierają fikcyjne opisy artykułów papierniczych. Poniższe testy zgodności to procedura opracowana na podstawie dokumentacji, a nie wyniki testów zainstalowanych aplikacji.

Które renderery Markdown obsługują wielowierszowe komórki tabel?

Tabele z kreskami pionowymi są rozszerzeniem, a nie częścią podstawowego CommonMark. GitHub Flavored Markdown (GFM) dodaje tabele, których komórki mogą zawierać treści wbudowane. Specyfikacja wyklucza z tych komórek elementy blokowe. W konsekwencji komórka wyświetlana w kilku wierszach różni się od komórki zawierającej osobne akapity, listę Markdown lub blok kodu w ogrodzeniu. Zobacz specyfikację tabel GFM.

Obsidian opisuje tabele z kreskami pionowymi i formatowanie wewnątrz komórek. Dokumentacja podstawowej składni wskazuje także <br> jako znacznik podziału wiersza. Razem stanowi to udokumentowaną podstawę zastosowanego tu rozwiązania, choć strona poświęcona tabelom nie zawiera osobnego przykładu wielowierszowej komórki. Zobacz Zaawansowaną składnię formatowania i Podstawową składnię formatowania.

Zanim zaczniesz edytować duży dokument, skorzystaj z tej tabeli decyzyjnej:

Miejsce docelowe Udokumentowane ograniczenie Praktyczny wybór
Podstawowy CommonMark bez rozszerzeń Tabele z kreskami pionowymi nie należą do podstawowej składni Użyj nagłówków i list
Renderer zgodny z GFM Tabele obsługują treści wbudowane, ale nie elementy blokowe wewnątrz komórek Wypróbuj podział wiersza w treści i sprawdź miejsce docelowe
Obsidian Udokumentowano tabele i znacznik podziału wiersza Edytuj źródło, a potem sprawdź widok Czytanie
Renderer o nieznanej obsłudze HTML Jego obsługa nie została ustalona Zanim wybierzesz format, wykonaj poniższe krótkie porównanie

Pierwsze trzy wiersze opierają się na specyfikacji CommonMark, specyfikacji GFM i połączonej wyżej dokumentacji Obsidiana. Ostatni wiersz zawiera zalecany krok weryfikacji: sama nazwa renderera nie pozwala ustalić, jak obsłuży on dokument.

Jak zapisać dwa wiersze w jednej komórce?

Skopiuj poniższy przykład do notatki, nie kopiując otaczającego go ogrodzenia kodu. Każdy wiersz tabeli zajmuje jeden fizyczny wiersz źródłowy; znacznik podziału znajduje się między dwiema frazami w drugiej komórce.

| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |
| Pencil | Graphite core<br>Hexagonal shape |

Oczekiwanym wynikiem jest tabela z dwiema kolumnami i dwoma wierszami danych. W pierwszej komórce ze szczegółami „Strony w kropki” pojawią się nad „Niebieską okładką”. W drugiej „Grafitowy rdzeń” pojawi się nad „Sześciokątnym kształtem”. To oczekiwany wynik renderowania, który należy zweryfikować, a nie wbudowana demonstracja działania w miejscu docelowym.

Mechanizm łączy wbudowany znacznik HTML podziału wiersza ze składnią tabeli. GitHub wymienia znacznik podziału wiersza HTML wśród obsługiwanych sposobów wstawiania podziałów, a Obsidian wprost dokumentuje <br>. Są to komórki Markdown wspomagane przez HTML, więc ich przenośność zależy od tego, czy miejsce docelowe akceptuje taki znacznik. Zobacz dokumentację podziałów wiersza GitHuba i dokumentację podstawowej składni Obsidiana.

Zachowaj prostą strukturę tabeli: wstaw pusty wiersz przed nią, użyj zgodnej liczby kolumn nagłówka i separatora oraz trzech łączników w każdej komórce separatora. Przewodnik GitHuba dotyczący tabel opisuje wymóg pustego wiersza i konwencję trzech łączników. Obsidian akceptuje co najmniej dwa łączniki, więc trzy to praktyczny wspólny wybór. Źródła: Porządkowanie informacji za pomocą tabel i Zaawansowana składnia formatowania.

Dlaczego Enter, dwie spacje ani ukośnik odwrotny nie rozwiązują problemu?

CommonMark obsługuje twarde podziały wiersza, gdy przed znakiem nowego wiersza w źródle znajdują się dwie spacje na końcu wiersza lub ukośnik odwrotny. Te reguły dotyczą treści wbudowanej w istniejącym bloku; nie definiują wielowierszowych komórek tabel z kreskami pionowymi. Zobacz twarde podziały wiersza w CommonMark.

Na przykład poniższy zapis celowo nie nadaje się do zachowania obu fraz w jednej komórce GFM:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages
Blue cover |

Zgodnie z regułami tabel GFM drugi wiersz źródłowy staje się kolejnym wierszem tabeli, a nie kontynuacją komórki ze szczegółami. Pusty wiersz zakończyłby tabelę. Zapisz cały wiersz w jednym kawałku i umieść podział w treści w miejscu, w którym ma zmienić się wyświetlany wiersz. Zobacz przykłady tabel GFM.

Rozróżniaj też automatyczne zawijanie tekstu od zamierzonego podziału. W tym zadaniu sukces oznacza, że druga fraza zaczyna się w nowym wierszu, nawet gdy okno jest na tyle szerokie, by zmieścić obie. Sam zrzut ekranu z wąskiego okna tego nie potwierdzi.

Jak sprawdzić tabelę w Obsidianie na Macu?

Użyj tymczasowej notatki zawierającej tylko przykładową tabelę. Dzięki temu łatwiej ustalisz, czy problem dotyczy samej tabeli, czy otaczającej ją treści.

  1. Przełącz notatkę na Source mode za pomocą kontrolki trybu edycji na pasku stanu. Ten tryb pokazuje Markdown dokładnie w zapisanej postaci.
  2. Wklej przykład i sprawdź, czy każdy wiersz danych nadal zajmuje jeden wiersz źródłowy.
  3. Naciśnij Cmd+E, aby przełączać się między edycją a Reading view.
  4. Sprawdź obie komórki ze szczegółami: każda powinna zawierać dwa wyświetlane wiersze, a żadna fraza nie powinna znaleźć się w nowym wierszu tabeli.
  5. Wróć do edycji i porównaj wynik także w Live Preview.

Obsidian dokumentuje Source mode, Live Preview oraz skrót klawiszowy dla Maca w artykule Widoki i tryb edycji. Live Preview ukrywa większość składni podczas edycji; Reading view pozwala osobno sprawdzić sformatowaną notatkę.

Aby porównać widoki obok siebie, przytrzymaj Cmd i kliknij przełącznik widoku, by otworzyć jednocześnie widok edycji i czytania. Jeśli ta kontrolka jest ukryta, Obsidian opisuje opcję Settings → Appearance → Show tab title bar oraz alternatywną kontrolkę na pasku stanu w Settings → Editor → Show editing mode in status bar. Zobacz Widoki i tryb edycji.

Podstawowy przewodnik składni Obsidiana opisuje skrót Shift+Enter do podziałów wiersza w akapitach oraz ustawienie Strict Line Breaks. Te ogólne wskazówki dotyczące akapitów nie określają przenośnego skrótu dla komórek tabel. Na potrzeby tego sprawdzenia obejrzyj zapisany wiersz w Source mode i użyj jawnego znacznika podziału, zamiast traktować to ustawienie jako sposób na rozwiązanie problemu zgodności tabel. Zobacz Podstawową składnię formatowania.

Jak szybko zdiagnozować różnice między rendererami?

Obok proponowanej wersji wielowierszowej użyj wersji kontrolnej w postaci zwykłego tekstu. Poniższy kompletny dokument testowy różni się wyłącznie znacznikiem podziału, co ułatwia oddzielenie obsługi tabel od obsługi wbudowanego HTML:

Control:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages; blue cover |

Multiline candidate:

| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |

Otwórz tę samą treść w każdym z docelowych miejsc. W przypadku pliku Markdown na GitHubie sprawdź wyrenderowany widok pliku; podgląd w Obsidianie potwierdza tylko wynik w Obsidianie. GitHub opisuje też różnice w zachowaniu zwykłych znaków nowego wiersza w akapitach między plikami Markdown a polami rozmów, co dodatkowo pokazuje, jak ważne jest sprawdzenie właściwego miejsca docelowego. Zobacz Podstawową składnię pisania i formatowania.

Na podstawie tych obserwacji zdecyduj, co sprawdzić dalej:

Obserwacja Następny krok
Oba przykłady wyświetlają się jako tekst rozdzielony kreskami pionowymi Potwierdź obsługę tabel i sprawdź, czy treść znajduje się poza ogrodzeniem kodu
Wersja kontrolna działa, ale propozycja wyświetla znacznik Sprawdź, czy znacznik nie znalazł się wewnątrz znaków grawisu lub nie został poprzedzony znakiem ucieczki
Wersja kontrolna działa, ale propozycja nie zachowuje podziału Sprawdź dokumentację wbudowanego HTML dla miejsca docelowego
Propozycja tworzy dodatkowy wiersz Sprawdź, czy w źródle nie ma rzeczywistego znaku nowego wiersza wewnątrz zamierzonego wiersza
Fraza znika lub trafia do innej kolumny Poszukaj w treści komórki niepoprzedzonej znakiem ucieczki kreski pionowej

To gałęzie diagnostyczne, a nie pewne wyjaśnienia dla każdego renderera. Najpierw popraw najmniejszą próbkę, a dopiero potem dodawaj resztę tabeli. Jeśli treść komórki zawiera dosłowną kreskę pionową, GitHub zaleca poprzedzenie jej ukośnikiem odwrotnym, na przykład Dotted \| plain. Zobacz Formatowanie treści wewnątrz tabeli.

Czego użyć, gdy wielowierszowe komórki nie są obsługiwane?

Jeśli miejsce docelowe obsługuje tabele, ale odrzuca wbudowany HTML, użyj osobnego wiersza dla każdego szczegółu. Powtórzenie nazwy elementu pozwala zachować powiązanie bez podziału wiersza wewnątrz komórki:

| Item | Detail |
| --- | --- |
| Notebook | Dotted pages |
| Notebook | Blue cover |

Jeśli miejsce docelowe obsługuje tylko podstawowy CommonMark, przenieś szczegóły do nagłówka i listy:

### Notebook

- Dotted pages
- Blue cover

Nagłówki i listy należą do składni CommonMark. To rozwiązanie zastępcze zapewnia też więcej miejsca na dłuższe wpisy, bez konieczności korzystania z rozszerzenia tabel.

Blok kodu wielowierszowego umieść w ogrodzeniu poza tabelą. Umieszczenie kilku wierszy źródłowych w jednym wbudowanym fragmencie kodu nie zachowuje ich podziałów wiersza: CommonMark normalizuje znaki końca wiersza w takich fragmentach do spacji. Zobacz Fragmenty kodu.

Wybierz format odpowiedni do treści, którą chcesz zachować. W przypadku dwóch krótkich fraz podział wbudowany to praktyczne rozwiązanie, które warto sprawdzić. Osobne akapity, dłuższe listy lub wielowierszowy kod przenieś poza komórkę. Zachowaj krótką próbkę zgodności w notatkach roboczych, aby móc powtórzyć test po zmianie miejsca docelowego.

Źródła