Každý článek o „nejrychlejším Python HTML parseru“ dřív nebo později zmíní selectolax a většinou to uzavře větou, že je „mnohem rychlejší než BeautifulSoup“. To je pravda. Co ale skoro nikdy nechybí, je srovnání se lxml — a právě tam se z jednoduchého tvrzení o „nejrychlejším“ stává složitější příběh.
Proto jsem ho otestoval pořádně: selectolax (oba backendy) proti lxml, BeautifulSoup s html.parser i s lxml, a také parselu, napříč pěti velikostmi stránek od 1 KB do 10 MB. Každé měření je medián ze tří samostatných běhů v oddělených procesech. Výsledek? selectolax jednoznačně porazil BeautifulSoup a s čistým lxml se dostal na podobnou úroveň — ale samotný krok parsování nakonec lxml přece jen vyhrálo. Všechna čísla níže jsou orientační a pocházejí z jednoho stroje (macOS arm64, Python 3.14.2); skripty jsou veřejně uložené, takže si je před citováním klidně spusťte i na svém zařízení.
Co selectolax vlastně je — a co není
selectolax je Python binding ke dvěma C enginům — Modest a Lexbor — které umí parsovat HTML5 a dotazovat se na něj pomocí CSS selektorů. Není to crawler, není to prohlížeč a není to „scraper“ ve smyslu nástroje, kam kliknete na tlačítko a ono vše udělá za vás. Je to vrstva, které předáte hotový HTML blob poté, co už jste stránku stáhli. Stručný popis od maintainerů zní: „Rychlý HTML5 parser s CSS selektory, napsaný v Cythonu a využívající enginy Modest a Lexbor.“
Existují dva backendy a rozdíl mezi nimi je důležitější, než napovídá dokumentace:
LexborHTMLParser(Lexbor engine) — ten, který README od roku 2024 doporučuje.HTMLParser(Modest engine) — původní varianta, jejíž podkladová C knihovna už podle stejného README „není nadále udržovaná“.
Než se dostaneme k rychlosti, pár faktů navíc. K datu snapshotu repozitáře 10. 7. 2026 měl selectolax 1 653 hvězdiček a poslední vydání bylo v0.4.10 (květen 2026). PyPI uvádí podporu pro Python >=3.9,<3.15. Instalace je na tomhle projektu ta nejméně dramatická část: pip install selectolax stáhl 2,3 MB předpřipravený cp314 wheel a na Pythonu 3.14 fungoval okamžitě — žádné stahování browseru, žádný doctor, žádná kompilace. To je tichá výhoda čistého parseru oproti nástroji napojenému na prohlížeč. Prostě se importuje a běží.
Ještě jedna licenční nuance, kterou je lepší říct hned: Python binding je pod MIT, ale wheel obsahuje zkompilované enginy a ty mají vlastní licence — Modest je LGPL-2.1, Lexbor je Apache-2.0. Tvrzení „selectolax je MIT“ je tedy pravdivé pro Python kód, ale neúplné pro binárku, kterou skutečně nasazujete. Pokud vaše právní oddělení řeší distribuované komponenty, je tohle detail, na který je potřeba upozornit.
Otázka rychlosti, tentokrát s reálnými čísly
Úloha, kterou jsem měřil: parsovat HTML string, vytáhnout veškerý text z <h3 class="title"> a všechny href z odkazů <a>. Latence je v milisekundách a je uváděná jako medián ze tří samostatných běhů v oddělených procesech; rozdíl mezi běhy se u C-backed parserů většinou držel pod ~5 %. Ještě před samotným měřením jsem výstupy každého parseru zredukoval na content hash, aby se odhalil případný parser, který potichu dělá méně práce — na testovaných stránkách se všech šest parserů shodlo ve všech velikostech, takže jde o férové srovnání jablek s jablky. Kompletní data jsou v uloženém souboru bench_parse.json.
| Stránka | selectolax (Lexbor) | selectolax (Modest) | lxml | parsel | BS (lxml) | BS (html.parser) |
|---|---|---|---|---|---|---|
| 1 KB | 0.027 | 0.029 | 0.036 | 0.044 | 0.281 | 0.323 |
| 10 KB | 0.160 | 0.171 | 0.166 | 0.228 | 1.705 | 2.049 |
| 100 KB | 1.464 | 1.565 | 1.423 | 2.020 | 16.5 | 20.6 |
| 1 MB | 14.901 | 16.9 | 14.177 | 20.9 | 181.9 | 232.6 |
| 10 MB | 159.9 | 247.9 | 172.9 | 231.9 | 2261.6 | 2788.7 |
Proti BeautifulSoup: zhruba 12–17x, a lidová moudrost to podhodnocuje
Když z toho uděláme poměry, selectolax-Lexbor vychází jako cca 12x rychlejší než BeautifulSoup(html.parser) na 1KB stránce a až zhruba 17x rychlejší na 10MB stránce, a zároveň cca 10–14x rychlejší než BeautifulSoup(lxml) ve stejném rozsahu. Často citované číslo — že je selectolax asi 4–5x rychlejší než BeautifulSoup — je vůči html.parser dost podhodnocené a odpovídá spíš variantě BeautifulSoup postavené na lxml. Skutečný násobek závisí na tom, kterou variantu BeautifulSoup myslíte a kolik dat z každé stránky skutečně vytahujete.
To zároveň sedí i s vlastním benchmarkem v README, který naznačuje náskok 25,5x oproti BeautifulSoup(html.parser). Ani jedno číslo není špatně. Úloha v README (titulek, odkazy, skripty a meta data z malých homepage) dělá méně extrakce na menších stránkách, takže režii BeautifulSoup převáží ještě víc. V praxi z toho vychází: selectolax je zhruba 10–15x rychlejší než BeautifulSoup u realistické práce typu parse + extract, ještě víc na malých stránkách a při lehčí extrakci.
Pokud je váš současný úzký profil plný kódu s BeautifulSoup, který žvýká stránky, tohle je migrace, která se sama zaplatí. Tohle není kontroverzní tvrzení. Další bod už je.
Proti lxml: remíza — a lxml vyhrává část, kterou většina testů zapomíná oddělit
Podívejte se zpět na řádky 100 KB a 1 MB. Lexbor a lxml jsou do sebe zapadlé v rámci ~5 %, jejich intervaly na jednotlivých bězích se překrývají a podle mojí metodiky je to remíza — žádný vítěz, žádné „rychlejší“. Jediné místo, kde selectolax skutečně ujede dopředu, je 10MB stránka (159,9 ms vs 172,9 ms, tedy rozdíl 8,1 % bez překrytí intervalů). U celé úlohy tedy selectolax lxml vyrovná a porazí ho jen na úplně největších dokumentech.
Pak jsem oddělil samotnou tvorbu stromu od CSS dotazů a výsledek se překlopil způsobem, který většina článků přehlíží. Pro čisté parsování, bez jakéhokoli dotazu, bylo lxml na tomto stroji konzistentně asi o 33–34 % rychlejší než selectolax-Lexbor — na 10MB stránce 77,9 ms vs 116,6 ms. V celé úloze se ty dva přirozeně sblíží, a moje pracovní hypotéza (ne něco, co bych prokázal atribučním experimentem) je, že na těchto stránkách tvoří CSS dotaz jen malou část celkového času, takže náskok lxml v parsování se zředí až do podoby remízy.
Tohle je nejzranitelnější tvrzení v celé recenzi, a říkám to otevřeně. Jde proti běžné moudrosti a jediný publikovaný benchmark, který jsem našel a který izoluje jen parsování — aows.jpt.sh — hlásí opak, tedy že selectolax je asi 4x rychlejší. Proto jsem to zarámoval opatrně: výsledek je z jednoho platformního prostředí (macOS arm64, Python 3.14, předkompilované cp314 wheely — Linux x86_64 ani build ze zdrojáků jsem netestoval), ověřený napříč čtyřmi velikostmi stránek a ve všech se opakoval, a navíc byl znovu zkontrolován dvěma různými lxml API, aby se vyloučil artefakt rozhraní. Obě lxml API byla ve všech velikostech rychlejší než selectolax-Lexbor. Netvrdím „lxml parsuje rychleji“ jako uzavřený fakt — říkám, že tohle vyšel můj benchmark, se skriptem přiloženým, navzdory většině publikovaných čísel. Otestujte si to sami.
Ještě jeden výřez: při dotazování 100 000 <a> na ploché stránce končí lxml a selectolax-Modest na remíze (33,30 ms vs 34,19 ms, intervaly se překrývají), zatímco selectolax-Lexbor za oběma zaostává asi o 15 %. Všechny tři C enginy spojuje to, že jsou 5–7x rychlejší než parsel nebo BeautifulSoup při hromadném výběru, kde je skutečnou brzdou model „jeden Python objekt na každý uzel“. Tvrzení „selectolax je nejrychlejší na bulk CSS selection“ tedy také neobstojí — Modest se pouze vyrovná lxml a Lexbor za ním zaostává.
Závěr, za který bych se podepsal: výhoda selectolax proti lxml není v plošné rychlosti celé úlohy. Vyhrává jen na úplně největší stránce. Jeho smysl je jinde — v ergonomii API, chování na špinavém vstupu a moderní CSS podpoře. A přesně tam se tento nástroj dostává do hry.
Paměť a cold start: hodnotit podle RSS, ne podle profileru
Paměť je oblast, kde musím opravit vlastní starší čísla, a právě to je pointa. Když jsem měřil rozdíl RSS na 10MB stránce s vypnutým tracemalloc, BeautifulSoup používal zhruba 1,5–1,8x více paměti než selectolax nebo lxml — od 1,51x (BS-lxml na 218,4 MB vs Lexbor na 144,6 MB) až po 1,75x v horní hranici. selectolax a lxml jsou v lehké kategorii; z nich je podle RSS nejekonomičtější lxml.
Předchozí měření mi vyšlo jako „asi 3x“, ale to bylo špatně z poučného důvodu: měřilo se s běžícím tracemallocem a jeho režie na jednotlivé alokace zhruba zdvojnásobuje zdánlivé RSS u parseru s nejvyšším počtem alokací. Takže doporučení pro kohokoli, kdo benchmarkuje paměť parserů: řaďte podle RSS a s vypnutým profilerem. Když člověk použije tracemalloc peak, zamíchá to pořadím C-backed parserů — konkrétně to dělalo z selectolax-Lexbor těžší variantu než Modest, přestože ve skutečném RSS jsou si blízko. BeautifulSoup je tady skutečně nejtěžší, jen ne o 3x, jak napovídal zkontaminovaný nástroj.
Cold start je menší, ale reálný faktor: selectolax se importuje zhruba za 14 ms, tedy přibližně stejně rychle jako lxml a asi 2,3x rychleji než bs4 nebo parsel. Pokud děláte CLI nástroj nebo serverless funkci, kde se čas importu počítá při každém spuštění, je to rozdíl, který stojí za zmínku.
Pokrytí CSS selektorů: silné, ale s několika skutečnými dírami
Pokrytí CSS jsem testoval v matici 41 případů, kdy byl každý selektor ověřen proti fixture s předem známou správnou odpovědí, a navíc ještě jednou v záměrně nepřátelském testu, který měl rozbít Lexbor. Každý případ běžel v samostatném subprocessu, což se nakonec ukázalo jako nutnost — jeden z nich totiž shodil celý interpreter. Výsledek:
| Engine | PASS | WRONG | UNSUPPORTED | PROCESS_ABORT |
|---|---|---|---|---|
| soupsieve | 41 | 0 | 0 | 0 |
| selectolax Lexbor | 39 | 0 | 2 | 0 |
| lxml (cssselect) | 37 | 1 | 3 | 0 |
| parsel (cssselect) | 37 | 1 | 3 | 0 |
| selectolax Modest | 35 | 3 | 2 | 1 |
Když do testu přidáte nepřátelské selektory, Lexbor už není absolutní vítěz — tím je soupsieve, které vyšlo čistě 41/41 oproti Lexborovým 39/41. Dvě chyby Lexboru jsou :lang(en) a :dir(rtl), které odmítne jako chybu parsování. Ve všem ostatním je přesný, včetně :has(), :is(), :where() a atributů necitlivých na velikost písmen.
Lexbor ale skutečně vyniká proti stacku cssselect. Vlajkový selektor z README — div > :nth-child(2n+1):not(:has(a)) — vrací správnou množinu na obou selectolax backendách i v soupsieve, ale špatnou množinu v lxml i parselu, a to bez jakéhokoli upozornění. Scraper, který tenhle selektor přenese do Scrapy nebo parselu, tak dostane tiše špatné výsledky. Pro přesnost: cssselect má :has() podporované od verze 1.2.0 (2022) a já testoval 1.4.0, takže nejde o „nepodporované“, ale o „podporované, jen špatně vyhodnocené“ složené pravidlo. To, že tenhle konkrétní compound vrací tichý chybný výsledek, není v trackeru cssselect, který uvádí limity :has() spíš jako vyvolané chyby. Lexbor navíc umí i case-insensitive atributový příznak [data-role="LEAD" i], který cssselect odmítne rovnou.
Jsou tu ale dva nedostatky, které rozhodnou o migraci. selectolax nepodporuje XPath vůbec — ani jeden backend nenabízí xpath() — a také neumí pseudo-elementy ::text / ::attr(), protože jde o rozšíření parselu/Scrapy, nikoli o skutečné CSS. Pokud vaše existující scrapery stojí na XPath, tohle je největší překážka; nepůjde jen o výměnu knihovny, ale o přepsání selektorů. Na druhou stranu Lexbor nabízí pseudo-class :lexbor-contains("text" i) pro case-insensitive vyhledávání textu, což lxml, parsel ani standardní CSS nenabízejí, a funguje přesně podle dokumentace.
Odolnost na ošklivém HTML, kde si selectolax vydělává body
Skutečné scrapingové projekty znamenají krmit parser špatnými daty a doufat, že nespadne. Otestoval jsem 18 nepřátelských vstupů a právě tady má selectolax proti lxml nejsilnější argument.
Když dáte lxml.html.fromstring prázdný string nebo jen whitespace, vyhodí ParserError("Document is empty"). Oba selectolax backendy naopak vrátí platný prázdný strom. Pro scraper, který prochází seznam URL a část odpovědí je prázdná, je to o jednu vrstvu try/except méně. selectolax také bez problémů zvládl 100 000 elementů bez přetečení zásobníku.
Nejostřejší rozdíl vyšla u hlubokého vnoření. Při 1 000 a 5 000 úrovních vnořených <div> lxml potichu zahodí nejhlubší obsah, zatímco selectolax ho zachová. libxml2 totiž omezuje hloubku parsování zhruba na 256 úrovní a strom usekne bez chyby, takže nejhlubší text je prostě nedostupný. Oba selectolax backendy vrátí celý strom. Je to zrcadlový obraz pasti s <template>, ke které se dostanu za chvíli: tam Lexbor zahazuje obsah, který ostatní zachovají; tady lxml zahazuje obsah, který selectolax zachová.
Ne všechno ale dopadlo ve prospěch selectolax. Backend Modest při zpracování :dir() ukončí celý Python interpreter signálem SIGABRT — nevyhodí exception, kterou by šlo zachytit, ale tvrdě zabije proces. To je reálná slabina pro kohokoli, kdo je stále na starém backendu, a přesně ten typ chyby, který zůstane neviditelný, dokud v noci ve 3:00 neskolí produkční job.
Dva tiché ztrátové scénáře, které je dobré znát před nasazením
Ani jeden z nich není moje objevná novinka — oba jsou zdokumentované upstream — ale oba umí potichu připravit o data, a v README to není vysvětlené dost nahlas.
Lexbor neprochází přes <template> uvnitř <a>
Na živé stránce MDN, kterou jsem testoval, selectolax-Lexbor našel 497 odkazů, zatímco lxml, oba backendy BeautifulSoup a dokonce i vlastní backend Modest našly 508. Chybějících jedenáct bylo přepínač jazyka a odkaz na diskuze, které ležely uvnitř elementů <template> (stránka používá web components Lit).
Důvod je legitimní: podle HTML5 specifikace se obsah <template> parsuje do samostatného inertního fragmentu, ne do běžného DOM, a Lexbor to striktně respektuje — tree.css("a") do obsahu template vůbec nesestupuje. lxml, oba backendy BeautifulSoup i Modest obsah template flattenují do hlavního stromu, takže ty odkazy najdou. Jde o zdokumentovaný open issue (selectolax#146, s kořenem v enginu na lexbor#170) a obě interpretace jsou obhajitelné — Lexbor je možná bližší specifikaci. Ale výsledek je pro vývojáře na doporučeném backendu tichá ztráta dat bez chyby. Naopak je fér říct i druhou stranu: ostatní parsery vám ukážou inertní template obsah, který browser nikdy nevykreslí, takže mohou vracet fantomová data, která uživatel ve skutečnosti nevidí. Spolehlivým únikem je pro tuhle konkrétní stránku backend Modest nebo jiná knihovna.
Ne-UTF-8 bytes tiše poškodí .text()
Když do selectolax pošlete bytes, které nejsou validní UTF-8, parsování projde — poškození se projeví až později, a je horší než čistý pád. U "<p>café éè</p>".encode("latin-1") vrací Lexbor v .text() náhradní znaky, Modest v .text() problémové bajty potichu zahodí, a oba enginy vyhodí UnicodeDecodeError až ve chvíli, kdy sáhnete na .html. Binding dekóduje při zpětném čtení jako striktní UTF-8, ne při parsování. Souvisí to s známým problémem selectolax kolem přísnosti encode/decode.
Oprava je jedna řádka a měla by se naučit nazpaměť: dekódujte bytes sami předem — LexborHTMLParser(resp.content.decode("latin-1")) — a oba enginy vrátí 'café éè' správně. V praxi tedy selectolax vždy předávejte str, nikdy syrové non-UTF-8 bytes. V README tohle není vysvětlené dost jasně.
Provozní aspekty v praxi (jednorázové měření, berte to orientačně)
Následující výsledky jsem měřil jednou, ne ve třech opakováních, takže je uvádím spíš jako signály než jako definitivní čísla.
Nejzajímavější je škálování přes vlákna. Při parsování 1MB stránky 48krát ve čtyřech vláknech ukázal selectolax zrychlení wall-clock času zhruba 3,5–3,9x — empirický podpis knihovny, která během C parsování uvolňuje GIL — zatímco BeautifulSoup(lxml) byl po vláknění několikanásobně pomalejší, což odpovídá serializaci práce přes GIL. lxml skončilo někde uprostřed a výsledek nebyl jednoznačný. Pro éru free-threadingu, do které Python směřuje, je to reálná, i když zatím orientační výhoda: selectolax se umí paralelizovat napříč vlákny tam, kde BeautifulSoup ne. Je to ale jedna konfigurace na jedné velikosti stránky a mechanismus je zatím hypotéza, ne něco, co bych potvrdil instrumentací C kódu.
K leakům: po 2 000 cyklech parse-extract-drop na 1MB stránce nevykázal ani jeden z parserů lineární růst RSS typický pro leak — každý se ustálil v omezeném pracovním rozsahu. Tohle měření považuji za důvěryhodné i proto, že jsem stejným nástrojem prohnal známý leak test a ten vystoupal přesně na +198 MB, takže bylo prokázáno, že nástroj leak vidět umí; u parserů ho ale nenašel. A také držadlo uzlu, které zůstalo naživu po odchodu stromu z rozsahu, bylo dál použitelné bez segfaultu. To vše je ale stále jen jednorázové měření, ne několikahodinový soak test.
Kam selectolax patří — a kde má předat štafetu
Všechno výše je o jedné jediné práci: proměnit HTML, které už máte, na strukturovaná data, a to rychle. V tom je selectolax výborný. Co naopak záměrně nedělá, je stahování stránky, vykreslování JavaScriptu, rotace proxy, řešení CAPTCHA nebo rozhodování, které elementy vlastně chcete. To všechno je pořád váš kód. selectolax je parsovací vrstva a netváří se, že je něco víc.
A právě tam nastupuje spravovaná extrakční služba jako nadstavba nad parserem, ne jako jeho náhrada. Pokud nechcete sami stavět a udržovat stack pro fetch/render/anti-bot/extract, Thunderbit to nabízí přes API, MCP server i CLI — POST /distill promění stránku na čistý Markdown a POST /extract vrátí strukturované JSON přesně podle schématu, přičemž renderování JS i anti-bot vrstvu vyřeší za vás. Je to jiná vrstva téhož problému: selectolax sáhnete ve chvíli, kdy už HTML máte a chcete syrovou rychlost parsování pod vlastní kontrolou; něco jako Thunderbit API, MCP server nebo CLI dává smysl tehdy, když chcete nechat na někom jiném stahování i extrakci a potřebujete jen hotová strukturovaná data. Není to výměna — je to jiná výška ve stejném stacku.
Vyzkoušet Thunderbit pro extrakci webových dat
Výhody, nevýhody a kdo by ho měl skutečně používat
Kde selectolax vyhrává:
- Zhruba 12–17x rychlejší než BeautifulSoup při realistické práci typu parse + extract, stabilně napříč třemi řády velikosti stránek.
- Úsporný v paměti (na úrovni lxml, asi o 1,5–1,8x lehčí než BeautifulSoup) a s importem kolem 14 ms.
- Dobře zvládá vstupy, které lxml rozbíjejí — prázdný obsah, whitespace a patologicky hluboké zanoření.
- Moderní CSS včetně
:has(),:is(),:where(), atributů necitlivých na velikost písmen a Lexbor-only:lexbor-contains(). - DOM API bezpečné vůči
None: chybějící elementy vracejíNonenebo[]místo výjimky a strom lze opravdu upravovat a znovu serializovat. - Aktivní údržba (v0.4.10, polovina roku 2026) a velmi jednoduchá instalace.
Kde nevyhrává:
- Není plošně rychlejší než lxml — v celé úloze je to remíza a v čistém parsování na mém testu lxml vyhrává.
- Nepodporuje XPath ani
::text/::attr()— pro scrapery postavené na XPath je to tvrdá migrační bariéra. - Dvě tiché pasti na ztrátu dat: obsah
<template>v Lexboru a ne-UTF-8 bytes přes.text(). - Backend Modest je starý a při
:dir()může shodit celý proces přes SIGABRT. - Všechna čísla zde jsou z jedné platformy (macOS arm64, Python 3.14) a jsou zatím orientační.
Máte selectolax používat? Ano, pokud chcete rychlost parsování na úrovni lxml, ale s přívětivějším, na None bezpečným API a výrazně lepším chováním na prázdném nebo rozbitém vstupu — a zároveň vám nevadí zůstat čistě v CSS světě. Pokud je váš kód postavený na XPath, náklady na přepis jsou reálné a je fér je přiznat. A pokud hledáte „absolutně nejrychlejší parser“, přesná odpověď z tohoto benchmarku je, že selectolax a lxml jsou dost blízko na to, aby rozhodovala ergonomie a odolnost, ne hrubá rychlost. A to je stejně lepší důvod pro výběr nástroje.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
Často kladené otázky
Je selectolax rychlejší než BeautifulSoup?
Ano, výrazně — přibližně 12–17x rychlejší než BeautifulSoup(html.parser) a 10–14x rychlejší než BeautifulSoup(lxml) u realistické úlohy parse + extract, a to stabilně od 1KB do 10MB stránek (macOS arm64, Python 3.14). Často citované „4–5x“ ten rozdíl vůči html.parser podhodnocuje.
Je selectolax rychlejší než lxml? Ne obecně. V celé úloze parse + extract vychází na 100KB a 1MB jako remíza, selectolax vyhrává jen na 10MB stránce. V čistém parsování bez dotazů bylo na mém stroji lxml dokonce asi o 33–34 % rychlejší — což je výsledek proti očekávání, ale je omezený na jednu platformu, takže si ho prosím ověřte na vlastním hardwaru.
Mám používat backend Lexbor, nebo Modest?
Téměř vždy Lexbor — je to udržovaný, plnohodnotný engine, který README doporučuje, a má lepší pokrytí CSS. Výjimkou je stránka, která schovává obsah uvnitř <template>; tam Lexbor podle specifikace ten obsah vynechá, zatímco Modest ho zachová. Modest má ale ostré hrany, včetně tvrdého pádu interpreteru na :dir().
Podporuje selectolax XPath?
Ne. Ani jeden backend nenabízí metodu xpath() — selectolax je čistě CSS-only. Pokud vaše scrapery stojí na XPath, migrace znamená přepis selektorů, což je největší náklad při přechodu z lxml nebo parsel stacku.
Proč je můj výstup ze selectolax rozbitý nebo mi chybí elementy?
Nejčastější jsou dvě příčiny. Pokud se text vrací s náhradními znaky nebo bez diakritiky, pravděpodobně jste předali syrové non-UTF-8 bytes — před parsováním je dekódujte na str (resp.content.decode("latin-1")). Pokud na moderním webu chybí odkazy nebo elementy, mohou být uvnitř <template> tagů, do kterých Lexbor nesestupuje; pro danou stránku použijte Modest nebo jiný parser.
