Съдържание

  1. Въведение
  2. История
  3. Уеб стандартите
  4. Структура и презентация
  5. (X)HTML
  6. CSS
  7. Достъпност
  8. Адреси
  9. Ресурси
  10. Речник

1. Въведение

Този документ обяснява как и защо употребата на уеб стандартите ще ви позволи да разработвате сайтове по начин, който спестява време и пари за разработчика, като същевременно осигурява по-добро преживяване за потребителя. Под внимание се взимат и други методи, насоки и препоръки, който ще ви помогнат да разработвате висококачествени сайтове, достъпни за възможно най-широка аудитория.

2. Малко предистория

Когато интернет стана масово явление в средата на 90те години, производителите на браузъри все още не бяха въвели поддръжка на CSS на ниво, което да позволи на разработчиците на сайтове да го използват за цялостен контрол върху презентацията на HTML документите. Разбираемо, предвид факта, че спецификацията CSS1 бе публикувана през 1996 година, а тази, описваща CSS2 – през 1998.

Липсата на CSS поддръжка в браузърите и желанието на графичните дизайнери да имат пълен контрол върху презентацията (навици от работата по печатни материали) доведе до масова погрешна употреба на HTML. Един от трудно умиращите прийоми и до момента си остава използването на таблици с невидима рамка. Така се оформя решетка, с която се контролира разположението на обектите по страницата. Друг подобен похват е употребата на прозрачно GIF изображение за фиксиране размерите на елементите – навик, останал предимно поради проблеми с интерпретацията от страна на господстващия през миналия век браузър Netscape 4.

HTML никога не е бил мислен като език за описване на презентация. Но му се наложи да стане, поради което употребата на хакове, грешен код, специфични за браузъра тагове и атрибути се превърна в ежедневие и едва ли не задължително за всеки един уеб разработчик. Привържениците на чистия код и придържането към стандартите лепнаха на подобен тип продукция етикета „таг-чорба“ (tag soup).

С излизането на нови версии на браузърите, поддръжката на CSS беше подобрена и разширена, макар и не на нивото на което би трябвало. Въпреки бавното темпо на въвеждането на CSS поддръжка, в момента лека полека достигнахме момента, в който браузъри с прилична такава са на масово въоръжение сред потребителите. Достатъчно, за да започнем да използваме HTML по предназначение – а именно да описваме структурата на документа, а не неговия изглед. За презентацията разполагаме със CSS, правен специално за това.

3. Уеб стандарти

Какво е това?

Уеб стандартите са технологии, установени от W3C и други организации, които се използват за създаването и интерпретирането на уеб базирано съдържание. Тези технологии целят създаването на максимално достъпни и ползваеми за в бъдеще уеб документи.

Структурни езици

Презентационно ориентирани езици

Обектни модели

Скриптови езици

Този документ фокусира върху употребата XHTML 1.0 Strict за описание на структурата, CSS Level 1 и Level 2 за презентацията, и ECMAScript 262 за контрол над поведението (не, че имаме голям избор).

За да кажем, че документа се придържа към стандартите, трябва да сме сигурни че документа:

Забележете – „функционира“ не значи че „изглежда еднакво“. Реално погледнато, да направим един документ да изглежда еднакво под различни браузъри и платформи е непосилна задача, дори и да го реализираме изцяло с изображения. Документи, публикувани в интернет са разглеждани посредством голям (и предстои да нараства за в бъдеще) брой видове устройства и приложения, различаващи се както по начина на интерпретация на документа, така и по хардуерни параметри (размер на екрана, ако има такъв, брой цветове, налични шрифтове). Приемете го, за да си улесните живота.

Защо да използваме уеб стандартите?

Доста дизайнери и програмисти изпитват страх и неприязън към уеб стандартите. Често чувам „Много е сложно“, „Ами то и така си работи“, „Програмите са ми виновни...“

Лесно е да се реагира емоционално, да се отрича нуждата от научаване на нови приоми и отказването от стари, които са ползвани с години. Но нека погледнем реално на ползите от употребата и научаването на стандартите:

Повече по темата

Валидация

Валидацията е процес на контрол върху това дали документа реално отговаря на изискванията на езика, на който сте написали документа. Представете си го като проверка за правописа и граматиката.

Валидацията е важна част от разработката на един сайт, и безотказен метод за намиране на трудни за откриване грешки. Грешките могат да бъдат от тривиални (като правописна грешка) до фатални - като неправилна употреба на елемент или атрибут.

За нещастие все още много хора не проверяват документите си. Някои не знаят, други забравят, а има и такива които съзнателно избягват да го правят. Това до голяма степен е вина на производителите на браузъри, които се стремят продуктите им да се умело справят с невалиден HTML по начин, който не нарушава презентацията, вместо да съобщят за грешката. Което превърна мърлявия и неверен код в нещо обичайно за мрежата. Проблемът на подобен тип код е, че това може да доведе до непредвидими резултати и разчита на способността на браузърите да се справят, както намерят за добре.

