aus dem ma­schi­nen- und to­do-raum

felix schwenzel in über wirres

beim le­sen der fol­gen­den ar­ti­kel fie­len mir lau­ter klei­nig­kei­ten auf, die ich mal wie­der auf­schrei­ben woll­te.

I keep a list of things I want to do for KDO in Apple Notes, organized into four sections: small, medium, large, and longshots/obsolete.

Ich habe Ferien gemacht und einiges – ich kor­ri­gie­re: vieles – hier technisch auf Vor­der­mann gebracht.


die­ser ar­ti­kel wie­der­holt vie­les was ich ge­le­gent­lich schon mal auf­ge­schrie­ben habe und ist eher tech­nisch. also für die meis­ten hier mit­le­sen­den si­cher­lich un­in­ter­es­sant. ich habe aber trotz­dem das be­dürf­nis ge­habt, das al­les mal auf­zu­schrei­ben, so­zu­sa­gen als quar­tals­wei­se be­stands­auf­nah­me.


wenns ums ma­chen, kon­stru­ie­ren, her­stel­len geht ist das wich­tigs­te: gute werk­zeu­ge. aber gute werk­zeu­ge sind wie­der­um nichts wert, wenn man kei­nen plan hat, wenn man nicht weiss, was man mit den werk­zeu­gen her­stel­len oder for­men will. und zu wis­sen, was man ma­chen will ist wie­der­um we­nig wert, wenn man kei­nen blick fürs gros­se und gan­ze, für den kon­text hat.

wenn ich an mei­ner ei­ge­nen web­sei­te rum­bas­tel bin ich bau­herr, ar­chi­tekt, fach­in­ge­nieur, bau­lei­ter und hand­wer­ker in per­so­nal­uni­on. als bau­herr for­mu­lie­re ich an­for­de­run­gen und zie­le, als ar­chi­tekt ent­wick­le ich das ge­samt­kon­zept, soll­te aber im­mer auch den blick aufs gros­se und gan­ze ha­ben, also die web­sei­te, aber auch den kon­text (das web). als ar­chi­tekt und fach­in­ge­nieur soll­te ich wis­sen was ge­ra­de sta­te of the art ist und wie man ei­ner­seits er­prob­te tech­ni­ken an­wen­det und trotz­dem hier und da in­no­va­tiv sein könn­te. als hand­wer­ker soll­te ich die ge­eig­ne­ten werk­zeu­ge, lie­be zum hand­werk und sorg­falt mit­brin­gen.

na­tür­lich muss man das al­les nicht in per­so­nal­uni­on ma­chen, die klas­si­sche ar­beits­tei­lung funk­tio­niert wei­ter­hin. aber mir macht ge­ra­de das bas­teln an mei­ner web­site als ge­ne­ral­un­ter­neh­mer spass. oder ge­nau­er, der spass, die in­ter­ess­anz, steckt ge­ra­de im pro­zess, in der lang­fris­ti­gen in­ter­ak­ti­on der ver­schie­de­nen rol­len. ich als bau­herr habe stän­dig neue ideen und an­for­de­run­gen an die web­sei­te. ich als ar­chi­tekt er­fah­re stän­dig von neu­en tech­ni­ken, neu­en ma­te­ria­li­en, ef­fi­zi­en­te­ren ver­fah­ren. der fach­in­ge­nieur in mir sieht neue best prac­ti­ces, neue test­ver­fah­ren, neue nor­men, der bau­lei­ter ent­deckt im­mer wie­der neue be­gab­te hand­wer­ker oder mög­lich­kei­ten re­a­dy­ma­des ein­zu­set­zen.

ich ver­ste­he men­schen gut, die ein­fach ei­nen ort zum ab­len­kungs­frei­en schrei­ben ha­ben wol­len und sich ei­gent­lich um nichts an­de­res küm­mern wol­len. aber mich fas­zi­niert das stän­di­ges rum­bas­teln und aus­lo­ten der mög­lich­kei­ten.

