HTML a CSS tvoří základ téměř každého webového rozhraní, které vytvářím.

HTML používám k definování struktury a významu, zatímco CSS řídí rozvržení, prezentaci, responzivitu a vizuální systém.

I když pracuji s WordPressem, Bricks Builderem, JavaScript frameworky nebo rozhraními ve stylu aplikací, HTML a CSS zůstávají pod vším ostatním.

Pro mě nejde o „základní frontendové technologie“.

Jsou vrstvou, která rozhoduje o tom, zda je web strukturálně správný, přístupný, responzivní, udržovatelný a rychlý.

Jak používám HTML a CSS

HTML a CSS používám například pro:

• kompletní rozvržení webů,
• responzivní rozhraní,
• design systémy,
• stylování komponent,
• WordPress šablony,
• úpravy Bricks Builderu,
• aplikační rozhraní,
• formuláře,
• dashboardy,
• obsahově rozsáhlé weby,
• interaktivní nástroje,
• přístupnost,
• optimalizaci výkonu.

Než přidám zbytečný framework nebo JavaScript, dávám přednost nativním možnostem webové platformy.

Sémantické HTML

Sémantické HTML používám všude tam, kde obsah má smysluplnou strukturu.

Patří sem například prvky:

• header,
• nav,
• main,
• section,
• article,
• aside,
• footer,
• nadpisy,
• seznamy,
• formuláře,
• tlačítka,
• odkazy.

Cílem není pouze to, aby stránka vizuálně vypadala správně.

Dokument musí dávat smysl také svou strukturou.

Sémantický markup zlepšuje:

• přístupnost,
• porozumění obsahu ze strany vyhledávačů,
• udržovatelnost,
• spolupráci s prohlížeči a asistivními technologiemi.

Struktura dokumentu

Stránka by měla mít jasnou hierarchii.

Věnuji pozornost:

• logickému pořadí nadpisů,
• smysluplným oblastem stránky,
• vhodné struktuře navigace,
• jasnému seskupení obsahu.

Vyhýbám se libovolným kontejnerům tam, kde existuje významově vhodnější HTML prvek.

Vizuální a dokumentová hierarchie by se měly navzájem podporovat.

Nadpisy

Nadpisy jsou strukturální prvky, ne zkratka pro stylování.

Používám je k vyjádření hierarchie dokumentu.

Například:

H1
→ téma stránky

H2
→ hlavní sekce

H3
→ podsekce

Úroveň nadpisu nevybírám jen proto, že má zrovna požadovanou velikost písma.

Typografie patří do CSS.

Význam dokumentu patří do HTML.

Tlačítka a odkazy

Rozlišuji mezi navigací a akcemi.

Odkaz slouží k přesunu někam jinam.

Tlačítko slouží k provedení akce.

Vyhýbám se klikacím prvkům typu div tam, kde už existuje nativní interaktivní prvek.

Správné HTML prvky automaticky poskytují užitečné chování, například:

• ovládání klávesnicí,
• práci s focusem,
• sémantiku.

Tím se snižuje množství vlastní práce potřebné pro zajištění přístupnosti.

Formuláře

Formuláře patří mezi oblasti, kde na správném HTML záleží nejvíce.

Používám:

• správně přiřazené popisky,
• vhodné typy vstupních polí,
• sémantiku povinných polí,
• srozumitelné validační zprávy,
• logické seskupení.

Vizuální placeholder nenahrazuje skutečný label.

Formuláře navrhuji tak, aby zůstaly srozumitelné i pro uživatele ovládající web klávesnicí nebo asistivními technologiemi.

Typy vstupních polí

Kde je to možné, používám nejvhodnější nativní typ vstupu.

Příklady:

email
url
number
date
tel

Správné typy vstupních polí mohou zlepšit validaci i chování mobilní klávesnice.

Nativní funkcionalita prohlížeče bývá často spolehlivější než ruční vytváření základního chování vstupních polí.

