Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00197 005991 13874752 na godz. na dobę w sumie
Projektowanie serwisów WWW. Standardy sieciowe. Wydanie III - książka
Projektowanie serwisów WWW. Standardy sieciowe. Wydanie III - książka
Autor: , Liczba stron: 448
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2658-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> tworzenie stron www
Porównaj ceny (książka, ebook, audiobook).

Jak to się robi z pomocą mistrza

Przewodnik po standardach autorstwa Jeffreya Zeldmana ponownie kontratakuje! Trzecie wydanie udowadnia, że to wciąż najważniejsza książka dla wszystkich projektantów, którzy chcą tworzyć nowoczesne i funkcjonalne witryny - błyskawicznie się wczytujące, trafiające do masowego odbiorcy i tanie w utrzymaniu. Do nowej, zaktualizowanej wersji dodano niezwykle przydatne informacje o usprawnieniach, a także wyzwaniach, jakie stoją przed projektantami pracującymi w nieustannie zmieniającym się środowisku standardów sieciowych.

W tym wydaniu książki znajdziesz informacje na temat tego, jak za pomocą standardów rozwiązywać problemy powstające w wyniku stosowania starych sposobów projektowania witryn WWW. Dowiesz się także, jak stare i nowe standardy przekształcają internet w dynamiczną platformę do tworzenia solidnych, dostępnych aplikacji oraz pięknych i łatwych do odnalezienia treści. Przeczytasz też o tym, jak zapowiada się przyszłość standardów sieciowych.

