22.02.2024 16:15 :has je funkční selektor, který můžeme mimo jiné použít jako selektor rodiče, tedy vybrat rodičovské prvky, obsahující potomky určitého typu: a:has Tento selektor cílí na všechny odkazy , které mají v DOMu jako potomka obrázek . Je to selektor rodiče. Ale taky nemusí být. Selektor :has od 19. 12. 2023, tedy vydání Firefoxu 121, podporován všemi prohlížeči. Fanfáry prosím! Nejen selektor rodiče Selektor :has je součástí návrhu specifikace W3C Selectors Level 4. Patří mu velká pozornost, protože jednou z možností jeho použití je právě selektor rodiče. Co je selektor rodiče? To je v CSS už asi dvacet let něco jako banány za komunistů. Lidé to strašně moc chtějí, stáli by na to fronty, ono se to občas někde objeví, ale zpravidla je to planý poplach. Tak teď už jsou banány na skladě a pro každého. Jenže :has ve skutečnosti selektor rodiče není. Doslovně, přesně podle specifikace, jde o relační pseudotřídu . Relační proto, že do závorek můžete napsat jakýkoliv relativní selektor, se vztahem k selektoru před dvojtečkou: a:has section:has img:has Všimněte si posledního případu. Vybírá prvního z bezprostředně navazujících sourozenců v DOMu. Tady o selektoru rodiče nemůže být řeč. Navíc je to užitečné a skoro stejně nedostatkové jako ty banány za komunistů. Nebo jako selektor rodiče v CSS. Ukázka se selektorem rodiče Podívejme se na následující CodePen. Jsou v něm dva prvky .box. Jeden obsahuje obrázek a jeden pouze text: Lorem ipsum… Quam doloremque… Relační pseudotřídou :has se pak snažím zacílit boxík s obrázkem: .box:has Výsledek uvidíte níže. Ukázka se selektorem předchozího sourozence V tomto demíčku se zaměříme na stylování prvků v textu, za nimiž následují jiné specifické prvky. Máme dva nadpisy, za jedním následuje odstavec, za druhým seznam položek: Lorem ipsum, dolor sit amet Lorem… Quam doloremque… Lorem… Pokud bychom ten druhý nadpis chtěli stylovat jinak, opět nemusíme složitě přidávat třídu. Prostě jen použijeme relační pseudotřídu :has: h2:has Na živo zde: Další možnosti, občas dechberoucí Když jsem procházel, co se selektorem :has vykouzlili jiní autoři, občas mě srdíčko poskočilo radostí. O jejich nápady se s vámi musím podělit, v tomto případě hlavně o nápady Matthiase Otta. form:has form:has figure img:has .grid:has :last-child) Všimněte si hlavně té poslední ukázky. Rozložení v CSS layoutu upravujeme počítáním prvků uvnitř. Jde o aplikaci takzvaných quantity queries, které už před lety popsal Heydon Pickering. Prostě můžete změnit layout podle toho, kolik je v něm položek. Kurnik šopa, proč já už vlastně nekóduju weby? Další zajímavé tipy přidal například na X/Twitteru Wes Bos u příležitosti plné podpory selektoru :has ve všech prohlížečích. Uvedu pár příkladů: The Anywhere Selector - Např. pokud je v zaškrtnutý checkbox, můžete vzít jakýkoli jiný prvek a nastylovat jej. Layout Targeting – Na základě struktury obsahu stránky mohu měnit rozvržení. All Siblings – Když na potomka najedete kurzorem, vybere všechny ostatní elementy. Máte jiný zajímavý příklad použití? Napište mi, přidám jej do článku. Podpora v prohlížečích Podpora je v prosinci 2023 plná. Firefox se přidal čerstvě, takže budeme muset chvilku počkat, než vymřou jeho starší verze. CanIUse: caniuse.com/css-has Pokud tedy začínáte nový projekt, nemusíte s použití příliš váhat. V mezičase může být užitečná detekce prohlížeče, které :has neumí. Prostě využijeme dotaz na podporu @supports: @supports selector ) Nevím jak vy, ale já mám z podpory :has v prohlížečích fakt radost. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
21.02.2024 07:00 INP je nová metrika rychlosti webu, se kterou přichází Google v rámci své sady Core Web Vitals. V 12. března 2024 nahrazuje dnes už neuspokojivou metriku FID . Tato změna se dotkne celé řady z vás, protože INP je metrika daleko přesnější a k webům přísnější. Metrika INP měří časový úsek, který trvá reakce uživatelského rozhraní na kliknutí nebo jiný vstup uživatele v rámci webové stránky. Měří se jen interakce, které uživatele nepřenášejí na nové URL, tedy klikání na UI komponenty typu tlačítka, modální okna, přidávání do košíku, karusely, filtrování v e-shopech… Těch problémových míst může být celá řada. Problém je samozřejmě hlavně v JavaScriptu a jeho pomalém vykonávání, občas také v Ajaxu nebo Fetch, tedy stahování dat ze serveru. Poznámky k nadcházející výměně FID za INP Prodlevy způsobené JavaScriptem budou více vidět. A pro některé vývojáře to může znamenat docela bolehlav. INP je totiž daleko přísnější. Například Tim Kadlec změřil, že z webů postavených na Reactu vyhovuje této metrice jen 17 %. Weby postavené na Next.js jsou na 12 % úspěšnosti. Tim Kadlec doslova píše, že INP bude pro javascriptové vývojáře „tvrdým budíčkem“. A já s ním souhlasím. V květnu 2023 jsem vzal 100 nejnavštěvovanějších českých e-shopů z naší studie o rychlosti webů českých e-shopů. Je to mazec. Na mobilu jich novou metriku rychlosti reakce INP splňuje pouhých 17. To jsou důvody, proč mě oznámení o tom, že INP bude už za méně než rok metrikou Core Web Vitals, překvapilo. Google sice v rámci projektu Aurora pomáhá autorům javascriptových frameworků mimojiné s optimalizací INP, ale to je jen malá část problému. Velký balvan bude ležet na ramenou vývojářů konkrétních webů a já vím, že optimalizovat JavaScript pro ně nebude snadné. Pojďme si teď něco povědět o samotné metrice Interaction to Next Paint. Metrika rychlosti odezvy Metrika Interaction to Next Paint zaznamenává prodlevu veškerých interakcí v průběhu celého životního cyklu stránky. Interaction to Next Paint je podobně jako právě FID metrikou interaktivity. Stránka se vám načte a vykreslí, vy můžete provádět interakce z myši, z dotykové obrazovky nebo z klávesnice, ale stránka nereaguje. Hlavní příčinou bývá samozřejmě JavaScript a probíhající dlouhotrvající úlohy , které zablokují vykreslovací vlákno prohlížeče. Metriky jako INP, se snaží tyto nepříjemnosti v uživatelském prožitku změřit a tím nám umožnit je odstranit. Odezva vpravo je dobrá, protože indikátor načítání se zobrazí okamžitě po vstupu uživatele, který chce zobrazit obrázek. Autoři z Googlu v případě INP namísto pojmu „interaktivita“ používají pojem „responsiveness“, tedy víceméně schopnost rychle reagovat. Zjednodušeně řečeno je INP metrikou rychlosti odezvy na uživatelské interakce. Ukazuje na to i samotný název. Interaction to Next Paint by se dalo přeložit jako „od interakce do dalšího vykreslení“. Překládat do češtiny se tento název bude špatně, a ani já o to tentokrát nebudu usilovat Nicméně – v původním názvu se přesně odráží fungování tohoto nového ukazatele. Co INP měří a jak se liší od FID? Metriku First Input Delay už dlouho považuji za nevyhovující. Problém s odezvou na interakce u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID žádné problémy ani u těchto webů neukazuje. Důvody, proč metrika FID už z dnešního pohledu nevyhovuje, jsou tři: Měří jen prodlevu při první interakci, nikoliv celou dobu pobytu uživatele na stránce. Neměří celou prodlevu, ale jen její první část. Ukazatel FID je málo přísný. Podle dat Googlu jej splňuje 95 % webů. Asi nikoho nepřekvapím, když napíšu, že INP toto všechno řeší: 1) Měří se celou dobu pobytu na stránce INP „sleduje“ odezvu všech interakcí až do změny URL a vybere tu nejhorší odezvu se všech interakcí. Pokud je interakcí více než 50 , nevybere se nejhorší hodnota, ale percentil, nejčastěji 98. Měřením po celou dobu pobytu na URL se řeší velká slepota metriky FID, protože podle propočtů Googlu zhruba 90 % interakcí probíhá až po úvodním načtení stránky. INP si tak můžete připodobnit k metrice Cumulative Layout Shift , která se také měří po celou dobu pobytu na stránce. 2) Počítá se celá prodleva FID měří jen první část prodlevy reakce – než reakce probublá do JavaScriptu, který ji musí zpracovat. Vůbec se ale nepočítá s dobou zpracování v samotném JS kódu, která může být opravdu dlouhá. Dále se nepočítá s dobou vykreslení. FID změří odhadem jen třetinu až polovinu reálného zpoždění po akci uživatele. Metrika INP a tři části, kde může nastat průšvih Na schématu vidíme tři části možného zpoždění interakce: Zpoždění vstupu – to, co nyní měří FID. Zpracování vstupu – události, ale hlavně zpracování JS. Zpoždění prezentace – většinou bývá v pohodě, mohou ale pokazit špatné CSS animace atd. Už z tohoto je jasné, že weby, které dříve v pohodě procházely přes metriku FID, teď projít nemohou. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 93 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. Hodnoty metriky INP a jak je změřit? Interaction to Next Paint má, stejně jako jiné Web Vitals, od výroby nastavené třístupňové hodnoty, kdy stránka vyhovuje více či méně: V tabulce to pak vypadá následovně: Metrika Dobrá Vyžaduje zlepšení Špatná INP ≤ 200 ms 200 - 500 ms > 500 ms Měření INP Hodnoty nové metriky odezvy interakcí můžete pro své weby získat už nějakou dobu, protože Google ji od uživatelů Chrome sbírá v rámci svého Chrome UX Reportu a poskytuje ve svých měřících nástrojích. Podobně jako u CLS nebo FID bude složitější ji naměřit pomocí syntetických měření typu Lighthouse, protože metrika se sbírá až na základě uživatelských akcí. Ale je zde světlo na konci tunelu, totiž nové režimy fungování právě u nástroje s majákem ve znaku. Takže jak novou metriku změřit? Data od uživatelů vašeho webu získáte například z PageSpeed Insights: pagespeed.web.dev nebo našeho testeru PageSpeed.cz. Můžete použít knihovnu web-vitals nebo extension Web Vitals . V Lighthouse je možné INP změřit v novém režimu Time Span. Nová verze rozšíření Web Vitals umí změřit prodlevy jednotlivých interakcí uživatele. Optimalizace INP Asi byste ode mě rádi dostali rovnou návod, jak tuto metriku snadno optimalizovat. Ale bohužel, tak jednoduché to nebude. Z praxe pro klienty vím, že obecné rady u jakékoliv metriky málokdy zafungují, vždy je potřeba analyzovat konkrétní web a konkrétní stránky. U této metriky to bude ještě složitější. Samozřejmě vás ale zkusím alespoň trochu navést. Pár konkrétních rad Některé konkrétní problémy se nám v rámci poradenství k rychlosti pod hlavičkou PageSpeed.cz opakují: Dlouhé prodlevy po klikání do filtrace na mobilech na e-shopech způsobené překreslením stránky, které je zbytečné, protože stránka není vidět. Prodlevy každého kliku způsobené analytikou . Dlouhé úlohy v JS při úvodním vykreslení webu, např. při provádění JS kódu v jQuery na document.ready . Hydratace v moderních JS frameworcích jako React nebo Vue. Pozdní indikace probíhajícího načítání v rámci Ajax/Fetch volání. Hodně nám při optimalizacích pomáhá trik se setTimeout . Mrkněte se na celý článek o INP, který připravila kolegyně Zuzana Šumlanská. Dále budu radit ještě obecněji. Zaměřte se na TBT Metriky jako FID nebo nově INP jsou velmi citlivé na takzvané long tasks v JavaScriptu. Pokud má totiž prohlížeč práci s dlouhým zpracováním JS kódu, nemůže reagovat na vstupy od uživatele. Zaměřit byste se tedy měli na optimalizaci metriky TBT , kterou jde změřit snadno všemi možnými nástroji. Podle údajů Googlu koreluje TBT dvakrát lépe s INP než s FID, což je dobrá zpráva, protože optimalizace FID byla často docela peklíčko. Optimalizujte prostě JavaScript Obecně samozřejmě pomáhá mít ve stránce co nejméně JS, který něco provádí: odstraňovat nevyužitý kód, správně bundlovat, odkládat stahování a spouštění kódu, který v daném uživatelském kontextu není potřeba. Dávat pozor na třetí strany. Důležitá v případě INP může být také volba JS frameworku. Např. weby běžící na Next.js na mobilu splňují metriku jen z 20 %. Lidé z Googlu sice deklarují, že s autory těchto knihoven budou pracovat na zlepšení, ale tipuji, že některé autory webů běžících na těchto frameworcích čekají zajímavé časy. Více o optimalizaci INP najdete jako vždy v materiálech přímo od Googlu Co s tím teď? Pokud vám můžu poradit, určitě si INP pro své weby pravidelně měřte. Jestliže vám vyjdou velmi špatná čísla a chcete-li do budoucna Web Vitals splňovat a hlavně mít rychlý web, pak raději začněte připravovat plán na nápravu . Z mé zkušenosti je totiž právě optimalizace JavaScriptu jedna z nejsložitějších a nejdéle se táhnoucích prací na rychlosti webu. Pokud INP splňujete, nezbývá než vám gratulovat. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
14.02.2024 06:00 Ve druhé části předvánoční diskuze v Productboardu, a padesátém díle našeho podcastu , jsme si vzali na mušku dvě oblasti, ve kterých se nyní mění paradigmata. Převládá ve sestavování aplikací stále Webpack, nebo se situace začíná měnit?“ Je SSR jasná cesta, kam bude vývoj webových aplikací směřovat a není to jen opsání kruhu do bodu, kde už jsme byli? V části o buildování JS jsme se shodli zhruba na následujícím: Webpack je produkt doby čistě klientských aplikací a potřeby dělat jeden velký build. Technologie se posunuly, máme např. HTTP/2, které umožňuje posílat více menších souborů naráz a také frameworky umožňují posílat menší buildy, které se načítají postupně. Nyní jsme ve stavu, kdy se hledá nové řešení, proto je nástrojů pro buildování opět hodně, ale převažuje Webpack a Vite. V zásadě ale nakonec vybíráme buildovací nástroj podle toho, co nám naservíruje meta-framework. V druhé polovině, tématicky o server-side renderingu , jsme se myslím na ničem úplně neshodli, ale povídali si o Edge Computingu, streamování HTML, Local First, Partial Prerenderingu, React Server Components, HTMX a dalších buzwordech i báječných technologiích. Bohužel jsme se opět ani jednou nepohádali. Podcast Celá epizoda na videu Hosté Riki Fridrich Riki píše JavaScript ve firmě Outreach. Učí ostatní, jak psát Javascript. Přednáší na konferencích a setkáních. Většinou o Javascriptu. Riki je z Ládví. Web – Twitter – Github – LinkedIn Libor Vaněk Libor je Head of Front-End Development v CDN77, kde poskytují infrastrukturu pro globální internet. Fanoušek World Wide Web platformy a rozumného přístupu k web developmentu. Má rád všechny JS frameworky, ale ještě radši je podrobuje kritickému pohledu. Kdysi dělal meetupy Vue.js, dneska migruje většinu věcí z Nextu na SvelteKit. Ve volném čase dělá pro bono projekty, jako např. web a newsletter pro novináře Davida Klimeše a konzultuje architekturu a výkon webových aplikací. LinkedIn – Twitter Petr Glaser Petr v rámci projektu Nauč mě IT pomáhá lidem získat dovednosti a znalosti vhodné pro práci v IT. Říká o sobě, že je vývojář zapálený pro technologie a vzdělávání. Zaměřuje se na performance, kterou vnímá jako součást UX a přístupnosti. I díky tomu si oblíbil framework Qwik, o kterém je řeč v podcastu. LinkedIn – Twitter O čem si povídáme? Buildování JS: Webpack jako produkt doby SPA Žezlo přebírá Vite, ve kterém jedou všechny frameworky mimo Reactu/Nextu Další hráči , potřeba univerzálnosti, jsme v mezidobí Next na Webpacku a chystaný posun k Turbopacku Další buildovací nástroje už nebudou v JavaScriptu Jde se bez buildu obejít? Viz No Build od 37signals Jak si stojí Rollup? Viz RollDown. Druhé téma: Server Side Rendering Rikiho „teorie sinusoidy“ a progressive enhancement Kde je dělící linka mezi SSR a klientským renderováním? Záleží vždy na zdroji dat a rychlosti odezvy, změna díky edge computingu Odvážná Rikiho vize: streamování HTML Jak do toho vstupuje Local First Jedna z dalších cest může být Partial Prerendering Možná změna definice frontendu a backendu, ještě v případě React Server Components vs. návrat k Rails, Django, Nette… HTMX- „niche záležitost“ a interaktivita bez HTML Stimulus.js a náš nenázor Děkujeme za spolupráci Jiří Nečas, Productboard – Vladimír Příhoda, Productboard – Honza Michálek – Johana Kratochvílová, Signatura . Odebírejte podcast ze Vzhůru dolů Spotify – Apple Podcasts – Google Podcasty – TuneIn – RSS podcastů Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo kamkoliv jinam. Hlavně, aby se to k nám dostalo. Přejeme vám příjemný poslech!
12.02.2024 19:45 V této epizodě se společně s Pavlem a Michalem ponoříme do důležitého, ale málokomu vyhovujícího oboru řízení vývoje. Společně zkoumáme, proč dochází k nedorozuměním mezi vývojáři a těmi, kteří jim práci zadávají. Podcast Povídáme si o různých metodikách a nástrojích. Diskutujeme také o roli prostředníků jako jsou byznys analytici, ale shodujeme se i na několika praktických tipech. Co se dá z obou stran zlepšit při zadávání práce? Devět tipů, jak vylepšit proces zadávání práce Ideálně potřebujeme dva nástroje pro řízení dvou stavů: Product Discovery a Product Delivery , více též v článku. Velmi se hodí silný Product Owner, projektový vedoucí nebo někdo, kdo slaďuje potřeby různých stran. Přípravu zadání je vhodné dělat produktovém triu: produkt, vývoj, design . Při zadávání se soustřeďte na ne výstupy , ale výsledky . Dobré zadání může vypadat takto: jednoduché user stories, vizuální nebo jiný cíl, jak otestovat výsledek. Dobře si nastavte cíle , bez toho to nejde. Agile je dobrý cíl, ale je potřeba být pragmatik a zohledňovat realitu v týmu. Hodí se vám byznys analytik nebo někdo, kdo tu roli zastává a pomáhá dodefinovat zadání. Potřebujeme vývojáře, kteří se nebojí oponovat, ptát se. „Nespokojte se se špatným zadáním.“ říká Marek Čevelíček v článku UX pro vývojáře. Hosté Pavel Ungr Pavel je „těžký kalibr na vaše SEO“, expert na online marketing na volné noze. V oboru SEO pracuje od roku 2004. Pořádá školení a pravidelně publikuje odborné články. Baví jej experimenty a propaguje SEO jako vytvoření zajímavého a kvalitního obsahu, který je prospěšný především pro uživatele. K zadávání práce vývojářům přichází jako externí konzultant. PavelUngr.cz – LinkedIn – X.com Michal Voják Michal je produkťák, zavádí Product Discovery do firem a vede startup userUP, který má za cíl pomoc firmám právě s tímto tématem. Michal za sebou má bohatou webařskou kariéru od frontendisty přes UX designéra až po současnost. Navíc má zkušenosti se spolupráci s korporáty, proto dokáže problém organizace projektů vnímat z různých úhlů pohledu. DesignDev – userUp – LinkedIn – X.com Obsah Robinův tip: Kniha Fluent React od Tejase Kumara Martinův tip: PLUS pro monitoring rychlosti Jak to vidí Pavel Ungr? Jak to vidí Michal Voják? Zásadní téma: jak se čte „JIRA“? Jak to vidí Robin? Jak to vidí Martin? První problém: neřeší se to v jednom nástroji Druhý problém: slabý či neexistující Product Owner Triáda a raději výsledky než výstupy Potřebujeme prostředníka? Agile Manifesto a střet s praxí Sedět spolu v kanclu může být lepší Jak vypadá dobré zadání? Byznys analytik jako člověk nebo role Pomůže si dobře nastavit cíle Definice „seniora“ Je JIRA super nebo příšerná? Vývojáři, nebojte se oponovat Pozvánka na 19. 12. do Productboardu Jak probíhá autogramiáda podcastu? Ukázka: Agile Manifesto vs. praxe Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – RSS podcastů Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo kamkoliv jinam, hlavně, aby se to k nám dostalo. Děkujeme za spolupráci: Honza Michálek . Přejeme vám příjemný poslech!
01.02.2024 13:30 Nedávno jsem řešil údajné porušení autorských práv u jednoho obrázku, který jsem používal na Vzhůru dolů. Přišlo mi to ve varování jako automatický e-mail. Ten jsem považoval za další podvod, scam, takže nazdar bazar. Scam to nebyl. No nazdar! Slyšte tedy můj příběh, který mě stál sedm tisícovek. Nebuďte jako já a neignorujte automatizované e-maily od PicRights. Můj příběh s „půjčeným“ obrázkem V květnu 2023 mi přišel e-mail s předmětem „Žádost o prokázání vlastnictví licence k obrázku společnosti Reuters News & Media Inc“ z adresy ResolveGL@picrights.com. V obsahu se mimojiné píše: společnost PicRights Europe GmbH zjistila, že na Vaší webové stránce, sociální média nebo média dostupná z vaší internetové stránky, byl použit obrázek/obrázky společnosti Reuters News & Media Inc. Našemu klientovi společnosti Reuters News & Media Inc se nepodařilo najít žádnou platnou licenci pro používání tohoto obrázku / těchto obrázků Vaší společností. V důsledku toho požadujeme jménem společnosti Reuters News & Media Inc přiměřené odškodnění za toto nepovolené používání. A dole je uvedený tenhle důkaz: Pozdrav od robota, který má rád peníze. Společnost PicRights po mě chtěla zaplatit 10 tisíc korun za využití obrázku pro koláž v článku, který jsem napsal v roce 2006, tedy před sedmnácti lety. S těmito typy e-mailů se obvykle nemažu. Víceméně je mažu, však Inbox Zero, že… Udělal jsem rychlé googlení, narazil na články s titulky jako „copyright trolling“ a zařadil si PicRights do mentálního šuplíku po bok internetových podvodníků, kteří se snaží vydělat na lidské neznalosti. Druhý e-mail přišel v červnu 2023. Třetí dorazil v červenci 2023. Obsahově byly stejné, i částka seděla. Nic jsem nedělal, na nic nereagoval, nic neplatil, obrázek dále visel na webu. S podvodníky se nebavím. Nazdar bazar. Zkraje ledna 2024 ovšem přišla předžalobní výzva od kanceláře PRK Partners s předmětem „Porušení autorských práv“. Mám prý udělat tři věci zároveň: Odstranit fotku. Kontaktovat PicRights a vyřešit ten případ. Zaplatit asi 14 tis. Kč. Tohle už zase tak snadno ignorovat nešlo, Inbox Zero nepomáhal. Takže jsem to začal řešit s advokátkou Petrou Dolejšovou. Tušil jsem, že jsem to trošku podělal, takže Petra mě v zásadě nepřekvapila. Prý to není podvod, mám se s nimi zkusit spojit a domluvit se alespoň na snížení té částky. To mi doporučila udělat po vlastní ose, aby netekly zbytečné peníze ještě na právní zastoupení, které by ve výsledku mohlo být vyšší než samotná částka Vzal jsem telefon a po chvíli se mi povedlo mluvit s člověkem z PRK Partners, který o tom něco věděl. Vysvětlil jsem mu situaci a po chvíli vyjednávání jsme se dohodli, že zaplatím polovinu a oni ten případ uzavřou. Ponaučení: obrázky nepůjčovat, nepůjčovat, nepůjčovat V mém případě to bylo jasné – fotku jsem opravdu kdysi stáhl ze sport.cz. Obvykle to nedělám, ale kdysi jsem občas dělal výjimky. Ono v té době, kdo to měl jinak… Docela dobře si pamatuju, že v takových případech jsem doufal, že pokud tam uvedu zdroj, původní fotku upravím a fotku vystavím na nevýdělečný web, jsem v suchu. Nejsem v suchu. Tyhle společnosti využívají roboty, kteří skenují web a získané informace párují s databázi fotek od agentur jako AP nebo Reuters. mimochodem v Česku nejspíš spolupracují i s ČTK. Mimochodem, v mém případě byla trošku smůla, že jsem použil fotku od Reuters, což je agentura v tomto směru údajně docela drahá a důsledná. Na rozdíl od některých jiných nejsou výzvy PicRights jen plané. O ceně a spravedlnosti si můžeme myslet cokoliv, ale ženě, algoritmům a právníkům se neodmlouvá. Co si z toho vzít? Autorské právo ctím, ale jak jsem psal, velmi vzácně se historicky stalo, že jsem pro potřeby ilustrace použil „fotku z internetu“. Nejsem expert na právo, ale mám pár webů a tomuto se chci v budoucnu vyhnout, takže vám alespoň řeknu, co jsem po této minikauze udělal: 1) Fotky stáhnout a neřešit Pokud na obrázky nemáte práva nebo si tím nejste jistí, prostě je hned po prvním upozornění smažte. A je to. Podle mě s PicRights dále nijak komunikovat nemusíte a podle ohlasů na internetech se domnívám, že vám pak dají pokoj. 2) Udělejte si audit fotek na webu Je možné, že vám zatím žádné upozornění nepřišlo, ale to neznamená, že vás nemají v merku. Pokud si nejste jistí původem svých fotek, raději si udělejte alespoň základní audit. Já prošel fotky v CMS a pak obrázky z Google Images. Ještě, že si ilustrace většinou dělám sám. Ale výjimky se najdou a mohou být drahé. Beru to tak, že Google je velmi schopný robot, takže obrázky, které nezná on, snad nebudou znát ani roboti vydřiduchů jako jsou PicRights. 3) Zakažte robotům přístup do archivů Na tom mém „ukradeném obrázku“ mě nejvíc štve, že jej roboti nalezli v archívu webu, který mám hlavně pro své soukromé účely. Některé moje starší články jsou bezesporu hodné čtení, ale obávám se, že ty z roku 2006 už fakt nikdo nečte. Nejjednodušší je prostě zakázat robotům přístup pomocí předpisu v robots.txt: User-agent: * Disallow: /data/ Pamatujte ale na to, že pro roboty jde jen o doporučení, na které se asi u soudu odvolávat nebudete moci. Bonus: právo kolem obrázků z fotobank Když už jsem s Petrou řešil tuhle kauzičku, poslala mi jeden svůj pěkný článek o právu kolem obrázků z fotobank na internetu. Tedy pěkný… mně se to vůbec nelíbí, co si budeme povídat. Dávám to sem proto, že i v téhle oblasti působí vydřidušské algoritmy napojené na právníky. Pokud používáte obrázky z fotobank, raději se ujistěte: Dvakrát měřte, takže čtěte licenční podmínky, jestli se opravdu vztahují na váš způsob použití. Ujistěte se, že na fotkách nejsou známé motivy , platí tam totiž licence i k původní fotce. Dejte si bacha na využití obrázků, kde jsou lidé nebo loga. Dotčené osoby nebo firmy se mohou bránit. Tož tak. Obávám se, že PicRights a spol. vydělávají nemalé prašule, takže těchto případů bude jen přibývat. Nepodceňujte to. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