Přístupnost

Přístupnost začíná už u struktury markupu a layoutu.

Zohledňuji:

• sémantické prvky,
• ovladatelnost klávesnicí,
• viditelnost focusu,
• dostatečný kontrast,
• velikost dotykových cílů,
• škálovatelnou typografii,
• sémantiku pro screen readery.

Preferuji řešit přístupnost strukturálně místo přidávání velkého množství ARIA atributů jako kompenzace za nesprávně použité HTML.

Nativní sémantiku používám všude tam, kde je to možné.

ARIA

ARIA je užitečná tam, kde nativní HTML nedokáže plně vyjádřit požadované chování.

Používám ji opatrně.

ARIA by měla sémantiku doplňovat, ne zbytečně nahrazovat správné HTML.

U složitějších vlastních ovládacích prvků zohledňuji:

• role,
• popisky,
• stav rozbalení,
• stav výběru,
• live regions.

Pokud už nativní HTML prvek poskytuje potřebnou sémantiku, zpravidla mu dávám přednost.

CSS

CSS používám jako jazyk pro layout a design systém, ne jako soubor izolovaných vizuálních oprav.

Udržovatelný stylesheet by měl vyjadřovat konzistentní pravidla pro:

• typografii,
• rozestupy,
• layout,
• barvy,
• responzivní chování,
• stavy komponent.

Preferuji znovupoužitelné systémy před jednorázovými deklaracemi opakovanými napříč jednotlivými stránkami.

Moderní CSS

Moderní CSS dokáže vyřešit mnoho problémů, které dříve vyžadovaly značné množství JavaScriptu nebo externí frameworky.

Používám například:

• Flexbox,
• Grid,
• custom properties,
• clamp(),
• logické vlastnosti,
• media queries,
• moderní selektory.

Preferuji nativní layout engine prohlížeče před přidáváním složitosti v situacích, které CSS řeší samo.

Flexbox

Flexbox používám pro layouty, kde se prvky potřebují primárně zarovnávat podél jedné osy.

Typické příklady zahrnují:

• navigaci,
• skupiny tlačítek,
• řady karet,
• layout hlaviček,
• zarovnání uvnitř komponent.

Je obzvlášť užitečný tam, kde mají prvky dynamické rozměry.

Vyhýbám se ručním marginům a positioningu tam, kde Flexbox dokáže zamýšlený vztah vyjádřit přímo.

CSS Grid

CSS Grid používám pro layouty s výraznější dvourozměrnou strukturou.

Příklady zahrnují:

• kolekce karet,
• dashboardy,
• obsahové gridy,
• komplexní sekce stránek.

Grid umožňuje strukturu vyjádřit explicitně místo jejího simulování pomocí vnořených kontejnerů.

Typický responzivní grid se může automaticky přizpůsobovat dostupné šířce.

Grid a Flexbox dohromady

Grid a Flexbox nevnímám jako konkurenční technologie.

Řeší rozdílné problémy.

Stránka může používat Grid pro celkovou strukturu a Flexbox uvnitř jednotlivých komponent.

Volba správného layout modelu obvykle vede k jednoduššímu CSS.

Responzivní design

Layouty navrhuji podle dostupného prostoru, ne podle jednoho pevného rozměru zařízení.

Zohledňuji:

• úzké telefony,
• větší telefony,
• tablety,
• desktopové obrazovky,
• zoom,
• škálování písma.

Cílem není pouze přidat několik breakpointů.

Rozhraní musí zůstat použitelné i při změně prostředí.

Mobile-first design

Kde je to praktické, začínám základním layoutem a postupně ho rozšiřuji pro větší obrazovky.

To může vést k jednoduššímu CSS a pomáhá zajistit, že mobilní verze není pouze dodatečná úprava.

Konkrétní přístup ale vždy volím podle projektu.

Důležité je, aby mobilní chování bylo navržené záměrně a neřešilo se až na konci.

Fluidní layouty

Kde je to vhodné, preferuji flexibilní rozměry.

Místo spoléhání pouze na pevné pixely používám kombinace:

• procent,
• min(),
• max(),
• clamp(),
• flexibilních gridových stop.

Díky tomu se layout může přizpůsobovat plynule, ne jen skokově na několika libovolných breakpointech.

Fluidní typografie

Moderní CSS umožňuje škálovat typografii mezi rozumnou minimální a maximální velikostí.

Například:

font-size: clamp(1.8rem, 4vw, 3.5rem);

Výsledkem může být přirozenější škálování napříč různými velikostmi viewportu.

Zároveň stále hlídám, aby výsledek zůstal čitelný a předvídatelný.

Šířky kontejnerů

Čitelný obsah by se neměl jednoduše roztáhnout přes celý velký monitor.

Používám vhodné maximální šířky pro:

• text,
• formuláře,
• aplikační panely,
• full-width sekce.

Různé typy obsahu mohou vyžadovat různé limity šířky.

Například dlouhý text těží z více kontrolované délky řádku než datový dashboard.

CSS Custom Properties

CSS custom properties používám k vytváření sdílených designových hodnot.

Například:

:root {
    --space-sm: 0.75rem;
    --space-md: 1.5rem;
    --space-lg: 3rem;
    --radius-card: 1rem;
}

Tyto proměnné mohou reprezentovat:

• barvy,
• rozestupy,
• typografii,
• zaoblení,
• rozměry.

Díky tomu lze design systém měnit globálně mnohem jednodušeji.

Design tokeny

U větších projektů přemýšlím spíše v design tokenech než v izolovaných hodnotách stylů.

Token reprezentuje konkrétní designové rozhodnutí.

Například:

primární barva textu
barva povrchu
malý rozestup
velký rozestup
zaoblení karty
stupnice nadpisů

Komponenty pak tyto společné hodnoty využívají.

Výsledkem je mnohem konzistentnější rozhraní.

Typografie

Typografie je jedním z hlavních strukturálních nástrojů rozhraní.

Zohledňuji:

• velikost písma,
• výšku řádku,
• tloušťku písma,
• délku řádku,
• hierarchii,
• rozestupy.

Vyhýbám se definování typografie samostatně pro každý jednotlivý prvek.

Konzistentní typografická škála usnadňuje údržbu designu i CSS.

Výška řádku

Čitelný text potřebuje vhodné řádkování.

U běžného textu se vyhýbám příliš těsné výšce řádku.

Velké nadpisy naopak mohou těžit z kompaktnějšího řádkování.

Typografie by měla odpovídat typu obsahu, ne jedné univerzální hodnotě.

Barevné systémy

Definuji sémantické barvy místo nahodilých hodnot roztroušených po stylesheetu.

Například:

text-primary
text-muted
surface
surface-raised
accent
error

Díky tomu lze rozhraní v budoucnu snadněji měnit a přizpůsobovat tématům.

Význam barvy je užitečnější než její hexadecimální hodnota.

Tmavý režim

Kde je to vhodné, navrhuji barevné systémy tak, aby podporovaly světlé i tmavé téma.

Sémantické proměnné tento proces výrazně usnadňují.

Komponenty by neměly být závislé na předpokladech typu:

pozadí je vždy bílé
text je vždy černý

Měly by používat hodnoty definované na úrovni tématu.

CSS architektura

S růstem projektu začíná být organizace stylesheetů důležitá.

Preferuji jasné oddělení mezi:

• globálními základy,
• layoutem,
• komponentami,
• utility třídami,
• výjimkami specifickými pro jednotlivé stránky.

Vyhýbám se tomu, aby se stylesheet postupně změnil v nahromadění stále specifičtějších override pravidel.