W tym przemyśle Jeffrey Zeldman zajmuje miejsce gdzieś pomiędzy 'Bogiem' a 'guru' - i potrafi wykorzystać swą mądrość oraz dowcip, by opowiadać o tym, CZYM są standardy sieciowe, JAK należy je stosować oraz DLACZEGO powinniśmy zwrócić na nie uwagę.
Kelly Goto, autorka książki Web ReDesign 2.0: Workflow that Works
Czasami, bardzo rzadko, udaje się znaleźć autora, o którym myślimy sobie: 'Ten gość jest inteligentny! I sprawia, że ja też czuję się mądrzejszy, bo w końcu zrozumiałem to zagadnienie'.T
Steve Krug,
autor książek Nie każ mi myśleć! O życiowym podejściu do funkcjonalności stron internetowych oraz Przetestuj ją sam! Steve Krug o funkcjonalności stron internetowych
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Projektowanie serwisów WWW. Standardy sieciowe. Wydanie III Autorzy: Jeffrey Zeldman, Ethan Marcotte T³umaczenie: Piotr Rajca ISBN: 978-83-246-2658-8 Tytu³ orygina³u: Designing with Web Standards (3rd Edition) Format: 158×235, stron: 448 Jak to siê robi z pomoc¹ mistrza (cid:129) Poznaj przysz³oœæ standardów sieciowych (cid:129) Stosuj skuteczne zasady pracy z nowoczesnymi przegl¹darkami (cid:129) Naucz siê eliminowaæ problemy i ci¹æ koszty Przewodnik po standardach autorstwa Jeffreya Zeldmana ponownie kontratakuje! Trzecie wydanie udowadnia, ¿e to wci¹¿ najwa¿niejsza ksi¹¿ka dla wszystkich projektantów, którzy chc¹ tworzyæ nowoczesne i funkcjonalne witryny – b³yskawicznie siê wczytuj¹ce, trafiaj¹ce do masowego odbiorcy i tanie w utrzymaniu. Do nowej, zaktualizowanej wersji dodano niezwykle przydatne informacje o usprawnieniach, a tak¿e wyzwaniach, jakie stoj¹ przed projektantami pracuj¹cymi w nieustannie zmieniaj¹cym siê œrodowisku standardów sieciowych. W tym wydaniu ksi¹¿ki znajdziesz informacje na temat tego, jak za pomoc¹ standardów rozwi¹zywaæ problemy powstaj¹ce w wyniku stosowania starych sposobów projektowania witryn WWW. Dowiesz siê tak¿e, jak stare i nowe standardy przekszta³caj¹ internet w dynamiczn¹ platformê do tworzenia solidnych, dostêpnych aplikacji oraz piêknych i ³atwych do odnalezienia treœci. Przeczytasz te¿ o tym, jak zapowiada siê przysz³oœæ standardów sieciowych. (cid:129) Prezentacja jêzyków XHTML, HTML 5, CSS. (cid:129) Zasady tworzenia strukturalnego, semantycznego kodu. (cid:129) Realizacja solidnych uk³adów, tworzonych w oparciu o CSS. (cid:129) Tworzenie nieinwazyjnego kodu JavaScript. (cid:129) Dodatkowe informacje dotycz¹ce typografii i dostêpnoœci. (cid:129) Prezentacje kilku projektów, w których pokazujemy sztuczki i rozwi¹zania w zakresie stosowania standardów. W tym przemyœle Jeffrey Zeldman zajmuje miejsce gdzieœ pomiêdzy „Bogiem” a „guru” – i potrafi wykorzystaæ sw¹ m¹droœæ oraz dowcip, by opowiadaæ o tym, CZYM s¹ standardy sieciowe, JAK nale¿y je stosowaæ oraz DLACZEGO powinniœmy zwróciæ na nie uwagê. Kelly Goto, autorka ksi¹¿ki Web ReDesign 2.0: Workflow that Works Czasami, bardzo rzadko, udaje siê znaleŸæ autora, o którym myœlimy sobie: „Ten goœæ jest inteligentny! I sprawia, ¿e ja te¿ czujê siê m¹drzejszy, bo w koñcu zrozumia³em to zagadnienie”. Steve Krug, autor ksi¹¿ek „Nie ka¿ mi myœleæ! O ¿yciowym podejœciu do funkcjonalnoœci stron internetowych” oraz „Przetestuj j¹ sam! Steve Krug o funkcjonalnoœci stron internetowych” Spis treĂci Wstēp do trzeciego wydania ................................................17 CzēħĄ I Zanim zaczniesz ..............................................................25 Przerwanie cyklu starzenia siÚ .................................................................... 26 ¿adnego dogmatu ........................................................................................ 27 Kontinuum, a nie zbiór sztywnych reguï ............................................... 27 Kilka waĝnych definicji ............................................................................... 28 Jeden rozmiar nie bÚdzie dobry dla wszystkich ............................................ 30 Witamy wĂród zwyciÚzców ........................................................................... 31 1. 99,9 witryn wciĎij jest przestarzaãych ...................................35 Nowoczesne przeglÈdarki i standardy sieciowe ............................................ 36 Nowy kod do nowej pracy ............................................................................ 37 Problem „wersji” ......................................................................................... 38 MyĂlenie wsteczne ....................................................................................... 40 Zïy kod: pierwsza siatka za darmo ........................................................ 41 W dïuĝszej perspektywie czasu rozgaïÚzianie kodu moĝe byÊ niebezpieczne dla witryny ............................................................. 43 Ukryte koszty rozbudowanego kodu stron ................................................... 46 ZgodnoĂÊ wstecz jest kïamstwem ................................................................ 47 Blokowanie uĝytkowników nie wpïywa dobrze na interesy ..................... 49 Lek .............................................................................................................. 52 2. Projektowanie i budowanie z uijyciem standardów .....................55 Pokonywanie trudnoĂci ............................................................................... 57 Koszt projektowania przed wprowadzeniem standardów ............................. 58 Nowoczesna strona starymi metodami ........................................................ 59 Trzy elementy standardów sieciowych ......................................................... 66 Struktura .............................................................................................. 66 Prezentacja ........................................................................................... 69 Zachowanie ........................................................................................... 69 6 Projektowanie serwisów WWW. Standardy sieciowe Standardy w praktyce .................................................................................. 69 Projekt standardów sieciowych: przenoĂnoĂÊ w zastosowaniu ...................... 72 Jeden dokument dla wszystkich ............................................................. 73 A List Apart: jedna strona, wiele widoków .................................................. 75 Projektowanie nie tylko z przeznaczeniem na ekran .............................. 77 OszczÚdnoĂÊ czasu i kosztów, wzrost zysków ......................................... 78 Co dalej? ...................................................................................................... 79 3. Delikatna perswazja ..........................................................83 4. PrzyszãoħĄ standardów sieciowych .........................................91 Wyszukiwanie, syndykacja, blogi, podcasty i dïugi ogon (oraz inne powody zwyciÚstwa standardów sieciowych) ................................ 92 Uniwersalny jÚzyk (XML) ..................................................................... 93 Jeden rodzic, wiele dzieci ....................................................................... 94 Zïota ĝyïa innowacji ............................................................................... 98 PrzyszïoĂÊ standardów ........................................................................ 108 Grupa robocza WHAT ............................................................................... 110 Internet Explorer 7 i standardy sieciowe ............................................. 113 NarzÚdzia do edycji i publikacji ........................................................... 114 CzēħĄ II 5. Nowoczesny ukãad znaczników ........................................... 119 Ukryty schemat kiepskiego kodu ............................................................... 125 Przeformuïowanie czego? ..................................................................... 129 Podsumowanie ..................................................................................... 130 XHTML 2 — nie dla kaĝdego ............................................................. 131 5 najwaĝniejszych powodów, dla których warto wybraÊ HTML ................. 133 5 najwaĝniejszych powodów, dla których warto wybraÊ XHTML 1 ........... 134 Podstawowy powód, dla którego nie warto wybieraÊ XHTML-a ................ 134 6. XHTML i kod semantyczny ................................................. 135 Konwersja do XHTML-a: proste zasady, ïatwe wytyczne .......................... 136 Dokument rozpoczynaj od deklaracji DOCTYPE i przestrzeni nazw .....137 Który DOCTYPE to Twój typ? ........................................................... 138 Wersja Strict czy Transitional: wielka bitwa naszych czasów .............. 139 Po DOCTYPE deklaracja przestrzeni nazw ........................................ 140 Zadeklaruj typ kodowania znaków ....................................................... 142 Wszystkie znaczniki pisz maïymi literami ............................................ 144 WartoĂci wszystkich atrybutów umieszczaj w cudzysïowach ................ 146 Przypisuj wartoĂci wszystkim atrybutom ............................................ 148 Zamykaj wszystkie znaczniki ............................................................... 148 Nie umieszczaj podwójnych myĂlników w komentarzach ..................... 150 Koduj wszystkie znaki i ................................................................ 150 Podsumowanie zasad XHTML-a ......................................................... 150 Kodowanie znaków: nudne, bardzo nudne i potwornie nudne .............. 151 Spis treħci 7 Leczenie strukturalne — dla nas bomba ................................................... 153 Sensowne kodowanie dokumentu ......................................................... 153 Elementy wizualne i struktura ............................................................ 159 7. HTML 5: nowa nadzieja ....................................................161 HTML 5 i aplikacje sieciowe: gra idzie o duĝÈ stawkÚ ............................... 162 HTML 5 a XHTML .................................................................................. 164 Niech diabli porwÈ obie nomenklatury ................................................. 164 Parada elementów HTML 5 ...................................................................... 166 Semantyka struktury strony ............................................................... 167 HTML 5 to na razie tylko specyfikacja ............................................... 172 Dowiedz siÚ wiÚcej ............................................................................... 175 8. Struktura i semantyka: gwarancja zwartych i trwaãych stron ........177 div, id i inni pomocnicy .............................................................................. 178 Czym jest element div? ........................................................................ 179 id kontra class ..................................................................................... 180 Twórz treĂÊ uïatwiajÈcÈ wyszukiwanie i stosowanie .................................. 183 Semantyczny kod i wielokrotne uĝycie ................................................. 184 Powszechne bïÚdy w nowoczesnym kodzie ............................................ 187 Znaczniki div sÈ w porzÈdku ............................................................... 190 PokochaÊ atrybut id ............................................................................ 191 WyeliminowaÊ (lub zminimalizowaÊ) style i skrypty w kodzie (X)HTML ............................................................................. 191 Przerwa i powtórka ............................................................................. 192 9. Podstawy CSS ................................................................193 WstÚp do CSS ........................................................................................... 193 KorzyĂci z CSS .......................................................................................... 194 Anatomia stylów ........................................................................................ 195 Selektory, deklaracje, wïaĂciwoĂci i wartoĂci ....................................... 195 WartoĂci ogólne i alternatywne ............................................................ 198 Dziedziczenie i jego przeciwnicy .......................................................... 200 Selektory potomne ............................................................................... 201 Selektory klas ...................................................................................... 203 Style zewnÚtrzne, osadzone i bezpoĂrednie .......................................... 206 Metoda „najlepszego moĝliwego scenariusza” ............................................ 210 10. Ukãady CSS: kod, ramki, elementy pãywajĎce — o rany! ..............213 Dao przepïywu strony ................................................................................ 214 Poznaj model ramkowy .............................................................................. 215 Jak dziaïa model ramkowy? ................................................................. 216 Ukïad stosowany ....................................................................................... 219 Skromne poczÈtki ................................................................................ 220 Magiczny dotyk klasy .......................................................................... 224 Modyfikacja ukïadu ................................................................................... 228 Analiza zawartoĂci — po raz wtóry ..................................................... 229 Tworzenie stylów ................................................................................. 233 8 Projektowanie serwisów WWW. Standardy sieciowe Modyfikacje elementów pïywajÈcych .................................................... 236 Nie zwracamy uwagi na szczegóïy ....................................................... 239 Podsumowanie ........................................................................................... 242 11. Praca z przeglĎdarkĎ. CzēħĄ I: przeãĎczanie z typu dokumentu na tryb standardowy ................ 243 Saga o przeïÈczaniu przez deklaracjÚ typu dokumentu .............................. 244 PrzeïÈcznik do wïÈczania i wyïÈczania standardów .............................. 244 Podstawy przeïÈczania przy uĝyciu deklaracji typu dokumentu ................. 246 Jak dokïadne jest przeïÈczanie? ........................................................... 247 Standardy sieciowe i przeglÈdarka IE8 ............................................... 247 Standardy sieciowe i silnik Gecko ........................................................ 249 Kompletne i niekompletne deklaracje typu dokumentu ....................... 250 Peïna lista kompletnych deklaracji typu dokumentu XHTML ............ 253 Zachowaj prostotÚ ............................................................................... 254 12. Praca z przeglĎdarkĎ. CzēħĄ II: bãēdy, sposoby i blask CSS 3 .............................................. 257 BïÚdy CSS w powtórce na zwolnionych obrotach ....................................... 258 BïÈd podwojonego marginesu w elementach pïywajÈcych .................... 263 Na ratunek obrazkom PNG ................................................................. 265 Co dalej? .............................................................................................. 266 Wiedza to jedynie poïowa sukcesu ....................................................... 268 CSS 3: nowy obiekt zainteresowania .......................................................... 277 Ty i kanaï alfa ..................................................................................... 277 Rezygnujemy z prostokÈtów ................................................................ 280 ProgramiĂci, miejcie siÚ na bacznoĂci! ................................................. 281 PrzemyĂlmy, czym jest „wsparcie”? ..................................................... 285 Flash i QuickTime: obiekty poĝÈdania? ..................................................... 288 Obiekty osadzane: opowieĂÊ o próĝnoĂci i zemĂcie ................................ 288 Podwójna zemsta W3C ........................................................................ 289 Dwie pieczenie na jednym ogniu: osadzanie obiektów multimedialnych przy przestrzeganiu standardów .......................................................... 290 ’yĝka dziegciu w beczce miodu: object nie dziaïa ................................ 291 Szczypta JavaScriptu .......................................................................... 291 ¥wiat, w którym omijanie bïÚdów jest codziennoĂciÈ .................................. 292 13. Praca z przeglĎdarkĎ. CzēħĄ III: typografia ............................. 295 Kilka sïów o typografii ............................................................................... 296 ABC czcionek na stronach WWW .............................................................. 299 Horrory starej szkoïy ........................................................................... 302 Nareszcie standardowy rozmiar ........................................................... 305 Karabiny i piksele ................................................................................ 307 Upojenie wÚszycieli .............................................................................. 308 Przygody z wielkoĂciÈ czcionek .................................................................. 310 PowiÚkszenie: demokracja bezpieczna dla pikseli ................................. 313 Jednostki em: radoĂÊ i pïacz ................................................................ 316 Metoda symbolicznych wartoĂci rozmiarów czcionek ........................... 317 Spis treħci 9 Ja chcÚ czcionki Franklin Gothic! ............................................................. 319 Reguïa @font-face: prawdziwe czcionki na stronach WWW ................ 319 sIFR — dostÚpne podmienienie czcionek ............................................ 322 Cufón — „czcionki dla ludzi” .............................................................. 323 Typekit i bracia ................................................................................... 324 14. DostēpnoħĄ: to, co w standardach najwaijniejsze .....................329 PiÚÊ porad dotyczÈcych tworzenia dostÚpnych witryn ................................ 330 1. Zabierz siÚ do pracy ......................................................................... 330 2. Skorzystaj z logicznej struktury stron ............................................. 331 3. Zapewnij moĝliwoĂÊ dostÚpu przy uĝyciu klawiatury ....................... 331 4. UdostÚpniaj rozwiÈzania alternatywne ............................................ 332 5. Wybierz standard i korzystaj z niego konsekwentnie ....................... 332 DostÚpnoĂÊ wedïug podrÚczników .............................................................. 333 Powszechna dezorientacja ......................................................................... 336 „¥lepy miliarder” ................................................................................ 336 DostÚpnoĂÊ nie ogranicza siÚ jedynie do niedowidzÈcych ..................... 337 WyjaĂniamy znaczenie paragrafu 508 ................................................. 339 Obalamy mity dostÚpnoĂci ......................................................................... 340 Uïatwienia dostÚpu element po elemencie .................................................. 345 Obrazki ............................................................................................... 345 Sprawdzone narzÚdzia ......................................................................... 354 Zachowaj kolejnoĂÊ: nasz dobry znajomy atrybut tabindex .................. 355 Planowanie dostÚpu: jak na tym skorzystasz ....................................... 356 15. Wykorzystanie skryptów opartych na modelu DOM ....................359 DOM wedïug podrÚczników ....................................................................... 360 Co to jest DOM? ........................................................................................ 360 Standardowy sposób na to, by strony WWW zachowywaïy siÚ jak aplikacje .............................................................. 362 Zatem gdzie to dziaïa? ......................................................................... 364 ProszÚ, DOM, nie zrób im krzywdy ........................................................... 365 Jak to dziaïa? ...................................................................................... 365 Sprawdzanie obsïugi ............................................................................ 371 Warianty kodu .................................................................................... 372 PrzeïÈczniki stylów: uïatwiajÈ dostÚp, oferujÈ wybór ........................... 373 Naucz siÚ kochaÊ swojÈ bibliotekÚ (JavaScript) ......................................... 375 Jak korzystaÊ z DOM? .............................................................................. 378 16. Przeprojektowywanie witryny ............................................379 Wychodzimy z przeszïoĂci .......................................................................... 382 Projektowanie wychodzÈce od treĂci .......................................................... 383 TrochÚ oddechu ................................................................................... 387 Czcionki, wprowadzenia i wpuszczone inicjaïy ..................................... 388 CiÈgle ta sama Ăpiewka ....................................................................... 394 Mania stopek ....................................................................................... 394 Gïowa do góry ..................................................................................... 400 Szczegóïy, szczegóïy ............................................................................ 402 10 Projektowanie serwisów WWW. Standardy sieciowe 17. NYMag.com: proste standardy, seksowny interfejs ................... 405 Zestawienie zawartoĂci .............................................................................. 407 Od spisu zawartoĂci do strategii .......................................................... 412 Przyjaciele, jeszcze raz wróÊmy do kodu .................................................... 414 Od nawiasów kÈtowych do klamrowych ..................................................... 417 Metody — czyste szaleñstwo ............................................................... 422 Porozmawiaj z DOM ................................................................................. 425 Poznaj element colgroup ...................................................................... 425 Skorzystajmy z jQuery ........................................................................ 426 Standardy na kaĝdÈ porÚ roku ................................................................... 432 Skorowidz .................................................................... 433 Ukryty schemat kiepskiego kodu 119 ROZDZIAâ PIčTY Nowoczesny ukïad znaczników C zÚĂÊ pierwsza nakreĂliïa w skrócie problemy biznesowe i produk- cyjne bÚdÈce wynikiem stosowania starych metod projektowa- nia sieci, naszkicowaïa korzyĂci pïynÈce ze stosowania standardów oraz odmalowaïa radosny obraz napÚdzanego standardami rozwoju sieci. W pozostaïej czÚĂci ksiÈĝki przejdziemy „od ogóïu do szczegóïu”. Najlepszym sposobem, by zaczÈÊ, bÚdzie poĂwiÚcenie kilku sekund na przeanalizowanie podstawowych zagadnieñ zwiÈzanych z tworze- niem kodu stron, takich jak wybór wersji jÚzyka, jakÈ naleĝy stosowaÊ, oraz sposoby kodowania niektórych, doskonale znanych, elementów stron: nagïówków, akapitów i list (podpowiedě: chodzi o to, jak to robiÊ prawidïowo semantycznie). Wielu projektantom i programistom myĂl o ponownym analizowaniu kodu nie przypadnie do gustu. Z pewnoĂciÈ kaĝdy, kto spÚdziï na pro- jektowaniu witryn wiÚcej niĝ kilka tygodni, wie doskonale, o co chodzi w starym, dobrym HTML-u. Czy nie powinniĂmy poĂwiÚcaÊ naszego ograniczonego wolnego czasu, uczÈc siÚ nowszych, uĝyteczniejszych jÚzyków? Czy na przykïad nie opïaca siÚ bardziej studiowaÊ techno- logii dziaïajÈcych po stronie serwera, takich jak PHP i jej podobne. Odpowiedě brzmi: „Tak i nie”. Technologie dziaïajÈce po stronie serwera majÈ istotne znaczenie przy tworzeniu dynamicznych wi- tryn odpowiadajÈcych na zapytania uĝytkownika. Nawet tradycyjne witryny informacyjne mogÈ odnieĂÊ korzyĂci przez umieszczenie ich 120 Rozdziaã 5. Nowoczesny ukãad znaczników treĂci w bazie danych i odwoïywanie siÚ do nich w miarÚ potrzeby przy uĝyciu PHP lub podobnych technologii. Niemal kaĝda nowoczesna witryna korzysta z takich technologii, nawet skromny i niepozorny blog. Podobnie do standardów przedstawianych w tej ksiÈĝce, jÚzyki skryptowe wykonywane po stronie serwera oraz szkielety do tworzenia aplikacji, takie jak Ruby on Raili, CakePHP, Dijango czy Symfony, umoĝliwiajÈ oddzielanie danych od interfejsu. Tak jak CSS, które niwelujÈ koniecznoĂÊ umieszczania wszyst- kich fragmentów treĂci w pozbawionych semantycznego znaczenia komór- kach tabel HTML, tak jÚzyki, na przykïad PHP, i systemy zarzÈdzania relacyjnymi bazami danych (jak choÊby MySQL) pozwalajÈ twórcom witryn uniknÈÊ wïasnorÚcznego pisania kaĝdej ze stron. Co to takiego to PHP? PHP (www.php.net) jest darmowym jÚzy- kiem skryptowym ogólnego przeznaczenia, który idealnie nadaje siÚ do tworzenia stron internetowych i moĝe byÊ osadzany wewnÈtrz kodu HTML i XHTML. (Kod PHP moĝna takĝe umieszczaÊ wewnÈtrz kodu HTML). Jego skïadnia przypomina jÚzyki, takie jak C, Java oraz Perl, i jest wzglÚdnie ïatwa do przyswojenia. PHP (skrót od Hypertext Preprocessor1) jest bardzo funkcjonalny, ale swojÈ popular- noĂÊ zyskaï gïównie dziÚki moĝliwoĂci wspóïpracy z bazÈ danych MySQL (www. mysql.com). Cecha ta pozwala progra- mistom i projektantom w ïatwy sposób tworzyÊ dynamiczne strony i budowaÊ aplikacje sieciowe. PHP stanowi projekt fundacji Apache (www.apache.org) i moĝe byÊ uĝywany zupeïnie za darmo, co stanowi jedno ze ěródeï jego ogromnej popularnoĂci. Innym jest ogromny zestaw narzÚdzi do testo- wania i profilowania2 kodu. Niezaleĝni projektanci i programiĂci uwielbiajÈ ten jÚzyk (bÈdě uwielbiali, zanim nie poznali jego mïodszego kuzyna — Ruby) i wyko- rzystujÈ go nieustannie do tworzenia coraz to nowych stron i produktów (patrz rysu- nki 5.1 i 5.2). Z powodu jego skalowal- noĂci (nie wspominajÈc o braku opïat) duĝe firmy, rzadko znane ze stosowania otwartych standardów, pokochaïy PHP. Przykïadowo PHP napÚdza Yahoo.com juĝ od 2002 roku (ostatnio jest przy tym uĝywany otwarty szkielet PHP o nazwie Symfony [http://www.symfony-project. org]). Równieĝ IBM wsparï PHP swÈ potÚgÈ, gïównie za poĂrednictwem formy Zend i szkieletu CakePHP (http://www. internetnews. com/ent-news/article.php/ 3485806). 1 Mianem preprocesora okreĂla siÚ program wstÚpnie analizujÈcy kod. Dla przykïadu w jÚzyku C preprocesor uruchamiany jest przed wïaĂciwÈ kompilacjÈ, aby dokonaÊ odpowiednich podstawieñ w kodzie — przyp. tïum. 2 Przez profilowanie naleĝy rozumieÊ badanie wydajnoĂci kodu (jako caïoĂci lub poszczególnych jego fragmentów) — przyp. tïum. Ukryty schemat kiepskiego kodu 121 Rysunek 5.1. Projektant i programista Shaun Inman uĝyï PHP, MySQL, JavaScript i CSS do stworzenia Mint (havemint.com), rozszerzalnego narzÚdzia do raportowania potrafiÈcego odpowiedzieÊ, kto odwiedza i tworzy odnoĂniki do Twojej witryny, z jakiej przeglÈdarki korzysta i duĝo wiÚcej Rysunek 5.2. Typowa instalacja Mint (widoczna tutaj pochodzi z witryny konferencji Event Apart) 122 Rozdziaã 5. Nowoczesny ukãad znaczników Co to takiego to PHP? — ciĎg dalszy PHP moĝe wspóïpracowaÊ z oprogramo- waniem serwerowym Microsoftu, ale naj- czÚĂciej uĝywany jest w poïÈczeniu z serwe- rem Apache. Apache pracuje zarówno na platformach Windows, jak i Unix (ze wska- zaniem na te drugie). System operacyjny OS X firmy Apple ma wbudowany jÚzyk PHP i serwer Apache, podobnie z resztÈ jak niemal wszystkie dystrybucje Linuksa. PHP nie wymaga budowania interfejsu przy uĝyciu ukïadu CSS i poprawnego semantycznego kodu znaczników, ale tam, gdzie trafiamy na oparte na standardach strony sieciowe, bardzo czÚsto okazuje siÚ, ĝe stoi za nimi PHP. Jednak nawet dynamicznie wygenerowane strony stanÈ siÚ bezuĝyteczne, jeĝeli bÚdÈ niedostÚpne, niezgodne z wieloma przeglÈdarkami i urzÈdzeniami lub zaĂmiecone niepotrzebnym kodem znaczników. Jeĝeli dynamiczna strona nie wyĂwietli siÚ poprawnie w jakiejĂ przeglÈdarce lub jej zaïadowanie zajmie 60 sekund przez ïÈcze modemowe, w sytuacji gdy wystarczyïoby w zupeïnoĂci 10 sekund, technologie serwerowe na niewiele siÚ zdadzÈ Twoim uĝytkownikom. JeĂli dodatkowo uĝytkownicy i wyszukiwarki nie bÚdÈ w stanie znaleěÊ na witrynie interesujÈcych ich informacji, gdyĝ zostaïy zagrzebane wewnÈtrz semantycznie bezsensownego kodu, wszystkie wysiïki wïoĝone w utworzenie piÚknego projektu, napisanie witryny i zapewnienie jej odpowiedniej obsïugi ze strony mechanizmów dziaïajÈcych po stronie serwera bÚdzie moĝna porównaÊ do genialnych muzyków wystÚpujÈcych przed pustÈ widowniÈ. Czym jest Rails? Ruby on Rails (www.rubyonrails.org) jest szkieletem do budowania aplikacji siecio- wych dostÚpnym na licencji otwartego kodu, zoptymalizowanym pod kÈtem szybkiego, produktywnego, stabilnego programowania (patrz rysunek 5.3). Czym jest Ruby? Dobre pytanie. Ruby jest zorientowanym obiektowo jÚzykiem programowania stwo- rzonym przez Yukihiro Matsumoto w 1995 roku i rozpowszechnianym jako wolne oprogramowanie na licencji open source. ’Èczy w sobie skïadniÚ inspirowanÈ jÚzy- kami Perl i Ada z funkcjami obiektowymi oraz posiada wspólne cechy z jÚzykami Lisp i Python Zatem czym jest Rails? Rails jest szkiele- tem aplikacji dziaïajÈcym w oparciu o mo- del projektowy MVC (ang. model-view- controller — model-widok-kontroler), napi- sanym w jÚzyku Ruby przez Davida Heine- meira Hanssona w lipcu 2004 roku. Rails zostaï wyodrÚbnionym z aplikacji Base- camp firmy 37signals (patrz rysunek 5.4). Ukryty schemat kiepskiego kodu 123 Rysunek 5.3. Ruby on Rails (www.rubyonrails.org) dostÚpny w postaci otwartych ěródeï szkielet programistyczny. Jego podstawowe zasady to: „Nie powtarzaj siÚ” oraz „Konwencja ponad konfiguracjÚ” Rysunek 5.4. Basecamp firmy 37signals (basecamphq.com) to nieustajÈce ěródïo prezentów. Nie tylko jest to wspaniaïa aplikacja do zarzÈdzania projektami, ale równieĝ aplikacja, z której wyodrÚbniono Ruby on Rails (Wersja 1.0 zostaïa opublikowana w po- staci otwartego kodu ěródïowego w grud- niu 2005 roku). ProgramiĂci rzucili siÚ na niego, poniewaĝ jego przewodnie zasady pozwalajÈ szybciej pisaÊ lepszy kod. 124 Rozdziaã 5. Nowoczesny ukãad znaczników Czym jest Rails? — ciĎg dalszy W wiÚkszoĂci Ărodowisk programistycznych trzeba napisaÊ tuzin wierszy kodu, aby przenieĂÊ zmiennÈ na ekran (lub z ekranu). I to samo powtarza siÚ za kaĝdym razem podczas tworzenia nowego programu, dla kaĝdej najmniejszej rzeczy, jakÈ robi ten program. To tak, jakby trzeba byïo pisaÊ edytor tekstu zawsze wtedy, kiedy chcemy wysïaÊ oficjalny list. Ruby on Rails odrzuca ten model. WewnÈtrz Rails programiĂci nie muszÈ juĝ kodowaÊ obsïugi kaĝdego najmniejszego szczegóïu — muszÈ jedy- nie skonfigurowaÊ to, co jest niekonwen- cjonalne. Podobnie jak PHP, Ruby nie wymaga budowania interfejsu zgodnie ze standardami, ale te dwa elementy idÈ w parze duĝo czÚĂciej niĝ osobno. PoïÈcze- nie XHTML-a, CSS, JavaScriptu i Ruby on Rails zapewnia dziaïanie wielu popu- larnych aplikacji internetowych, takich jak Twitter (patrz rysunek 5.5). Ruby on Rails jest takĝe z powodzeniem wykorzystywany w tradycyjnych aplikacjach internetowych, na przykïad yellowpages.com (patrz rysu- nek 5.6). Inne jÚzyki programowania — wĂród nich PHP i Python — takĝe udo- stÚpniajÈ szkielety aplikacji MVC, podobne do Ruby on Rails. Rysunek 5.5. Twitter (www.twitter.com), niezwykle popularna aplikacja do dystrybucji mikrowiadomoĂci, powstaïa przy uĝyciu CSS, XHTML 1.0 Strict oraz Ruby on Rails Ukryty schemat kiepskiego kodu 125 Rysunek 5.6. PoÊwicz trochÚ palce, przeszukujÈc ksiÈĝkÚ telefonicznÈ Yellow Pages (www. yellowpages.com), napisanÈ w XHTML 1.0 Transitional i korzystajÈcÈ z Ruby on Rails Krótko mówiÈc, nie moĝna rozdzielaÊ obu technologii. Technologie dziaïajÈce po stronie serwera w poïÈczeniu z bazami danych umoĝliwiajÈ tworzenie sprytniejszych, bardziej funkcjonalnych stron, ale to, co dostarczajÈ te strony, jest zawartoĂciÈ, która dziaïa najlepiej, kiedy posiada czystÈ i prostÈ strukturÚ. I wïaĂnie w tym miejscu wiÚkszoĂÊ z nas zawodzi (ale zawodzi takĝe wiele sys- temów do zarzÈdzania zawartoĂciÈ, na których polegamy). Ukryty schemat kiepskiego kodu W trakcie pierwszej dekady istnienia przemysïu sieciowego projektowanie przypominaïo próbÚ nakarmienia mnóstwa wybrednych dzieci. Aby zbu- dowaÊ dziaïajÈcÈ stronÚ, posïusznie uczyliĂmy siÚ „diety” kaĝdej przeglÈ- darki. Obecnie wszystkie przeglÈdarki akceptujÈ to samo poĝywne jedzonko, a robiÈ to od 2001 roku, ale wielu programistów jeszcze tego nie zrozu- miaïo i wciÈĝ dosypuje cukier do jajecznicy. Zïe jedzenie zatyka arterie, niszczy zÚby i zmniejsza ĝywotnoĂÊ tych, którzy je spoĝywajÈ. Zïy kod znaczników jest szkodliwy dla krótkoterminowych potrzeb uĝytkowników oraz dïugoterminowego zdrowia zawartoĂci stron. Do niedawna jednak fakt ten byï przed nami ukrywany wskutek tolerowa- nia przez popularne przeglÈdarki zaĂmieconego i bïÚdnego kodu, o czym mówiïem w rozdziale 1. Tu oraz w kolejnych rozdziaïach bÚdziemy odkrywaÊ na nowo zapomnianÈ naturÚ czystego, semantycznego ukïadu znaczników oraz nauczymy siÚ 126 Rozdziaã 5. Nowoczesny ukãad znaczników Inne platformy, inne obszary Dwie inne platformy skryptowe uĝywane do tworzenia dynamicznych stron i seksownych aplikacji sieciowych to Microsoft Active Server Pages .NET 2.0 (www.asp.net) oraz Adobe ColdFusion 8 (www.adobe. com/software/coldfusion/). Kaĝda z nich ma swoje mocne strony oraz zagorzaïe Ărodowisko uĝytkowników. Java Serve Pages (JSP), jeszcze jedna technologia dynamiczna, jest powszechnie stosowana w ogrom- nych systemach dla przedsiÚbiorstw i zdecydowanie wykracza poza zakres tej ksiÈĝki. Systemy do publikacji utworzone w niektórych z wymienionych jÚzyków mogÈ przy braku uwagi popsuÊ szablony stron przygotowane zgodnie ze standardami. W jednej z aplikacji, w tworzenie której zaangaĝowana byïa moja agencja, ASP (przed .NET 2.0) generowaï wszystko niepo- prawnie, dopóki nie wïÈczyliĂmy do procesu HTML Tidy (tidy.sourceforge. net). Przypominaïo to obrzucanie bïotem czystych ubrañ, a nastÚpnie mycie ich wÚĝem, ale pozwalaïo uzyskaÊ poprawne strony z systemu, który byï nieprzyjazny dla dobrego, czystego kodu. PomijajÈc juĝ HTML Tidy, bardzo pomocne przy wprowadzaniu danych do systemów CMS moĝe siÚ okazaÊ wykorzystanie takich narzÚdzi jak TinyMCE (tinymce.moxicode.com) lub WYMEditor (www.wymeditor.org). IstniejÈ takĝe jÚzyki „quasi-znacznikowe”, takie jak Textile Deana Allena (www.redcloth.org/hobix.com) lub Markdown Johna Brubera (www. daringfireball.net/projects/markdown), które takĝe mogÈ pomóc osobom nieobeznanym z HTML-em w tworzeniu prawidïowego, zgodnego ze standardami kodu. myĂleÊ strukturalnie, zamiast postrzegaÊ kod znaczników jako drugorzÚdne narzÚdzie projektowania. JednoczeĂnie przyjrzymy siÚ XHTML-owi 1.0 — standardowemu jÚzykowi do projektowania witryn. Poznamy jego cele oraz korzyĂci wynikajÈce z jego stosowania. Opracujemy strategiÚ przejĂcia z HTML-a na XHTML. Przyjrzymy siÚ takĝe nowemu graczowi na rynku — jÚzykowi HTML 5 (www.w3.org/TR/html5). SYNDROM B’}DNYCH ADRESÓW URL JÚzyki skryptowe czÚsto generujÈ dïugie adresy URL zawierajÈce niezakodowane znaki , zastrzeĝone w HTML/XHTML. W HTML-u i XHTML-u znak uĝywany jest do wskazania encji znakowej, takiej jak #8217;, która oznacza poprawny typograficznie znak apostrofu w kodzie Unicode. Moĝna to naprawiÊ, stosujÈc funkcjÚ ColdFusion o nazwie Ukryty schemat kiepskiego kodu 127 URLEncodeFormat(). ASP posiada podobnÈ funkcjÚ o nazwie HTMLEncode. Z kolei jÚzyk PHP udostÚpnia funkcje urlencode() (http://php.net/ manual/pl/function.urlencode.php), rawurlencode() (http://php.net/ manual/pl/function.rawurlencode.php) oraz htmlentities() (http://php.net/ manual/pl/function.htmlentities.php). We wszystkich tych przypadkach programiĂci mogÈ (i powinni) unikaÊ problemu, przepuszczajÈc wszystkie adresy URL przez wymienione funkcje przed umieszczeniem ich w kodzie strony. Dziwnym zbiegiem okolicznoĂci jest to, ĝe poprawne kodowanie z uĝyciem XHTML-a zachÚca do pisania kodu w sposób strukturalny i zniechÚca do tworzenia prezentacyjnych „sztuczek”. W XHTML 1.0 Transitional takie sztuczki sÈ uwaĝane za przestarzaïe, co oznacza, ĝe moĝesz je stosowaÊ, jeĂli musisz, ale jesteĂ zachÚcany do osiÈgania tego samego rezultatu w inny sposób — na przykïad przy uĝyciu CSS. W XHTML 1.0 i 1.1 Strict sztuczki prezentacyjnie sÈ oficjalnie zabronione. Ich zastosowanie sprawi, ĝe strona przepuszczona przez usïugÚ weryfikujÈcÈ poprawnoĂÊ kodu W3C (nazywanÈ walidatorem) nie przejdzie testu (patrz rysunek 5.7). (Jeĝeli nie poznaïeĂ jeszcze tego narzÚdzia, zrobisz to z pewnoĂciÈ, kiedy nauczysz siÚ projektowaÊ i budowaÊ strony z uĝyciem standardów. Patrz ramka „Sprawdě to!”). Rysunek 5.7. Projektanci i programiĂci korzystajÈ z darmowej usïugi sprawdzajÈcej poprawnoĂÊ kodu oferowanej przez W3C (validator.w3c.org), aby siÚ upewniÊ, czy ich strony sÈ zgodne ze standardami Niezaleĝnie od tego, czy wybierzesz XHTML, czy Strict lub Transitional, doĂwiadczysz uczÈcego pokory odkrycia, ĝe „caïa Twoja wiedza jest zïa”: ïamanie wierszy (br) stosowane do symulowania listy, nagïówki wymuszajÈce 128 Rozdziaã 5. Nowoczesny ukãad znaczników Sprawdı to! Usïuga weryfikowania poprawnoĂci stron (validator.w3.org) testuje strony zbudowane przy uĝyciu XHTML-a 4.01, XHTML-a 1.0 oraz XHTML-a 1.1 i ocenia ich zgodnoĂÊ ze specyfikacjÈ jÚzyka. Usïuga weryfikujÈca CSS (jigsaw.w3.org/css-validator) robi to samo w odnie- sieniu do arkuszy stylów. Grupa zajmujÈca siÚ projektowaniem sieci w htmlhelp.com utrzymuje równie niezawodnÈ usïugÚ do sprawdzania ukïadu znaczników (www.htmlhelp.com/tools/validator). Wszystkie trzy usïugi oferowane sÈ caïkowicie za darmo. Rada: HTML-owi maniacy — jeĂli zajmujecie siÚ juĝ HTML-em 5, pamiÚtajcie, ĝe nie wszystkie walidatory bÚdÈ prawidïowo sprawdzaÊ wasze strony. JednÈ z usïug, która to potrafi, jest walidator HTML 5 dostÚpny na stronie validator.nu (patrz rysunek 5.8). Takĝe Validation Service W3C jest juĝ w stanie sprawdzaÊ poprawnoĂÊ kodu HTML 5. Cieszcie siÚ i radujcie! Rysunek 5.8. ByÊ moĝe ta strona nie jest szczególnie piÚkna, jednak validator.nu jest uĝytecznym narzÚdziem, które sprawdza poprawnoĂÊ kodu XML, HTML 5, itd. (www.validator.nu) okreĂlony sposób wyĂwietlania, przezroczyste obrazki GIF do tworzenia biaïej przestrzeni... BÚdziesz zaszokowany faktem, ĝe kiedyĂ stosowaïeĂ tego typu sztuczki. Zamiast korzystaÊ z prezentacyjnych sztuczek, zaczniesz myĂleÊ struktu- ralnie. Pozwolisz kodowi znaczników, by peïniï swojÈ rolÚ. Nawet w ukïa- dach hybrydowych, stosujÈcych tabele oraz inne elementy do prezentacji, Ukryty schemat kiepskiego kodu 129 nauczysz siÚ robiÊ wiÚcej przy uĝyciu CSS — na przykïad usuwaÊ zïoĝone i nadmiarowe znaczniki koloru oraz atrybuty komórek tabel i zastÚpowaÊ je jednÈ lub dwoma reguïami w globalnym arkuszu stylów. W miarÚ pozna- wania nowego jÚzyka kodowania bÚdziesz zapominaÊ stopniowo o zïych przy- zwyczajeniach. Przejděmy zatem do rzeczy. Przeformuãowanie czego? Powoïamy siÚ na W3C i zacytujemy: „XHTML (www.w3.org/TR/xhtml1) jest przeformuïowaniem HTML-a w XML”. MówiÈc proĂciej i mniej pre- cyzyjne, XHTML jest jÚzykiem znaczników bazujÈcym na XML-u i dzia- ïajÈcym oraz wyglÈdajÈcym jak HTML z kilkoma maïymi, lecz znaczÈ- cymi róĝnicami. W przeglÈdarkach oraz innych klientach uĝytkownika XHTML 1.0 dziaïa dokïadnie tak samo jak HTML, chociaĝ niektóre nowo- czesne przeglÈdarki mogÈ traktowaÊ ten jÚzyk nieco odmiennie — o czym piszemy w nastÚpnym rozdziale. Z punktu widzenia projektantów i pro- gramistów, pisanie w XHTML-u 1.0 przypomina do zïudzenia pisanie w jÚzyku HTML — tyle ĝe z trochÚ bardziej Ăcisïymi reguïami i jednym lub dwoma nowymi elementami, o których za chwilÚ. W rozdziale 4. opisaliĂmy XML (ang. eXtensible Markup Language) jako „superjÚzyk”, z którego programiĂci mogÈ wywodziÊ inne, dostosowane do wïasnych potrzeb jÚzyki znaczników. XHTML (ang. eXtensible Hypertext Markup Language) jest jednym z takich jÚzyków. XHTML 1.0 jest pierwszÈ i najbardziej zgodnÈ wstecz wersjÈ XHTML-a, stÈd teĝ najlepiej nadaje siÚ do nauki i sprawia najmniej kïopotu starszym przeglÈdarkom. Inne aplikacje i protokoïy bazujÈce na XML-u liczone sÈ w setkach, a ich popularnoĂÊ bazuje miÚdzy innymi na zdolnoĂci do wymiany i transformo- wania danych przy minimalnym koszcie oraz zaledwie kilku (o ile w ogóle) kïopotach ze zgodnoĂciÈ — cnotach, jakie dzielÈ z XHTML-em. PoĂród tych protokoïów wymieniÊ moĝna Rich Site Summary (blogs.law.harverd. edu/tech/rss), Scalable Vector Graphics (www.w3.org/TR/SVG), Synchro- nized Multimedia Integration Language (www.w3.org/TR/REC-smil) i Resource Description Framework (www.w3.org/RDF). (WiÚcej informacji o tych jÚzykach moĝna znaleěÊ w rozdziale 4.). Kaĝdy z tych protokoïów peïni rolÚ w rozwijajÈcej siÚ sieci, ale ĝaden z nich nie jest tak istotny dla projektantów i programistów jak XHTML — i ĝaden z nich nie jest teĝ równie prosty. Po co w ogóle „przeformuïowywaÊ” HTML na XML lub cokolwiek innego? Z jednego powodu — XML jest jÚzykiem spójnym, czego nie moĝna 130 Rozdziaã 5. Nowoczesny ukãad znaczników powiedzieÊ o HTML-u. Jeĝeli w XML-u otworzysz znacznik, musisz go zamknÈÊ. W HTML-u niektóre znaczniki nigdy nie sÈ zamykane, inne zaw- sze, jeszcze inne zaleĝnie od woli programisty. Ta niekonsekwencja moĝe spowodowaÊ praktyczne problemy. Przykïadowo niektóre przeglÈdarki mogÈ odmówiÊ wyĂwietlania strony HTML, która pozostawia niedomkniÚte komórki tabeli, mimo ĝe specyfikacja HTML pozwala na takÈ praktykÚ. XHTML zmusza do zamykania wszystkich elementów, zatem unika siÚ problemów z przeglÈdarkami i oszczÚdza czas niezbÚdny na testowanie oraz usuwanie usterek. Nie trzeba równieĝ pamiÚtaÊ, które znaczniki naleĝy zamykaÊ, a które nie. Co waĝniejsze, jeĝeli napiszesz stronÚ w jÚzyku bazujÈcym na XML-u, bÚdzie ona lepiej wspóïdziaïaïa z innymi jÚzykami, aplikacjami i protokoïami opar- tymi na XML-u. Skoro XML jest tak waĝny, czemu nie napisaÊ jÚzyka opartego na XML-u, który bÚdzie dziaïaï dokïadnie tak jak HTML? XML jest potÚĝny i wszech- obecny, nie moĝna jednak zaserwowaÊ przeglÈdarce danych w surowej postaci XML-a i oczekiwaÊ, ĝe zrobi z nimi coĂ inteligentnego, na przykïad wyĂwietli ïadnie sformatowanÈ stronÚ internetowÈ. Niestety, starsze prze- glÈdarki nie poradzÈ sobie z wyĂwietleniem strony napisanej w XML-u. W istocie zatem XHTML jest technologiÈ poĂredniÈ, ïÈczÈcÈ potÚgÚ XML-a (w pewnej czÚĂci) z prostotÈ jÚzyka HTML (w wiÚkszoĂci). Podsumowanie MówiÈc ogólnie, XHTML to XML dziaïajÈcy jak HTML w starych i nowych przeglÈdarkach oraz w wiÚkszoĂci urzÈdzeñ internetowych, poczynajÈc od antycznych, takich jak Newton (produkowany w latach 90. ubiegïego wieku), poprzez urzÈdzenia Palm, aĝ po iPhony. Praktyczna, przenoĂna i wydajna technologia. XHTML jest równie prosty jak HTML — trochÚ prostszy dla poczÈtku- jÈcych, którzy nie posiadajÈ zïych przyzwyczajeñ i byÊ moĝe ciut trudniej- szy dla weteranów zajmujÈcych siÚ projektowaniem od samego poczÈtku lat 90. ubiegïego stulecia. XHTML jest aktualnym standardem (zastÚpujÈcym HTML 4), który ma na celu przywrócenie rygorystycznej, logicznej struktury i zawartoĂci doku- mentu zapewniajÈcej lepsze wspóïdziaïanie z innymi standardami siecio- wymi, takimi jak CSS i DOM, oraz dobrÈ wspóïpracÚ z innymi istniejÈcymi i przyszïymi jÚzykami, aplikacjami oraz protokoïami bazujÈcymi na XML-u. Ukryty schemat kiepskiego kodu 131 Lista wszystkich korzyĂci pïynÈcych ze stosowania XHTML-a zostaïa zamieszczona na koñcu rozdziaïu. WERSJA STRICT CZY TRANSITIONAL? W pierwszych dwóch wydaniach tej ksiÈĝki zalecaliĂmy stosowanie wersji XHTML 1.0 Transitional jako najbardziej wyrozumiaïej spoĂród wszystkich wersji tego jÚzyka, najbardziej zbliĝonej do tradycyjnych metod tworzenia stron oraz najïatwiejszej do poznania i zastosowania. JeĂli starasz siÚ oduczyÊ starych nawyków lub chcesz uaktualniÊ istniejÈce witryny w ïagodny i spokojny sposób, XHTML 1.0 Trasitional bÚdzie najlepszym z moĝliwych wyborów. Jednak z drugiej strony, aktualnie wiÚkszoĂÊ zwolenników przestrzegania standardów preferuje tworzenie stron w bardziej rygorystycznej wersji XHTML 1.0 Strict bÈdě teĝ, jeĂli sÈ w stanie generowaÊ odpowiednie typy MIME dla wszystkich przeglÈdarek, z wyjÈtkiem Internet Explorera, w wersji XHTML 1.1 Strict. Wybór wersji Strict jako domyĂlnej jest czÚĂciowo kwestiÈ mody — to sposób pokazania caïemu Ăwiatu (albo przynajmniej tej jego czÚĂci, która zaprzÈta sobie gïowÚ oglÈdaniem kodu ěródïowego odwiedzanych stron), ĝe nie uznajemy kompromisów, jeĂli chodzi o stosowanie standardów. Zasadniczo to nic zïego. XHTML 2 — nie dla kaijdego W momencie wydania pierwszej edycji tej ksiÈĝki wersja robocza specyfi- kacji XHTML 2.0 zostaïa przekazana do konsultacji spoïecznoĂci projek- tantów i programistów. Kiedy zaczynaliĂmy pracÚ nad trzecim wydaniem szeĂÊ lat póěniej XHTML 2.0 jest nadal wersjÈ roboczÈ (www.w3.org/ TR/xhtml2) i nie zostaï zaktualizowany od trzech lat. Mogïoby to Ăwiad- czyÊ o tym, ĝe Ăwiat nie dopomina siÚ XHTML-a 2. I faktycznie, choÊ w jego specyfikacji moĝna znaleěÊ kilka fascynujÈcych rozwiÈzañ, jednak nigdy nie znalazï wielkiego poklasku w spoïecznoĂci programistów. 2 lipca 2009 roku W3C skróciïo mÚki XHTML-a 2 (http://www.w3.org/News/2009# item119), zamykajÈc prace nad nim, a spoïecznoĂÊ osób zainteresowanych standardami oszalaïa z wĂciekïoĂci (http://www.zeldman.com/2009/07/07/ in-defense-of-web-developers/). Gïównym celem XHTML 2.0 byïo zbliĝenie siÚ do semantycznego ideaïu, nawet za cenÚ wyrzucenia na Ămietnik dotychczasowych metod progra- mowania. PoczÈtkowa wersja byïa faktycznie bardzo purystyczna. Z zaïoĝe- nia XHTML 2.0 nie byï zgodny wstecz z HTML lub XHTML 1.0. Porzu- caï znajome konwencje, takie jak element img (zastÚpowany przez element 132 Rozdziaã 5. Nowoczesny ukãad znaczników object), znacznik br (zastÚpowany przez nowy element line, zamieniony póěniej na l) oraz wiekowy znacznik zakotwiczenia; zamiast niego otrzymu- jemy do dyspozycji technologiÚ zwanÈ hlink. ProgramiĂci tak bardzo narzekali na tÚ ostatniÈ zmianÚ, ĝe w póěniejszej wersji element a zostaï przywrócony. Ale w skorygowanym XHTML2 kaĝdy element bÈdě grupa elementów strony mogïy posiadaÊ atrybut href. Naleĝy zwróciÊ uwagÚ, ĝe wielu programistom niezwykle spodobaïa siÚ moĝliwoĂÊ dodania atrybutu href do kaĝdego elementu strony; rozwiÈzanie to zostaïo póěniej wykorzystane w HTML-u 5, nastÚpcy XHTML-a 1.0, którym obec- nie pasjonuje siÚ sporo dzieciaków. Problem polega jednak na tym, ĝe aktu- alnie wiÚkszoĂÊ przeglÈdarek obsïuguje atrybuty href umieszczane jedynie w elementach a. JeĂli chodzi o img, to w koñcu udaïo mu siÚ wróciÊ do XHTML 2 (http://www. w3.org/TR/xhtml2/mod-image.html#sec_20.1), zostaï jednak uznany za przestarzaïy. WciÈĝ zamiast niego powinniĂmy uĝywaÊ object, chociaĝ od dawna wiadomo, ĝe object nie dziaïa w Internet Explorerze z wyjÈtkiem wersji IE8. (Moĝna to takĝe wyraziÊ w bardziej uprzejmy sposób, mianowi- cie tak: to fajnie, ĝe IE8 w koñcu obsïuguje element object). Niektórzy projektanci przywitali proponowanÈ specyfikacjÚ XHTML 2 okrzykami radoĂci. Inni narzekali, ĝe wydaje siÚ zbytnio bujaÊ w obïokach, a za maïo skupia siÚ na faktycznych problemach tworzenia stron. (No dobrze, to chyba nam siÚ wyrwaïo). WiÚkszoĂÊ projektantów nie przywiÈzywaïa do niej wcale uwagi. SzeĂÊ lat póěniej wszyscy, poza garstkÈ nowatorów, nadal jÈ ignorujÈ. Zamiast obsïugiwaÊ i rozwijaÊ dwa standardy „jÚzyków znacz- nikowych przyszïoĂci”, spoĂród których tylko jeden interesowaï spoïecz- noĂÊ twórców stron WWW, W3C podjÚïo caïkiem sensownÈ decyzjÚ, by zakoñczyÊ prace nad XHTML 2.0. ByÊ moĝe XHTML 2.0 jest juĝ martwym pomysïem, jednak nie musimy siÚ tym martwiÊ. ¿adna z przeglÈdarek nie przestanie bowiem obsïugiwaÊ XHTML-a 1. Podobnie, ĝadna z przeglÈdarek nie przestanie obsïugiwaÊ HTML-a 4. Witryny napisane poprawnie i zgodnie ze specyfikacjÈ HTML 4.01 bÚdÈ prawidïowo wyĂwietlane jeszcze przez dïugie lata. To samo dotyczy witryn napisanych prawidïowo i zgodnie ze specyfikacjÈ XHTML 1. Jednak po co uĝywaÊ XHTML-a, skoro w przyszïoĂci jÚzykiem do tworzenia stron WWW ma byÊ HTML 5? To caïkiem zasadne pytanie, które twórcy stron uĝywajÈcy HTML-a od ponad dekady niejednokrotnie sobie zada- wali. Gdyby XHTML 5 miaï siÚ pojawiÊ niebawem, a wszystkie przyszïe wersje przeglÈdarek miaïy obsïugiwaÊ wszystkie jego nowoĂci (zaczynajÈc 5 najwaijniejszych powodów, dla których warto wybraĄ HTML 133 do elementów strukturalnych, takich jak footer, a koñczÈc na atrybutach href dodawanych do dowolnych elementów strony), to faktycznie zawracanie gïowy naukÈ XHTML-a byïoby maïo sensowne. Jedynym argumentem prze- mawiajÈcym na korzyĂÊ XHTML-a mogïaby byÊ nieco wiÚksza zgodnoĂÊ witryny z aplikacjami XML. Jednak prace nad standardem HTML 5 sÈ jesz- cze dalekie od zakoñczenia, a Internet Explorer (i w mniejszym stopniu takĝe inne przeglÈdarki) nie obsïuguje wiÚkszoĂci nowych elementów tego jÚzyka. A zatem obecnie wybór pomiÚdzy jÚzykami HTML i XHTML moĝna spro- wadziÊ do listy piÚciu podstawowych zagadnieñ, przedstawionych poniĝej. 5 najwaijniejszych powodów, dla których warto wybraĄ HTML 1. HTML dziaïa prawidïowo we wszystkich przeglÈdarkach, a wszystkie przeglÈdarki (w tym IE) prawidïowo obsïugujÈ MIME HTML. 2. ChoÊ najprawdopodobniej prace nad HTML 5 nie zostanÈ jeszcze zakoñczone przez kilka najbliĝszych lat, jednak najnowsze przeglÈdarki obsïugujÈ juĝ niektóre jego elementy. Stwarza to doskonaïÈ okazjÚ, by juĝ teraz rozpoczÈÊ naukÚ tej nowej, uĝytecznej wersji jÚzyka. 3. HTML traktuje bïÚdy bardziej wyrozumiale niĝ XHTML. 4. HTML nie wymaga tak Ăcisïego zamykania elementów jak XHTML, a to z kolei moĝe nieznacznie zmniejszyÊ zuĝywanÈ przepustowoĂÊ. (A zuĝycie przepustowoĂci przez DOCTYPEE HTML 5 jest najmniejsze z moĝliwych), 5. HTML 5 jest pierwszÈ wersjÈ tego jÚzyka, zaprojektowanÈ pod kÈtem bogatych aplikacji internetowych, dlatego teĝ wielkie firmy internetowe, takie jak Google, bez wÈtpienia bÚdÈ nim bardzo zainteresowane. JeĂli zatem zajmujesz siÚ aplikacjami internetowymi i odpowiada Ci kierunek rozwoju HTML-a 5, to teraz jest doskonaïy moment, by zaczÈÊ go poznawaÊ i stosowaÊ. Dodatkowym plusem jest fakt, ĝe w ĝadnej z nowoczesnych przeglÈdarek obecnoĂÊ DOCTYPE HTML nie powoduje juĝ automatycznego przechodzenia do trybu „dziwactw”. ChoÊ nie jest to ĝadnÈ zaletÈ w porównaniu ze stoso- waniem XHTML-a, jednak uĝycie HTML-a nie pogarsza juĝ sytuacji pro- gramistów i nie zwiÚksza ryzyka przejĂcia przeglÈdarki do niebezpiecznego trybu „dziwactw”. W dalszej czÚĂci ksiÈĝki, w rozdziale 7., opiszemy pod- stawowe cele jÚzyka HTML 5, jego róĝnice w stosunku do XHTML-a oraz dokïadniej przedstawimy jego elementy, reguïy i skïadniÚ. 134 Rozdziaã 5. Nowoczesny ukãad znaczników 5 najwaijniejszych powodów, dla których warto wybraĄ XHTML 1 1. XHTML jest aktualnym standardem znaczników, zastÚpujÈcym HTML 4. 2. XHTML jest zaprojektowany do wspóïpracy z innymi jÚzykami skryptowymi, aplikacjami i protokoïami bazujÈcymi na XML. HTML nie posiada takiej moĝliwoĂci. 3. XHTML jest bardziej spójny niĝ HTML, zatem mniej skïonny do stwarzania problemów zwiÈzanych z funkcjonowaniem i wyĂwietlaniem treĂci. 4. Tworzenie w jÚzyku XHTML pozwala na wyzbycie siÚ przyzwyczajenia do pisania prezentacyjnego kodu znaczników, a to z kolei moĝe pomóc w unikniÚciu problemów z dostÚpnoĂciÈ i niezgodnoĂciÈ przy wyĂwietlaniu stron w przeglÈdarkach róĝnych producentów. (Jeĝeli piszesz strukturalny kod XHTML i umieszczasz wszystkie lub prawie wszystkie elementy prezentacji w CSS, czyli tam, gdzie powinny byÊ, nie bÚdziesz musiaï dïuĝej martwiÊ siÚ o róĝnice pomiÚdzy przeglÈdarkami Firefox i Internet Explorer, takie jak puste komórki tabel, do których zastosowano atrybut szerokoĂci). 5. Podobnie jak Êwiczenia z metronomem sprawiÈ, ĝe bÚdziesz lepszym muzykiem, tak znaczenie, jakie w XHTML-u jest przykïadane do prawidïowego formatowania kodu i przestrzegania reguï, stanowi doskonaïÈ platformÚ edukacji spoïecznej dla wszystkich projektantów i programistów, którzy przez dïugie lata nawykli do tworzenia kodu HTML pozbawionego semantycznego sensu. JeĂli nawet za dwa lub trzy lata wrócisz do HTML-a 5, to dziÚki poznaniu XHTML bÚdziesz tworzyÊ bardziej przejrzysty i lepszy kod — nauczysz siÚ bowiem przestrzegaÊ semantyki wymuszanej przez Ăcisïe i rygorystycznie przestrzegane zasady. Podstawowy powód, dla którego nie warto wybieraĄ XHTML-a 1. Nie znasz zasad XHTML-a. Na szczÚĂcie, temu punktowi moĝemy zaradziÊ — patrz rozdziaï 6.
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Projektowanie serwisów WWW. Standardy sieciowe. Wydanie III
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: