txt2tags - jak psát HTML inteligentně

5. 10. 2007 | Martin Lebeda | Recenze | 7874×

Někomu nevadí psát HTML přímo, někdo používá WYSIWYG editory a někdo používá udělátka pro konverzi vhodně zapsaného čistého textu do HTML.

Úvod

Psát přímo v HTML je pro mne nepohodlné, zvykl jsem si na TeX syntax, kde se jednotlivé odstavce oddělují pomocí prázdného řádku, což mi přijde nejrychlejší, nejlogičtější a hlavně nejčitelnější. Kromě tagu <p>, který opravdu nemám rád, podle mne zhoršují čitelnost i ostatní příliš "ukecané" tagy. Třeba si zkuste přečíst takovou definici tabulky v HTML a srovnejte s definicí v LaTeXu nebo prostými oddělovači v CSV. Pro samé značky není ani vidět obsah. A při psaní textu jsem se musel vždy více soustředit na dodržování formální struktury než na samotný obsah.

Zkrátka psát HTML přímo mi nevyhovuje. LaTeX je sice skvělý a dříve jsem jej používal prakticky na všechny své texty, jenže doba se mění a dnes jsem ve stavu, kdy jen málo mých textů půjde na papír, daleko nejvíce jich jde na web - čili právě do HTML. Z důvodů, které jsem popsal (a mnoha dalších), vznikly konvertory z textu do HTML. Další seznam důvodů, proč nepsat přímo v HTML, lze najít třeba na http://txt2tags.sourceforge.net/writing-book.html.

Používat konvertor z textu do HTML znamená naučit se další značkovací jazyk a v něm psát. Základní výhoda je ale v tom, že tento značkovací jazyk je obvykle tak jednoduchý a minimalistický, že jej téměř lze při psaní ignorovat a prostě jen psát. Je velmi podobný přirozenému formátování čistého ASCII dokumentu a svou syntaxí neruší při psaní ani při čtení. Používaný jazyk jde většinou cestou nejmenšího překvapení a používá již zažité konvence, na které jsou lidé zvyklí např. z emailů, takže naučení formátovacích značek je velmi snadné.

Ovšem existují i nevýhody. Především pokud autor textu potřebuje používat složitější konstrukce HTML, pak jich lze dosáhnout jen obtížně (pokud vůbec). A spolu s existencí mnoha konvertorů existuje i mnoho různých syntaxí zdrojových textů, které se navzájem mírně liší. A určitě by se daly najít i další nevýhody. Každý si tak musí rozmyslet, zda používání takového nástroje bude právě pro něj přínosem.

Asciidoc

Asciidoc je asi nejznámějším zástupcem těžké třídy. Jeho formát je komplexní a asi nezajímavější je možnost převodu do cílového formátu pomocí nástrojů DocBook.

Export dokumentů je možný do HTML i XHTML, LaTeX a manuálové stránky. Ovšem hlavním lákadlem tohoto konvertoru je nepochybně možnost konverze do docbook a tím se řádově rozšiřují možnosti dalšího zpracování. Je také možné napsat vlastní konverzní filtr pro libovolný tzv. backend (pomocí konfiguračních souborů).

Vstupem je pochopitelně čistý textový soubor v definované syntaxi. Ta je velmi komplexní a uživatelská příručka popisující obsluhu konvertoru má bezmála 90 stránek. Většina popisuje možnosti formátování vstupního dokumentu. Možnosti jsou bohaté, ale je otázka, zda pak uživatel najde onu výše zmíněnou jednoduchost. Také zpracování pomocí nástrojů DocBook není podle mne nic jednoduchého (většinou si připadám jako s kanónem na vrabce).

Samotný konvertor je psán v Pythonu a nemá na systém žádné speciální nároky; pouze pro syntakticky zvýrazněné výpisy zdrojových kódů je potřeba mít v systému příslušné filtry (GNU source-highlight), podobně pro notové zápisy...

Podpora v editoru vim je formou zvýraznění (PNG) syntaxe.

Markdown a spol

Markdown jsem zvolil jako zástupce "lehkých konvertorů". Je to především knihovna určená pro implementaci ve webových aplikacích. Samostatný program existuje jen jaksi mimochodem. Jeho výstupním formátem je pouze torzo HTML. Přesněji je to jen část HTML určená pro zobrazení v rámci již existující stránky, žádné formální HTML hlavičky, patičky nebo snad dokonce CSS. Na druhou stranu je syntaxe popsána na jediné krátké stránce.

Do editoru vim lze doplnit zvýraznění syntaxe, existuje i mód pro emacs. Knihovny pro zpracování existují do mnoha známých i exotických jazyků. Ovšem velmi zajímavá implementace je pomocí javascriptu pro plugin Greasemonkey Markdown textareas, které umožňuje konvertovat text v libovolném textovém poli - třeba zrovna ve fórech na AbcLinuxu.

Markdown není jediným programem v této kategorii. Zvláště pěkný je dle mého názoru Texy! původem z českých krajů. Původně byl dostupný pouze formou knihovny pro PHP, což jej pro mé potřeby poněkud znevýhodňovalo. V poslední době přibyly i knihovny pro ruby, .NET a existují i převodníky do LaTeXu a pro zpětnou konverze z HTML, které jsem ale nezkoušel a jejich kvalitu nemohu posoudit.

