Здрастуйте, шановні читачі блогу . Я хочу продовжити розповідати про основи роботи з Html з самого початку, послідовно і нічого не опускаючи. Сьогодні ми поговоримо про спеціальному тегу (декларації) Doctype, дізнаємося, як правильно оформляти коментарі в ХТМЛ код, як прописувати заголовок веб документа Title і постараємося розібратися у відмінностях блокових і малих елементах.
У попередній статті з рубрики Html для чайників (в якій в основному розповідалося про те, що таке мова ХТМЛ, теги і валідатор W3C) ми закінчили на тому, що будь-який документ в інтернеті повинен мати певну структуру.
Директива Doctype Html, Xhtml і ХТМЛ 5
Першим елементом мови розмітки, який ви зустрінете в будь-якому правильному Web документі (сторінці), буде спеціальна директива Doctype. Вона починається з кутової дужки та проставленого відразу ж за нею знака оклику
Сам по собі елемент Doctype служить для оголошення типу документа і допомагає браузеру зрозуміти, на яку версію Html або XHTML (за класифікацією валідатора W3C) йому слід спиратися при розборі коду завантажує веб сторінки.
Якщо тип документа не буде зазначений у цій директиві згідно з загальноприйнятими правилами, то браузер, швидше за все, все одно правильно відобразить ваш документ, але не факт, що теж саме зроблять і інші популярні браузери тисяч ваших читачів. Тому Doctype повинен бути присутнім у вихідному коді сторінки обов’язково і складений він повинен бути правильно.
Але давайте на цьому зупинимось трохи детальніше. Зараз ми з вами спостерігаємо певний дуалізм або ж два типи документів в мережі — як робили раніше до виділення CSS з лона мови ХТМЛ і як роблять зараз з прийнятим сучасним стандартам.
Природно, що після прийняття нових стандартів в мережі інтернет залишалося все одно величезна безліч документів, створених за старими принципами чистого ХТМЛ (без CSS) і браузери повинні були з ними працювати. Корпорація Майкрософт свого часу запропонувала використовувати цю саму директиву Doctype з нової мови розмітки XML.
Виглядати вона може по різному (про це читайте нижче), але простіше всього використовувати такий варіант (трохи нижче по тексту поясню чому):
Таким чином браузер буде розуміти, за яким саме стандартам йому розбирати код документа. Якщо ця декларація має місце бути, то браузер переходить в режим роботи за стандартами (standarts mode). Якщо ж її браузер не знайде в самому початку документа (або вона буде не відповідати правильного варіанту написання), то тоді браузер включить хитрий режим прийомів (quirks mode).
Документ у цьому випадку буде відображатися таким чином, як ніби цей браузер дуже старий (старовинний). Якщо в цей же документ додати декларацію, то браузер буде здійснювати розбір коду з урахуванням всіх наявних на поточний день стандартів.
Правда, поняття старого браузера надто розпливчасте. Все той же лідер за швидкістю роботи і швидкості западання в серця користувачів Google Chrome з’явився тільки в 2008 році.
У IE (тут можна завантажити останню версію Експлорера і не пошкодувати) історія набагато більш довга, саме тому всі браузери в режимі quirks mode (прийомів, тобто коли декларація не була прописана) будуть відображати вебсторінку точно так само, як це б робив старовинний IE версії 5.5 (вона вважається базовою).
Більш докладно і на конкретному прикладі дізнатися про те, чому обов’язково потрібно прописувати Doctype на початку будь-якого веб документа, ви зможете з цієї статті про CSS властивості height, width і overflow. Насправді повчально.
Хоча, якщо ви створюєте свій проект на базі якогось движка або іншими словами CMS, то за правильність формування цієї декларації буде відповідати використовуваний вами движок, але знати призначення Doctype та варіанти його написання все одно зайвим, на мій погляд, не буде.
Виглядати це справа може, наприклад, так:
Якщо ви читали мою попередню статтю, то, напевно, зрозуміли, що дана директива в цьому випадку вказує браузеру на те, що код цього документа потрібно буде розбирати, спираючись на стандарти мови HTML 4.01. Для пошуку потрібного вам варіанти ви можете звернутися до описаного в попередній статті валідатору W3C, але щоб там знайти що-небудь, потрібно точно знати де це лежить, інакше…
Сайт валідатора W3C не володіє дружнім інтерфейсом і інтуїтивно зрозумілою навігацією. Там ви запросто можете знайти варіант директиви з відносною посиланням на сторінку з описом потрібного вам стандарту ХТМЛ або XHTML і, вставивши такий варіант до себе на сайт, нічого доброго не отримаєте:
При такому варіанті Doctype браузер буде шукати документ з описом стандарту на вашому власному сайті, додавши до відносної ссылке «TR/html4/strict.dtd» доменне ім’я вашого ресурсу: «https:///TR/html4/strict.dtd».
Загалом, така директива працювати не буде і в майбутньому слід звертати особливу увагу на наявність «http://www.w3.org/» в її коді, щоб не наступити на ці граблі.
Взагалі-то існує всього лише кілька варіантів DOCTYPE Html і ще кілька для XHTML. Всі ці варіанти ви зможете переглянути на відповідній сторінці валідатора W3C.
Давайте почнемо зі стандарту мови гіпертекстової розмітки 4.01 (ХТМЛ 5 поки що ще тільки розробляється). Для цього випадку існує три варіанти Doctype: строгий, перехідний і з підтримкою фреймів:
Найчастіше використовують другий варіант (Transitional), т. к. він допускає більше вольностей в написанні коду документа, ну, а варіант з фреймами вам навряд чи стане в нагоді, в силу неактуальність їх використання на сьогоднішній день.
Власне, є такі ж три варіанти Doctype для XHTML — суворий, перехідний і з підтримкою фреймів:
Але давайте подивимося, звідки беруться ці варіанти правильного написання декларації. Пам’ятаєте, ми в першій статті розглядали таблиці допустимих Html тегів:
І окрему таблицю можливих атрибутів Html:
Як ви можете бачити, в обох цих таблицях присутній стовпець «Depr», в якому буквою «D» позначені застарілі і не рекомендовані до застосування теги і атрибути мови ХТМЛ. Це ми з вами вже розглянули. Але зверніть увагу, що навпроти кожної літери «D» в сусідньому праворуч стовпці «DTD» варто або літера «L» (Loose DTD), або літера «F» (Frameset DTD).
Т. о. всі теги і атрибути, які не позначені літерами «D» (не рекомендовані) входять в строгу декорацію Doctype (тільки рекомендовані елементи і нічого більше). Якщо ж ви все-таки будете допускати використання не рекомендованих тегів і атрибутів мови Html (вони позначені літерою «D»), то потрібно буде оголошувати для таких документів декларацію перехідну.
Деякі елементи і атрибути, позначені в стовпці «DTD» буквою «F» (наприклад, FRAME, FRAMESET), будуть входити в декларацію Doctype для фреймових структур. Вона базується на основі перехідний, до якої додаються теги і атрибути для створення фреймів, про які ви можете почитати за наведеним посиланням.
А тепер давайте спробуємо розібратися, а з яких частин складається декларація Doctype?
Спочатку йде назва — «Doctype». Тут, думаю, все зрозуміло. Далі йде «Html» — кореневий елемент даного мови розмітки. Потім йде вказівка — публічна дана декларація або ж системна. Всі варіанти Doctype є публічними, що позначається словом «PUBLIC».
А далі йдуть два ідентифікатора документа. Перший з них називається публічним ідентифікатором («-//W3C//DTD HTML 4.01//EN»). Мінус означає те, що ця декларація не зареєстрована в стандарті ІСО. Потім слід назва консорціуму, її назва і мова, на якому вона написана. У другому ідентифікатор вказується шлях до файлу суворого варіанти.
Ну, а тепер давайте розкрию вам всю правду про Doctype. Браузерам важливо тільки формально правильне її написання, але вони ні в якому разі не полізуть на сайт консорціуму, щоб завантажити вказаний в ній файл.
Навіть якщо ви виберіть варіант суворої декларації і при цьому будете використовувати не рекомендовані у сучасній версії Html теги і атрибути, то будь-який браузер все одно вас правильно зрозуміє — це факт перевірений і підтверджений.
Тому, щоб не мудрувати лукаво, в Html 5 написання Doctype буде виглядати вже ось так:
І все. Залишили тільки «Html». І незважаючи на те, що ХТМЛ 5 ще не повністю впроваджений, даний варіант підтримується всіма сучасними браузерами і ви можете сміливо їм користуватися. Про як, а ви кажете…
Html коментарі в вихідному коді сторінки тег Title
В службовій області Web документа (між тегами Head) обов’язково повинен бути прописаний заголовок цього самого документа (веб-сторінки), укладений елементи Title (див. на рисунку).
Переоцінити значимість укладеної в ньому інформації дуже важко (я не перебільшую). Коли ви буде підбирати ключові слова у Яндекс Wordstat (використовуючи для цього статистику пошукових запитів Яндекса), то після складання семантичного ядра вам обов’язково потрібно буде згадати вибрані ключові слова в заголовку Title.
Про те, наскільки важливі слова укладені в Тайтлі для майбутнього успішного просування проекту, ви можете дізнатися зі статті Як розкрутити сайт самому, а про те, як прописати потрібні вам слова в Title для Joomla та WordPress, ви дізнаєтеся зі статті Самостійне просування, оптимізація і розкрутка сайту.
Вміст метатега Title буде відображатися вгорі вікна браузера користувача і в пошуковій видачі Google і Яндекса, тому, крім вмісту в ньому ключових слів, він повинен стимулювати користувачів перейти саме на ваш сайт з пошукової видачі. Для кожної сторінки вашого ресурсу заголовок тайтл повинен бути унікальним, інакше буде погіршення в ранжируванні вашого проекту.
Тепер давайте перш, ніж переходити до розгляду конкретних тегів, зупинимося на такому понятті, як коментарі в Html коді. Вони досить часто наводяться для того, щоб потім було простіше знайти потрібні ділянки або ж для того, щоб іншим було простіше зрозуміти задум автора. Само собою зрозуміло, що текст цих коментарів ні в якому разі не повинен відображатися на веб сторінці, тому вони спеціальним чином оформляються в коді.
Особливо актуальні коментарі в Html були в часи панування табличної верстки (читайте про ХТМЛ таблиці), бо тоді, у порівнянні з сучасною блокової версткою (тут описана Div верстка на прикладі), дуже просто було заплутатися, що і в якій комірці таблиці виводиться:
Напевно, з наведеного вище прикладу ви вже зрозуміли, що всі коментарі в мові Html починаються точно так само, як і будь-які інші елементи — з кутової дужки, але відразу ж після неї, при формуванні коментаря, потрібно буде поставити знак оклику (при описі Doctype я згадував, що коментарі теж є деклараціями, які обов’язково починаються з
Весь текст коментаря, який буде знаходитися між цими двома дефісами, буде розглядатися браузерами як службова інформація і ніяк оброблятися не буде. Коректність її написання можна наочно оцінити при використанні описаного тут Html редактора notepad з підсвічуванням коду:
Але всередині коментаря можна розміщувати не тільки текст, але і все що завгодно. Наприклад, досить часто зустрічаються закомментированные фрагменти Html коду і ця ділянка браузерами оброблятися не буде. Що примітно, коментар можна відкрити на одному рядку коду, а закрити хоч через сотню рядків, і укладений таким чином шматок коду для браузера просто перестане існувати.
Все досить просто і думаю, що з ними у вас проблем не виникне. Хоча є одна тонкість в роботі з багаторядковими коментарями в ХТМЛ. Всередину одного коментаря не можна поміщати інший, інакше частина закомментированной інформації може бути відображена браузером на веб сторінці. Давайте для прикладу розглянемо таку конструкцію:
Отже, браузер при розборі коду веб сторінки виявить відкривають символи декларації коментаря і почне пошук закривають. Знайде його після слів «Вкладений комент», а от все інше (в нашому випадку це продовження зовнішнього коммент—>) буде оброблено браузером та виведено на веб сторінці.
В принципі, якщо ви користуєтеся при написанні Html редактором коду з підсвічуванням, то відразу ж помітите недобре по зміні кольору вашого коментаря:
Поняття блокових і рядкових елементів (тегів) в Html
Всі теги, які можливо використовувати всередині елементів Body (те, що відображається на веб сторінці, список яких ви можете знайти в валидаторе W3C), можна розділити на дві групи: малі та блочні теги.
Блокові елементи використовуються для побудови структури Web-документа, а малі використовуються для оформлення шматків тексту (рядків). Причому, завжди потрібно дотримуватися одне непорушне правило — не укладати всередину рядкових блокові теги.
Найяскравішими і показовими представниками малих і блокових тегів є, відповідно, Div (блочний елемент — звідси і пішла назва блокової верстки) і U (рядковий). Ці теги мови гіпертекстової розмітки є парними, тобто у них є відкриваючий і закриваючий тег.
Взагалі, теги Div і Span абсолютно не мають ніякого призначення і сенсу в чистому Html без використання таблиць каскадних стилів CSS. Вони є контейнерами, що дозволяють змінювати властивості ув’язнених у ньому елементів через CSS.
Якщо ви пропишіть у вихідному коді сторінки поспіль кілька елементів Div, то на веб сторінці кожен з них, швидше за все, спробує зайняти весь доступний йому простір по ширині, і тому розташовані такі контейнери будуть один під одним. Контейнери Div при нормальних умовах поруч один з одним стояти не будуть, якщо примусово змусити їх робити це.
Наприклад, ось такий Html-код буде відображатися в трьох блоках розташованих один під одним:
У браузері Firefox поряд з дуже корисним плагіном Firebug я ще використовую плагін Web developer, який дуже допомагає при верстці. Серед усього іншого він може показувати блокові елементи, обводячи їх рамочкою. Саме цей плагін developer створив сині рамочка навколо контейнерів Div на цьому скріншоті.
Теги ж Span можна укладати шматки тексту (рядки) Html коду для додання їм певних властивостей через CSS, і такі елементи можуть розміщуватися в одному рядку поруч один з одним. Наприклад, ось такий код в браузері буде мати наступний вигляд:
Вміст Span тут теж було підсвічено з допомогою плагіна Web developer. Т. к. елементи Span є малими, то не слід всередину них укладати блокові теги, наприклад, всі ті ж Div контейнери.
Удачі вам! До зустрічей на сторінках блогу