Няма причина да не проверяваме кода си, дори точно обратното – от това можем само да спечелим.

Защо ние няма да ти помогнем от Марк Пилгрим представлява едно чудесно обяснение за предимствата на проверката на кода. Един от основните акценти на статията е защо е значително по-трудно да получим помощ от хората в пощенски списъци и форуми, ако преди да попитаме не проверим документите си за валиден код.

Някои HTML редактори, като BBEdit или Homesite имат вградена проверка на кода. Ако вашият редактор не го поддържа, можете да използвате услугите на W3C - (X)HTML: W3C MarkUp Validation Service и CSS: W3C CSS Validation Service.

Да разберем съобщенията за грешките на валидатора понякога може да е трудно. Грешка в началото на документа обикновено води до допълнителни такива по-надолу. След оправянето на първата, обикновено останалите, причинени от нея изчезват, затова проверявайте отново след като оправите първите няколко. Най-често срещаните грешки са документирани във Common XHTML Validation Errors от Black Widow Web Design.

Винаги е добра идея е да се уверите, че кода ви е напълно валиден, но в някои случаи има грешки, които са трудни за оправяне – например влагането в документ на flash обект, или друг документ, който изисква зареждането на plug-in. Повече информация за това как да избегнем проблема с flash обектите можете да научите от Flash Satay: Embedding Flash While Supporting Standards (бел. ред.: Тази статия можете да намерите преведена на български на сайта на FlashBG) и Embedding flash without <embed>.

4. Структура и презентация

Когато стане въпрос за уеб стандарти, това, което винаги се споменава, е разделението на структура и презентация. Да разберем разликата между двете обикновено е трудно, особено ако не сме разсъждавали върху семантичната структура на документите. Въпреки това разбирането на проблема е от изключителна важност, защото контрола над изгледа на даден документ е много по-лесен, ако структурата и презентацията за разделени.

Структурата се състои от задължителните части на документа, заедно с семантичното и структурното обозначение на съдържанието.

Презентацията е начина по които желаете да представите документа. В повечето случаи това засяга начина по който този документ изглежда, но понякога това касае и начина по който звучи – не всеки използва графичен браузър.

Разделяйте структурата от презентацията на всяка цена, доколкото това е възможно. В идеалния случай HTML документа трябва да описва структурата и съдържанието, а презентацията да се контролира изцяло със CSS.

Подобна практика в момента е рядко срещана в момента, в повечето случаи HTML кода е не-структуриран и лишен от семантика.

Таблици за изграждане на изгледа

За да отделите структурата от презентацията трябва да използвате CSS вместо таблици при изграждането на изгледа на документа. Когато сте използвали таблици за това, може би ще се почувствате неудобно и непривично, но реално погледнато не е толкова трудно, колкото изглежда. Има много информация и помощ из интернет, а предимствата на този подход са толкова много, че определено си струва да отделим време за да се научим да мислим по този начин.

(бел. ред.: Препоръчвам ви да разгледате Защо използването на таблици за оформяне на страницата е глупаво? - една презентация на Bill Merikallio, преведена на български от екип на FlashBG.

Семантичен HTML

Друга важна част от разделянето на структурата от съдържанието е употребата на семантично обозначаване за структуриране на съдържанието на документа. Когато разполагаме с XHTML елемент, който да има семантично значение, подходящо за това, което имаме в съдържанието, няма причина да използваме нещо друго. С други думи, не използвайте CSS за да накарате един HTML елемент да изглежда като друг HTML елемент – като например да използвате и стилизирате <span> елемента, вместо <h1>, за да обозначите заглавие.

Ако използвате семантичен код, вие ще обозначите различните части от документа по начин, разбираем за всеки един браузър (дори и за такива, за които не подозирате) – независимо дали това са последните модерни графични браузъри, античен браузър от миналия век без поддръжка на CSS, или текстови браузър под UNIX shell.

Заглавия

За да ги обозначите, използвайте <h1>, <h2>, <h3>, <h4>, <h5> или <h6> в зависимост от йерархията - <h1> е най-голямото по важност.

Примери:
<h1>Заглавие на документа</h1>
<h2>Подзаглавие</h2>

Заглавие на документа

Под заглавие

Параграфи

Използвайте <p> елемента за да обозначите параграфите. Не (не, не и не!) слагайте <br /> елементи за да оформите пространство между параграфите. За да се оформи посредством CSS отстоянието на параграфите, текста трябва да е обозначен правилно.

Пример:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.

Списъци

Списък от неща трябва да бъде обозначен като такъв. Има три различни вида списъци в XHTML – неподреден, подреден, и дефиницонен.

Неподредените списъци, известни още като bulleted започват с <ul> и завършват с </ul>. Всяка точка от списъка се обозначава с <li> елемент.

Подредените списъци започват с <ol> и завършват с </ol>.

Дефиницонните списъци са малко по-различни и могат да бъдат използвани, за да обозначат списък с термини и техните описания. Те започват с <dl> и завършват с </dl>. Всеки термин се маркира с <dt>, а всяко от последвалите го описания (едно или повече) се обозначават с <dd>.

Примери:
<ul>
	<li>Първо нещо</li>
	<li>Второ нещо</li>
	<li>Трето нещо</li>
</ul>
<ol>
	<li>Първо нещо</li>
	<li>Второ нещо</li>
	<li>Трето нещо</li>
</ol>
  1. Първо нещо
  2. Второ нещо
  3. Трето нещо
<dl>
	<dt>Уеб сайт</dt>
	<dd>Сбор от свързани помежду си страници, които представят компания или човек.</dd>
	<dt>Уеб страница</dt>
	<dd>Основната градивна единица на уеб сайта, съдържаща текст, графика и друга медия.</dd>
</dl>
Уеб сайт
Сбор от свързани помежду си страници, които представят компания или човек.
Уеб страница
Основната градивна единица на уеб сайта, съдържаща текст, графика и друга медия.

С помощта на CSS вие можете да използвате списъци дори когато не искате съдържанието им да изглежда по обичайния за тях начин. Навигация или списък с връзки са добър пример за употреба на списък в непривичен за него изглед. Предимството на този подход е, че списъка, който сте използвали за меню ще обозначи правилно менюто дори и за браузъри, които не поддържат CSS. (бел. пр.: Можете да прочетете повече за списъците в тетрадката на How Bizarre.)

Цитати

Елементът <q> може да бъде използван за кратки цитати в текста. Браузърите би трябвало да показват кавички преди и след съдържанието му. За съжаление, IE не го прави и в определени случаи това може да доведе до проблеми с достъпността на съдържанието. За това препоръчваме да не използвате <q>, и да добавяте кавички ръчно. Добавянето на кавички в текста и <span> елементи в комбинация със CSS позволява оформяне на изгледа като цитат, но няма семантична стойност. Прочетете статията Елементът Q от Mark Pilgrim за детайлна информация относно проблемите с този елемент.

За по-големи цитати, простиращи се в един или повече параграфа, използвайте елемента <blockquote> и CSS (при нужда), за да оформите представянето му. Забележете, че не можете да поставите текст директно в <blockquote> - той трябва да бъде в друг елемент – например в <p>.

Атрибутът cite може да бъде използван и при двата елемента, за да посочи с URL източника на цитата.

Примери:
<p>The W3C says that <q cite="http://www.w3.org/TR/REC-html40/
struct/text.html#h-9.2.1">The presentation of phrase elements
depends on the user agent.</q>.</p>

The W3C says that The presentation of phrase elements depends on the user agent..

<p>The W3C says that <span class="quote">&bdquo;The presentation of
phrase elements depends on the user agent.&ldquo;</span>.</p>

The W3C says that „The presentation of phrase elements depends on the user agent.“.

<blockquote cite="http://www.w3.org/TR/1999/REC-html401-19991224/
struct/text.html">
	<p>&bdquo;The following sections discuss issues
	surrounding the structuring of text. Elements that present text
	(alignment elements, font elements, style sheets, etc.)
	are discussed elsewhere in the specification. For information
	about characters, please consult the section on the
	document character set.&ldquo;</p>
</blockquote>

„The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.“

Акцент

<em> се използва за акцент, а <strong> за важен акцент. Повечето браузъри показват съдържанието на <em> в курсив, а това на <strong> - удебелено. Това обаче не е задължително, затова ако искате да сте сигурни в начина, по който изглежда съдържанието, опишете го с помощта на CSS. Не използвайте акцент, ако единственото, което търсите е визуален ефект.

Пример:
<p><em>Emphasized</em> text is normally displayed in italics,
while <strong>strongly emphasized</strong> text is usually
displayed in bold.</p>

Emphasized text is normally displayed in italics, while strongly emphasized text is usually displayed in bold.

Таблици

В XHTML таблиците не трябва да бъдат използвани за оформяне на презентация. Но за представяне на таблична информация те са точно на мястото си. За да направите табличните данни колкото може по-достъпни е важно да знаете компонентите, които изграждат таблицата – например табличните заглавия (<th>), кратките описания (атрибута summary) и етикета (елемента <caption>).

Пример:
<table class="example" summary="This table shows the annual population
increase in Sweden during the years 1999 to 2003.">
	<caption>Annual population increase in Sweden, 1999–2003</caption>
	<thead>
		<tr>
			<td>&nbsp;</td>
			<th scope="col">1999</th>
			<th scope="col">2000</th>
			<th scope="col">2001</th>
			<th scope="col">2002</th>
			<th scope="col">2003</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<th>Population</th>
			<td scope="row">8 861 426</td>
			<td scope="row">8 882 792</td>
			<td scope="row">8 909 128</td>
			<td scope="row">8 940 788</td>
			<td scope="row">8 975 670</td>
		</tr>
		<tr>
			<th>Increase</th>
			<td scope="row">7 104</td>
			<td scope="row">21 366</td>
			<td scope="row">26 368</td>
			<td scope="row">31 884</td>
			<td scope="row">34 882</td>
		</tr>
	</tbody>
</table>
Annual population increase in Sweden, 1999–2003
  1999 2000 2001 2002 2003
Population 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Increase 7 104 21 366 26 368 31 884 34 882

Повече информация за таблиците и употребата им можете да прочетете в Таблици в HTML документи и HTML техники за уеб съдържание – препоръки за достъпност 1.0.

Повече информация:

5. (X)HTML

Възможно е да използваме HTML 4.01 за изграждането на модерни, структурирани, и съобразени със стандартите сайтове. Но XHTML 1.0 Strict е за препоръчване предвид желанието да направим прехода към чист и семантичен маркъп, и за да бъдем по-добре подготвени за миграцията към XML и други бъдещи декларативни езици. Примерите в този документ използват XHTML 1.0 Strict.

XHTML 1.0 представлява преформулиране на HTML 4 съобразно изискванията на XML 1.0. XHTML беше разработен, за да замени HTML. XHTML 1.0 Strict, който препоръчвам да ползвате, не позволява употреба на никакъв маркъп, описващ презентация (същото важи и за HTML 4.01 Strict, но в момента се разбрахме, че ще учим XHTML, нали?). Поради тази причина, ако ползваме XHTML 1.0 Strict, то самият език налага разделянето на структура и презентация – просто нямаме избор.

XHTML 1.1, последната версия на XHTML, е малко по-сложен за употреба, тъй като спецификацията му изисква документите да имат MIME тип application/xhtml+xml, и не трябва да бъдат изпращани като text/html (както HTML документите до момента). Не е напълно забранено да го направим, но не е препоръчително. От друга страна XHTML 1.0 документите трябва да използват application/xhtml+xml, но могат също да използват и text/html, ако са съвместими с HTML. XHTML Media Types от W3C съдържа преглед на препоръчителните MIME типове.

За съжаление, някои стари браузъри, както и IE, не разпознават MIME типа application/xhtml+xml, и в крайна сметка или показват кода като текст, или отказват да покажат документа.

Ако все пак желаете да използвате application/xhtml+xml, тогава ще ви се наложи да проверите дали браузъра може да разпознае такъв тип. Ако не – тогава го изпратете като text/html.

Ако използвате PHP, следващия пример ще ви помогне с това да определите дали браузъра ви ще разбере типа application/xhtml+xml:

<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") || 
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
	header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
	header("Vary: Accept");
	echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
} else {
	header("Content-Type: text/html; charset=iso-8859-1");
	header("Vary: Accept");
}
?>

Кодът проверява дали хедъра Accept, който браузърът изпраща към сървъра съдържа „application/xhtml+xml“ (или пък агента е валидатора на W3C, който не изпраща такъв хедър, но все пак интерпретира коректно „application/xhtml+xml“. Ако това е така, документа е изпратен като application/xhtml+xml. Освен това към браузъра е изпратена и XML декларация. За всички останали браузъри (в тази категория влизат всички версии на IE) документа е поднесен като text/html, без XML декларацията, защото това кара IE под Windows да интерпретира документа в Quirks mode – нещо, което не искаме.

Освен Content-Type скриптът изпраща и друг такъв – Vary, за да съобщи на всички междинни прокси сървъри, че типа на съдържанието на документа зависи от възможностите на клиента, изискал документа.

За по-сложен PHP код относно типа на съдържанието прочетете Serving up XHTML with the right MIME type. Този скрипт използва q-рейтинга на браузъра (информация за това дали приема определен MIME тип), и при нужда трансформира XHTML в HTML 4, след което изпраща документа като text/html за браузъри, които не разбират application/xhtml+xml.

Ето и подобен код за ASP/VBScript:

<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0 
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
	Response.ContentType = "application/xhtml+xml"
	Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
	Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>

Забележете, че ако MIME типа е application/xhtml+xml някои браузъри (например Мозила и производните и) няма да покажат документи със грешки в кода. Това е сравнително полезно по време на разработката, но може да създаде проблеми на действащия сайт, ако хората, които отговарят за съдържанието не са XHTML експерти. Затова се подсигурете, че кода, който извежда системата за управление на съдържанието не може да бъде невалиден. Ако все пак рискът е неоправдан, помислете за употребата на HTML 4.01 Strict.

Ето списък със неща, които са трябва да бъдат взети предвид, ако сте решили да използвате XHTML 1.0 Strict наместо HTML:

Повече Информация

Декларация на типа на документа (Doctype)

В момента много малко html документи имат правилна и пълна декларация (DTD). В миналото тя беше повече декоративна отколкото функционална, но от няколко години наличието на правилна декларация може да повлияе значително на визуализацията на документа в браузъра.

За да бъдат валидни, всички HTML и XHTML документи трябва да имат декларация – тя указва коя версия на HTML (или XHTML) е използвана. Валидаторът проверява документа спрямо нея, а браузърите я използват, за да определят в какъв режим да покажат документа. Ако пълна и правилна декларация е налице, модерните браузъри ще преминат в режим, съвместим със стандартите (standards compliant mode) и ще се придържат по-близко до CSS спецификацията. Документа ще се визуализира по-бързо, защото на браузъра не му се налага да компенсира за невалиден html. Правилната декларация също така и ще намали разликите при показването в различните браузъри.

Тази декларация указва, че документът е XHTML 1.0 Strict и ще накара браузърите, които поддържат превключване на режима спрямо декларацията, да минат в стандартен режим:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Повече по темата:

Кодова таблица на символите (Character encoding)

Всички XHTML документи трябва да указват кодирането си. Най-добрия начин това да стане е да конфигурираме уеб сървъра да изпраща content-type хедър. За повече информация прегледайте документацията на сървъра, който използвате.

Ако използвате Apache, можете да укажете кодирането, като добавите едно или повече правила във вашия .htaccess файл. Например – ако всички файлове са в UTF-8, добавете това:

AddDefaultCharset utf-8

За да укажете специфично кодиране за файлове с определено разширение използвайте:

AddCharset utf-8 .html

Ако сървърът ви позволява да ползвате PHP, може да ползвате функцията header:

<?php
	header("Content-Type: application/xhtml+xml; charset=utf-8");
?>

Ако пък искате да изпращате страниците си като HTML, заменете application/xhtml+xml с text/html. Ако по някаква причина не можете да конфигурирате сървъра, използвайте <meta> елемент във <head> секцията на документа. Това е препоръчително, дори и когато сървъра е конфигуриран правилно. Например – следния <meta> елемент указва на браузъра, че документа използва ISO-8859-1 кодова таблица:

<meta http-equiv=“content-type“ content=“text/html; charset=ISO-8859-1“ />
Повече по темата:

6. CSS

Доскоро използван основно за да укаже характеристиките на шрифтовете, сега CSS може да бъде използван за да опише цялостния изглед и представяне на документа. Това обаче изисква малко по-различен подход от този, при който изгледа се оформя с таблици.

За да можем успешно да контролираме изгледа с помощта на CSS ни трябва структуриран, семантичен XHTML.

Поддръжка на браузърите

Както споменахме по-рано, CSS поддръжката на браузърите е подобрена значително за последните няколко години. За зла врага, производителите на браузъри изглежда нямат интерес от това да изградят пълна поддръжка на стандартите, така че нивото на поддръжка не е еднакво при всички. На всичкото отгоре наличието на бъгове в браузърите ги кара не винаги да интерпретират кода както трябва.

В момента (2004), браузърите с най добра поддръжка на CSS са Mozilla (и другите и производни - Firefox, Camino, Netscape 6+), Opera и Safari (и други базирани на WebCore: OmniWeb 4.5 и нагоре). Internet Explorer 6/Win няма това ниво на поддръжка, но се справя с повечето основни неща. Internet Explorer 5/Mac има много добра поддръжка на CSS 1, но не разбира много от CSS 2. IE 5 за Windows разбира тук таме, но има някои сериозни проблеми, за които трябва да знаете. По-ранните версии на Internet Explorer нямат поддръжка, за която си струва да се говори. Същото важи и за версиите на Netscape преди 6.

В момента болшинството от потребителите използват Internet Explorer за Windows (бел. ред: В края на 2004 година се ползва предимно IE 6+; потребителите на IE 5 са вече под 5%), така че ще трябва да се съобразявате най-често с него. Това не значи, че не трябва или че не може да се възползвате от възможностите на по-добрите браузъри, за да подобрите изгледа си за тях.

Не всички браузъри в момента могат да покажат сайт, който използва пълните възможности на CSS за оформлението си по правилния начин (бел. ред.: В момента достатъчно способни са Mozilla 1.7+, Firefox 1.0, Opera 7.5+). За щастие, в повечето случаи, посетителите, които използват толкова стар браузър, който да не се справи с изгледа, са много малък процент (бел. ред.: В момента е прието, че това са около 1% до 2% от посетителите).

Важно е да отбележим, че тези хора няма да бъдат пращани в забвение и лишавани от възможността да разгледат сайта. През деветдесетте години на миналия век проверките за вида и версията на браузъра бяха популярен начин да „изхвърлиш“ всеки, който ползва грешен браузър (в повечето случаи всичко друго освен IE за Windows) на страница, която учтиво гo кара да си смени браузъра, за да разгледа сайта.

Но сега можем да се отнасяме по-добре с браузъри, който не поддържаме. Едно голямо предимство на употребата на логичен и семантично правилен XHTML е факта, че документите стават използваеми и достъпни дори и без поддръжката на CSS. Презентацията – начина, по който изглежда документа, няма да бъде същата, но съдържанието ще си е там. В повечето случаи за посетителите на сайта именно съдържанието, а не изгледът е от значение. Затова е по-добре да покажем една не-стилизирана страница, отколкото да забраняваме достъпа до сайта.

Това може да се направи по различни начини – един от най-често използваните е да се използва @import за закачане на CSS файла. Netscape 4 и другите антични браузъри не разбират тази команда и няма да заредят CSS файла при представянето на документа. Има много начини да скрием CSS от браузъра – почти всички са базирани на бъгове, открити в начина, по който браузърите интерпретират CSS кода. Това разбира се крие риска, че производителя ще оправи бъга, който ние използваме за да скрием CSS кода, но няма да оправи проблема, станал причина за употребата му (бел. ред.: Макар че е в кръга на невъзможното някой тепърва да тръгне да поправя Netscape 4, IE 5, Opera 5 и подобните.). Така че – колкото по-малко разчитате на тези хакове, толкова по-добре (бел. ред.: Това е така, но в момента на практика е невъзможно да изградите добър сайт, базиран на XHTML и CSS без да използвате солидно количество хакове.).

Разбира се, винаги можете да разчитате на сървърна технология за да пратите различни css файлове към различните браузъри. Но ако го правите трябва да сте сигурни че скрипта работи и няма да изпраща грешни CSS файлове при обновяване на браузър или пускането на изцяло нов такъв.

Повече по темата:

Начини за прилагане на CSS

Има няколко начина да приложим CSS към елементите на HTML документ.

Външен

Има няколко предимства на това да дъжим всички CSS директиви в отделни файлове. HTML документите стават по-малки, CSS файловете се кешират при клиента, и трябва да бъдат зареждани само веднъж, трябва да редактирате кода само веднъж, за да промените изгледа на цял сайт. Външен CSS файл може да изглежда така:

h1 {
	font-weight:bold;
}

Забележка: Във външния CSS файл няма <style> елемент – това е CSS а не HTML.

Можете да свържете CSS файл с HTML документ посредством <link> елемента:

<link rel="stylesheet" type="text/css" href="styles.css" />

Или като използвате директивата @import в елемента <style>:

<style type="text/css">
	@import url("styles.css");
</style>

Вложен (Inline)

Използвайки атрибута style, можете да укажете CSS директно за даден елемент:

<h1 style="font-weight:bold;">Заглавие</h1>

Това обаче не е препоръчително, защото смесва структура и презентация.

Вътрешен

Вътрешен CSS се пише в елемента <style>, който на свой ред се намира в секцията <head> на документа:

<style type="text/css">
	h1 {
		font-weight:bold;
	}
</style>

Това също трябва да се избягва – най добре е да разделяме HTML и CSS в отделни файлове.

Повече по темата:

CSS Синтаксис

Всяко CSS правило се състои от селектор и една или повече декларации. С помощта на селектора указваме за кой HTML елемент се отнася правилото. Декларативния блок е ограден с { }, а всяка декларация завършва с ; (точка и запетая).

Ето едно просто CSS правило:

p {
	color:#0f0;
	font-weight:bold;
}

В този случай p е селектора, което означава че това правило се отнася до всички <p> елементи в документа. Правилото има две декларации, които указват текста в параграфите да бъде зелен и удебелен.

За по-детайлно описание на цсс правилата прегледайте CSS Beginner’s Guide, CSS from the Ground Up или някоя книга, посветена на CSS.

Повече по темата:

Излишни елементи и класове

Често срещана грешка на всеки начинаещ е употребата на излишни XHTML елементи, неуместни CSS класове и допълнителни <div> елементи. Това не значи, че кода няма да е валиден, но противоречи с целта за разделеняне на структура и презентация - по-прост и чист код.

Ето и пример:

<h3><em>Headline</em></h3>

Ако искате направите заглавието в курсив, използвайте CSS:

h3 {
	font-style:italic;
}

Неправилната употреба на класове може да изглежда така:

<div id="main">
	<div class="maincontent">
		<p class="maincontenttext">
			Lorem ipsum dolor
		</p>
	</div>
</div>

Когато и това би свършило работа:

<div id="main">
	<div>
		<p>
			Lorem ipsum dolor
		</p>
	</div>
</div>

За да контролирате елементи в div#main, можете да използвате контекстуалните селектори. В този случай това би изглеждало така:

div#main p {
		/* тук поставете нужните правила */
}