txt2tags

txt2tags je zástupcem střední cesty a jeho možnosti jsou někde mezi dříve zmíněnými programy. Jeho komplexnost zdaleka nedosahuje Asciidoc, ale ani to není jednoduchý prográmek určený pro implementaci v polích diskusních fór na webu. Jedná se o samostatnou aplikaci napsanou v Pythonu, nikoliv o knihovnu.

Program txt2tags je napsán v čistém pythonu bez závislostí na funkcích, které nejsou součástí standardní knihovny. Výsledkem je prográmek, který zvládá konverzi textu na HTML, XHTML, SGML, LaTeX, Lout, Man page, MoinMoin, MagicPoint a PageMaker a přitom nemá žádné zvýšené nároky na systém ani interpreter a má slušnou podporu pro editaci ve vimu.

Syntaxe je velmi jednoduchá. Dokument začíná hlavičkou, kterou tvoří první tři řádky - titulek, autor a datum poslední změny. Jejich pořadí a pozice jsou závazné - pokud je některý z řádků prázdný, je vynechán. Lze také první řádek nechat prázdný a hlavička je pak úplně vynechána. Za hlavičkou následuje prázdný řádek a pak nepovinná sekce konfigurace. Opět prázdný řádek a začíná dokument. Konfigurace je identifikována počátečními znaky procenta a vykřičníku - při vynechání není třeba místo ní nechávat prázdný řádek. A pak už následuje obsah.

