RSS

Czy naprawdę nikt nie chce kodować w HTML?

Liczba odsłon: 218

Standard za­pi­su tek­stu Mark­down zdo­by­wa co­raz więk­szą po­pu­lar­ność. Pozwala za­pi­sy­wać tekst w prost­szy i bar­dziej przej­rzy­sty spo­sób niż ję­zyk HTML. Niektó­rzy twier­dzą na­wet, że dni zna­jo­moś­ci ję­zy­ka HTML wśród auto­rów za­war­toś­ci stron WWW są po­li­czo­ne. Problem w tym, że Mark­down ma spo­ro ogra­ni­czeń i na ra­zie nie mo­że stać się na­praw­dę uni­wer­sal­nym stan­dar­dem, a bar­dziej po­waż­ne za­sto­so­wa­nia i tak wy­ma­ga­ją się­ga­nia po znacz­ni­ki HTML.

Z pew­nym nie­po­ko­jem prze­czy­ta­łem ar­ty­kuł Mark­down throw­down: what hap­pens when FOSS soft­wa­re gets cor­po­ra­te back­ing, opu­bli­ko­wa­ny w ser­wi­sie Ars Technica. Jego Autor rzu­ca od­waż­ną te­zę: […] Innymi sło­wy, pi­sa­nie w ję­zy­ku HTML nie jest skom­pli­ko­wa­ne. Jest po pros­tu uciąż­li­we. Wpisywa­nie tych wszyst­kich znacz­ni­ków sta­wia mur mię­dzy to­bą a two­imi my­śla­mi. Nikomu nie chce się prze­cież wsta­wiać <p> na po­cząt­ku każ­de­go aka­pi­tu a po­tem </p> na koń­cu, po pros­tu chce­my na­ci­snąć Return i kon­ty­nu­ować pi­sa­nie […].

Owszem, gdy­by tak moż­na by­ło pi­sać, to by­ło­by cu­dow­nie. Autor cy­to­wa­ne­go tek­stu nie bie­rze jed­nak pod uwa­gę, że moż­na tak ro­bić tyl­ko w naj­prost­szych, naj­mniej wy­ma­ga­ją­cych przy­pad­kach. Na przy­kła­dzie te­go krót­kie­go tek­stu po­ka­żę, że Mark­down nie speł­nia wy­mo­gów każ­de­go twór­cy WWW, któ­ry ma po­nad­prze­cięt­ne ocze­ki­wa­nia.

Każdy ser­wis WWW ma swo­je wy­mo­gi co do za­miesz­cza­ne­go tek­stu. Oczywiś­cie, do­brą prak­ty­ką jest za­pi­sy­wa­nie jak naj­bar­dziej ogól­ne­go, „czys­te­go” ko­du HTML i ta­kie przy­go­to­wa­nie ar­ku­sza sty­lu CSS, by właś­ci­wie for­ma­to­wał ten kod w za­leż­noś­ci od kon­tek­stu. Nie zaw­sze jed­nak jest to moż­li­we i auto­rzy tek­stów zna­ją naz­wy klas sty­lu, któ­re po­win­ni sto­so­wać, by pew­ne ele­men­ty wy­róż­niać wy­glą­dem. Mark­down nie prze­wi­du­je klas sty­lu: aby z nich sko­rzys­tać, na­le­ży osa­dzić w tekś­cie znacz­ni­ki HTML. Mój CMS ma ogra­ni­czo­ną do mi­ni­mum licz­bę wy­ma­ga­nych sty­lów, jed­nak „wstęp­niak” ar­ty­ku­łu, pi­sa­ny nie­co po­więk­szo­ną i po­gru­bio­ną czcion­ką, wy­ma­ga za­sto­so­wa­nia kla­sy in­tro. Gdybym pi­sał tek­sty w ję­zy­ku Mark­down, mu­siał­bym al­bo osa­dzać w tekś­cie znacz­ni­ki HTML w tym jed­nym aka­pi­cie, al­bo two­rzyć skrypt, któ­ry od­po­wied­nio tłu­ma­czył­by wy­ni­ko­wy kod zgod­nie z po­trze­ba­mi sys­te­mu za­rzą­dza­nia treś­cią.