В повечето случаи CSS може да бъде използван за да стилизира логично оформен XHTML по начина, по който искате, без да се налага да добавяте допълнителен маркъп код. Понякога обаче, това не е точно така.

CSS съвети

Веднъж започнали да използвате CSS сериозно, ще се натъкнете на проблеми от разнообразно естество. Някои от тях ще бъдат причинени от неправилно разбиране, други от неясна документация или бъгави браузъри. В посочената по-горе статия Пищови по CSS (съставена от Dave Shea и преведена от Георги Варзоновцев) можете да намерите колекция от полезни съвети. Ето и някои от най-важните от тях, както и няколко, които няма да намерите там.

CSS Лейаути

Има много примери и уроци за това как да изградите сайта си с помощта на CSS. Добро решение е да започнете с прост изглед, да разберете как работи, и после да преминете към по-сложни решения.

Повече по темата:

7. Достъпност

Достъпността не касае само и единствено възможността сайта да се използва от хора с увреждания, макар и това да е една от основните причини да правим сайтовете достъпни. Достъпен сайт работи по-добре за всеки, независимо дали страда от увреждания или не, и може да бъде видим за повече хора с различни браузъри и устройства.

Честа грешка е идеята, че ако направим сайта достъпен, той ще изглежда различен и по-малко привлекателен от преди. Това не е така. Достъпността често няма допирни точки с презентацията на даден документ.