Jak tedy vypadá formátování jednoduchého textu? Předveďme si to na ukázce:

  titulek
  autor
  datum poslední úpravy
  
  = Hlavní nadpis =
  
  Nějaký úvodní text.
  
  == nadpis druhé úrovně ==
  
  Další test obsahující **tučné** nebo //kurzívní// zvýraznění. Také obsahuje
  nějaký text ``neproporcionálním`` písmem a [link http://www.abclinuxu.cz]. 
  
  Následuje další odstavec.
  
  ```
  prostředí pro výpisy
  takto lze vložit třeba výpis kódu
  ```
  
  A poslední odstavec.

Přeložit do HTML lze příkazem:

  txt2tags -v --no-headers --target=html ukazka.t2t

Výsledek po překladu se nachází v souboru ukazka.html a vypadá takto:

  <H1>Hlavní nadpis</H1>
  <P>
  Nějaký úvodní text.
  </P>
  <H2>nadpis druhé úrovně</H2>
  <P>
  Další test obsahující <B>tučné</B> nebo <I>kurzívní</I> zvýraznění.
  Také obsahuje nějaký text <CODE>neproporcionálním</CODE> písmem a 
  <A HREF="http://www.abclinuxu.cz">link</A>. 
  </P>
  <P>
  Následuje další odstavec.
  </P>
  <PRE>
    prostředí pro výpisy
    takto lze vložit třeba výpis kódu
  </PRE>
  <P>
  A poslední odstavec.
  </P>

Překladem pro LaTeX s ostatními parametry stejnými pak získáme tento soubor:

  \section*{Hlavní nadpis}
  Nějaký úvodní text.
  
  \subsection*{nadpis druhé úrovně}
  Další test obsahující \textbf{tučné} nebo \textit{kurzívní} zvýraznění.
  Také obsahuje nějaký text \texttt{neproporcionálním} písmem a 
  \htmladdnormallink{link}{http://www.abclinuxu.cz}. 
  
  Následuje další odstavec.
  
  \begin{verbatim}
  prostředí pro výpisy
  takto lze vložit třeba výpis kódu
  \end{verbatim}
  
  A poslední odstavec.

Větší ukázku syntaxe txt2tags lze najít v příkladech.

Konfigurace probíhá na několika místech: v konfiguračním souboru ~/.txt2tagsrc, na příkazovém řádku při spouštění konvertoru a v samotném souboru v hlavičce. Makra PreProc a PostProc umožňují ovlivnit výsledek pomocí jednoduchých nahrazení (s regulárními výrazy). Žádný zázrak to není, ale pro jednoduché věci se tento preprocesor hodí. Na ty složitější pak máme přece m4, že. Další možností, jak obejít omezení překladu, je vložení přímo cílového kódu např. v HTML, ovšem tím se samozřejmě připravíme o možnost překladu pro více výstupních formátů.

Pro použití txt2tag si lze rozšířit editor vim o podporu syntaxe, kompilátoru a menu pro grafickou verzi.

Kromě vim lze najít podporu maker i pro gedit a TextMate (což ovšem není pro Linux). Standardně v instalačním balíčku je podpora syntaxe pro vim, Emacs, Nano a Kate. Zajímavé triky a tipy na použití se objevují čas od času v oficiálním blogu. Jsou to odkazy na texty popisující, jak generovat celé statické weby, jak používat txt2tags jako wiky a další někdy dost exotické možnosti použití.

Závěr

Doufám, že jsem představil zajímavou možnost, jak psát texty určené (nejen) pro web. Podobné nástroje nejsou samozřejmě samospasitelné a nejsou vhodné pro tvorbu jakýchkoliv textů. Zejména při náročnějších požadavcích na formátování je vhodnější psát přímo. V mnoha případech však mohou výrazně ulehčit život.

Osobně dávám přednost txt2tags, jemuž jsem věnoval nejvíce prostoru. Dostal jsem se k této osobní volbě po několika jiných pokusech o použití podobného formátovače, ale tento mi prostě "sednul" nejvíce.

       

Komentáře

[xm]

Chybí mi tu zmínka o reStructuredText (který je mimo jiné součástí pythoních docutils) a Textile. Tyto dva lehké markup-jazyky patří IMHO mezi ty nejrozšířenější (o txt2tags naopak slyším poprvé).

[xm]

Nicméně teď jsem na txt2tags koukal a velmi se mi líbí Takže děkuji za rozšíření obzorů...

[xm]

I když tedy jsou taky věci, které se mi na txt2tags hodně nelíbí - třeba to že seznamy je nutno ukončovat dvěma prázdnými řádky (nebo prázdnou položkou seznamu). To mi přijde opravdu ošklivé.

[Martin Lebeda]

Kdyby existoval ideální pro všechny, nebylo by jich tolik....

[Yin]

Snad:

%!preprocess   '^(\n)'   '\1\1'

Ak nie, myslim, ze napisat jednoduchy filter v akomkolvek jazyku by nemal byt problem. Teda aspon pre mna nie... budem potrebovat nejaky poriadny konvertor, nie moj "pain text 2 html", takze filter najdete v mojom blogu.

[Tomáš P]

VST je verze reST která nepotřebuje Python (ale je nutné mít Vim 7 a Vim script VST).

[Filip Jirsák]

Nějak moc nechápu módu těchhle značkovacích zápisů určených pro převod do HTML. většina z nich je dobrá akorát tak pro ty, kdo nemůžou na klávesnici najít špičaté závorky. Ještě bych pochopil zápis, který mi umožní napsat odstavce, nadpisy, seznamy a možná nějaké jednoduché odkazy. Ale proč se k tomuhle pak přidávají nejrůznější šablony, tabulky a další složité zápisy, které ovšem mají svou extra notaci a zpravidla se nedají rozumně parsovat, to nechápu.

[Hynek (Pichi) Vychodil]

Nějak moc nechápu módu těchhle značkovacích zápisů určených pro převod do HTML. většina z nich je dobrá akorát tak pro ty, kdo nemůžou na klávesnici najít špičaté závorky.

Možná proto, že SGML deriváty jsou hnus fialovej, HTML počínaje a XML konče. Editace člověkem je těžkej opruz a pro stroj je to ... no to potvrdí, každej kdo se pokusil napsat full featured XML parser a u HTML by HTML5 W3C WG mohla vyprávět. Ve výsledku SGML deriváty nesplňují ani jednu ze základních premis, není to ani pro člověka, ani pro stroj.

Ale proč se k tomuhle pak přidávají nejrůznější šablony, tabulky a další složité zápisy, které ovšem mají svou extra notaci a zpravidla se nedají rozumně parsovat, to nechápu.

Jo, to taky nechápu, proč se zpravidla vymýšlí ještě něco horšího. Jako by SGML nebylo dost hnusné, musí se vymýšlet něco, co je ještě hůře parsovatelné.

[Filip Jirsák]

Pro tenhle typ užití ale není potřeba plnohodnotný XMl parser, na to stačí jednoduchoučký parser na pár řádek (který umí tagy, atributy, entity pro <, > a & a entity pro znaky).

Docela by mne zajímalo, jak byste si představoval formát, který je dobře editovatelný člověkem a stroj ho může parsovat bez použití křišťálové koule. Podle mne tam musí být něco jako značky, kterým můžu volitelně přidat atributy. A nenapadá mne žádný zápis, který by byl o mnoho jednodušší než jednoduché XML. Třeba ASN.1 se sice parsuje dobře, ale z lidí to ocení asi jen málokdo.

[Hynek (Pichi) Vychodil]

Takže třeba namátkou rfc 4627 aka JSON, YAML nebo UBF (pokud je server nedostupný, tak třeba článek, nebo implementace v cl). Každý z jmenovaných předčí v obou parametrech SGML deriváty o několik délek. K tomu jako další bonus přidávají menší datový objem v řádu desítek procent. Jen pro srovnání parser/serializer UBF v erlangu je nějakých 391 řádek, "(XML) scheme" parser 270 a validátor 301. K XML parseru, který by pracoval s XML scheme by jste se nedostal ani na setinu tohoto počtu. To samé YAML nebo JSON. Oba se parsují nesrovnatelně snáz než XML nebo HTML a čitelnost? Hehe, to se snad ani nedá srovnat. Prakticky cokoli, co zkušený člověk vymyslí do dvou dnů bude o několik řádů lepší než SGML deriváty. Jen ten systém eskejpování, to byl vtip? CDATA, to je taky vtip, ne?

[zoul]

Nezlobte se na mě, ale věty jako SGML deriváty jsou hnus fialovej, HTML počínaje a XML konče nejsou dobrý začátek rozumné diskuse o technologiích. Upřímně už mě mrzí (dokonce jsem chtěl napsat sere!), jak se pod každým článkem o HTML nebo XML objeví nějaký Probuzený, který začne vysvětlovat, jak špatně vymyšlené ty technologie jsou. Kdybych měl označkovat třeba text na web nebo článek do sborníku a měl bych si vybrat mezi JSON a XML, osobně bych si nejspíš vybral XML. Nepovažuju XML za všelék, ale taky si nemyslím, že bych to přechodem k JSON, s-výrazům či [doplňte podle oblíbené technologie příslušného fanatika] nějak zásadně vyhrál.

[Hynek (Pichi) Vychodil]

... Kdybych měl označkovat třeba text na web nebo článek do sborníku a měl bych si vybrat mezi JSON a XML, osobně bych si nejspíš vybral XML. ...

A proč? Protože to funguje stejně jako .doc a .xsl. Žádnou logiku v tom nehledejte.

[zoul]

Já té odpovědi moc nerozumím. Proč? Protože by se mi to v XML líp psalo, viz Filipův odstrašující příklad JSON zápisu níže.

[Filip Jirsák]

To jsou ale všechno formáty popisující hlavně strukturu dat, kde ta struktura je převažující část. Převod z textu do HTML se ale používá především pro takový vstup, kde máte spoustu textu a v tom sem tam nějakou značku. Třeba komentáře tady na Abíčku bych rozhodně nechtěl psát ani v jednom ze zmíněných formátů.

CDATA mi nijak nevadí, protože se skoro nepoužívají a je možné se obejít i bez nich. A eskejpování (dá-li se tomu tak u XML vůbec říkat) je velice jednoduché. Všechno, co je za & až do středníku je entita, a hlavně se vám nemůže stát, že se eskejpovaný znak objeví v jiném kontextu. Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí jen od začátku do konce entity). U takového JSONu bez syntaktického kontextu ani nerozdělíte vstup na tokeny.

[Hynek (Pichi) Vychodil]

Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí jen od začátku do konce entity). ...

Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je to móda. XML je špatný formát!

[Filip Jirsák]

Tady se ale neustále bavíme o zápisu formátovaného textu. Můžete mi říci jeden jediný dobrý důvod, proč do formátovaného textu (který se má později převést na HTML) vkládat CDATA? Ve spoustě případů nejsou potřeba ani ty komentáře. A i s těmi komentáři parsování XML pořád funguje tak, že když začnu kdesi od prostředka, pořád se dříve či později tokenizer chytí. U JSONu tohle nefunguje, tam musím jít od začátku, abych věděl, zda jsem uvnitř uvezovek nebo venku, a když začnu od prostředka, mám prostě smůlu. Pokud se vám nezdá k ničemu dobré parsovat dokument od prostředka, stačí si uvědomit, že přesně takhle "parsuje" text člověk – najdu si část, která mne zajímá, trochu předsadím a začnu číst. U XML brzy poznám, co je značka, co atribut a co text. U JSONu mám smůlu, musím prostě jet od začátku a počítat paritu neescapovaných uvozovek.

Mimochodem, to byste opravdu radši svůj komentář psal následujícím způsobem?

odstavce = [
  [
	  {
    text: "Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli"+
"náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu"+
"potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí"+
"jen od začátku do konce entity). ...",
    typ: "citace"
    }
	],
	[
		{
     text: "Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první"+
"komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA"+
"nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se"+
"nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to"+
"nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu"+
"XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v"+
"parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je"+
"to móda. XML ",
			typ: "prostý text"
		},
		{
			text: "je",
			typ: "tučně"
		},
		{
			text: " špatný formát!",
			typ: "prostý text"
		}
	]
]

[Hynek (Pichi) Vychodil]

Máte to špatně a krom toho si nejsem vědom, že bych něco takového psal v html. A že jste si jak na potvoru z všech možností vybral právě JSON, copak to? Záměr? No když teda ten JSON, tak já osobně co si pamatuju, tak jsem do html toho příspěvku psal něco takového:

