Translations of this article are available.
Този документ обяснява как и защо употребата на уеб стандартите ще ви позволи да разработвате сайтове по начин, който спестява време и пари за разработчика, като същевременно осигурява по-добро преживяване за потребителя. Под внимание се взимат и други методи, насоки и препоръки, който ще ви помогнат да разработвате висококачествени сайтове, достъпни за възможно най-широка аудитория.
Когато интернет стана масово явление в средата на 90те години, производителите на браузъри все още не бяха въвели поддръжка на CSS на ниво, което да позволи на разработчиците на сайтове да го използват за цялостен контрол върху презентацията на HTML документите. Разбираемо, предвид факта, че спецификацията CSS1 бе публикувана през 1996 година, а тази, описваща CSS2 – през 1998.
Липсата на CSS поддръжка в браузърите и желанието на графичните дизайнери да имат пълен контрол върху презентацията (навици от работата по печатни материали) доведе до масова погрешна употреба на HTML. Един от трудно умиращите прийоми и до момента си остава използването на таблици с невидима рамка. Така се оформя решетка, с която се контролира разположението на обектите по страницата. Друг подобен похват е употребата на прозрачно GIF изображение за фиксиране размерите на елементите – навик, останал предимно поради проблеми с интерпретацията от страна на господстващия през миналия век браузър Netscape 4.
HTML никога не е бил мислен като език за описване на презентация. Но му се наложи да стане, поради което употребата на хакове, грешен код, специфични за браузъра тагове и атрибути се превърна в ежедневие и едва ли не задължително за всеки един уеб разработчик. Привържениците на чистия код и придържането към стандартите лепнаха на подобен тип продукция етикета „таг-чорба“ (tag soup).
С излизането на нови версии на браузърите, поддръжката на CSS беше подобрена и разширена, макар и не на нивото на което би трябвало. Въпреки бавното темпо на въвеждането на CSS поддръжка, в момента лека полека достигнахме момента, в който браузъри с прилична такава са на масово въоръжение сред потребителите. Достатъчно, за да започнем да използваме HTML по предназначение – а именно да описваме структурата на документа, а не неговия изглед. За презентацията разполагаме със CSS, правен специално за това.
Уеб стандартите са технологии, установени от W3C и други организации, които се използват за създаването и интерпретирането на уеб базирано съдържание. Тези технологии целят създаването на максимално достъпни и ползваеми за в бъдеще уеб документи.
Този документ фокусира върху употребата XHTML 1.0 Strict за описание на структурата, CSS Level 1 и Level 2 за презентацията, и ECMAScript 262 за контрол над поведението (не, че имаме голям избор).
За да кажем, че документа се придържа към стандартите, трябва да сме сигурни че документа:
Забележете – „функционира“ не значи че „изглежда еднакво“. Реално погледнато, да направим един документ да изглежда еднакво под различни браузъри и платформи е непосилна задача, дори и да го реализираме изцяло с изображения. Документи, публикувани в интернет са разглеждани посредством голям (и предстои да нараства за в бъдеще) брой видове устройства и приложения, различаващи се както по начина на интерпретация на документа, така и по хардуерни параметри (размер на екрана, ако има такъв, брой цветове, налични шрифтове). Приемете го, за да си улесните живота.
Доста дизайнери и програмисти изпитват страх и неприязън към уеб стандартите. Често чувам „Много е сложно“, „Ами то и така си работи“, „Програмите са ми виновни...“
Лесно е да се реагира емоционално, да се отрича нуждата от научаване на нови приоми и отказването от стари, които са ползвани с години. Но нека погледнем реално на ползите от употребата и научаването на стандартите:
Документ от W3C, описващ как да подобрим кода на своя сайт
Мисията на проекта Уеб стандарти
Описание на стандартите и защо е добре да ги ползваме
Статия от Netscape DevEdge относно това как да изкараме пари от употребата им.
Статия, насочена към хора от маркетинг, комуникационни и IT отдели.
Валидацията е процес на контрол върху това дали документа реално отговаря на изискванията на езика, на който сте написали документа. Представете си го като проверка за правописа и граматиката.
Валидацията е важна част от разработката на един сайт, и безотказен метод за намиране на трудни за откриване грешки. Грешките могат да бъдат от тривиални (като правописна грешка) до фатални - като неправилна употреба на елемент или атрибут.
За нещастие все още много хора не проверяват документите си. Някои не знаят, други забравят, а има и такива които съзнателно избягват да го правят. Това до голяма степен е вина на производителите на браузъри, които се стремят продуктите им да се умело справят с невалиден 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>.
Когато стане въпрос за уеб стандарти, това, което винаги се споменава, е разделението на структура и презентация. Да разберем разликата между двете обикновено е трудно, особено ако не сме разсъждавали върху семантичната структура на документите. Въпреки това разбирането на проблема е от изключителна важност, защото контрола над изгледа на даден документ е много по-лесен, ако структурата и презентацията за разделени.
Структурата се състои от задължителните части на документа, заедно с семантичното и структурното обозначение на съдържанието.
Презентацията е начина по които желаете да представите документа. В повечето случаи това засяга начина по който този документ изглежда, но понякога това касае и начина по който звучи – не всеки използва графичен браузър.
Разделяйте структурата от презентацията на всяка цена, доколкото това е възможно. В идеалния случай HTML документа трябва да описва структурата и съдържанието, а презентацията да се контролира изцяло със CSS.
Подобна практика в момента е рядко срещана в момента, в повечето случаи HTML кода е не-структуриран и лишен от семантика.
За да отделите структурата от презентацията трябва да използвате CSS вместо таблици при изграждането на изгледа на документа. Когато сте използвали таблици за това, може би ще се почувствате неудобно и непривично, но реално погледнато не е толкова трудно, колкото изглежда. Има много информация и помощ из интернет, а предимствата на този подход са толкова много, че определено си струва да отделим време за да се научим да мислим по този начин.
(бел. ред.: Препоръчвам ви да разгледате Защо използването на таблици за оформяне на страницата е глупаво? - една презентация на Bill Merikallio, преведена на български от екип на FlashBG.
Друга важна част от разделянето на структурата от съдържанието е употребата на семантично обозначаване за структуриране на съдържанието на документа. Когато разполагаме с 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>
<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">„The presentation of phrase elements depends on the user agent.“</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>„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.“</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> </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>
| 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.
Великолепен източник на информация относно това как да изградим правилна семантична структура на съдържанието.
Възможно е да използваме 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:
Пишете с малки букви, и заграждайте атрибутите с кавички: Всички елементи и имена на атрибути трябва да бъдат с малки букви, а стойностите на атрибутите да са оградени с двойни кавички.
Неправилно: <A HREF="index.html" CLASS=internal>
Правилно: <a href="index.html" class="internal">
Затваряйте всички елементи: В HTML някои елементи не трябва да бъдат затваряни – те се затварят автоматично при началото на следващия. XHTML не позволява това – всички елементи трябва да бъдат затворени, дори тези, които нямат съдържание – като <img>
.Неправилно: <li>Item 1
Правилно: <li>Item 1</li>
Неправилно: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Правилно: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Неправилно: <br>
Правилно: <br />
Неправилно: <img src="image.jpg" alt="">
Правилно: <img src="image.jpg" alt="" />
Атрибутите не могат да бъдат съкращавани: В HTML, някои атрибути не могат да бъдат съкращавани. XHTML не го позволява.
Неправилно: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Правилно: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Не използвайте остарели елементи: Някои елементи и атрибути, позволени в HTML 4.01 Transitional и XHTML 1.0 Transitional са отбелязани като остарели в XHTML 1.0 Strict и HTML 4.01 Strict. Например - <font>, <center> alink, align, background, width и height (за някои елементи).
Проекта Web Standards пита W3C защо да използвате HTML и защо - XHTML.
Статия от A List Apart за прехода от HTML към XHTML.
Добро обяснение на това как да използваме XHTML и CSS.
Списък на разликите между XHTML 1.0 Strict и Transitional
Проекта Web Standards пита W3C какви MIME типове трябва да бъдат използвани със HTML и XHTML, и защо.
Обобщение на това какви типове медия трябва да бъдат използвани при изпращането на XHTML документи.
Препоръки на HTML Dog за това какво да не ползваме в XHTML.
Статия посветена на MIME типовете и как да определим правилния формат на съдържанието с помощта на различни сървърни езици.
Документ на W3C относно MIME типовете и XHTML.
В момента много малко 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">
Статия от A List Apart за това как и защо да използваме декларациите.
Обзор на това как различните декларации определят режима на браузърите
Официалният документ от W3C на правилни декларации на типа на документа.
Всички 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“ />
Web Standards Project пита W3C как е редно авторите да указват кодовите таблици.
Статия за различните кодови таблици.
Обяснение за специалните символи в HTML документите.
Демонстрация на това как да изберем и да укажем кодирането на документа.
Доскоро използван основно за да укаже характеристиките на шрифтовете, сега 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 файлове при обновяване на браузър или пускането на изцяло нов такъв.
Eric Meyer обяснява четири начина да скрием 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>
Използвайки атрибута style, можете да укажете CSS директно за даден елемент:
<h1 style="font-weight:bold;">Заглавие</h1>
Това обаче не е препоръчително, защото смесва структура и презентация.
Вътрешен CSS се пише в елемента <style>, който на свой ред се намира в секцията <head> на документа:
<style type="text/css">
h1 {
font-weight:bold;
}
</style>
Това също трябва да се избягва – най добре е да разделяме HTML и CSS в отделни файлове.
Обяснение на @import и @media директивите в CSS.
Всяко CSS правило се състои от селектор и една или повече декларации. С помощта на селектора указваме за кой HTML елемент се отнася правилото. Декларативния блок е ограден с { }, а всяка декларация завършва с ; (точка и запетая).
Ето едно просто CSS правило:
p {
color:#0f0;
font-weight:bold;
}
В този случай p е селектора, което означава че това правило се отнася до всички <p> елементи в документа. Правилото има две декларации, които указват текста в параграфите да бъде зелен и удебелен.
За по-детайлно описание на цсс правилата прегледайте CSS Beginner’s Guide, CSS from the Ground Up или някоя книга, посветена на CSS.
Заедно с читателите си, Dave Shea е съставил списък с практически CSS съвети.
(бел. ред.: Тази статия можете да намерите преведена на български от Георги Варзоновцев)
John Gallant и Holly Bergevin обясняват как да пишем компактен и ефективен CSS код.
Много добро обяснение на 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 (съставена от Dave Shea и преведена от Георги Варзоновцев) можете да намерите колекция от полезни съвети. Ето и някои от най-важните от тях, както и няколко, които няма да намерите там.
Винаги първо проверявайте кода с валидатор: Когато дебъгвате, започнете с валидация на XHTML и CSS кода. Много проблеми са причинени от неправилен код.
Тествайте в най-модерния браузър, после го подкарайте и на останалите: Ако използвате стар браузър с лоша имплементация на CSS по време на разработката, вашия код ще бъде адаптиран към специфичната за браузъра поддръжка. И когато го погледнете с по-модерен браузър има голяма вероятност изгледа на страницата да не е това, което очаквате. По-добре е първо да се разработи за браузърите, съобразени със стандартите, а после кода да се адаптира където е нужно с оглед поддръжка на по-стари браузъри.
Изследвайте хаковете на CSS box модела: Реалната височина (H) и ширина (W) на даден елемент е равна на зададената H или W плюс отстъпа (padding) плюс дебелината на рамката (border). В Internet Explorer 5, обаче, положението е точно обратното - реалната H или W е равна на зададената H или W минус отстъпа минус рамката. Ето и пример:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
Общата ширина на този елемент е 360px, от които 300px са за съдържанието.
10px + 20px + 300px + 20px + 10px = 360px
Обаче под Internet Explorer 5.*/Win общата ширина е 300px, от които за съдържанието са 240px.
300px - 10px - 20px - 20px - 10px = 240px
За да заобиколим този проблем, трябва да използваме CSS хак, за да подадем различни стойности за браузърите, които го интерпретират правилно, и за тези, които го разбират грешно. Другият вариант е просто да избягваме едновременната употреба на ширина и padding.
За подробно описание на проблема прегледайте Box model.
Бел. ред.: Освен това е полезно да погледнете универсалния box model hack на Tantek Çelik, както и страницата посветена на този тип хакове, поместена на изключително полезния сайт CssDiscussList.
Задавайте единици за числовите стойности, различни от 0: CSS изисква дефиницията на мерната единица при дефиниции като width, height, and font-size. Изключение прави нулата, защото тя си е нула, независимо от мерната единица.
Разберете флоутовете: Концепцията им е малко трудна за разбиране, но е много важна, защото употребата на float правилото е почти неизбежна при изграждането на презентацията само със CSS. Можете да прочетете повече в Containing Floats, Floatutorial, и в Float: The Theory.
„LoVe/HAte“: Указвайте псевдо класове за връзките си в порядъка Link, Visited, Hover, Active.
„TRouBLed“: Когато използвате съкратено описване на свойствата margin, padding или border, правете го по посока на часовниковата стрелка от горе - Top, Right, Bottom, Left.
Кръщавайте класовете и идентификаторите по тяхната функция, а не по изгледа им: Ако кръстите клас .smallblue(малък син текст), но в последствие решите, че текстът трябва да е голям и червен, името на класа ще бъде объркващо. По добре да използвате имената, за да описвате функцията – като например.copyright или.important.
CSS е чувствителен към големи и малки букви: Стойностите на атрибутите class и id в HTML са чувствителни към малки и големи букви, поне що се отнася до CSS (за справка: CSS2 syntax and basic data types).
Проверете вашите идентификатори: Само един елемент в документа може да има дадена стойност за атрибута id, докато много елементи могат да притежават една и съща стойност за class атрибута.
Използвайте само позволени символи за стойностите на class и id: Class и id имената могат да се състоят само от малки и големи латински букви, цифри[A-Za-z0-9] и тире (-), като не могат да започват с тире или с цифра. (за справка: CSS2 syntax and basic data types).
Коментирайте правилно: Коментарите в CSS започват с /* и се затварят с */:
/* Това е коментар */
Има много примери и уроци за това как да изградите сайта си с помощта на CSS. Добро решение е да започнете с прост изглед, да разберете как работи, и после да преминете към по-сложни решения.
Пример за това как да изградим прост лейаут с хедър, две колони и футър.
Колекция с връзки към различни лейаути, реализирани със CSS.
Достъпността не касае само и единствено възможността сайта да се използва от хора с увреждания, макар и това да е една от основните причини да правим сайтовете достъпни. Достъпен сайт работи по-добре за всеки, независимо дали страда от увреждания или не, и може да бъде видим за повече хора с различни браузъри и устройства.
Честа грешка е идеята, че ако направим сайта достъпен, той ще изглежда различен и по-малко привлекателен от преди. Това не е така. Достъпността често няма допирни точки с презентацията на даден документ.
Ето пример за това как достъпността може да е от полза за всеки: сайт има формуляр, посредством която потребителя може да се регистрира за семинар. Във формуляра трябва да изберете града в който желаете да посетите семинара посредством радио бутони. Името на града е до радио бутона. Ако разработчика на формуляра не е взел достъпността предвид, всеки, който използва графичен браузър трябва да постави мишката си точно върху малката зона на радио бутона, за да избере град. Ако обаче програмистът е взел предвид достъпността на формуляра, то той е маркирал текстовете до радио бутоните с елемента <label>, и вие ще можете да натиснете върху името, за да изберете града. Кой от двата начина за избор е по-лесен за всеки един от нас?
Употребата на семантичен, добре структуриран XHTML е голяма част от работата по изграждането на достъпен сайт. За да добиете груба идея колко е достъпен документа, погледнете го през текстови браузър като Lynx, за да видите дали съдържанието е разбираемо. Това далеч не е всичко, което трябва да направите, но е добър старт.
Много дизайнери обичат фреймовете като средство да разделят екрана в браузъра на различни части, като всяка една е различен HTML документ. Това би могло да е от полза в една интранет апликация, но в публичен сайт фреймовете създават някои проблеми:
Обърквате потребителя: Един от основните принципи на уеб е, че всяка страница има собствен URL. Като нарушите този принцип с фреймовете си, вие затруднявате потребителите в опита им да разберат как работи сайта.
Фреймовете затрудняват търсещите машини: За да могат ботовете на търсещите машини да индексират сайт изграден с фреймове, трябва да им осигурите връзки към всички страници със съдържание. След което потребителите, пристигнали от резултатите от търсенето вероятно ще се озоват на вътрешна страница, която вие не сте предвидили да се показва самостоятелно. Вероятно ще липсват основни неща, необходими на потребителя, като навигация или обозначение на сайта. Някои сайтове се мъчат да заобиколят този проблем като указават на ботовете чрез robots.txt файла да не търсят навътре по сайта. Други сайтове пък използват JavaScript, за да прехвърлят посетители, отворили директно вътрешна страница, към началната страница. Прекрасни методи – ако целта е да получавате по-малко посетители.
Фреймовете не позволяват bookmarks: Повечето браузъри не могат да отбележат в bookmarks страница, която е в фрейм. Когато отворите отбелязаното от вас, ще попаднете на състоянието на фреймсета по подразбиране – обикновено това е началната страница на сайта.
Печатането става трудно: Много потребители все още имат проблеми при отпечатването на документи. Много браузъри изискват да активирате фрейм, преди да го разпечатате.
Затруднява се изпращането на връзки по email: Фреймовете на практика правят изпращането на връзка към вътрешността на сайта невъзможно. Съществуват начини да заобиколите това, но изпълнението става сложно.
Сайтът става трудно достъпен: Посетителите, неизползващи графичен браузър, поддържащ фреймове се натъкват на проблеми. По тази причина препоръките за достъпност отричат употребата на фреймове.
Освен всичко останало с фреймовете си усложнявате живота на разработчик. Фреймовете правят сайта ненужно сложен технически.
Много често хората разбират „Не използвайте таблица за изграждане на презентация“ като „Не използвайте таблици въобще“. Това е неправилно. Ако представяте таблична информация, правилният начин да я покажете е точно посредством таблица. Важно е обаче да се отбележи, че когато изграждате таблици има много начини да ги направите по-логични и достъпни.
Връзки към статии относно това как да направите таблиците достъпни.
Статия на тема как да покажем таблична информация с таблици
Статия от Roger Johansson за представянето на таблична информация в достъпен вид.
Често формулярите са ненужно трудни за употреба, донякъде защото са направени нелогично, донякъде и защото кода им не използва правилните елементи за да направи формуляра достъпен и лесен за употреба. Елемени като <label>, <fieldset> и <legend> съществуват и трябва да бъдат използвани.
Чест въпрос е какво да бъде използвано за оформление на визията на форма. Някои твърдят, че формата може да бъде разгледана като таблична информация, и трябва да бъде описана с таблица, други настояват за CSS презентация. Използвайте което намерите за добре, но ако решите, че таблицата е вашия избор, проверете дали формуляра има смисъл и когато таблицата е игнорирана.
Статия от WebAIM за достъпните форми
Статия, която обяснява основите на създаването на по-добри и достъпни форми.
Избягвайте зависимостта от JavaScript. Доста хора (повече отколкото предполагате) са изключили JavaScript в браузъра си, било поради причини свързани със сигурността или за да избегнат попъпи. Освен това те може би използват браузър без поддръжка на JavaScript. Според TheCounter.com, 6% от потребителите нямат JavaScript. Според W3Schools.com цифрата е 8%.
В повечето случаи употребата на JavaScript не носи особена полза на потребителя. Разбира се има случаи, когато с помощта на JavaScript можете да постигнете по-добро потребителско изживяване. Пример за това е клиентска валидация на формуляр.
Това не значи, че не трябва да използвате JavaScript. Но означава, че сайта ви трябва да бъде достъпен и ползваем дори и без JavaScript. Същото важи и за cookies. Не ги използвайте по начин, който ще направи сайта ви недостъпен за потребителя, който не ги приема.
Същото важи и за cookies. Използвайте ги, но само по начин, който няма да наруши нормалната работа на сайта, ако потребителят е избрал да не приема cookies.
Тази секция всъщност не се отнася за стандарти или достъпност, но трябва да се спомене, че начина, по който се формира адреса може да има голямо значение за това как търсачките индексират сайта, и за това колко той е ползваем от потребителите.
Някои роботи не проследяват връзки към адреси с параметри (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 съотвествието им - &. Ако не го правите, някои браузъри ще (както би трябвало да правят) разберат амперсанда като начало на HTML знак, и последвалия след него текст ще бъде интерпретиран като символ, което в повечето случаи ще счупи адреса.
За повечето сайтове е ненужна употребата на www поддомейн - може спокойно да бъде ползвано http://yourdomain.com вместо http://www.yourdomain.com. Повече информация за това може да бъде намерена на http://no-www.org. За всеки случай най-добре би било да конфигурирате сървъра си да пренасочва http://www.yourdomain.com/ и http://yourdomain.com/ към едно и също място.
Статия относно проблемите с адресите и как те да бъдат избегнати.
Защо е добре да завършваме адреса с „/“.
Колекция с връзки и статии на тема адреси.
Подробно обяснение на проблемите, който некодираните амепрсанди могат да предизвикат.
Списък с материали, книги, сайтове и пощенски списъци, които могат да ви бъдат полезни.
Практически ориентирана книга на тема употреба на CSS.
Продължението на първата част.
Упътване относно CSS и обяснение на спецификацията.
Практически примери за приложение на стандартите.
Книга, посветена на темата достъпност и достъпни сайтове.
Спецификация на W3C
Спецификация на W3C
Спецификация на W3C (все още в разработка)
Пощенски списък на тема практическа употреба на CSS.
Сайт с много уроци и примери на тема HTML и CSS.
Прекрасен пример за това как един и същи HTML документ може да бъде представен по множество различни начини с помощта на CSS.
Няколко добри презентации и статии на тема CSS (някои от тях са преведени на български).
Статии, примери, браузърни бъгове и др.
Седмичник със статии на тема web дизайн и разработка, фокусирано върху различни техники и ползи от употребата на стандартите.
Пощенски списък за хората, който правят web. Повечето теми са свързани с дизайн и разработка на сайтове.
Официалната спецификация от W3C.
Сайт с много уроци и примери на тема HTML и CSS.
Книгата на Joe Clark’s за достъпността в електронен вариант.
Книгата на Mark Pilgrim.
Препоръките на W3C относно изграждането на достъпни сайтове.
Информация от W3C за инструменти, полезни за подобряването на достъпността на сайта ви.
Проектът е неофициална коалиция, бореща се за стандарти, които да позволят прост и лесен достъп до уеб за всички.
Мисията на MACCAWS е да осигури необходимите ресурси за внедряването на уеб стандартите в комерсиални проекти. Два интересни документа от MACCAWS: What Every Web Site Owner Should Know About Standards: A Web Standards Primer и The Way Forward with Web Standards.
Уптване от Dave Shea за всеки, който желае да се запознае с употребата на уеб стандартите.
Официалната спецификация на W3C.
Сайт с много уроци и примери на тема HTML и CSS.
Коментари, въпроси и предложения изпращайте на автора.
© Copyright 2004 Roger Johansson
Ако имате забележки по превода на материала, моля пишете в тази тема във форумите на FlashBG.org. Преводът беше направен от Петьо Иванов, а редакцията - от Боби Димитров.