Co se jinam nevešlo
a co se nám v přehledu témat modralo...
Validita, XHTML/HTML Dokument by měl začínat definicí typu, aby bylo jasno, co v něm je. - zavedeno od verze HTML5
Předtím...
Validita, XHTML/HTML HTML4 – 3 standardy: •Strict •Transitional •Frameset
Validita, XHTML/HTML XHTML1.0 – 3 standardy: •Strict •Transitional •Frameset
Validita, XHTML/HTML
• Strict - trvá na určitých pravidlech, zejména toho, jaké prvky mohou být v jakých zanořené -neobsahuje "zavržené" elementy
• Transitional - obsahuje zavržené elementy • Frameset - obsahuje rámce (a jen rámce!)
Validita, XHTML/HTML Vykreslovací režimy:
• "Režim platných standardů" • Quirks Postupem času je jich, kvůli kompatibilitě, víc a víc, IE9 má rovné 4: Quirks, Strict (IE 7 Standards), Hybrid (IE8 Standards) a Standards (IE9 Standards)
Validita, XHTML/HTML Hlavní rozdíly:
+ různá tolerance k chybám - odlišné vykreslování (Box model apod.) Důsledek: Web vypadá v jednom prohlížeči jinak, když je v Quirks, jinak když je ve Standards.
Validita, XHTML/HTML Jak "přepnout"?
Obecně – pomocí DTD: -HTML bez doctype: Quirks -HTML s chybami: Quirks -HTML Transitional: Quirks -HTML Strict: Standard
Validita, XHTML/HTML Snažte se nepřepínat, zůstat ve standardech, protože standardní vykreslovací mód přináší alespoň nějakou naději, že web bude vypadat "všude plus mínus stejně".
Validita, XHTML/HTML Validita: syntaktická správnost dokumentu podle daného DTD Význam: Přeceňovaný.
Prohlížeče si nemohou dovolit nezobrazit nevalidní HTML dokument, takže se snaží chyby ignorovat, "domýšlet"... ... ovšem validní dokument zajistí, že nebude potřeba nic domýšlet!
Validita, XHTML/HTML ... což neplatí pro XHTML!
XHTML přímo ve specifikaci říká, že syntaktická chyba, např. použití "&" v URL místo "&", má ukončit zpracování dokumentu a vrátit chybu.
Stav implementace CSS Vendor prefixy:
CSS se neustále vyvíjí a nové možnosti jsou častěji implementovány v prohlížečích dřív než ve standardech. Aby z toho nevznikl zmatek, jsou používány tzv. "vendor prefixy"...
Stav implementace CSS Názorný příklad: zakulacené rohy
CSS vlastnost border-radius border-radius: 10px; Tvůrce prohlížeče pracuje s nestabilní specifikací. Měl by správně počkat, až to bude vydáno jako standard, ale on čekat nechce, protože je to pro něj konkurenční výhoda a designéři to chtějí.
Stav implementace CSS Řešení: Využijeme toho, že CSS co nezná, to inoruje, a přidáme si specifickou předponu (prefix).
Mozilla (Firefox): -moz-border-radius WebKit (Chrome, Safari): -webkit-border-radius IE: -ms-border-radius Opera: -o-border-radius
Stav implementace CSS Výhoda prefixů: výrobci je mohou používat dřív než je standard hotový. Nevýhoda: jsou proprietární a prodlužují zápis
Nakonec bývají nahrazeny jednotným zápisem bez –prefixu-
Stav implementace CSS div.coolEffect { -webkit-transition-property: opacity; -webkit-transition-duration: 2s; -o-transition-property: opacity; -o-transition-duration: 2s; -moz-transition-property: opacity; -moz-transition-duration: 2s; -ms-transition-property: opacity; -ms-transition-duration: 2s; transition-property: opacity; transition-duration: 2s; }
Snazší CSS CSS má několik kodérských nevýhod:
• nemá proměnné ani konstanty, vše je řešeno literálem • nemá "makra" (hodily by se pro zápis podobných metod, využívajících vendor prefixy) Řešení v podobě preprocesorů – nejznámější jsou LESS a Sass
Snazší CSS Praxe: #header { -moz-border-radius: 5px; -webkit-border-radius: 5px; border-radius: 5px; } #footer { -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius: 10px; }
Snazší CSS Řešení v LESS – makra: .rounded_corners (@radius: 5px) { -moz-border-radius: @radius; -webkit-border-radius: @radius; border-radius: @radius; } #header {.rounded_corners;} #footer { .rounded_corners(10px);}
Snazší CSS Praxe: #container { width: 960px; } #aside { width:123px; margin-right:6px; } #content { margin-left: 831px; /*MAGIE!!!*/ }
Snazší CSS LESS a proměnné: @width: 960px; @aside: 123px; @span: 6px; #container { width: @width; } #aside { width: @aside; margin-right: @span; } #content { margin-left: @width - @aside - @span; }
Bezpečnost JavaScriptu JavaScript může být velmi nebezpečný, protože manipuluje s obsahem stránky. Může číst vaše hesla, když je zadáváte. Může provádět operace, o kterých ani nevíte. Může vám ukrást přihlašovací údaje, může za vás převést peníze, změnit vám fotku v profilu a ještě vám přepsat heslo...
Bezpečnost JavaScriptu ... a ne, nemusíte kvůli tomu lézt na "pochybné" stránky! Webdesignéři a programátoři na bezpečnost kašlou, a to není dobře. Jiní si myslí, že jí rozumí, a to je ještě hůř.
Škodlivý JS kód se tak může objevit na jakýchkoli stránkách. Jediná ochrana je zakázat JS (a povolit jen někde...)
Bezpečnost JavaScriptu Základní bezpečnostní mechanismus JS: Same-Origin Policy, tedy "politika stejného původu"
Zhruba: Do obsahu HTML stránky z domény http://xyz.cz/ smí zasahovat jen skripty, které pocházejí ze stejné domény.
Bezpečnost JavaScriptu Do stránky http://xyz.cz/index.html vložíme pomocí iFrame třeba http://www.seznam.cz Skript z vnitřního okna nemá právo volat mateřské okno, skript z mateřského okna nemá právo volat vložené okno, měnit ho atd.
Bezpečnost JavaScriptu AJAX
(metoda, jak může prohlížeč požádat server o data, aniž by znovunačítal stránky) Bezpečnost: Skript, načtený z xyz.cz, smí položit AJAX požadavek pouze na adresu z téže domény.
Bezpečnost JavaScriptu Kuriozní důsledek: pokud načtete obrázek/video do canvasu, můžete do něj kreslit. Pokud je obrázek / video z jiné domény, zahlásí prohlížeč bezpečnostní chybu a nedovolí to.
Existují způsoby, jak toto pravidlo obejít, a to jak legální techniky (CORS, komunikace mezi okny), tak ne-zrovna-čistá řešení.
Bezpečnost JavaScriptu XSS
Cross-Site Scripting Do "normálního" webu je vložen škodlivý kód (např. do vyhledávacího formuláře). Ten pak může provádět nekalosti, včetně např. krádeže přihlašovacích údajů.
Agilní metodiky Pro vývoj webu jsou velmi vhodné, protože u webu víc než kde jinde platí: - Zákazník nemá přesnou představu o tom, co chce - Vývojář dělá spoustu práce, která "není vidět" - Když už je něco vidět, tak je většinou pozdě něco měnit
Klasický model "Vodopád" •Na počátku je zadání •Ze zadání je zpracována analýza •Z analýzy jsou vytvořeny odhady nákladů •Analýza je rozpracovaná pro vývojáře, designéry, grafiky, kodéry, ... •Postupně je vytvořen web •Až v betaverzi je vůbec možné ukázat něco zákazníkovi. •Práce předána, následuje dohadování o tom, zda splňuje zadání, co by mělo být jinak a kdo to zaplatí.
Model "Vodopád"
Agilní metodiky •Na počátku je zadání, které nemusí být zcela přesné • Analýza především hledá "minimální funkční model" • Vývoj probíhá v krátkých iteracích (třeba týden) • Na konci každé iterace ("běhu") je jasné, co je hotové a co se bude dělat dál • Vývoj po malých funkčních celcích pomáhá motivovat vývojáře • Zákazník má možnost vidět, jak dílo vzniká
Agilní metodiky U klasických metodik zákazník říká, že chce informační portál, ale když ho dostane, zjistí, že vlastně potřeboval e-shop. U agilních metodik se zákazník podílí na vývoji, takže sice chce informační portál, ale díky neustálé zpětné vazbě nakonec mnohem pravděpodobněji dostane to, co potřebuje.
Release early, release often! Snažte se co nejrychleji udělat funkční kostru se základní sadou funkcí. Neřešte detaily, neřešte "co by se ještě mohlo". Udělejte základ a spusťte ho co nejdřív! KISS Keep it Small and Stupid DRY Don't Repeat Yourself