mir fal­len beim schrei­ben stän­dig din­ge ein, die ich viel­leicht ha­ben kön­nen woll­te. fuss­no­ten, ver­knüf­pungs­mög­lich­kei­ten, die mir er­mög­li­chen din­ge bes­ser zu struk­tu­rie­ren oder sinn­voll zu ver­knüp­fen. mög­lich­kei­ten das ge­schrie­be­ne auch zu il­lus­trie­ren oder, je nach kon­text, auch mal an­ders zu ge­stal­ten. bei wie­der­keh­ren­den pro­ble­men fällt mir beim schrie­ben, nach dem hun­ders­ten stol­pern, plötz­lich eine lö­sung ein. oft schrei­be ich bei­trä­ge um ein tech­ni­sches fea­ture das mich fas­zi­niert aus­zu­pro­bie­ren.

eine web­sei­te wie eine woh­nung zu be­schrei­ben ist gar nicht so weit weg von der rea­li­tät. was man sich bei der pla­nung aus­denkt, funk­tio­niert im all­tag und im ver­lauf der zeit nicht im­mer so, wie man es mal ge­plant hat oder sich vor­ge­stellt hat. egal wie vie­le steck­do­sen man ein­ge­plant hat, am ende sind es im­mer zu we­ni­ge oder sie sind dann doch an den fal­schen stel­len. nut­zung ver­än­dert die an­for­de­run­gen. und der lu­xus dar­auf stän­dig re­agie­ren zu kön­nen ist (für mich) sehr be­frie­di­gend.


die to-do-lis­te bei kott­ke hat bei mir meh­re­re sai­ten klin­gen las­sen. ei­ner­seits weil sich ein paar der ideen von ihm mit mei­nen de­cken und an­de­rer­seits weil er hem­mungs­los gros­se und klei­ne to-dos auf eine lis­te setzt. und:

some of the pro­jects and site tweaks I most want to make aren’t even on my list. They live only in my head and I mull them over in the show­er or while wal­king un­til they’re “done” en­ough to start working on.

egal wie doll ich ver­su­che struk­tu­riert zu pla­nen und auf­zu­schrei­ben was ich mit die­ser web­sei­te ma­chen will, ein gross­teil der ideen will mei­nen kopf nicht ver­las­sen be­vor sie ei­nen ge­wis­sen rei­fe­grad er­reicht ha­ben. so­lan­ge schwir­ren sie zu­ver­läs­sig in mei­nem hin­ter­kopf her­um.

im fol­gen­den ein paar der din­ge die es im letz­ten jahr aus mei­nem kopf auf die web­sei­te ge­schafft ha­ben. da­nach ein paar din­ge die es aus mei­nem kopf in eine lis­te ge­schafft ha­ben.


syn­di­ka­ti­on

eine die­ser ideen oder eher eine der fra­gen die jah­re­lang in mei­nem kopf her­um­schwirr­te war: wie gehe ich mit in­sta­gram um? ei­ner­seits find ich meta doof und ver­ste­he in­sta­gram nicht mehr wirk­lich, an­de­rer­seits gibt es dort im­mer noch ei­ni­ge leu­te die sich of­fen­sicht­lich über fo­tos von mir freu­en und sich dort ger­ne her­um­trei­ben. aber weil in­sta­gram in den letz­ten jah­ren alle schot­ten ab­ge­dich­tet hat und es un­mög­lich ge­macht hat von dort ko­pien der ei­ge­nen posts für die ei­ge­ne web­sei­te zu zie­hen, wur­de das pos­ten dort zu ei­nem müh­se­li­gen ma­nu­el­len pro­zess. bis mir ir­gen­wann ein­fiel, dass man dort mit ei­nem „pro“-ac­count auch pro­gra­ma­tisch pos­ten kann. seit­dem schie­be ich in­sta­gram-posts ein­fach von mei­nem kir­by-ba­ckend per knopf­druck an, ko­pie­re also von hier nach da. da­mit blei­ben erst­mal alle me­ta­da­ten und ori­gi­na­le bei mir. in­sta­gram be­kommt ne ko­pie.

ge­nau­so ma­che ich es mit grain, fo­tos oder foto-se­ri­en schie­be ich se­lek­tiv von wir­res.net zu grain. grain ist üb­ri­gens ei­ner der we­ni­gen #AT­pro­to-diens­te, die mein in­ter­es­se seit mei­ner kur­zen eu­pho­rie­pha­se hal­ten konn­ten. den AT­pro­to-stan­dard-rea­der, in dem ich kurz­zei­tig ei­nen po­ten­zi­el­len nach­fol­ger des goog­le-rea­ders ge­se­hen habe, fin­de ich nach wie vor in­ter­es­sant, nut­ze ihn aber kaum noch. auch weil er (noch) so lang­sam wer­kelt, dass es die be­nutz­bar­keit und den be­die­nungs­spass stark ein­schränkt. aber grain ist toll, so wie frü­her mal in­sta­gram war: leu­te und de­ren fo­tos, um­ge­kehrt chro­no­lo­gisch sor­tiert. fer­tig.

mitt­ler­wei­le be­kom­me ich teil­wei­se bei grain (17 fol­lower) ge­nau­so vie­le ♥️ wie auf in­sta­gram (942 fol­lower). fürs glei­che bild. ab­surd. dar­an sieht man wie ab­ge­fuckt in­sta­gram mitt­ler­wei­le ist.

nicht sicht­ba­res de­sign

ro­man ja­siek schreibt, dass er sich ger­ne in vie­le klei­ne de­tails rein­stei­gert, „die ver­mut­lich kaum je­mand be­wusst wahr­nimmt“. das geht mir auch so.

screenshot einber überschrift mit einem anführungszeichen. das anführungszeichen ist nach links eingezogen, so dass die schrift der überschrift sich an der schrift des folgendes absatz ausrichtet.
  • zum bei­spiel zie­he ich an­füh­rungs­zei­chen in der ers­ten zei­le ei­ner über­schrift oder ei­nes ab­sat­zes ein stück­chen ein, so dass der text sich nach dem text aus­rich­tet und nicht nach dem satz­zei­chen. ich gehe da­von aus, dass so­was aus­ser mir nie­mand sieht. aber mich macht so­was froh.
  • oder über­gän­ge beim wech­sel/la­den von sei­ten mit den gross­ar­ti­gen view-tran­si­ti­ons die mitt­ler­wei­le von al­len brow­sern un­ter­stützt wer­den. zum ers­ten mal beim me­di­en­bä­cker ge­se­hen und gleich über­nom­men. mir gehts mitt­ler­wei­le so, dass die mir nur noch auf­fal­len, wenn ich sie mal aus­ver­se­hen ka­putt ma­che, weil ich am CSS rum­ge­spielt habe.
    absatz mit vier trennungen und 97 unsichtbaren, bedingten trennzeichen
  • sil­ben­tren­nung mit be­ding­ten trenn­stri­chen (soft hy­phens). alle tex­te wer­den html-sei­tig be­reits mit ­ an den stel­len die trenn­bar sind aus­ge­lie­fert, so dass brow­ser dann (re­la­tiv) zu­ver­läs­sig den text tren­nen kön­nen. das nervt zwar beim ko­pie­ren von text, weil die soft-hy­phens mit­ko­piert wer­den, aber wer mich un­be­dingt zi­tie­ren oder tei­le mei­ner tex­te ko­pie­ren will, kann je­der­zeit auf die mark­dow-ver­si­on wech­seln.
  • oder XLS-da­tei­en, mit de­nen mal xml-da­tei­en ge­stal­ten und struk­tu­riert dar­stel­len kann. das OPML-ge­döns, das ich von mat­thi­as pfef­fer­le über­nom­men habe, stylt die OPML-XML-da­tei­en zum bei­spiel mit so ei­ner XLS-da­tei (bei­spiel bei mat­thi­as oder hier). die­se wo­che bin ich via kott­kes-RSS-feed drauf ge­kom­men, dass man das auch mit RSS (oder atom) ma­chen kann. also hab ichs auch gem­cht: /feed oder /feed/bil­der. spä­ter hab ich ge­se­hen, mat­thi­as macht das (na­tür­lich) auch: no­tiz.blog/feed/. wer das rohe xml se­hen will kann im­mer noch den quell­code an­se­hen. aber ei­gent­lich sieht das al­les eh kei­ner.
    endmarken bei spiegel.de und wirres.met
  • ein like-but­ton kann auch eine end­mar­ke sein. bis ich drauf ge­kom­men bin, dass ich auch das was der spie­gel am ende sei­ner tex­te macht auch ma­chen kann, sind un­ge­fähr 12 mo­na­te ver­gan­gen. jetzt bin sehr zu­frie­den, dass der „like“ but­ton nicht mehr ir­gend­wo rum­hängt, son­dern sei­nen platz am tex­ten­de hat. un­sicht­bar ist er zwar nicht, aber so ob­skur, dass er wohl in 90 pro­zent der fäl­le igno­riert wird. und jetzt be­kommt man auch eine vi­su­el­le be­loh­nung, wenn man drauf klickt.
  • ich habe eine rück­sei­te und ar­ti­kel-bei­la­gen, weil ich die vor­der­sei­te mög­lichst — nun ja — mi­ni­ma­lis­tisch hal­ten will. ich fin­de sei­ten­leis­ten und wid­gets zwar prak­tisch, aber ei­gent­lich sind sie auch quatsch, weil das web heut­zu­ta­ge vor­nehm­lich mo­bil statt­fin­det und da sei­ten­leis­ten und wid­gets nicht auf den bild­schirm pas­sen auf ta­schen­rech­nern ans sei­ten­en­de rut­schen. ich mag die idee aus­schliess­lich den ei­gent­li­chen bei­trag zu zei­gen, mit den wich­tigs­ten meta-in­for­ma­tio­nen. da wo ich mich durch­ge­run­gen habe zu­satz­in­fos auf den vor­der­sei­ten an­zu­zei­gen (kom­men­ta­re, back­links, re­ak­tio­nen-zäh­ler), kann man sie auch zu­klap­pen mit dem ▶, bzw. ▼ — was dann auch im brow­ser ge­spei­chert wird.
  • auch nicht of­fen­sicht­lich, also qua­si un­sicht­bar: wenn man auf bil­der klickt, geht eine light­box mit dem bild auf mit der man das bild ver­grös­sern kann, wenn man will. und mit den pfeil­tas­ten (desk­top) oder wi­schend (mo­bil) kann man dann alle bil­der auf der sei­te durch­scrol­len, dank pre­fet­ching in ei­nem af­fen­zahn. selbst ma­che ich das ge­le­gent­lich sehr ger­ne auf mei­ner bil­der-über­sicht, qua­si mei­nem in­sta­gra­mer­satz.
  • la­de­ge­schwin­dig­keit sieht man auch nicht wirk­lich. was man sieht ist wenn die la­de­ge­schwin­dig­keit fehlt. auch wenn die­se sei­te nicht be­son­ders schlank ist, fühlt sie sich nach mei­nem ge­fühl — in der re­gel — sehr flüs­sig an und be­steht auch fast alle pa­ge­speed.web.dev-tests. ich möch­te auch nicht da­von ab­rü­cken 21 der neu­es­ten bei­trä­ge auf der start­sei­te kom­plett an­zu­zei­gen, ob­wohl das na­tür­lich kos­tet. 4,1 mb wiegt die start­sei­te beim in­itia­len la­den. wenn man die start­sei­te bis zum ende durch­scrollt, kom­men 10 mb zu­sam­men. ein jahr über­schrif­ten lädt da­ge­gen nur 203 kb (800 kb un­kom­pri­miert). im hin­ter­grund (un­sicht­bar) wer­keln da la­zy­loa­ding, src-sets und op­ti­mier­te bild­for­ma­te.
    pagespeed-test-ergebnis von wirres.net auf mobil-device; 80% (leistung), 91% (barrierefreiheit), 100% (best practices), 100% (SEO)
    pagespeed-test-ergebnis von wirres.net auf desktop-device; 99% (leistung), 91% (barrierefreiheit), 100% (best practices), 100% (SEO)
  • live fo­tos sind nicht un­sicht­bar, aber im bes­ten fall sind sie ein foto mit ei­ner sub­ti­len be­we­gung, so wie hier zum bei­spiel. bis­her habe ich ive-fo­tos in ei­nem lan­gen ma­nu­el­len pro­zess ver­ar­bei­tet: air­drop des live fo­tos auf mei­nen lap­top (kommt als .mov an), ein web-op­ti­mier­tes .mp4 und pos­ter .jpg mit pi­xel­ma­tor und me­diaCMS er­stel­len, mit ei­nem batch-script ein fall­back .gif er­stel­len und dann die­se drei da­tei­en im ba­ckend hoch­la­den und kon­fi­gu­rie­ren. nach­dem ich die­sen pro­zess über 12 mo­na­te op­ti­miert habe, hab ich mir ei­nen kir­by-block schrei­ben las­sen, der das al­les au­to­ma­ti­si­ert. jetzt muss ich nur noch den ge­air­dropp­ten .mov hoch­la­den, den rest er­le­digt kir­by ser­ver­seits.

