Списание за дизайн, визуална култура и Новата медия.
Попитайте кой да е, занимаващ се с информационни технологии, дали знае какво е мотото на Slashdot и той ще ви отговори - “News for Nerds. Stuff that Matters” (“Новини за маниаци. Важните неща.”). Slashdot е много известен сайт, но под повърхността се крие жалка таратайка, която би могла да се възползва от услугите на механик.
В тази статия ще покажем как може да се направи основен ремонт на двигателя като преобразуваме една страница от сайта. В момента Slashdot използва HTML 3.2, таблици и невалиден, семантично неправилен език, при положение, че би могъл да има един фино настроен според уеб стандартите състезателен двигател. Целта ни не е да променим Slashdot, а да го обновим според уеб стандартите и да покажем изгодите от промяната.
Преди да се паникьосате, че се заяждам със Slashdot, трябва да ви уведомя, че поисках от Rob “CmdrTaco” Malda - гуруто, който стои зад Slashdot, - разрешение да публикувам тази информация и той ми отговори следното:
Забавлявайте се. Изпратете ни промените си, ако измислите нещо полезно. Кодът на Slashdot е отворен и може да бъде свален от www.slashcode.com.
Започнахме със сваляне на копие от първата страница на Slashdot от 22 юли 2003 година. След като се сдобихме с копие на страницата, първата стъпка беше да се отстранят всички тагове, които не са от решително значение. Единствените тагове, които останаха, бяха връзките, списъците, формите, изображенията, скриптовете и мета информацията. Разполагайки с изчистената версия, преработихме кода до XHTML 1.0 Transitional и го валидирахме. На този етап, страницата изглеждаше като минно поле от връзки сред море от информация. Беше валидна, но не беше приятна гледка, затова преминаваме към следващата стъпка.
Докато разглеждахме валидния код, стана ясно, че по-голямата част от информацията можеше да бъде описана най-добре чрез различни списъци. Например, изображенията за отделните категории на Slashdot сега стояха точно едно до друго. Въобще, всичко което имаше повече от две части, беше превърнато в списък. Това включваше - логин формата, разделите на сайта, помощта, статиите, информацията за сайта, услугите и т.н. Списъците могат да бъдат описани и разположени както си искаме, а пък и указвайки, че дадени елементи са част от списък, ние описваме връзката помежду им.
Следващата стъпка беше да използваме таговете за заглавия. В страницата имаше доста заглавия и информация, но тази информация не беше описана правилно, а и взаимоотношението й с другите части на съдържанието не беше разяснено. Затова ние маркирахме всяко заглавие на статия с <h1>
, информацията за автора с <h2>
, за раздела - с <h3>
, а областта “read more” - с <h4>
. Така всяка част от информацията за една статия беше обозначена по уникален начин, като в същото време се описваха и връзките между отделните части. След това дойде лесното: обособяването на абзаците и изчистването на кода.
Ползата от преминаването към семантично правилен код се крие в това, че таговете се използват за това, за което всъщност са предвидени. Ясно е, че един списък с обекти, принадлежи към общо цяло и между различните заглавия съществува йерархия. Друго предимство е, че така страницата се оптимизира за търсещите машини.
В крайна сметка се получи една бъркотия от описана по-чудесен начин информация. Различните части информация трябваше да бъдат обединени в едно цяло и свързани адекватно. Като начало, всяка статия беше поставена в <div class="node">
. Сега цялата информация за една статия беше обединена, а всички статии бяха равнопоставени, като йерархията зависеше от физическото им разположение.
След това, обозначихме по уникален начин всички останали групи от информация и ги затворихме в отделни <div>
кутийки. Пример:
Информацията се поставя в тези <div> кутийки, за да бъде логически групирана, което пък помага при оформянето. Сега чрез CSS можем да се обръщаме към всяка група и да й задаваме конкретни характеристики - за разположение или външен вид. Това групиране не е обезателно семантично, но е необходимо за оформянето на външния вид. Ето и семантично организирания пример. Все още няма CSS - това е просто структурирания код на страницата.
Сега, след като всички групи са обозначени с конкретен <div>, страницата трябва да бъде оформена чрез CSS, така че дизайнът да съвпада със предишния външен вид на Slashdot. Това е въпрос на време, търпение и опит. Първата цел не е да се копира стария дизайн, а дa позиционираме нещата в три колони с общ хедър и футър. Това правим чрез първия CSS файл: layout.css
.
Ползата от позиционирането на елементите в страницата в отделен файл е лесно обяснима: когато имате проблем с позиционирането, знаете къде да го търсите. Често, когато имате проблем, той е свързан с позиционирането. На този етап, ние сме загрижени за това как ще изглежда страницата в различните браузъри и затова решаваме да използваме @import
техниката, понеже всеки браузър, който не я разбира, няма да зареди съответния файл. Това се отнася и до мобилните телефони, PDA устройствата, старите браузъри и други устройства с достъп до Интернет. Ето как изглежда страницата с CSS позициониране.
Сега вече имаме правилно позиционирани елементи, но страницата все още не изглежда като Slashdot. Вторият CSS файл е markup.css
, който съдържа информация за шрифтовете, цветовете, фоновите изображения и начина, по който трябва да се показват списъците. Ето и крайния вариант.
Освен това можем да добавим втори скин ако искаме да дадем на потребителя възможността да променя външния вид на страницата. Вторият скин не повтаря информацията за позиционирането, която вече е във вече кеширания layout.css
файл.
За да завършим промяната, поставяме връзките към CSS файловете в началото на документа.
<link rel="stylesheet" type="text/css" href="styles/layout.css" media='screen' /> <style type="text/css"> @import "styles/markup.css"; </style>
В този пример, файлът layout.css
е предназначен само за определяне на позицията на елементите върху екрана (media="screen"). Това е нарочно. Информацията в него има значения само, когато страницата се показва на екран и от нея няма полза, когато същата страница се отпечатва или се използва по друг начин (aural, tv, braille и др.). Файлът markup.css
, който е "скин" за страницата, се импортира и по този начин остава скрит за устройствата, който не поддържат уеб стандартите, защото неговото съдържание може да е вредно за тях.
Сега страницата се показва нормално в съвместимите с уеб стандартите браузъри, също както и преди, но също така ще се вижда по разбираем начин в нестандартните браузъри. Ето как, макар дизайнът да не е толкова прелестен в старите браузъри, съдържанието е достъпно за хората, които ги използват. То е и доста по-изчистено и разбираемо за екранните четци. Понеже CSS оформлението се скрива, когато е нужно, съдържанието се вижда и в PDA устройствата, и в телефоните с уеб достъп. Освен това няма и вертикални скролбарове! И накрая - имаме версия за печат, използвайки единствено CSS (няма нужда от отделна страница със специално оформление). Обаче най-голямата ползва в този случай е спестения трафик:
Макар тези няколко КВ да не звучат като много трафик, нека направим някои изчисления. Във FAQ страницата на Slashdot, последно обновена на 13 юни 2003 година, се казва, че всеки месец се зареждат около 50 милиона страници. Когато направим една разбивка се вижда, че това прави приблизително 1,612,900 всеки ден или приблизително 18 страници в секунда. Спестеният трафик е както следва:
Повечето посетители на Slashdot ще кешират CSS файла, така че можем да закръглим спестения трафик за един ден на приблизително 10 GB. Високоскоростен трафик може да струва от 1 до 5 долара за гигабайт трансфер, но нека приемем, че е 1 долар през цялата година. За този пример, през цялата година Slashdot може да спести общо $3,650!
Забележете: тези сметки се базират на брой посещения към 13 юни 2000 година. Вярвам, че сега трафикът на Slashdot е доста по-голям, но дори използвайки цифри отпреди три години, сумата си остава внушителна.
Всичко обяснено до този момент е обсъдено подробно в Slashdot Web Standards примера на сайта на Университета в Уисконсин.
С файл print.css
се създава възможност, която преди не съществуваше в Slashdot, а пък заема само десет реда CSS код. просто премахваме флоутинга на всеки <div>
и добавяме display:none;
за всеки <div>
, чиято информация става безполезна при отпечатване - търсенето, рекламите и др.
Накрая свързваме css файла към страницата, указвайки и подходящия вид на медията, така че CSS правилата в този файл да се прилагат само когато браузърът изпълнява командата за отпечатване:
<link rel="stylesheet" type="text/css" href="styles/print.css" media='print' />
Сега Slashdot има версия за отпечатване без специално проектирани страници или сървър-сайд скриптове.
Най-различни видове устройства с достъп до Интернет придобиват все по-голяма популярност. Защо да не направим сайт, който да може да се възползва от тези устройства? Проблемът, който повечето разработчици с това, може да се сведе до: "Нямам нито едно подобно устройство, на което да тествам!" Едно лесно решение е използването на емулатори. Ето няколко връзки към няколко такива, които използвам и аз:
Да видим как изглеждаше Slashdot в Openwave Phone Simulator (илюстрация 1).
Забелязвате ли основния проблем? Черен текст се показва върху черен фон като няма начин да селектираш текста и да прочетеш какво пише! Единствените видими думи са връзките. Получи се така, защото в кода на HTML 3.2 документа пишеше: <body BGCOLOR="#000000" ...>
.
Това е ОК за повечето бразъри понеже по-надолу в документа цветът на фона се променя благодарение на таблиците, но табличната структура е тотално развалена, за да може да се покаже в екрана на мобилен телефон. Ако например погледнете началото на същата тази страница, можете да видите къде точно са били разчупени, за да бъде побран документа на екрана (figure 2).
Почти се разбира какво пише: “Lo...gi...n W...hy Lo...gin...?” Сега да видим към версията, която реконструирахме с XHTML и CSS (илюстрация 3).
Тук се показва точно същото място от страницата както на Илюстрация 1. Единствената разлика е, че кодът във втория случай е според стандартите. Нямаше нужда от допълнителни промени в кода.
Нека хвърлим бърз поглед и към Palm emulatora, за да видим стария Slashdot (илюстрация 4).
Първото, което забелязвате е хоризонталния скролбар. Доста прилича на уеб страница гледана през микроскоп. Можеш да видиш информацията ако нямаш нищо против скролването. Тази страница е създадена, за да се гледа от компютърен екран, а не на екрана на безжично устройство.
Нека я сравним с другата версия (илюстрация 5).
Колко чисто изглежда заради стандартите!
Но чувам някой да казва: "Хей, тук също има хоризонтален скролбар!” Да, знам. Ако погледнете статията “Adopting Open Source” на тази страница, ще забележите, че тя е от секция “the don’t-worry-they’ll-print-more-money dept.” Това е дума, състояща се от 36 букви, която просто е прекалено дълга за екрана! Ето, че всъщност това е проблем със съдържанието, което аз разбира се не съм променял!
Ако изпитвате нужда да поговорите за тази статия с някой, да кажете колко (не) ви харесва или въобще - форумът е отворен непрекъснато. Заповядайте »
Статия в категория Код
Ключови думи: стандарти, slashdot, css, xhtml, печатна версия, безжични устройства
Източник: Retooling Slashdot with Web Standards
A List Apart, http://www.alistapart.com
Все още не можете да намерите онова, което търсите? Защо не пробвате с това малко поленце отдолу (подсказки: въвеждайте повече думи; пишете на кирилица; използвайте по-конкретни понятия.)