Dobrá CSS architektura snižuje potřebu používat !important a eskalovat specificitu selektorů.

Specificita

Specificita CSS by měla být předvídatelná.

Preferuji znovupoužitelné třídy před hluboce vnořenými selektory, například:

.page .section .card .content span

Příliš specifické selektory komplikují budoucí změny.

Komponenta by měla být zpravidla stylovatelná pomocí jasného a relativně mělkého selektoru.

Vyhýbání se !important

!important používám pouze tam, kde pro to existuje jasný důvod.

Časté spoléhání na něj obvykle signalizuje problém se specificitou nebo architekturou.

Může komplikovat budoucí override pravidla a skrývat skutečnou strukturu stylesheetu.

Stylování komponent

Styly stavím kolem znovupoužitelných komponent.

Například:

.card
.card__title
.card__content
.card--featured

Konkrétní strategie pojmenování se může mezi projekty lišit.

Důležitý je princip jasně definované hranice komponenty a předvídatelných variant.

Utility třídy

Malé utility třídy mohou být užitečné pro běžné layoutové chování.

Příklady mohou zahrnovat:

• vizuálně skrytý text,
• pomocné třídy pro rozestupy,
• utility pro zarovnání.

Utility vrstvu udržuji pod kontrolou.

Pokud se každá vizuální vlastnost stane samostatnou utility třídou bez konzistentního systému, HTML může být obtížně čitelné.

CSS nesting

Tam, kde je podporovaný a vhodný, může moderní CSS nesting zpřehlednit organizaci souvisejících selektorů.

I tak se vyhýbám hlubokému vnořování.

Nesting by měl zlepšovat čitelnost, ne znovu vytvářet problémy vysoce specifických řetězců selektorů.

Logické vlastnosti

Logické CSS vlastnosti umožňují lépe přizpůsobit layout směru zápisu.

Místo uvažování pouze v pojmech fyzického „vlevo“ a „vpravo“ může moderní CSS pracovat s:

• inline start,
• inline end,
• block start,
• block end.

To je užitečné u rozhraní, která mohou potřebovat širší podporu lokalizace.

Internacionalizace

Různé jazyky mohou layout výrazně ovlivnit.

Přeložený text může být:

• delší,
• kratší,
• psaný opačným směrem,
• vykreslovaný jiným písmem.

Vyhýbám se návrhu komponent, které fungují pouze s jednou přesně dlouhou anglickou textovou hodnotou.

Layout by měl zvládat realistické rozdíly v obsahu.

Obrázky

HTML markup obrázků ovlivňuje použitelnost i výkon.

Zohledňuji:

• smysluplný alt text,
• vlastní rozměry obrázku,
• responzivní zdroje obrázků,
• lazy loading tam, kde je vhodný.

Prohlížeč by měl mít dostatek informací k rezervování prostoru v layoutu a výběru vhodného zdroje.

Responzivní obrázky

Různá zařízení nepotřebují vždy stejnou velikost obrázku.

Kde je to vhodné, používám mechanismy responzivních obrázků, aby si prohlížeč mohl vybrat odpovídající asset.

To může snížit zbytečný objem přenesených dat, zejména na mobilních zařízeních.

Aspect ratio

Kde to dává smysl, používám CSS vlastnost aspect-ratio k rezervování předvídatelného prostoru pro média.

To může omezit layout shifts během načítání.

Zároveň to usnadňuje správu responzivních kontejnerů pro obrázky a video.

Výkon

HTML a CSS přímo ovlivňují výkon frontendu.

Věnuji pozornost:

• velikosti DOMu,
• složitosti stylesheetů,
• nepoužívanému CSS,
• doručování obrázků,
• webovým fontům,
• layout shifts.

Přidávání dalšího markupu není bez nákladů.

Hluboce vnořený DOM může prodražit stylování i samotné vykreslování v prohlížeči.

Složitost DOMu

Page buildery usnadňují vytváření zbytečných wrapperů.

