У форматі HTML5 з'явилися нові елементи, які служать заміною для звичайних блокових елементів з атрибутами class і id, наприклад або .
Розглянемо три елементи, які легко можна сплутати один з одним:
- div – "базовий контейнер", який ми всі знаємо і любимо.
- section – "документ або розділ програми" Зазвичай містить верхній (header) і нижній (footer) колонтитули.
- article — «незалежна частина документа чи сайту» Ця частина повинна мати сенс незалежно від іншого змісту.
Різниця між div, section та article
У HTML4 div використовувався як базовий елемент розмітки. Він не мав особливого семантичного значення.
Елемент section
Новий елемент section дуже схожий div , т.к. використовується як контейнер, але він має особливе семантичне значення – об'єкти, які розташовуються всередині нього, об'єднані загальним змістом.
Також цей елемент служить для розбивки тексту на розділи.
Елемент article
Новий елемент article – це спеціальний вид section , який позначає незалежну та самодостатню частину сторінки. section, але article додає більше семантичного значення.
Що вибрати?
Якщо проводити аналогію з HTML4, то можна порівняти ці теги з p і blockquote.Обидва теги – блокові елементи, але blockquoteяк різновид p, має значення «блок цитованого тексту». section і article: тег section означає близький за змістом текст, а тег article означає осмислену частину цього тексту.
Бентежною обставиною є те, що section може бути використана для різних частин сторінки (головна колонка, розділ новин тощо на одній сторінці) та містити article, а також для дроблення великого article (тобто використовуватися всередині article).
Щоб визначити, який із елементів вибрати, можна використовувати алгоритм:
- Чи матиме вміст осмислене значення саме по собі, наприклад, при публікації в RSS-потоці? article
- Якщо частини вмісту об'єднані загальним значенням, то вибираємо section
- Зрештою, якщо немає ніякого семантичного значення, то вибираємо div
Елемент section , За рідкісним винятком, не повинен використовуватися, якщо у нього немає заголовка. nav і aside може бути цілком типовим явищем.
Отже, елемент section не варто використовувати якщо:
- потрібний блоковий елемент для декорування. div
- тут для розмітки вмісту більше за змістом підходять елементи article, aside або nav
- у розділу немає природного заголовка
Елементи section і article використовуються аналогічно div в HTML4. Вони не повинні зустрічатися всередині. p, blockquote або address.
Ще замітки зі схожою тематикою
Категорії
Коментарі до нотатки
Дякую, давно хотілося прочитати настільки осудний і гарний текст з зазначеної теми. Усіх благ автору!
Чітко і у справі. Що, коли та де застосовувати. краще не знайшов, скрізь інфа чи неповна, чи неточна. Сайт в закладках будь-кому.
Повне марення, не знайшов жодної причини, щоб використовувати section або article, замість усіх улюбленого div'а. Це теж саме, що стверджувати, що для дзвінка потрібно використовувати iPhone 6, а не старенький самсунг, хоча в плані здійснення дзвінка самсунг вже всім сподобався і немає потреби його чимось заміняти.
Професіонали застосовують ці теги не тому, що вони модні. Вони потрібні, щоб наповнити розмітку змістом для допоміжних технологій, пошукачів, роботів тощо. Ви можете верстати одними div-ами і взагалі ніякі інші теги, крім нього, не використовувати. І це не жарт.
Але можна замість section написати article? Реклама це самодостатній розділ? він не залежить ні від чого іншого… контент може бути один, а реклама взагалі на іншу тему… коротше марення це все з цими елементами, тільки заплутує більше… далі:
Свіжі статті
Стаття 1
Текст статті
Стаття 2
Текст статті
Зі статті про section — «…об'єкти, які розташовуються всередині нього, об'єднані загальним змістом.» Хіба у прикладі у section об'єкти об'єднані загальним змістом?
Свіжі статті "Заголовок статті 1" = Автоваз випускає новий автомобіль "Заголовок статті 2" = Збірна Росії виграла чемпіонат світу
Дякую за запитання.
Ви самі його процитували: Свіжі статті Про поєднання кількох статей тегом все дуже просто. Статті виводяться списком. Якщо вони потрапили до списку, то цей список має заголовок. Він і відбиває їхній загальний зміст. Якщо до блоку section ви не можете вигадати заголовок, то це використовуйте div . У прикладі статті пов'язує лише те, що вони були нещодавно опубліковані. Якщо ви подивіться на список статей у будь-якій категорії, то їхній загальний зміст стане більш очевидним.
Доброго дня! А чи можна розміщувати рекламу adsence та віджет коментарів вконтакті між елементами article і main, в яких знаходиться сама стаття? Якщо так, то треба їх ще оточувати елементом aside чи section?
Будь-яка реклама та віджети сторонніх сайтів вставляються через JS. На момент завантаження документа їх немає. Тому ніяка додаткова розмітка їм не потрібна — використовуй звичайні
Доброго дня, Володимире! Якщо я створю два сайти абсолютно ідентичних, але в 1 випадку – використовуватиму тільки div, а в 2 – div, section, article, то браузери будуть охоче і швидше просувати останній варіант? Чи це впливає на просування сайту?
Олександре, здогадуюсь, що ви мали на увазі пошукові системи, а не браузери. Якщо не помиляюся, то вони поки що ніяк не розпізнають ці теги. Інакше кажучи, вони для краулера однакові.
все дуже дохідливо.. особливо аналогія з p і blockquote. тільки p і blockquote хіба блокові елементи, я знав їх як малі
Питання про розмітку у коментарях до статті. Вордпресс в wp-includes/class-walker-comment.php Є коментарі для сайтів з розміткою HTML5.Чому у вас не розмічені коментарі тегом артикл? Це я до того, що в вордпрес тямущі реяті і може вони мають рацію щодо цієї розмтеки?
Jurassic Park
Dinos були великі!
Way too scary for me.
I agree, dinos are my favorite.
Гарний приклад. У ньому проілюстровано вкладену структуру.
Дякую за відповідь. У мене ще питання щодо вашої розмітки. Після перевірки у валідаторі у вашому Head виє таке:
Error: Attribute itemprop не дозволяється на елементі meta на цьому пункті. From line 53, column 1; to line 53, column 229 crodata">↩↩ У мене питання чергове. Чим загрожують подібні помилки під час ранжирування сайту? Мені подобається ваше рішення щодо мікророзмітки сайту. І я взяв її собі на озброєння. Тому і копаюсь у вашому коді))
Костянтин, дивіться, валідатор HTML-розмітки знає стандарти, яким має відповідати документ. Але він уявлення не має про розмітки типу microdata, RDFa, Open Graph, Twitter Cards та багато інших. Він не має завдання валідувати їх. Відповідно він показуватиме помилки та попередження на дані, про які він не знає. Розумієте? Якщо вас цікавить як якась пошукова система чи соціальна мережа сприймає контент сторінки, користуйтеся інструментами валідації, які надають ці платформи.
Це знов я) Ви приховали h1. Навіщо? Він не лізе у загальну концепцію дизайну? Заздалегідь вдячний за відповідь
Костянтин, цей елемент потрібний, щоб сформувати правильну структуру документа. Але в дизайні мені цей заголовок, що дублює, не потрібен, тому я і приховав його. Щоб не плодити дублікатів, потрібно забрати на сторінці статті. Вся сторінка це і є стаття.
Просто, чим більше я розумію ваш html код, тим більше відкриваю для себе новин і все більше постають питання. Хотілося б почитати статтю від вас про код вашого сайту і дізнатися чому ви вибрали в коді те чи інше рішення. З тим же і h1. У всіх посібниках щодо СЕО, категорично заявляють про важливість не приховувати контент і особливо в такому тегу. Ви ж зробили все навпаки і приховали його помітивши класом visuallyhidden, при цьому не отримавши каральних санкцій від пошукових систем. Чому ви не використовуєте теги nav і main. Адже якщо використовувати їх у вашій розмітці, то губиться правильна структура заголовків (якщо аналізувати за допомогою html5 outliner). Цього ніде не прочитати у російському інтернеті.
Так, розумію, що мої експерименти виглядають марно. Область SEO оточена містикою та забобонами. Люди просто роблять те, що пишуть інші люди, не вдаючись у суть (типу, наші діди так робили, батьки так робили і ми так робитимемо), і тим самим зайво обмежують себе. Я не соромлюся почитати специфікації, подумати над ними та поєднати різні вимоги, уникнувши протиріч. У більшості випадків так випаровуватися не потрібно.
Якщо ви про експерименти з тегами nav і main, то це зовсім не марно. Я якраз учора був спантеличений відповіддю Untitled Section на перевірку розмітки заголовків у html5 outliner. З'ясував, що проблема полягає в тому, що він вимагає заголовки в nav і body. У вас ця проблема вирішена дуже елегантно). Я маю чергове питання.Хочу всередині статті використовувати блок зі змістом (список змістів у статті):
Розмітка у фрагменті цілком адекватна. З іншого боку, ні Google, ні Яндекс не цікавлять ці дані. Вони їм рівносильні звичайному тексту. Головна суть усіх розміток – це донести якусь інформацію споживачеві. Можна згорнути все на
Дякую за таку розгорнуту відповідь. Щодо реалізації списку змістів на джаві – вже думав про це – це було б найкращим варіантом. Я читав здається у вашому твіттері, що ви обожнюєте джаву і вам здасться реалізація цією мовою легким завданням, але на мене дуже поверхові знання в програмуванні. Я просто пилю сайт для себе та своїх пацієнтів. Щодо атрибуту aria і role. Тобто. на вашу думку ці маркери більш зрозумілі роботам, ніж та ж розмітка від счема.орг? До речі, а вам не доводилося написати статтю на більш конкурентну фразу? Наприклад, «програмування на java»? Цікава видача в Гуглі)
Щодо атрибуту aria і role. Тобто. на вашу думку ці маркери більш зрозумілі роботам, ніж та ж розмітка від счема.орг?
Костянтин, атрибути aria-* та role потрібні для допоміжних технологій, а не для пошукових систем. У попередньому коментарі я хотів показати, що будь-які додаткові «розмітки» потрібно застосовувати з чітким розумінням, кому вона буде корисна. Якщо ви не знаєте, в чому її користь, то і додавати не потрібно. Загалом, слоган «що простіше, краще» тут діє безвідмовно.
До речі, а вам не доводилося написати статтю на більш конкурентну фразу? Наприклад, «програмування на java»? Цікава видача в Гуглі)
© 2009–2023 Володимир Кузнєцов.
Усі права захищені та належать їх власникам.
Копіювання матеріалів даного блогу допускається лише з дозволу автора.
Від автора: візуальне відображення браузерами заголовків, вкладених у елементи section, створює враження, що вони призначають логічну ієрархію цих заголовків.Однак це суто візуальний ефект і не передається допоміжним технологіям. Який сенс у section і як автори повинні відзначати заголовки, які є надзвичайно важливими для користувачів AT?
Кілька днів тому я розмовляв з кількома друзями, один з яких запитав мене про різницю між article та section у HTML. Це одна з вічних загадок веб-розробки: чому white-space: nowrap, а не white-space: no-wrap? і «чому колір CSS «gray» темніший, ніж «darkgray»?».
Я дав свою звичайну відповідь: уявіть собі article не просто як газетну статтю чи пост у блозі, а й як одяг — окремий об'єкт, який можна використовувати в іншому контексті. Ваші штани – це article, і ви можете носити їх з іншим вбранням; ваша сорочка – це article, і її можна носити з різними штанами; ваші чоботи з лакованої шкіри – це article (ви не одягнете їх тільки одні без інших предметів гардеробу, чи не так?).
У специфікації сказано: «Елемент article є повною або самодостатньою композицією в документі, сторінці, додатку або сайті і, в принципі, може незалежно поширюватися або використовуватися повторно, наприклад, у синдикації. Це може бути повідомлення на форумі, стаття в журналі чи газеті, запис у блозі, коментар коментар, інтерактивний віджет чи гаджет або будь-який інший незалежний елемент контенту».
Таким чином, головна сторінка зі списком записів у блозі буде елементом main, що обгортає ряд елементів article, по одному для кожного запису в блозі. Ви б використовували ту ж структуру для списку відео (наприклад, YouTube) з кожним відео, оберненим в article, список товарів (наприклад, Amazon) і таке інше.Будь-який із цих пунктів article є концептуально синдикованим – кожен може виділятися на окремій виділеній сторінці, в оголошенні на іншій сторінці, як запис в RSS-стрічці і т.д.
Apple WatchOS містить Reader, який використовує елемент article, щоб дізнатися основний зміст вашої сторінки. Apple каже:
Ми перевели Reader на watchOS 5, де він автоматично активується при переході за посиланнями на веб-сторінки з великою кількістю тексту. Важливо переконатися, що Reader виділяє ключові частини веб-сторінки, використовуючи семантичну розмітку для посилення значення та призначення елементів у документі. Давайте розглянемо приклад. Спочатку ми вказуємо, які частини сторінки є найважливішими, обертаючи в тег article».
У поєднанні article з мікроданими HTML5 Reader створює оптимальне уявлення дисплея для невеликих екранів смарт-годин:
Зокрема, включення цих елементів заголовка до статті гарантує, що всі вони відображаються в Reader. Reader також стилізує кожен елемент заголовка по-різному залежно від його атрибута itemprop. Використовуючи itemprop, ми можемо забезпечити, щоб автор, дата публікації, заголовок та підзаголовок були помітні».
То що про section?
Моя звичайна порада така: не турбуйтеся про section і не турбуйтеся про те, чим вона відрізняється від article. Він був введений як універсальна оболонка для заголовків, щоб браузер міг визначити структуру документа HTML5.
Що? Алгоритм контуру документа передбачає використання тільки одного тега заголовка — h1 — і він чарівним чином стає правильним рівнем заголовка (наприклад, перетворюється на h2, h3 і т.д.), залежно від того, наскільки глибоко він вкладений у секціонуванні елементів HTML5 : article, section і так далі.
Наприклад, ось що ви ввели в CMS:
Структура HTML5 — div, section та article :: Зберігач нотаток - Mriya.v.ua Lorem Ipsum Trondant Fnord
Це чудово працює, коли відображається, як окрема стаття. Але як щодо головної сторінки, яка є списком останніх статей?
Структура HTML5 — div, section та article :: Зберігач нотаток - Mriya.v.ua Структура HTML5 — div, section та article :: Зберігач нотаток - Mriya.v.ua Lorem Ipsum Trondant Fnord
Структура HTML5 — div, section та article :: Зберігач нотаток - Mriya.v.ua Magnum solero paddle pop
У цьому прикладі, відповідно до специфікації, h1 всередині елементів article «стають» логічними h2, тому що article, як і section, є елементом секціонування.
Це не нова ідея. Ще 1991 року сер Анкл Тімбо писав:
«Я б насправді віддав перевагу замість h1, h2 і т.д. для заголовків [ти приходять з AAP DTD] мати вкладення елементів
, та загальні
Однак, на жаль, жоден браузер не реалізує контури HTML5, тому немає сенсу використовувати section. У якийсь момент програма читання з екрану JAWS спробувала реалізувати алгоритм контуру документів (IE, але не Firefox), але це погано вийшло. Здається, що розробники браузерів просто не зацікавлені в цьому (більше подробиць у розділі «Додаткові матеріали»).
"Але, – вставив інший співрозмовник, – тепер браузери відображають різні розміри шрифту в залежності від того, наскільки глибоко h1 вкладені в section", і продовжив доводити це. Розрив мозку!
Ось схожа демонстрація. У лівому стовпчику показано чотири h1, вкладені у section; у правому стовпці показано h1, h2, h3, h4, без вкладеності. Знімок екрана Firefox показує, що для вкладених h1 за замовчуванням використовується той же шрифт, що і для звичайних тегів h1…h4:
Порівняння h1, вкладених у елементи section, і h1, h2, h3, h4>
Ті ж результати будуть у Chrome, похідних Chromium, таких як Edge beta для Mac та Safari для Mac. Чи означає це, що ми всі повинні з радістю почати використовувати h1 як єдиний елемент заголовка, вклавши його в section?
Ні. Тому що це лише зміна візуального стилю h1. Якщо ми відкриємо інспектор спеціальних можливостей Firefox в інструментах розробника, то побачимо, що текст level 2 оформлений стилем H2, але все ще встановлений на рівні 1 – дерево доступності не було змінено на рівень 2.
Інспектор доступності Firefox показує, що вкладений елемент h1 візуально виглядає так само, як і h2, але для його aria-level неправильно встановлено значення "1", а не "2"
Порівняйте це з реальним H2 у правому стовпці:
Інспектор доступності Firefox показує, що реальний h2 має обчислений aria-level "2", що коректно
Це показує, що дерево доступності було правильно поінформовано, що це заголовок рівня 2. Фактично, Mozilla дійсно намагалася передати обчислений рівень дерево спеціальних можливостей:
«Ми трохи поекспериментували з цим… але потім нам довелося скасувати це, тому що люди в нашій команді скаржилися на дуже велику кількість регресій (випадкове зниження рівнів h1 тощо)».
Для користувачів допоміжних технологій життєво важливою є правильна ієрархія заголовків. Як показало восьме опитування користувачів WebAIM:
«Корисність правильних структур заголовків дуже висока: 86,1% респондентів вважають рівні заголовків дуже чи певною мірою корисними».
Тому ви повинні продовжувати використовувати h1…h6 та ігнорувати section.
Ніколи не кажи ніколи
«Але…, — можливо, тепер ви обуритеся, — на цій самій сторінці є елемент section!». І ви будете праві, дорогий читачу. "Короткий зміст" укладено в section, з міркувань доступності. Коли користувач програми читання з екрану Леоні Уотсон провела свій вебінар «Як користувач програми читання з екрана отримує доступ до Інтернету», вона вказала на область, де розмітка журналу Smashing Magazine може бути змінена, щоб поліпшити її сприйняття.
Як ви можете бачити на скріншоті, статті передує короткий зміст, за яким слідує горизонтальна лінія, що відокремлює резюме від самої статті.
«Короткий зміст» Smashing відокремлено від повної статті горизонтальною лінією
Але роздільник чисто декоративний, тому Леоні не змогла сказати, де закінчується резюме та починається стаття. Вона запропонувала виправити це: ми обернули короткий зміст елемент section:
У більшості програм читання з екрану елемент
не оголошується, якщо він не має доступного імені. У разі текст мітки aria. Тепер її програма читання з екрану оголосила «Область короткого змісту», а потім «Кінець області короткого змісту». Ця проста розмітка також дозволяє користувачеві програми читання з екрана перестрибувати через короткий зміст, якщо цього хоче.
Ми могли б використовувати простий div, але тоді, як пише Марко Зіа: «Як правило, якщо ви позначаєте щось за допомогою aria-label або aria-labelledby, переконайтеся, що він має відповідний віджет або орієнтир».
Тому замість того, щоб використовувати , ми вибрали section, так як він має вбудовану роль області, і застосовується закон Брюсу про ARIA™: вбудоване завжди перевершує додане.
Висновок
Сподіваюся, ви засвоїли таке:
Не використовуйте скрізь h1. Зробіть основний заголовок вашої сторінки h1, а потім використовуйте h2, h3, h4 і т.д. у належній ієрархії, не пропускаючи рівнів.
section може використовуватися з міткою aria, щоб повідомити користувача програми читання з екрана, де починається і закінчується певна частина статті. В іншому випадку забудьте про це або використовуйте інший елемент, наприклад, або .
main, header, footer та nav дуже корисні для користувачів екранних дикторів, та повністю прозорі для тих, хто не використовує допоміжні технології. Тож використовуйте їх.
article не тільки для записів у блозі – він для будь-якої окремої речі. Це також допомагає WatchOS правильно відображати ваш контент.
Автор: Bruce Lawson
Редакція: Команда webformyself.