Ето пример за това как достъпността може да е от полза за всеки: сайт има формуляр, посредством която потребителя може да се регистрира за семинар. Във формуляра трябва да изберете града в който желаете да посетите семинара посредством радио бутони. Името на града е до радио бутона. Ако разработчика на формуляра не е взел достъпността предвид, всеки, който използва графичен браузър трябва да постави мишката си точно върху малката зона на радио бутона, за да избере град. Ако обаче програмистът е взел предвид достъпността на формуляра, то той е маркирал текстовете до радио бутоните с елемента <label>, и вие ще можете да натиснете върху името, за да изберете града. Кой от двата начина за избор е по-лесен за всеки един от нас?

Употребата на семантичен, добре структуриран XHTML е голяма част от работата по изграждането на достъпен сайт. За да добиете груба идея колко е достъпен документа, погледнете го през текстови браузър като Lynx, за да видите дали съдържанието е разбираемо. Това далеч не е всичко, което трябва да направите, но е добър старт.

Фреймове

Много дизайнери обичат фреймовете като средство да разделят екрана в браузъра на различни части, като всяка една е различен HTML документ. Това би могло да е от полза в една интранет апликация, но в публичен сайт фреймовете създават някои проблеми:

Освен всичко останало с фреймовете си усложнявате живота на разработчик. Фреймовете правят сайта ненужно сложен технически.