Snažím se proto držet markup tak mělký, jak to layout dovoluje.

Místo:

container
→ container
→ container
→ container
→ content

preferuji pouze takovou strukturu, která má skutečný účel.

Čistší markup se snáze kontroluje, styluje a udržuje.

Stabilita layoutu

Stránky by se během načítání neměly výrazně posouvat.

Layout shifts omezuji definováním předvídatelných rozměrů pro obsah, jako jsou:

• obrázky,
• embedy,
• dynamické sekce.

Stabilní stránka působí výrazně profesionálněji než stránka, na které se během načítání neustále přesouvají tlačítka a text.

Webové fonty

Fonty mohou mít výrazný vliv na načítání stránky.

Zohledňuji:

• kolik rodin písem je skutečně potřeba,
• kolik řezů se opravdu používá,
• fallback fonty,
• způsob načítání.

Design se automaticky nestává lepším jen proto, že stahuje mnoho souborů s fonty.

Výkon a vizuální kvalita musí být v rovnováze.

Nativní CSS před JavaScriptem

Mnoho typů chování rozhraní lze dnes realizovat přímo pomocí CSS.

Kde je to vhodné, preferuji CSS pro:

• layout,
• přechody,
• responzivní chování,
• jednoduché stavy.

JavaScript přidávám až tam, kde ho skutečně vyžaduje aplikační logika nebo interakce.

Omezení zbytečného JavaScriptu zpravidla vede k robustnějším rozhraním.

Přechody

CSS transitions používám pro jemnou zpětnou vazbu při interakci.

Příklady zahrnují:

• hover stavy,
• změny focusu,
• rozbalování vizuálních stavů,
• zpětnou vazbu tlačítek.

Přechody by měly podporovat interakci.

Vyhýbám se animování každé vlastnosti nebo zbytečnému zpomalování rozhraní.

Preference omezeného pohybu

Někteří uživatelé preferují omezené množství pohybu.

Pokud rozhraní používá výraznější animace, zohledňuji uživatelskou preferenci reduced motion.

Rozhraní musí zůstat srozumitelné i bez závislosti na animacích.

Hover stavy

Hover je užitečný na zařízeních s ukazatelem, ale neměl by být nutný pro základní funkcionalitu.

Dotyková zařízení neposkytují stejný model interakce.

Komponenty navrhuji tak, aby důležité akce zůstaly dostupné i bez hoveru.

Focus stavy

Uživatelé ovládající web klávesnicí potřebují viditelnou indikaci focusu.

Vyhýbám se globálnímu odstraňování focus outline bez dostupné náhrady.

Focus stav by měl být jasně viditelný a zároveň konzistentní s vizuálním systémem.

Pseudotřídy

Moderní pseudotřídy poskytují velmi silné možnosti stylování.

Používám je například pro stavy:

• hover,
• focus,
• checked,
• disabled,
• validation.

Vizuální stav tak může zůstat přímo propojený se sémantickým stavem prohlížeče.

Nativní stavy formulářů

Ovládací prvky formulářů v prohlížeči už samy zpřístupňují užitečné stavy.

Pomocí CSS komunikuji například:

• focus,
• neplatný vstup,
• disabled stav,
• checked stav.

Preferuji rozšiřování nativního chování před zbytečným nahrazováním každého formulářového prvku vlastní implementací.

CSS Grid pro aplikační rozhraní

Grid je obzvlášť užitečný pro aplikační layouty obsahující:

• postranní panely,
• toolbary,
• obsahové oblasti,
• datové panely.

Tyto layouty se mohou přizpůsobit z vícesloupcové desktopové struktury na jednodušší mobilní zobrazení bez výrazných změn podkladového HTML.

Sticky positioning

Sticky positioning používám tam, kde skutečně zlepšuje použitelnost.

Příkladem může být:

• navigace,
• hlavičky tabulek,
• kontextové ovládací prvky.