[{"citace":"Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli
náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu
potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí
jen od začátku do konce entity). ..."},
"Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první
komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA
nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se
nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to
nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu
XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v
parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je
to móda. XML ", {"tučně": "je"}, " špatný formát!"]

Ale to by nevypadalo tak úděsně a nešly by s tím strašit malé děti. Pěkná ukázka demagogie, ale dosti chabá. A v YAMLu by to bylo ještě lepší.

[zoul]

A že jste si jak na potvoru z všech možností vybral právě JSON, copak to? Záměr?

Však jste nám ho sám nabízel jako první alternativu…?

Ale to by nevypadalo tak úděsně a nešly by s tím strašit malé děti.

"XML ", {"tučně": "je"}, " špatný formát!"

XML <tučně>je</tučně> špatný formát!

Vy máte fakticky pocit, že ten první zápis je jednodušší?

[Daniel Kvasnička ml.]

Jo, na tomhle je to hezky videt. To prvni muze za jednodussi a prehlednejsi povazovat jen fanatik. Jeste si rikam, jak by to asi v te prvni syntaxi vypadalo, kdybychom pridali par namespaces, atributy...to uz by byla uplna Cina. A psat takovymhle zpusobem treba XSLT?

[Filip Jirsák]

Dobře, čistý text je implicitní typ, o to se to dá zkrátit (i když osobně nemám rád určování hodnot podle typu objektu). Ovšem stále je to neuvěřitelně nepřehledné a nepohodlné něco takového psát. Nehledě na to, že konce řádků uvnitř stringu vám nezbaští každý parser.

Můžete sem dát ukázku takového komentáře v YAMLu? Mně to trápění s JSONem bohatě stačilo a nejsem masochista, abych to opakoval ještě jednou s YAMLem, ale pohled na ten příšerný zápis, který z toho zajisté vyleze, snad ještě snesu.

[zoul]

A mimochodem, argument s psaním parserů je strašně divnej – proč by měl člověk pro každý takový formát psát parser? Mně je úplně fuk, jestli psaní toho parseru trvalo měsíc, nebo dva. Mně je úplně fuk, jestli bude parsování hotové za 0,01 vtěřiny, nebo 0,02 vteřiny. Já prostě použiju nějaký hotový parser, kterých je pro každý jazyk kupa, a basta. Ano, psaní parseru je argument, a zvlášť tady mezi programátory je to velká obsese, ale pro praktický úspěch a praktickou použitelnost formátu jsou mnohem důležitější věci.

[Hynek (Pichi) Vychodil]

Mně je úplně fuk, jestli bude parsování hotové za 0,01 vtěřiny, nebo 0,02 vteřiny.

No jasně, kdyby to bylo takhle, tak je to putna každému, ale on ten rozdíl je přinejmenším desetkrát větší a když děláte nějaké větší řešení, tak už mě sakramentsky zajímá jestli na to budu muset koupit mašiny za půl nebo za pět miliónů jek kvůli tomu, že XML je prostě standard.

Já prostě použiju nějaký hotový parser, kterých je pro každý jazyk kupa, a basta. Ano, psaní parseru je argument, a zvlášť tady mezi programátory je to velká obsese, ale pro praktický úspěch a praktickou použitelnost formátu jsou mnohem důležitější věci.

Ano, hezky se to poslouchá jen do chvíle, kdy to má fungovat s trochu větším dokumentem, nebo nedej bože pár miliónů byť i malých dokumentíků, jo to je pak takovej průser, ale co je to dobré pro HW byznys.

[zoul]

Vy máte zkrátka pocit, že když se XML nehodí rovným dílem na všechno, je to špatný formát. Podle mě se na spoustu věcí hodí docela dobře, a tak ho na ně používám, tečka. Je spousta případů, kdy člověk nemusí parsovat několik gigabajtů nebo několik miliónů dokumentů. Je to přeci jen nástroj. Pokud se na něco nehodí a stejně ho do toho montuju, těžko si pak můžu stěžovat. Opravdu mi připadne, jako kdybyste si stěžoval, že jste se kladivem snažil zalévat květiny a ony vám uschly ⇒ kladivo je zatraceně mizerná technologie. (Nebo mám radši zkusit nějaké přirovnání s autem?

[Daniel Kvasnička ml.]

Ooo, pan Vychodil a jeho "nazor" na XML. Uz jsem to dlouho neslysel, zvlaste si uzivam tu cast o tom, jak je tezke pro cloveka to cist a psat. Pro vas je to mozna tezke, ale nemusite si to lecit na nas ostatnich.

O trosku nize se podivejte v komentari pana Jirsaka na ten "uzasne citelny" zapis vaseho komentare. Kdyz dam ty dva zapisy vedle sebe, na prvni pohled zcela jiste poznam vic z XML zapisu nez z te zmeti znaku.

[Hynek (Pichi) Vychodil]

O trosku nize se podivejte v komentari pana Jirsaka na ten "uzasne citelny" zapis vaseho komentare. ...

Jistě, jeden demagog podpoří druhého odkazem na schválně zmršený příklad. Ale jde to i jinak. To bych sem mohl rovnou dát ukázku html generovanou Front Page nebo MS Word blahé paměti. Nebo OpenXML? Jo to by jsme se nasmáli.

[Daniel Kvasnička ml.]

Ale jde to i jinak

Je mi lito, porad stejny hnus

Nebo OpenXML? Jo to by jsme se nasmáli.

Nebo ODF, ne? To je prece taky XML. Na pohled pro vas o nic mene deprimujici pohled. Opravdu by me zajimalo, cim prehlednejsim a hezcim byste nahradil XML v pripade techto datovych formatu. Vite co, zkuste napsat v OOo nejaky maly dokumentik, pak vezmete content.xml z toho dokumentu a prepiste to do vasi oblibene alternativy XML. A pak si povime, co je prehlednejsi...

[Věroš]

Nějak moc nechápu módu těchhle značkovacích zápisů určených pro převod do HTML. většina z nich je dobrá akorát tak pro ty, kdo nemůžou na klávesnici najít špičaté závorky.

Protože ne všichni umí zapisovat HTML. Když jsem do Cestovatele přidal možnost zapisovat text do článků v Texy!, tak se to mezi členy redakce velmi ujalo a rychle začali vyžadovat přidání Texy i do zpráviček a dalších částí webu...

[Filip Jirsák]

Protože ne všichni umí zapisovat HTML. Když jsem do Cestovatele přidal možnost zapisovat text do článků v Texy!, tak se to mezi členy redakce velmi ujalo a rychle začali vyžadovat přidání Texy i do zpráviček a dalších částí webu...

Takže se místo HTML učí Texy! A na jiném webu wiki dle MediaWiki. A jinde zase trochu jinou wiki. A pokud chtějí něco speciálnějšího, musí se zase naučit to HTML. V čem je třeba Texy! od nadpisů a seznamů dál jednodušší než HTML? Podle mne v ničem, naopak je složitější – v HTML se tag vždycky píše do špičatých závorek a uvnitř mohou být pojmenované atributy.

[Martin Lebeda]

Takže se místo HTML učí Texy! A na jiném webu wiki dle MediaWiki. A jinde zase trochu jinou wiki.

Ano je to jedna z nevýhod. Idelání řešení pro všechny neexistuje, bohužel.

A pokud chtějí něco speciálnějšího, musí se zase naučit to HTML. V čem je třeba Texy! od nadpisů a seznamů dál jednodušší než HTML?

• Značky nepřekáží při čtení
• Značky neotravují při zápisu
• "Značky" jsou tak jednoduché, že se dají naučit s mnohem menším úsilím

[Martin Lebeda]

Ještě bych pochopil zápis, který mi umožní napsat odstavce, nadpisy, seznamy a možná nějaké jednoduché odkazy.

Vlastně jste si sám odpověděl. Pokud tento seznam pokryje 95% pořizování textu a je mi umožněno zbytek dopsat přímo v HTML. Pak mohu psát mnohem pohodlněji.

Ideální řešení pro všechny neexistuje a určitě někomu bude vyhovovat více jiný přístup.

[Filip Jirsák]

Ještě bych pochopil zápis, který mi umožní napsat odstavce, nadpisy, seznamy a možná nějaké jednoduché odkazy.

Vlastně jste si sám odpověděl. Pokud tento seznam pokryje 95% pořizování textu a je mi umožněno zbytek dopsat přímo v HTML. Pak mohu psát mnohem pohodlněji.

Což ale právě není případ ani jednoho mně známého systému. Každý začne přidávat svou syntaxy pro vkládání obrázků, částí kódu tabulek, šablon… Už jenom to zvýrazňování textu – hvězdičky, apostrofy, uvozovky – možná to tolik neruší při čtení textu, ale když každý systém používá jinou syntaxy, je to celé k ničemu. To radši budu psát <b> a <i> a nebudu se muset pokaždé dívat, jakou ten který systém zrovna používá syntaxy.

Ale aspoň jsem si ujasnil, jak by takový ideální wiki-like zápis měl vypadat Nelíbila se mi syntaxe MediaWiki se složitými šablonami a tabulkami, na druhou stranu se mi líbí jednoduchý zápis jednoduchého textu (odstavce, seznamy) bez "složitého" XML. Už je mi ale jasné, že nebude těžké napsat XML parser, který zvládně i to jednoduché z wiki syntaxe – odstavce, seznamy, nadpisy. Vše ostatní už pak může být XML.

[Martin Lebeda]

Opravdu jednoduchý mi přijde ten Markdown (z těch co znám a neznám všechny), obsahuje jen ten základ, co jste vyjmenoval v původním příspěvku. Žádné tabulky, žádné šablony ani jiné složitosti... Právě ta složitost mi vadila na Asciidoc.

Pro mé potřeby je ale Markdown až moc jednoduchý...

Ve věci přemýšlení nad tím jak se zrovna píše <b> si dovolím oponovat. To je přesně to co nemusím dělat, pokud chci stejný text vystavit na web, vyrobit z něj PDF, poslat do firemní wiky... Pak mám konvertor, který mi z jednoho zdroje ty varianty vyrobí. Neumí to všechny konvertory a ani do všech možných formátů. Ale to je pak otázka potřeb a vhodného kompromisu.

[Filip Jirsák]

Pokud chci nějaký systém používat sám pro sebe a pro generování do různých výstupních formátů, jsem ochoten se nějaký vstupní formát naučit. To přemýšlení se týkalo těch systémů, které se používají pro komentáře, wiki, blogy (i když chápu, že to nebyl primární cíl popsaný v článku) – a každý systém má trochu jiný zápis.

I ten Markdown je na můj vkus příliš složitý. Já bych všechno, co má nějaké parametry (složitější odkazy, obrázky, výpis kódu), psal jako XML. Fakt ale je, že jsem zvyklý psát HTML a mám po ruce několik editorů, které mi doplňují koncové tagy atd.

[zoul]

Velká legrace je Atox, u kterého si můžete zdrojovou i cílovou syntaxi upravit.

[michalel911]

nieco podobne ako txt2tags som programoval minuly rok ako projekt v BASHi :)...len mal inu syntax...ale slo to...dokonca to kontrolovalo aj vlastnym checkspell-om

[mofo]

už perex "...udělátka pro konverzi vhodně zapsaného čistého textu do HTML" je zcestný - ten text už není čistý! - stejně tak celá idea nahrazovat jedny značky značkami jinými a mezi sebou to konvertovat. a ten html kód co vám z toho vypad - už jen ta velká písmena tagů... a tag <B> - toto je hnus... netvrdím, že někdy není obhajitelné použít jako základ pro html jiné značky (i vlastní výroby, před lety jsem to sám udělal), ale obecně je to ideově mimo. a ještě se v tom takto vyžívat...

[mofo]

...ještě jsem opomněl napadnou "inteligentně" v titulku ;) nicméně celý text je založen na nějaké VÍŘE a subjektivním pohledu. na výčet možností převodu různých textových zápisů mezi sebou je v něm příliš mnoho emocí. on tomu člověk snadno podlehne, že? ;)

