tohle je ještě otevřené téma a probíhá diskuze, jakou variantu zvolit. Hlasy o tom, že řada lidí prostě na to nevidí a chce to zvětšit také jsou, já jsem jednoznačně pro a pokud se to dostane na některý náš projekt, zoom bude povolený.
Můžeš se do diskuze zapojit a přednést svoje argumenty https://github.com/ampproject/amphtml/issues/481 a ne jen vyřvávat "NEEEE" v komentářích.
Za tu vzorovou kostru bych jejího autora pověsil za koule do průvanu jménem všech, kteří potřebujou mobilní web zoomovat. Klazule meta tagu viewport "minimum-scale=1,maximum-scale=1,user-scalable=no" v podstatě znamenají, že web je naprosto nepoužitelný pro nás, co ještě využívame naše nepatrné zbytky zraku a obsah si zoomojeme, abychom ho vůbec přečetli. GRRRRRRR!!!!!!!
ano AMP nepřináší nic nového a je stejný jako dalších tisíc podobných frameworků, jen s tím rozdílem, že se google nejprve dohodnul s velkými vydavateli.
Ano, sdílení zdrojů funguje i teď, ale rozmanitost je tak velká, že v praxi to tolik nepomáhá (vycházím z interních statistik doby načítání stránky našich klientů).
To je zajímavý nápad, přibalit frameworky do prohlížeče, ale byl by tady problém s aktualizací a nejnovějšími verzimi. Problém by to ale neřešilo, kvůli obrovské rozmatinosti a nekompatibilitě napříč prohlížeči. Nedokážu si ani představit testování, jak by se řešil fallback, když prohlížeč nebude mít požadovanou verzi?
bylo by to příliš nedetermistické a velikost by nebyla zanedbatelná, pokud stáhnu vše z https://developers.google.com/speed/libraries/, jde to do stovek mb.
Každopádně je mnohem lepší používat podobná cdn, protože pak dojde pouze jednou ke stáhnutí :).
Ale jdeš dobrým směrem, asi jsem pro to, aby se rozšířily možnosti DOMu, který už nebyl deset let aktualizovaný a přidat možnosti, které má jquery do specifikace od W3C. Raději bych používal vanillaJs než jQuery :).
> Pokud člověk, který se nezabývá bezpečností, tvrdí něco o bezpečnosti, nemá to žádnou vypovídající hodnotu
Tím myslíš koho? Sebe? Nemůžu než souhlasit.
> pro sha256/384 je teoreticky možné najít kolize pro jquery, překážkou je pouze cena/čas.
To je ale dobrá překážka. Bavíme se tu totiž o hodně velkých násobcích stáří vesmíru. Celá kryptografie na tomto stojí a padá.
ne, čtu mailing w3c skupiny a cross-site hashing byl zavrhnut, místo toho se doporučuje CORD a vzniká akorát resource Integrity hashing. Ti lidi předpokládám, že tomu rozumí a ví proč od toho prozatím upustili.
Celá kriptografie stojí na tom, že se vymění algoritmy dříve než jí technologie dožene.
Já zase čtu Čtyřlístek, co má jako být?
Nevím, co je CORD, možná myslíš CORS, ale připojení otisku k nalinkovanému zdroji už svůj Working Draft má taky: Subresource Integrity (SRI), dokonce s možností použít libovolný (nebo vícenásobný) druh otisku.
> Celá kriptografie stojí na tom, že se vymění algoritmy dříve než jí technologie dožene
SHA-256 se běžně používá v TLS, DNSSEC, DKIM, PGP … you name it.
Pokud obsahuje kritickou chybu, nějaké linkování javascriptů bude poslední starost, kterou budou administrátoři řešit.
Dneska se to ale dela tak, ze se posle giganticke html, k tomu hromada css, a jeste vetsi spousta js, velmi casto nekolikanasobne vic, nez co ve skutecnosti tvurce pouziva. A teprve pak se zjisti, ze jde o mobil, a zobrazi se z toho 1%. Pochopitelne pomoci toho js.
Pritom kdyby si tvurce vzal hlavicku kterou mu ten mobil posle uz pri prvnim pozadavku, tak obratem vi, ze staci poslat 1/100 dat. Jenze to by nesmel pouzivat vsemozne uzasne frameworky a misto vyplnit necim jinym nez pilinami.
líbí se mi slovo šelmostroj :)
ale v podstatě ano… je to to pro vývojáře snadnější řešení s media queries, kde je vše v jednom, ale zase se mohou přenášet redundantní data a pak to nové řešení s druhou oddělenou samostatnou mobilní verzí (což vlastně není až tak nové, spíše recyklované řešení) které bude zase příjemnější pro uživatele, ale o to pracnější (zdlouhavější) pro vývojáře.
Ano, to není nic nového, naopak do tohoto se vyvinul WAP, lehkou mobilní verzi má i Lupa (m.lupa.cz) nebo třeba Žive (m.zive.cz) a v klidu to zobrazí Java2ME Opera Mini či browsery vetavěné v hloupých telefonech typu Netfront, šlape to přes GPRS/EDGE jak víno.
Pokud se web dobře navrhne, tak stačí udělat specifickou view vrstvu.
Bohužel se od toho upouští a přechází se na reponsivní web, kde je sice optimalizace vzhledu pro malý displej, ale všechny verze jsou v jednom HTML, halda JS a frameworky typu Foundation a je to pomalé i na dnešních levných Androidech.
Teď se dívám na AMP detailněji a dělá to na mě dojem, že je to rovněž myšleno jako separátní mobilní verze (a pokud ne a použijí se techniky responzivního webu, tak jsem tam kde jsme byli) a to mohu udělat lehkou mobilní verzi bez AMP a vzhledem k potřebě JS (a nejspíš procházení celého DOMu a hledání těch speciálních značek, což není zrovna laciná operace) i daleko lečí než s tím AMPem..
Do Chrome je na to plugin, který si uloží jquery a i když jsou pak na stránce nestahují se, ale použijí se ty (ta která verze je potřeba) z prohlížeče https://chrome.google.com/webstore/detail/jquery-cache/kalnennlfaffhbdbnoakkiiciifmmohk?utm_source=chrome-app-launcher .
Na desktopu asi dobrý, ale na mobilu, kde by to bylo o to více potřeba by to asi bylo problematičtější … všechny verze všech JS knihonen a frameworků, … zabírají fakt moc místa a navíc tak jak tak se ten obří JS soubor (bez ohledu na to kde se vzal a jestli se stahoval nebo ne) musí držet v dost malé paměti mobilního zařízení. Na mobilu je to asi prostě nejčistější řešení moc JS knihoven nepoužívat… ideálně jen několik málo drobných vlastních scriptíků.
Stejně jako lze nyní v objektu navigator zjistit základní info o vlastnostech prohlížeče, tak obdobně by mohla jít zjistit i (ne)přítomnost nějaké JS knihovny a podle toho se rozhodnout odkud to načtu.
Nebo rovnou ve script tagu přidat k normálnímu src další speciální atribut typu browser-src="" a v případě jeho přítomnosti si prohlížeč použije přednostně svou integrovanou verzi.
To byly jen příklady, vyřešit technicky ten fallback nebude nic složitého, pokud se do toho nezatáhne W3C :-).
Ty opravdu čekáš, že si někdo nechá diktovat, jaké má mít na webu UX? Web je otevřený, to je důvod jeho úspěchu.
Keš podle hashe není žádné bezpečnostní riziko. Jako autor říkám „hele, tento můj /jquery.js má hash XYZ123, možná už ho máš někde v paměti odjinud.“
HTTP/2 je nasaditelné okamžitě kdekoliv, kde o to provozovatel stojí. Podpora koncových stanic je už teď solidní a bude brzo vynikající.
já si říkal odkud ty bláboli máš a ono to je z čtyřlístku :-D.
Ano, myslel jsem CORS, který se postupně na velkých webech nasazuje a brání použití neautorizovaných zdrojů. SRI řeší ale pouze integridu a zatím nevypadá, že myšlenka podle toho hashovat se vůbec prosadí.
Bezpečnost v reálném čase a najítí po několika týdnech počítání konfliktního hashe k jedné knihovně je naprosto něco jiného.
Představ si, že máš volných 100k USD, najdeš konfliktní hash k používané knihovně, donutíš lidi, aby tvojí stránku navštívili a máš persistentní kód v prohlížeči, který se volá na velkém množství stránek. Zatím k tomuhle není vůle a obecná shoda a tohle je prozatím argument, proč se na tom nepracuje.
Řada firemních politik a doporučení právě tomuhle brání, užitek by nebyl tak moc velký, viz diskuze, které se o tomhle vedou.
Připojovat takovou spoustu skriptů se zdá být nerozumné. Při rozšířeném používání Accelerated Mobile Pages by ale všechny tyto knihovny v sobě měla už cache prohlížeče, takže by šlo používat hotové JS funkce bez načítání dalších dat.
Ale to už v podstatě funguje i dnes, beztak má každý nakešovanou nějakou známou cdn verzi běžných JS frameworků.
Proč vůbec prohlížeče už nyní v sobě neobsahují přímo zaintegrované nejpoužívanější JS frameworky a nějakou možnost si na ně z webstránky šáhnout? Něco jako:
<script src="browser://jquery123"></script>
Těch pár mega navíc, co by se při instalaci/aktualizaci prohlížeče stáhlo nehraje žádnou roli.
Další zbytečný mikroformát. Přitom by stačilo vyřešit dvě věci: kešování souborů na základě obsahu nikoliv adresy a lepší kontrola priorit načítání zdrojů.
První věc by se dala řešit připojením informace o kontrolním součtu odkazovaného zdroje a druhou do jisté míry řeší HTTP/2
Nejedná se o mikroformát, cachování a priorita zdrojů není jediná věc, kterou to řeší. Současné mobilní weby nemají dobré UX a tohle je jedna z odpovědí, nelíbí, ignoruj, nepoužívej.
a jak to chceš řešit? Párování souboru podle hashu je bezpečnnostní riziko a prozatím bych to nedoporučil. Jinak zatím je spec pouze v draftu http://www.w3.org/TR/SRI/ a o možnosti právě cachování podle hashe se vede diskuze.
HTTP/2 ale není v současné době plošně nasaditelné a ještě to nějaký ten rok potrvá. Nebude to ale řešit případ, kdy chci načíst obrázky podle rozlišení nebo je nenačítat, když nejsou vidět.
UX je míra příjemnosti, snadnosti, efektivnosti, orientace na stránce, nejedná se o grafiku a ani nic konkrétního, je to pouze míra, kterou mohu konkretizovat jen uživatelskými testy. Design mám pod kontrolou.
Pokud člověk, který se nezabývá bezpečností, tvrdí něco o bezpečnosti, nemá to žádnou vypovídající hodnotu. Kolize hashů je problém, i pro sha256/384 je teoreticky možné najít kolize pro jquery, překážkou je pouze cena/čas.
HTTP/2 není stabilní a nasaditelné. Neexistují HW balancery, soft jsou v beta verzích, neexistuje dobrá podpora v frameworcích pro webové aplikace, vývojáři neznají možnosti a struktura aplikací neodpovídá možnostem a principem fungování http (preloading a sdílení spojení zejména).