Vyhýbám se příliš velkému množství sticky prvků, zejména na malých obrazovkách, kde mohou zabírat cennou část viewportu.

Overflow

Scrollovatelný obsah vyžaduje promyšlenou práci s overflow.

Věnuji pozornost například:

• tabulkám,
• blokům kódu,
• horizontálním kolekcím,
• dialogům.

Neočekávané přetékání prvku mimo viewport je častým zdrojem problémů v mobilních layoutech.

Tabulky

Pro skutečná tabulková data používám HTML tabulky.

Nenahrazuji sémantické tabulky libovolnými grid layouty jen kvůli dosažení určitého vzhledu.

Pro úzké obrazovky navrhuji vhodnou responzivní strategii místo narušení vztahu mezi hlavičkami a daty.

Content-first layout

Preferuji, aby rozhodnutí o layoutu vycházela ze skutečného obsahu.

Design, který funguje pouze s dokonale zvoleným placeholder textem, často selže po vložení reálného obsahu.

Rozhraní testuji s:

• krátkým textem,
• dlouhým textem,
• chybějícím volitelným obsahem,
• přeloženými popisky.

Robustní layout by měl zvládat všechny tyto situace.

WordPress

HTML a CSS zůstávají zásadní i při práci s WordPressem.

Šablony a buildery nakonec vždy vytvářejí HTML, které vykresluje prohlížeč.

Porozumění tomuto generovanému výstupu mi umožňuje:

• diagnostikovat problémy s layoutem,
• zlepšovat sémantiku,
• optimalizovat responzivitu,
• omezovat zbytečný markup.

WordPress nevnímám jako černou skříňku.

Bricks Builder

Bricks Builder používám jako vizuální vývojovou vrstvu, přitom ale stále pracuji přímo s principy HTML a CSS.

Používám:

• sémantické prvky,
• globální třídy,
• CSS Grid,
• Flexbox,
• custom properties,
• vlastní CSS.

Vizuální editor urychluje vývoj, ale konečný výsledek stále určují podkladové technologie prohlížeče.

Advanced Custom Fields

ACF řídí strukturovaný obsah.

HTML a CSS určují způsob jeho prezentace.

Dynamické pole může obsahovat například:

• text,
• obrázek,
• metadata,
• vztahy.

Šablona stále potřebuje správný markup a layout pro prezentaci těchto dat.

WooCommerce

Rozhraní WooCommerce vyžadují pečlivou práci s HTML a CSS, protože e-commerce workflow musí zůstat použitelné a přístupné.

Věnuji pozornost:

• layoutu produktů,
• ovládacím prvkům variant,
• akcím v košíku,
• formulářům,
• checkoutu,
• validaci.

Vizuální úpravy by neměly zhoršit použitelnost transakčního procesu.

JavaScript

HTML, CSS a JavaScript mají rozdílné odpovědnosti.

Obecně o nich přemýšlím takto:

HTML
→ struktura a význam

CSS
→ prezentace a layout

JavaScript
→ chování a aplikační logika

V reálných projektech se tyto oblasti přirozeně částečně překrývají, ale jejich koncepční oddělení vede k čistším rozhraním.

Browser API

Při tvorbě aplikací běžících v prohlížeči poskytují HTML a CSS rozhraní kolem funkcionality založené na API, jako jsou:

• File API,
• Canvas,
• Web Workers,
• WebAssembly,
• Web Audio.

I technicky složité aplikace stále potřebují přehledný a dobře použitelný frontend.

Progressive enhancement

Kde je to vhodné, navrhuji rozhraní tak, aby jejich základní struktura zůstala použitelná ještě před přidáním pokročilé JavaScript funkcionality.

To může zlepšit:

• odolnost,
• přístupnost,
• kompatibilitu.

Ne každá aplikace může plně fungovat bez JavaScriptu, její HTML by ale stále mělo smysluplně reprezentovat rozhraní.