[Martin Lebeda]

Celý text není založen na víře, ale z pochopitelných důvodů jsem popsal, to co ovládám - takže ano, je to také osobních preferencích.

Myslím, že není třeba být suchar a trocha nadsázky není škodlivá. Jistě jsou i jiné cesty jak se dobrat stejného výsledku - to nikde netvrdím ani nevnucuji nabízené řešení jako jedinou správnou.

[root/localhost]

Psat HTML inteligentne znamena jej nepsat vubec. Muzeme vse vygenerovat pres XSLT == psat XSL.
Je to casove vyhodnejsi? (Y/[N]):

GUI by melo jit naklikat a nabizet s pomoci wrapperu vse co ma nativni OS. Treba ten mainform, jenz ma Vas browser by mel jit sestavit.

V necem jako je Delphi/C++ Builder/Kylix bych docilil stejneho GUI za par minut, v zas*anem (X)HTML nikdy a to nemluve o assignovani funkci na zaklade eventu, trochu se to zlepsi s XUL, jenze nez bude implementovan prekona ho jina technologie a budeme mit < | > opet.

SGML je zastarale, IBM by mohla releasovat do sveta neco lepsiho.

[petr_p]

Toto je zářný příklad, jak se HTML ohýbá a ohýbá až…

HTML je výborné na popis hypertextu s jednoduchou strukturou (odstavce, několik nadpisů, jeden seznam a dva obrázky). Používat jej na vysoce strukturované dokumenty (např. obdoba DocBooku, to, o co se snaží mikroformáty) nebo na tvorbu interaktivního GUI (lépe v XUL, XForms) je čistý masochismus.