Таблици

Много често хората разбират „Не използвайте таблица за изграждане на презентация“ като „Не използвайте таблици въобще“. Това е неправилно. Ако представяте таблична информация, правилният начин да я покажете е точно посредством таблица. Важно е обаче да се отбележи, че когато изграждате таблици има много начини да ги направите по-логични и достъпни.

Повече по темата:

Формуляри

Често формулярите са ненужно трудни за употреба, донякъде защото са направени нелогично, донякъде и защото кода им не използва правилните елементи за да направи формуляра достъпен и лесен за употреба. Елемени като <label>, <fieldset> и <legend> съществуват и трябва да бъдат използвани.

Чест въпрос е какво да бъде използвано за оформление на визията на форма. Някои твърдят, че формата може да бъде разгледана като таблична информация, и трябва да бъде описана с таблица, други настояват за CSS презентация. Използвайте което намерите за добре, но ако решите, че таблицата е вашия избор, проверете дали формуляра има смисъл и когато таблицата е игнорирана.

Повече по темата:

JavaScript и cookies

Избягвайте зависимостта от JavaScript. Доста хора (повече отколкото предполагате) са изключили JavaScript в браузъра си, било поради причини свързани със сигурността или за да избегнат попъпи. Освен това те може би използват браузър без поддръжка на JavaScript. Според TheCounter.com, 6% от потребителите нямат JavaScript. Според W3Schools.com цифрата е 8%.