op­ti­mie­run­gen

pa­ge­speed.web.dev ist von goog­le, aber trotz­dem ein un­ver­zicht­ba­res werk­zeug. ein paar op­ti­mie­rungs­vor­schlä­ge schla­ge ich kon­se­quent in den wind, des­halb der punkt­ab­zug bei der bar­rie­re­frei­heit und im mo­bi­len be­reich. aber wenn ich an der web­sei­te rum­fum­mel, schlei­chen sich un­wei­ger­lich ge­le­gent­lich feh­ler ein. vie­les da­von ent­de­cke ich dann mit hil­fe der Pa­ge­Speed In­sights. das werk­zeug hält mich qua­si auf dem stand der ak­tu­el­len best prac­ti­ces. die op­ti­mie­run­gen die aus sol­chen be­su­chen re­sul­tie­ren kom­men auch nicht nur goog­le zu­gu­te, son­dern je­dem be­su­chen­den, sei es eine ma­schi­ne oder ein mensch.

auch das habe ich schon öf­ter ge­schrie­ben, aber es ist und bleibt eins mei­ner lieb­lings­the­men: op­ti­mie­rung auf ma­schi­nen­les­bar­keit. auch hier ist mei­ne mo­ti­va­ti­on nicht pri­mär eine op­ti­mie­rung für goog­le, son­dern eben für alle. wer eins mei­ner re­zep­te in eine re­zept­ver­wal­tung wirft, soll­te ein gu­tes re­sul­tat be­kom­men. wer will kann die re­zep­te so­gar in mela abon­nie­ren. bing, kagi, per­ple­xi­ty kön­nen alle auf die struk­tu­rier­ten da­ten zu­grei­fen die ich hier an mei­ne bei­trä­ge hän­ge. aber so­weit ich das mit­be­kom­me, macht der­zeit ei­gent­lich nur goog­le da­von ge­brauch. ich mag was da­bei teil­wei­se raus­kommt.