Je na čase si uvědomit, že Web neznamená jen (X)HTML.

[truhla]

Psaní HTML má dvě roviny - formu a obsah. Praktické zkušenosti ukazují, že je dobré tyto dvě oddělit. Forma je design/theme a tady nám nějaký zjednodušený zápis nepomůže a je nutné tvrdě hackovat HTML/CSS/Javascript. Obsah je naproti tomu text s odstavci, nadpisy, různými fonty, obrázky atd., celé ale jen velmi jednoduchá a snadno parsovatelná podmnožina HTML, kterou bez problémů zvládají klikací WYSIWYG editory. Existuje tedy objektivní důvod používat txt2tags či podobné? Ne.

[Filip Jirsák]

Obsah je naproti tomu text s odstavci, nadpisy, různými fonty, obrázky atd.

Ne ne, písma jsou forma. Obsah je citace, zdůraznění, příklad atd. A teprve těmto různým významům obsahu se pak přiřazuje forma – různé druhy nebo řezy písma. Problém většiny WYSIWYG je právě to S, tj. že se v nich nastavuje forma (písmo, barva, tučnost atd.), místo aby se určoval význam textu (ať už speciálními tagy, které HTML má, nebo třídami a přiřazenými styly pro ty ostatní významy).

U složitějších věcí je pak jednodušší vytvořit jejich obsah i formu společně. Vemte si jako příklad Wikipedii, jaké se tam často používají složité konstrukce. Pokud se pak taková konstrukce oddělí do šablony, je to zase takové oddělení formy od obsahu – al ebylo by hodně náročné vytvořit a udržovat takový WYSIWYG editor, který by zvládal jako sémantické konstrukce používat i tu spoustu šablon.

Nicméně to ještě není důvod, proč pro ty složitější konstrukce vymýšlet šílené zápisy nesrovnatelně složitější, než HTML.

[truhla]

V obecném případě máte jistě pravdu - písma jsou forma a obsah je citace, zdůraznění, příklad atd. Běžně se ale tenhle rozdíl úplně stírá. Napíšu-li něco bold, je to prostě zvýraznění a netřeba o tom přemýšlet.

Wiki syntaxi mám docela rád, ale každopádně preferuju, když nad textareou pro zadávání textu jsou tlačítka, kterými lze udělat totéž, co syntaxí. Nenapadá mě žádný příklad konstrukce, která je natolik složitá, že nejde řešit WYSIWYG, a zároveň lze elegantně řešit něčím jako txt2tags či Texy! Jestli o nějakém takovém příkladu víte, byl by to určitě významný příspěvek této diskuzi.

[Martin Lebeda]

IMHO jsou cílovou skupinou tohoto a podobných programů technicky zaměření uživatelé, jako jsou např. programátoři. Ten kdo chce používat svůj oblíbený vim/emacs/... a zároveň považuje konstrukci & za čitelnější než & je vhodným kandidátem na používání podobného nástroje.

Tento přístup není samozřejmě vhodný pro každého, někomu třeba vyhovuje některý z WYSIWYG editorů nebo přímé psaní HTML.

[truhla]

Máte pravdu, každý máme jiné požadavky. Já zrovna jsem profi programátor a weby jsou jednou z mých oblastí, ale tohle se mi nelíbí. Tvrdím toto: 1) složité věci tím nejdou udělat (layout stránek, levé či pravé menu apod.) 2) jednoduché věci jdou udělat jednodušeji (zmíněný WYSIWYG sestavovač příspěvků)

Každopádně je dobře, že jste o tom napsal článek a můžeme se nad tím společně zamyslet.

[Martin Lebeda]

Já jsem také profi programátor a nikdy jsem nenapsal jediný web . XML a jeho deriváty považuji za dobrý základ pro protokoly a data zapisované a čtené programy, nikoliv lidmi.

[truhla]