SEO

Struktura HTML přímo ovlivňuje schopnost vyhledávačů porozumět obsahu.

Věnuji pozornost:

• smysluplným titulkům,
• hierarchii nadpisů,
• sémantickému obsahu,
• interním odkazům,
• alternativním textům obrázků.

Vyhýbám se používání vizuální prezentace jako náhrady za strukturální význam.

Vyhledávače zpracovávají strukturu dokumentu, ne designový soubor.

Crawlability

Důležitý obsah by měl být reprezentovaný způsobem, kterému lze spolehlivě porozumět.

U obsahově rozsáhlých webů se bez reálného technického důvodu vyhýbám architekturám, které skrývají zásadní obsah za křehké chování čistě na straně klienta.

Implementace by měla podporovat jak uživatele, tak automatizované systémy, které web zpracovávají.

Udržovatelnost

Nejlepší HTML a CSS nejsou ta nejsložitější.

Preferuji implementace, ve kterých může další vývojář snadno pochopit:

• strukturu dokumentu,
• layout model,
• hierarchii komponent,
• designové proměnné.

Design systém by měl budoucí změny usnadnit, ne nutit vývojáře hledat mezi stovkami izolovaných override pravidel.

Kompatibilita prohlížečů

Moderní prohlížeče podporují stále schopnější webovou platformu.

Moderní CSS funkce používám tam, kde jsou vhodné pro cílové publikum.

U novější funkcionality zohledňuji:

• podporu prohlížečů,
• graceful fallback,
• zda je daná funkce skutečně potřeba.

Vyhýbám se zbytečným kompatibilitním hackům pro zastaralá prostředí, pokud je projekt výslovně nevyžaduje.

Ladění

Vývojářské nástroje prohlížeče jsou zásadní součástí mého workflow s HTML a CSS.

Používám je ke kontrole:

• struktury DOMu,
• vypočtených stylů,
• děděných vlastností,
• rozměrů layoutu,
• chování Gridu a Flexboxu,
• responzivních breakpointů.

Preferuji nalezení skutečné příčiny problému s layoutem před přidáváním náhodných override pravidel, dokud problém nezmizí.

Vyhýbání se CSS záplatám

Stylesheet se může postupně změnit v řetězec záplat:

původní pravidlo
→ override
→ mobilní override
→ pozdější override
→ !important

Tomuto vzoru se snažím vyhýbat.

Pokud je problém v samotné komponentě, preferuji opravit její strukturu nebo původní pravidlo místo nekonečného přidávání výjimek.

HTML & CSS v mém technologickém stacku

HTML a CSS běžně používám společně s technologiemi, jako jsou:

• JavaScript,
• TypeScript,
• WordPress,
• Bricks Builder,
• Advanced Custom Fields,
• WooCommerce,
• PHP,
• REST API,
• browser API,
• Three.js.

Tvoří strukturální a vizuální základ pod těmito technologiemi vyšší úrovně.

Proč používám HTML & CSS přímo

Frameworky, CMS platformy a vizuální vývojové nástroje používám tam, kde zvyšují produktivitu.

Pod nimi se ale stále spoléhám na znalost HTML a CSS.

Je to důležité, protože každé webové rozhraní se nakonec skládá z:

HTML
+
CSS
+
chování prohlížeče

Porozumění této vrstvě mi dává kontrolu nad sémantikou, přístupností, výkonem, responzivitou a udržovatelností.

Zároveň díky tomu nejsem závislý na builderu nebo frameworku při řešení každého frontendového problému.

HTML poskytuje strukturu.

CSS poskytuje vizuální systém.

Všechno ostatní na těchto základech staví.

Proto HTML a CSS považuji za základní inženýrské nástroje mého webového technologického stacku, nikoli za úvodní technologie, které s příchodem nástrojů vyšší úrovně přestávají být relevantní.