Dociekli­wi mo­gą też spraw­dzić, że wszyst­kie an­giels­kie wy­ra­zy uży­te w tym tekś­cie, włącz­nie z sa­mą naz­wą ję­zy­ka Mark­down, są za­pi­sa­ne w od­ręb­nych znacz­ni­kach uzu­peł­nio­nych atry­bu­tem lang="en", za­zna­cza­ją­cych je ja­ko róż­nią­ce się ję­zy­kiem od resz­ty ar­ty­ku­łu. Twórcy anglo­ję­zycz­nych stron WWW naj­częś­ciej nie ma­ją te­go prob­le­mu, za­tem na­wet nie myś­lą o nim. Oczywiś­cie, moż­na nie ozna­czać właś­ci­wie ję­zy­ka ob­co­ję­zycz­nych wy­ra­zów, jed­nak, kon­ty­nu­ując ten tok myś­le­nia, moż­na by myć zę­by szczot­ką do czysz­cze­nia ubi­ka­cji. Po pros­tu pew­ne rze­czy na­le­ży al­bo ro­bić po­rząd­nie, al­bo w ogó­le.

Dotyczy to też choć­by cy­ta­tów. Gdy cy­tu­ję frag­ment tek­stu po­cho­dzą­cy z in­nej stro­ny WWW (w ory­gi­na­le lub prze­tłu­ma­czo­ny), sto­su­ję ele­ment <q> ję­zy­ka HTML. W ten spo­sób ułat­wiam auto­ma­tycz­ną ana­li­zę stro­ny, po­zwa­lam od­szu­kać tekst ory­gi­na­łu, a prze­de wszyst­kim uni­kam ja­kich­kol­wiek po­są­dzeń o na­ru­sza­nie praw autor­skich lub pla­giat. Mark­down ob­słu­gu­je cy­to­wa­nie tyl­ko w pod­sta­wo­wym za­kre­sie, ja­ko wy­róż­nie­nie aka­pi­tu tek­stu, nie po­zwa­la jed­nak wtrą­cać cy­ta­tów w środ­ku aka­pi­tu ani po­da­wać od­noś­ni­ków do cy­to­wa­ne­go tek­stu.

W tekś­cie sto­su­ję też zna­ki spe­cjal­ne, ta­kie jak cu­dzy­sło­wy dru­kars­kie, wie­lo­krop­ki czy pau­zy i pół­pau­zy. Zawiera­ją­cy je tekst du­żo bar­dziej przy­po­mi­na tekst dru­ko­wa­ny i jest łat­wiej­szy i mil­szy w czy­ta­niu. Standard Mark­down nie prze­wi­du­je spe­cjal­nej ob­słu­gi ta­kich zna­ków spe­cjal­nych: al­bo trze­ba je osa­dzać ręcz­nie ja­ko en­cje HTML lub zna­ki Uni­code, al­bo pi­sać włas­ny skrypt, któ­ry do­ko­na od­po­wied­nie­go tłu­ma­cze­nia. Ja aku­rat po­szed­łem tą dru­gą dro­gą: zna­ki spe­cjal­ne za­pi­su­ję po­dob­nie jak w sys­te­mie LaTeX i ko­rzy­stam z włas­ne­go skryp­tu do­ko­nu­ją­ce­go auto­ma­tycz­nej za­mia­ny.

Proble­mem jest na­wet spac­ja nie­łam­li­wa. Mark­down nie ob­słu­gu­je te­go zna­ku, na­le­ży za­tem osa­dzać go ja­ko en­cję HTML lub znak Uni­code. Ja wsta­wiam nie­łam­li­we spac­je ja­ko zna­ki pod­kreś­le­nia (_), co ma tę wiel­ką za­le­tę, że po­zwa­la edy­to­wać ład­nie sfor­ma­to­wa­ne tek­sty do­wol­nym edy­to­rem, w do­wol­nym sys­te­mie opera­cyj­nym i przy do­wol­nym ukła­dzie kla­wia­tu­ry. Skrypt za­mie­nia po­tem te zna­ki na właś­ci­we en­cje HTML. Niestety, Mark­down trak­tu­je znak _ ja­ko wy­róż­nik for­ma­to­wa­nia tek­stu.