zur op­ti­mie­rung ge­hört auch dar­auf zu ach­ten, dass die sei­te auch ohne css und js funk­tio­niert. das kon­trol­lie­re ich auch ge­le­gent­lich und ver­su­che die gröbs­ten feh­ler weg­zu­op­ti­mie­ren, wenn ich wel­che fin­de. das wür­de­vol­le ka­putt­ge­hen oder in web­dev-sprech: „graceful de­gra­da­ti­on“ ist eine der wich­tigs­ten lek­tio­nen aus mei­nem ar­chi­tek­tur­stu­di­um und dem rum­wü­ten in web­de­sgn-sphä­ren. auch in mei­ner schrei­ner aus­bil­dung ver­such­te ich so zu bau­en, dass mei­ne ar­bei­ten auch nach ei­nem ei­nen schlag mit nem ham­mer noch gut aus­se­hen. mau­er­werk al­tert wür­di­ger als vor­hang­fas­sa­den, ein mas­siv­holz­tisch wür­di­ger als ein span­plat­ten-tisch mit dün­nen, auf­ge­leim­ten fur­nier­kan­ten. die lis­te kann man un­end­lich wei­ter­füh­ren: putz / ta­pe­te, ge­öl­tes holz / la­ckier­tes holz, par­kett / la­mi­nat, ter­raz­zo / la­mi­nat, ver­schraubt / ver­klebt, …


  • css op­ti­mie­ren, ver­schlan­ken und pfle­ge­leich­ter ma­chen
  • eine idee, die ich auf ei­nem der letz­ten spa­zier­gän­ge hat­te: book­mark­vor­schlä­ge per web­men­ti­on an­neh­men. auf in­die­web­news kann man ei­nen link zur ei­ge­nen sei­te pos­ten, in­dem man ers­tens auf in­die­web­news linkt und zwei­tens ei­nen u-syn­di­ca­ti­on-link an­legt. wenn man dann ei­nen web­men­ti­on sen­det, lan­det ein link auf die ei­ge­ne sei­te auf in­die­web­news. so könn­ten mir auch an­de­re ins-in­ter­net-schrei­ben­de links in die le­se­zei­chen­samm­lung le­gen.
  • die­se mark­down check­lis­ten (* [ ]) im front­end kor­rekt ren­dern.
  • ein buch schrei­ben
  • mehr bü­cher le­sen
  • ein struk­tu­rier­tes, re­gel­mäs­si­ges ch­an­ge­log schrei­ben
  • ein ma­ni­fest schrei­ben, in dem alle fea­tures die­ser web­sei­te ge­ne­risch be­schrie­ben sind und nach dem man die­se web­sei­te fea­ture-com­ple­te nach­bau­en könn­te. wür­de wahr­schein­lich hun­der­te sei­ten lang wer­den und wer­de ich nie ma­chen. aber ich hät­te so ein ma­ni­fest ger­ne für mein al­tes wir­res.net ge­habt, dass ich vor an­dert­halb jah­ren nach kir­by mi­grier­te. es hat mich im­mer wie­der selbst er­staunt wie vie­le un­sicht­ba­re und sicht­ba­re fea­tures ich da über die jah­re ein­ge­baut hat­te. und ich habe nach an­dert­halb jah­ren im­mer noch nicht al­les re­kon­stru­iert.
  • mit RSS.chat rum­spie­len
  • mein blogroll-plug­in auch für an­de­re nutz­bar(er) ma­chen
  • isso-kom­men­ta­re auch ohne ja­va­script zu­gäng­lich ma­chen
  • über­schrif­ten und ab­sät­ze mit sprung­mar­ken ver­se­hen (bei mou­seo­ver: #). sieht viel­leicht ko­misch aus und nie­mand weiss wozu es dient, ge­hört aber auf die to-do-lis­te.
  • an­zei­ge im foo­ter in wel­cher stadt ich ge­ra­de bin. kann stim­men, muss aber nicht, steue­rung von mei­nem han­dy.
  • ein web­log-log das er­eig­nis­se wie pu­blish und edits er­fasst, aber viel­leicht auch shit­vo­tes und an­de­re li­kes. auf der rück­sei­te site weit, in der ar­ti­kel­bei­la­ge wer­den nur die ar­ti­kel-re­le­van­ten er­eig­nis­se an­ge­zeigt.

… wird fort­ge­setzt und er­gänzt. 

keine reaktionen
3 kommentare
Matthias Pfefferle
Ich habe bei Dave Winer gelesen, dass XSLT aus den Browsern entfernt werden soll.
Ich habe gerade alle XML Formate die ich in WordPress finden konnte, mit XSLT aufgehübscht und jetzt beschließen Google & Co. ernsthaft den Support einzustellen!?!?
Aber bevor ich weiter „rante“, hier ein kurzer Einschub was XSLT überhaupt ist: Mit XSLT lassen sich XML-Dateien in andere Formate umwandeln, zum Beispiel HTML. Man verlinkt dazu ein Stylesheet in der XML-Datei und der Browser übernimmt die Umwandlung. So wird aus einem RSS-Feed eine lesbare Webseite. Ohne JavaScript und ohne dass man dafür auf dem Server etwas installieren muss.
Für den Feed-Reader ändert sich dabei nichts. Der bekommt weiterhin die XML-Datei. Wenn ihr den Feed im Browser öffnet, seht ihr dagegen Beiträge, Links und eine Erklärung wie ihr ihn abonnieren könnt.
Ich benutze das hier seit einer ganzen Weile. 2020 hab ich meinen RSS-Feed mit XSLT und CSS gestaltet. Später kam die OPML-Ausgabe meines .well-known/feeds Plugins dazu. Und jetzt auch die OPML-Dateien meiner Blogroll. Screenshot des RSS-Feeds von notiz.blog im Browser, mit XSLT als lesbare Webseite dargestellt. Oben erklärt ein gelber Bereich mit RSS-Symbol, wie man den Feed abonniert. Darunter stehen das Blog-Logo, die Beschreibung und die neuesten Beiträge als anklickbare Links.
Bei OPML finde ich das besonders praktisch: Ihr klickt auf den Link und bekommt eine Liste von Blogs durch die ihr stöbern könnt. Die gleiche URL könnt ihr in euren Feed-Reader importieren. Man muss nicht einmal wissen was OPML ist um etwas damit anfangen zu können.
@ix hat auch gerade nochmal über seine Basteleien geschrieben. Er hübscht seine OPML-Dateien auch mit XSLT auf und inzwischen auch seine RSS-Feeds.
Die generelle Idee hinter XSLT erinnert mich sehr an den Microformats-Grundsatz:
Designed for humans first and machines second microformats.org
Bei Microformats ergänzt man das HTML einer Webseite so, dass auch Software etwas damit anfangen kann. Das gleiche HTML für Menschen und Maschinen. Bestehendes sinnvoll erweitern, mit dem arbeiten was schon da ist.
XSLT macht im Prinzip das Gleiche, nur aus der anderen Richtung:
Designed for machines first and humans second
Die XML-Dateien bleiben für Maschinen lesbar. Mit einem Stylesheet können aber auch Menschen etwas damit anfangen.
RSS und OPML sind ein wesentlicher Bestandteil des Open Webs. Wir verlinken sie an so vielen Stellen, weil wir wollen dass Besucher es einfach haben den Blog zu abonnieren oder weil wir ihnen neue Links vorschlagen wollen. Was sie in Zukunft sehen werden ist reines XML. Keine Möglichkeit irgendetwas zu erklären oder auf das Wesentliche aufmerksam zu machen! Nur XML!
Leider ist das auch keine rein theoretische Diskussion mehr. Stand 5. Oktober 2026: Chrome: XSLT ist bereits deprecated. Die Abschaltung ist für Chrome 158 am 17. November 2026 geplant. Befristete Ausnahmen für registrierte Websites und verwaltete Browser sollen am 17. August 2027 enden. Betroffen sind sowohl die Verknüpfung mit einem XSLT-Stylesheet als auch die JavaScript-API XSLTProcessor. Zeitplan von Chrome Firefox: Mozilla hat die Abschaltung für August 2027 angekündigt. Intent to Unship Safari/WebKit: WebKit unterstützt die Entfernung grundsätzlich, formuliert seine Zustimmung aber vorsichtig. Einen verbindlichen Abschalttermin habe ich in den geprüften Quellen nicht gefunden. WebKits Stellungnahme
Bei Chromium ist die Entfernung bereits beschlossen. Noch ist XSLT aber nicht aus allen Browsern verschwunden und auch die Änderung am HTML-Standard ist noch offen.
RSS, Atom und OPML funktionieren natürlich weiter. Entfernt wird die XSLT-Verarbeitung im Browser. Der Reader kann meinen Feed also weiterhin lesen, aber wer auf den Link klickt bekommt die XML-Ansicht.
Die Begründung der Browserentwickler sind Sicherheitslücken, Wartungsaufwand und geringe Nutzung. Das sind alles nachvollziehbare Argumente. Trotzdem finde ich den Verweis auf JavaScript und moderne Frameworks als Ersatz unbefriedigend. Ich hab eine XML-Datei und ein Stylesheet. Für das was ich damit machen will hat das bisher gereicht!
Was können wir stattdessen machen? XSLT mit JavaScript nachrüsten. Es gibt einen Polyfill mit WebAssembly, den man direkt in die XML-Datei einbindet. Der Browser führt damit das Stylesheet aus, der Reader bekommt weiterhin XML. Das könnte die bisherige Darstellung unter der gleichen URL erhalten. Allerdings dokumentiert das Projekt Unterschiede zur eingebauten XSLT-Verarbeitung, etwa beim Nachladen weiterer Dateien. Ob es mit meinen Stylesheets und den Readern funktioniert müsste ich ausprobieren. XML mit CSS gestalten. Das bleibt möglich. Die gleiche XML-Datei lässt sich damit im Browser lesbar darstellen, für Reader ändert sich nichts. CSS kann aber nicht alles was XSLT kann: Aus einer URL in einer OPML-Datei wird dadurch noch kein anklickbarer HTML-Link. Für eine einfache Ansicht kann es trotzdem reichen. HTML und XML unter der gleichen URL ausliefern. Mit Content Negotiation könnte der Server anhand des Accept-Headers entscheiden welche Version er zurückgibt. Nur für die HTML-Version würde ich XSLT auf dem Server ausführen, Reader müssten weiterhin das ursprüngliche XML bekommen. Eine zusätzliche öffentliche URL braucht es dafür nicht. Der Haken: Browser und Reader lassen sich über den Header nicht zuverlässig auseinanderhalten. Das müsste ich mit verschiedenen Readern testen. Caches brauchen außerdem Vary: Accept damit sie die Versionen nicht verwechseln.
Ganz ehrlich? Das ist alles 💩 und keine wirkliche Alternative!
Gewöhnt euch lieber schon mal wieder an XML!