Webové technologie se stále vyvíjejí a prohlížeče přicházejí s novými a novými možnostmi. V dnešním článku si ukážeme, jak byly vyřešeny nedávno zmiňované bezpečnostní problémy v protokolu WebSocket, a představíme si jednu novinku, která by mohla zlepšit „prožitek“ z některých webových aplikací.
Když se občas na přednáškách ptám, jakou verzi HTML posluchači používají, jsem vždy překvapen tím, že naprostá většina se hlásí k XHTML. Při bližším ohledání stránek tvůrců v XHTML však vyjde najevo, že káží víno a pijí špinavou vodu. Svůj validní XHTML kód podsouvají prohlížeči se špatným MIME typem text/html a nutí jej používat parser HTML. HTML5 přináší některé změny syntaxe, které konečně umožňují tuto praktiku dělat tak, abychom se za ni nemuseli stydět.
HTTP je jedním z těch starých dobrých protokolů (jako třeba SMTP nebo POP3), u kterých člověk nepotřebuje žádný zvláštní klientský program a k tomu, aby se serverem navázal smysluplnou komunikaci a získal od něj odpověď, mu stačí telnet. V textu se podíváme na HTTP trochu techničtěji, „pod kapotu“.
V předchozím článku jsme podrobně probírali třídy Blob, File a metody rozhraní FileReader. Ukázali jsme si, jak v prohlížeči otevřít soubor, předaný buď pomocí drag-n-drop, nebo pomocí INPUT FILE. V dnešním pokračování si ukážeme možnosti vytváření souborů v prohlížeči a jejich ukládání, jak na server, tak na místní disk.
Před deseti lety bylo moderní dělat weby v XHTML a v tento jazyk byly vkládány velké naděje. Pak nastalo jisté vystřízlivění a s mohutnou propagací HTML5 v posledních několika letech i jisté zatracení XHTML. Nenechme se však zmást. HTML5 a XHTML se nevylučují, naopak specifikace HTML5 je v mnoha ohledech nejlepší specifikací XHTML, jaká kdy existovala.
HTML5 je nový standard, a ačkoli vychází z toho, co už všichni webdesignéři a kodéři dobře znají, tak jeho novinky, zejména tzv. „sémantické“ tagy, nemusí být vždy a za všech okolností jasně srozumitelné. V článku si ukážeme nejčastější situace, kde se právě při práci s těmito elementy nejčastěji chybuje.
Lámete si hlavu, jak vyřešit přístupnost vašeho webu pro mobilní zařízení? Nevymýšlejte kolo a podívejte se do tohoto Průvodce – připravil po vás seznam základních strategií při „mobilizaci“, jejich výhody, nevýhody a pár tipů, které oceníte nejen při návrhu mobilních webů.
Už několikrát jsme v článcích na Zdrojáku použili FileAPI, relativně novou součást webových technologií, která umožňuje číst, zpracovávat a ukládat soubory. V této minisérii se podíváme na nejrůznější nástroje a rozhraní, která využijete při zpracovávání souborů v prohlížečích, trochu podrobněji.
Možná znáte výrok: „Vesmír existuje, jen když se na něj někdo dívá“. Mottem dnes popisované novinky – Page Visibility API – by mohla být parafráze tohoto výroku, nějak takto: „Stránka pracuje, jen když si ji někdo prohlíží“. Jak to celé funguje a jaký to má praktický význam? Ukážeme si v článku.
Ve světě nových webových technologií se nashromáždilo zase několik drobností a novinek, o nichž jsme na Zdrojáku nepsali. Teď je vhodná příležitost to trochu napravit a na některé se podívat. Začneme datovými URL, které sice nejsou až taková novinka, ale někteří webdesignéři a kodéři o nich stále nevědí.
V předchozím díle jsme si na naší aplikaci s předpovědí počasí ukázali, jak vykreslit data pomocí Views a rozdělili jsme si HomeView do podrobnějších komponent. V tomto díle uděláme naši aplikaci pro uživatele zajímavější a přidáme možnost, jak zadávat lokalitu.
V nově vydaném Chromiu/Chromu 85 se objevila nenápadná CSS vlastnost, která může mít obrovský dopad na zrychlení načítání stránky. Zapisuje se jako „content-visibility“ a je to v současné chvíli nejjednodušší způsob, jak prohlížeči říct: „přeskoč vykreslování tohoto prvku, dokud to nebude nutné“.
Tento článek vznikl na základě podnětů k předchozímu článku o zprovoznění proxy serveru na Digital Ocean. V něm jsem zmiňoval, že proxy server rozhodně nenahrazuje VPN, které zajišťuje plně šifrovaný přístup. Podíváme se tedy, jak si zprovoznit vlastní VPN server.