Taky se mi mnohem víc líbí YAML a XML píšu nerad (i když v Eclipse, které umí inteligentně napovídat, se to nechá vydržet), ale je potřeba se vyrovnat s realitou a neštkát. Standard většinou nebývá nejlepší řešení.

Když jsem řešil konfigurák pro svou aplikaci, chtěl jsem použít YAML, ale nenašel jsem žádnou široce podporovanou a stabilní knihovnu (pro Javu). Nakonec stejně nějaký admin zvládne konfigurovat i v XML a pro klikače se stejně musí udělat GUI. Kolik třešní, tolik višní.

[Filip Jirsák]

V obecném případě máte jistě pravdu - písma jsou forma a obsah je citace, zdůraznění, příklad atd. Běžně se ale tenhle rozdíl úplně stírá. Napíšu-li něco bold, je to prostě zvýraznění a netřeba o tom přemýšlet.

Jenže to je právě problém. Někdo pak používá pro zvýraznění tučné písmo, jiný kurzívu a jiný červené písmo. A je to třeba ve stejné diskuzi, ve stejném redakčním systému, nebo dokonce na stejné wiki-stránce.

Wiki syntaxi mám docela rád, ale každopádně preferuju, když nad textareou pro zadávání textu jsou tlačítka, kterými lze udělat totéž, co syntaxí. Nenapadá mě žádný příklad konstrukce, která je natolik složitá, že nejde řešit WYSIWYG, a zároveň lze elegantně řešit něčím jako txt2tags či Texy! Jestli o nějakém takovém příkladu víte, byl by to určitě významný příspěvek této diskuzi.

To po mně nechtějte, já tu celou dobu tvrdím, že txt2tags nebo Texy! řeší složitější konstrukce velmi neelegantně Problém s WYSIWYG je, že je nemůžete rozumně používat s jiným způsobem zápisu, než HTML (bylo by moc pracné takový editor napsat a udržovat). A pro složitější systémy, než jsou komentáře (redakční systémy, blogy, wiki) potřebujete různé konstrukce jako šablony. Třeba jenom hloupý obsah stránky (__TOC__ z MediaWiki) – musel byste zařídit, aby vám jej WYSIWYG editor nedovolil změnit, dovolil vám jej úplně smazat nebo přesunout na jiné místo ve stránce, a aby se zaktualizoval, pokud změníte obsah stránky.

Může se zdát, že už chci po takovém systému moc, třeba tady v dikuzích ani blozích žádné šablony potřeba nejsou. Ale co když sem budu chtít implementovat funkci snadného vkládání odkazu do slovníku nebo FAQ? Už budu muset oželet to, že se mi text zobrazí skutečně tak, jak bude vypadat ve výsledku (tedy třeba odkaz na heslo ve slovníku a jako tooltip jeho vysvětlení), takže už to nebude tak úplně WYSIWYG, nebo budu muset zapomenout, že je to odkaz na heslo ve slovníku, a bude to prostě obyčejný odkaz s tooltipem – a až se změní URL slovníku, nebude mi stačit změnit v generátoru adresu, která se vygeneruje ze zdroje [slovník:heslo], ale budu muset změnit všechny komentáře v databázi.

[truhla]

Mně se nejvíc líbí způsob, jakým to má řešený WordPress, jeden z nejúspěšnějších systémů na vytváření webového obsahu na světě (Google: asi 67 600 000 na dotaz "powered by wordpress"). Tam je editor dvouzáložkový - jedna je WYSIWYG a druhá HTML. Váš příklad s _TOC_ byste nejspíš v editoru s WordPressovou filozofií řešil kliknutím na tlačítko TOC ve WYSIWYG editoru - na místě, kam jste vložil TOC, by se vám objevil ilustrační obrázek (stylizovaná ikona TOC). Kdybyste překlikl do HTML viděl byste na místě pro TOC komentář <!-- _TOC_ -->. (Alespoň takto to wordpress řeší u tagu more, který dělí příspěvek na úvod a zbytek.)

Pokud jde o slovník, tam by to šlo nepochybně řešit podobně.

A jedna mírně mimotématická věc: změna URL slovníku, na který odkazují příspěvky, by se kromě měnění všech příspěvků dala řešit i konfigurací serveru (u PHP např. .htaccess a mod_rewrite), aby se požadavek na starou URL přepsal na novou.

[Ash]

Bold není asi dobrý příklad, protože zvýzaznit "mohu" jako amatér v zásadě čímkoliv, třeba zvětšením fontu :), ale existující html značky pro důraz jsou strong nebo em, nikoliv bold, italics, nebo třeba class=important.

[Filip Jirsák]

Normálně je zvýraznění <em> což se zobrazuje většinou jako kurzíva, a <strong> (které se zobrazuje většinou jako tučné písmo) je silné zdůraznění, ale většina lidí má pocit, že zvýraznění přece musí být pořádně vidět, tak jaká pak kurzíva…

[petr_p]

V obecném případě máte jistě pravdu - písma jsou forma a obsah je citace, zdůraznění, příklad atd. Běžně se ale tenhle rozdíl úplně stírá. Napíšu-li něco bold, je to prostě zvýraznění a netřeba o tom přemýšlet.

A výsledkem jsou takováto zvěrstva.

Bold je poplatný době. Člověk který nikdy neviděl Word vůbec nepochopí, o co jde. Uvidíme za 20 let, co na to řeknou naše děti.