В повечето случаи употребата на JavaScript не носи особена полза на потребителя. Разбира се има случаи, когато с помощта на JavaScript можете да постигнете по-добро потребителско изживяване. Пример за това е клиентска валидация на формуляр.

Това не значи, че не трябва да използвате JavaScript. Но означава, че сайта ви трябва да бъде достъпен и ползваем дори и без JavaScript. Същото важи и за cookies. Не ги използвайте по начин, който ще направи сайта ви недостъпен за потребителя, който не ги приема.

Същото важи и за cookies. Използвайте ги, но само по начин, който няма да наруши нормалната работа на сайта, ако потребителят е избрал да не приема cookies.

8. Адреси

Тази секция всъщност не се отнася за стандарти или достъпност, но трябва да се спомене, че начина, по който се формира адреса може да има голямо значение за това как търсачките индексират сайта, и за това колко той е ползваем от потребителите.

Някои роботи не проследяват връзки към адреси с параметри (query string). Такъв тип адреси се среща често при сайтове, които държат съдържанието си в база дани. Адреса може да изгледа по подобен начин:

http://yourdomain.com/products.asp?item=34627393474632&id=4344

Най-лесният начин да създадете по-добър адрес за търсачките и за посетителите е да го замаскирате като директория. Горният пример би изглеждал така:

http://yourdomain.com/products/item/34627393474632/id/4344/

Уеб сървъра интерпретира адреса и го превръща обратно в оригиналния. В края на тази секция има връзки към статии, които обясняват подробно как може да бъде реализирано това.

По-добър, но и по-сложен начин да променяте адреси е напълно да подмените видимия адрес с разбираем за потребителите:

http://yourdomain.com/products/flowers/tulips/

Предимствата на такъв тип адреси е, че търсачките ще индексират сайта по-добре, за потребителите е по-лесно да прочетат и запомнят адреса, а вие скривате сървърната си технология - адресите не съдържат специфични разширения като .asp, .cf, cgi или .jsp. Което прави лесна евентуална подмяна на технологията ако това се наложи.

Ако решите да използвате параметри в адреса, важно е да превръщате всички амперсанди в HTML съотвествието им - &amp;. Ако не го правите, някои браузъри ще (както би трябвало да правят) разберат амперсанда като начало на HTML знак, и последвалия след него текст ще бъде интерпретиран като символ, което в повечето случаи ще счупи адреса.

За повечето сайтове е ненужна употребата на www поддомейн - може спокойно да бъде ползвано http://yourdomain.com вместо http://www.yourdomain.com. Повече информация за това може да бъде намерена на http://no-www.org. За всеки случай най-добре би било да конфигурирате сървъра си да пренасочва http://www.yourdomain.com/ и http://yourdomain.com/ към едно и също място.

Повече по темата:

9. Ресурси

Списък с материали, книги, сайтове и пощенски списъци, които могат да ви бъдат полезни.

Книги

CSS

Разработка на сайтове

HTML

Достъпност

Уеб стандарти

XHTML

10. Речник

Достъпност
Достъпен сайт е този, който може да бъде достъпен и употребен от всеки потребител, независимо от хардуера или софтуера, който използва.
CSS (Cascading Style Sheets)
Правила, описващи представянето на документа.
HTML (HyperText Markup Language)
Език, описващ структурата на документа.
Презентация
Начинът по който изглежда (или звучи) документа.
Структура
Задължителните части на документа и логичният markup на съдържанието му.
Markup
Маркирайки документа, вие придавате на съдържанието му структура и значение. За тази цел се използва HTML или XHTML.
Валидация
Валидацията е процесът на проверка за правилността на езика, използван в документа. Представете си го като проверка за правописни и граматически грешки.
W3C (World Wide Web Consortium)
Организация, кото разработва спецификации, препоръки и инструменти за уеб.
Уеб стандарти
Уеб стандартите са технологии, практики и принципи, установени от W3C и други организации, използвани при изработката на уеб базирано съдържание. Употребата на тези технологи цели документите да бъдат използваеми в бъдеще и достъпни за възможно най-голям брой потребители.
XHTML (Extensible HyperText Markup Language)
HTML, подчинен на правилата на XML.
XML (Extensible Markup Language)
Маркъп език, подобен на HTML, но позволяващ свободната дефиниция на елементи, с цел описание на информация.

Коментари, въпроси и предложения изпращайте на автора.

© Copyright 2004 Roger Johansson

Ако имате забележки по превода на материала, моля пишете в тази тема във форумите на FlashBG.org. Преводът беше направен от Петьо Иванов, а редакцията - от Боби Димитров.