Niezręczne jest też to, że Mark­down nie jest jed­nym spój­nym stan­dar­dem. Istnieje oczy­wiś­cie orygi­nal­na im­ple­men­tac­ja, jed­nak jej nie­ścis­ło­ści i ogra­ni­cze­nia spo­wo­do­wa­ły, że po­wsta­ło wie­le mniej lub bar­dziej zgod­nych od­mian, wpro­wa­dza­ją­cych włas­ne zmia­ny i roz­sze­rze­nia. Spory po­stęp sta­no­wi po­ja­wie­nie się od­mia­ny Common­Mark, któ­rej ce­lem jest ze­stan­da­ry­zo­wa­nie spo­so­bu in­ter­pre­to­wa­nia tek­stu, udo­ku­men­to­wa­nie go i udos­tęp­nia­nie wzor­co­wej im­ple­men­tac­ji. Niestety, ist­nie­ją­ce sys­te­my wciąż uży­wa­ją róż­nych dia­lek­tów.

Przez chwi­lę za­sta­na­wia­łem się nad sto­so­wa­niem ję­zy­ka Mark­down do pi­sa­nia tek­stów na mo­ją stro­nę WWW. Przepro­wa­dzi­łem na­wet eks­pe­ry­ment po­le­ga­ją­cy na na­pi­sa­niu ca­łe­go ar­ty­ku­łu w Mark­down, prze­two­rze­niu go na HTML i sko­ry­go­wa­niu tak, by speł­niał wy­mo­gi mo­je­go CMS. Dostrzeg­łem pew­ne za­le­ty ta­kie­go po­dej­ścia: edy­tor tek­stu (po za­in­sta­lo­wa­niu od­po­wied­nie­go pa­kie­tu for­ma­tu­ją­ce­go) po­tra­fił (choć z pew­ny­mi błę­da­mi) pod­świet­lać for­ma­to­wa­nie wy­róż­nia­ne­go tek­stu, a sam tekst wy­glą­dał nie­co bar­dziej przej­rzyś­cie, niż za­pi­sa­ny bez­po­śred­nio w HTML. Jednak po kon­wer­sji oka­za­ło się, że mu­szę wpro­wa­dzać do ko­du na­praw­dę du­żo po­pra­wek, by na­da­wał się on do bez­po­śred­niej publi­kac­ji.

Wiele ele­men­tów mu­sia­łem też wciąż za­pi­sy­wać wprost w ję­zy­ku HTML. Pisze o tym zresz­tą rów­nież Autor cy­to­wa­ne­go ar­ty­ku­łu: […] Na przy­kład, przez 10 lat ko­rzy­sta­nia z Mark­down nig­dy nie uży­łem skład­ni osa­dza­nia obra­zów te­go ję­zy­ka. Jak dla mnie, ta skład­nia nie jest ani bar­dziej czy­tel­na, ani łat­wiej­sza w za­pi­sie niż znacz­nik <img> ję­zy­ka HTML. Stosuję za­tem znacz­nik HTML. […]. Jeżeli stan­dard nie jest w sta­nie uwzględ­nić ol­brzy­miej więk­szoś­ci uży­wa­nych ele­men­tów i ułat­wić ko­rzy­sta­nia z nich, to wed­ług mnie coś jest z nim jed­nak nie tak. Cóż bo­wiem z te­go, że […] Mark­down jest bar­dzo elas­tycz­ny — być mo­że na­wet zbyt elas­tycz­ny […], je­że­li zwięk­szo­ną czy­tel­ność i łat­wość za­pi­su mo­gę sto­so­wać tyl­ko w nie­któ­rych frag­men­tach tek­stu?

Nie za­mie­rzam za­tem ani re­zyg­no­wać z pi­sa­nia w ję­zy­ku HTML, ani z nau­cza­nia te­go ję­zy­ka i „ewan­ge­li­zo­wa­nia” w za­kre­sie je­go uży­wa­nia. Uważam, że tekst za­pi­sa­ny w HTML rów­nież mo­że być pros­ty w za­pi­sie i czy­tel­ny i wy­star­czą do te­go pros­te skryp­ty do­ko­nu­ją­ce me­cha­nicz­nej za­mia­ny do­dat­ko­wych znacz­ni­ków na dłuż­sze i fak­tycz­nie mniej czy­tel­ne frag­men­ty „czys­te­go” HTML.