). Каждый тэг {section} должен иметь пару {/section} . Обязательными параметрами являются name и loop . Имя цикла {section} может быть любым, состоящим из букв, цифр и знаков подчеркивания. Циклы {section} могут быть вложенными и имена вложенных {section} должны быть уникакльными между собой. Переменная loop (обычно - массив значений) определяет количество итераций цикла. При печати переменных внутри секции, имя секции должно быть указано рядом с именем переменной внутри квадратных скобок . {sectionelse} выполняется в том случае, если параметр loop не содержит значений.

Имя атрибута	Тип	Обязателен	По умолчанию	Описание
name	string	Да	n/a	Название секции
loop	mixed	Да	n/a	Значение, определяющее количество итераций цикла.
start	integer	Нет	0	Индекс позиции, с которой будет начинаться цикл. Если значение отрицательное, то начальная позиция вычисляется от конца массива. Например, если в переменной цикла 7 элементов и значение атрибута start равно -2, то начальный индекс будет 5. Неверные значения (значения, вне массива) автоматически обрезаются до ближайшего верного значения.
step	integer	Нет	1	Значение шага, которое используется для прохода по массиву. Например, step=2 указывает обход массива по элементам 0,2,4... Если шаг отрицателен, то обход массива будет производится в обратном направлении.
max	integer	Нет	1	Максимальное количество итераций цикла.
show	boolean	Нет	true	Указывает, показывать или нет эту секцию

Note

Начиная с версии Smarty 1.5.0, синтаксис переменных свойств сессий был изменен с {%sectionname.varname%} на {$smarty.section.sectionname.varname}. Старый синтаксис всё ещё поддерживается, но вы увидите лишь примеры нового синтаксиса.

index используется для отображения текущего индекса массива, начиная с нуля (или с атрибута start, если он был указан) и увеличиваясь на единицу (или на значение атрибута step, если он был указан).

Техническое Замечание

Если атрибуты step и start не указаны, то index аналогичен атрибуту секции iteration, кроме того, что начинается с 0, а не с 1.

iteration используется для отображения текущего номера итерации цикла.

Note

Это значение не зависит от свойств start, step и max, в отличие от свойства index . Кроме того, итерации начинаются с единицы, а не с нуля, как индексы. rownum - это синоним к свойству iteration, они работают одинаково.

Example 7.38. свойство {section} iteration

assign("custid",$id); ?> {section name=cu loop=$custid start=5 step=2} iteration={$smarty.section.cu.iteration} index={$smarty.section.cu.index} id={$custid}
{/section}

Результат выполнения данного примера:

Iteration=1 index=5 id=3005
iteration=2 index=7 id=3007
iteration=3 index=9 id=3009
iteration=4 index=11 id=3011
iteration=5 index=13 id=3013
iteration=6 index=15 id=3015

Этот пример использует свойство iteration для вывода заголовка таблицы через каждые пять строчек (использует {if} с оператором mod - остаток от деления).

{section name=co loop=$contacts} {if $smarty.section.co.iteration % 5 == 1} {/if} {/section}

	Name>	Home	Cell	Email
view	{$contacts.name}	{$contacts.home}	{$contacts.cell}	{$contacts.email}

Шаблоны в битриксе можно разделить на несколько типов:

• Шаблоны обычных и комплексных компонентов 2.0
• Шаблоны сайта
• Шаблоны прочих сущностей (почтовых отправлений, выпусков рассылок, веб-форм, генераторов экспортов и еще много чего)

В шаблонах компонентов есть даже возможность использовать шаблонизаторы. В принципе можно подключить любой шаблонизатор, но из коробки никаких вспомогательных инструментов нет. Если кому надо, есть у меня пара ссылок на расширения для twig и blade , которые работают и вполне себе используются на продакшене. Но и тут битриксоиды извратились. Шаблонизатор можно использовать только с компонентами. Подключить шаблонизатор к рендереру шаблона сайта, или других сущностей не получится, т.к. нет там никакого рендерера.

В шаблонах компонентов раздражает еще момент с их размещением. Компонент подключается с помощью нехитрой контструкции
$APPLICATION->IncludeComponent("bitrix:catalog.section", "template_name", );
В качестве второго параметра идет название шаблона компонента. Так вот в зависимости от различных условий, местоположение этого шаблона может быть в самых неожиданных местах:

• bitrix/components/bitrix/catalog.section/templates/template_name
• local/components/bitrix/catalog.section/templates/template_name
• bitrix/templates/.default/components/bitrix/catalog.section/template_name
• bitrix/templates/site_template/components/bitrix/catalog.section/template_name
• local/templates/.default/components/bitrix/catalog.section/template_name
• local/templates/site_template/components/bitrix/catalog.section/template_name
• bitrix/components/bitrix/catalog/templates/.default/bitrix/catalog.section/template_name
• local/templates/site_template/components/bitrix/catalog/.default/bitrix/catalog.section/template_name

И это еще я не все варианты перечислил…

Шаблон сайта можно рассматривать как набор файлов: header.php, footer.php (да, у сайта обязательно они должны быть), description.php (системное описание шаблона сайта), template_styles.css (стили шаблона сайта), директорию с шаблонами компонентов и еще группка менее значимых файликов. И все. И никак на это не повлиять, ничего с этим не сделать. Невозможно подцепить шаблонизатор.

Про другие шаблоны и говорить нечего. Они либо просто хранятся в БД в виде верстки со включением в нее каких-то «переменных» данных, либо это тупой php файл, который делает всю работу, от выборки параметров из БД до вывода информации. Для примера, можно посмотреть на генератор YML файла для маркета. Нет никакого смысла выкладывать его сюда, просто потому, что он достаточно большой, около 2к строк. Кому нужно, тот нагуглит, лежит он в /bitrix/modules/catalog/load/yandex_run.php

Файловая природа

Как стало ясно выше, в битриксе с архитектурой все не очень хорошо. Но есть у битрикса и еще один важный аспект архитектуры.
Битрикс - это на половину файловая CMS. Очень многие вещи управляются с помощью каких-то файлов:

• Нужна страница - создай файл
• Нужен набор страниц - создай файл и подключи там компонент, работающий с инфоблоками
• Нужно задать title для страницы - отредактируй файл
• Нужно задать title для всех страниц раздела - создай специальный файл.section.php в корне этого раздела
• Нужно отредактировать права - редактируй файл.access.php
• Настройки до инициализации системы - в файле dbconn.php, .settings.php и.settings_extra.php
• result_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

И таких специальных файликов по битриксу разбросано огромное множество. С одной стороны, это дает определенную гибкость при работе с системой. С другой - это может превратиться в муку как для разработчика, так и для менеджера сайта. Файлы страниц иногда превращаются в кашу из php кода, верстки, и подключаемых компонентов. В результате визуальный редактор может некорректно распарсить этот файл, и при редактировании он запросто может экранировать php теги в некоторых местах, что приведет к неработоспособности страницы. Вы скажете - не надо писать php код в таких файлах? Да, я знаю. Но битрикс очень часто и безальтернативно заставляет так поступить.
Да и в голове нужно держать постоянно информацию о том, что это за файлы такие, и какие данные они могут содержать. В разных файлах должны содержаться разные данные с разной структурой, и нужно ее помнить для каждого варианта. В документации искать это каждый раз - тяжелый труд.

В дополнение к вышесказанному

Можно бесконечно жаловаться на то, как все плохо устроено в битриксе. На мой взгляд, все эти жалобы можно охарактеризовать одним словосочетанием - «как-то не до конца». И действительно, если вдруг битриксоиды анонсируют какую-то фишку, то они ее релизят как-то не полностью, не доделывают, не доводят до ума. Примеров - масса:

• внедрили ORM - не доделали, пользоваться в полной мере нельзя
• сделали автозагрузчик, он работает только в модулях, и не по стандартам
• дали возможность подключить шаблонизатор, но использовать его можно не везде, и не полностью
• и т.д. и т.п.

В двух словах попробую охарактеризовать остальные проблемы, с которым приходится сталкиваться ежедневно.

Админка

Если кто-то работал с админкой, создавал свои страницы в административной части так, как это предлагает делать битрикс, тот меня поймет. Это просто ад. Для тех, кто не в курсе - битрикс предлагает для каждой страницы использовать файл с лапшой. Например, страница детального просмотра заказа в админке в исполнении разработчиков битрикса занимает over 4к строк. У меня IDE начинает подтормаживать при просмотре содержимого этого файла. Там тебе и php, и js, и html. Хорошо хоть, от SQL избавились, хотя я уверен, что на других административных страницах он есть.
И что мешало сделать работу административных страниц с помощью тех же компонентов - не понятно. Кастомизировать большинство административных страниц просто нет никакой возможности. В случае с компонентами это можно было бы сделать в два счета.
К слову, добрые люди сделали модуль , который поможет вам в построении административных страниц

js-фреймворк

В битриксе есть js составляющая, которая выполняет роль некоего клиентского фреймворка. Никто из разработчиков не любит его по нескольким причинам:

• он почти не документирован
• он монструозен
• он во многом дублирует привычный многим jquery

Битрикс очень часто использует его в своих компонентах, тем самым вызывая еще больше гнева разработчиков. Ядро этой библиотеки в минифицированном виде составляет 85кб, что очень не мало. Избежать его подключения не получится, если вы хотите использовать все возможности битрикса (композит, asset-management).

Дух копипасты

В последнее время все меньше, но все равно довольно часто, битрикс заставляет что-то копипастить. Хочешь модифицировать работу компонента - скопипасти. Хочешь создать свой шаблон выгрузки - скопипасти системный и допили. Хочешь сделать почти такой же шаблон, который у тебя есть - скопипасти и немного измени его. И об этом даже рассказывают на курсах для начинающих разработчиков. Слов нет.

Asset-management и CDN

Очень «мне нравится» в битриксе способ управления ресурсами. В принципе, можно зарегистрировать набор определенных «библиотек». Каждая библиотека - это набор css/js файлов, который может зависеть от каких-то других библиотек. Если подключить какую-то библиотеку на страницу, то перед ее подключением будут разрешены все зависимости и все зависимые библиотеки будут вставлены на страницу. Все вроде бы хорошо, только каждый ресурс будет вставлен в виде отдельного файла в тег script или link. И благодаря этому существуют сайты, у которых подключено по 30-50 скриптов и столько же файлов стилей.
Говно-вопрос, сказали в битриксе, и сделали волшебную галочку, которая объединяет все эти файлы в один. И появились сайты, где вместо 50 скриптов стало 2, каждый по 300-500кб. Какое-то время назад это объединение работало с ошибками и объединяло одни и те же ресурсы по нескольку раз, но сейчас вроде бы исправили.
И тут битриксоиды выкрутились - прикрутили возможность выгрузить все ресурсы на CDN сервер. Который вечно отваливается…
Потом появился Google Pagespeed Insights, который рекомендовал опустить все ресурсы в нижнюю часть страницы. И в битриксе опять сделали волшебную галочку, которая тупо опускает все ресурсы в body, если они не помечены специальным атрибутом.
А еще они вместе с коробкой распространяют минифицированные версии своих скриптов, которые подключаются при использовании еще одной волшебной галочки в админке.
В общем, никаких вам scss, никаких TypeScript. Хотите грамотно управлять ресурсами - не используйте встроенную систему битрикса, юзайте webpack, который можно спокойно с битриксом подружить.

Многосайтовость / многоязычность

Это, наверно, самая страшная головная боль разработчика, которая продолжается с момента зарождения продукта. Нельзя просто так взять, и создать многоязычный сайт. А если вам нужен многоязычный каталог с разными ценами и валютами - то это превращается в муку, за которую нужно еще и выложить кругленькую сумму (на покупку доп.лицензии для очередной языковой версии сайта придется раскошелиться).
Если вы создаете многоязычный и многовалютный сайт, то будьте готовы к тому, что битрикс будет очень агрессивно сопротивляться этому. Настройки многосайтовости децентрализованы по всей админке. Каждая сущность в админке имеет свою зависимость от языковой версии сайта. Какие-то сущности могут вообще не поддерживать зависимости от сайта/языка, а какие-то имеют только однозначную привязку к языку, так что придется эту сущность продублировать и потом поддерживать.
В базовом варианте, чтобы заставить инфоблок работать в нескольких языках, вам придется создать дубль этого инфоблока. Но на практике никто этого не делает, и пытается придумать свои способы хранения одной сущности централизованно, разнося ее языкозависимые атрибуты по другим хранилищам.
Нельзя задать дефолтный язык при локализации. Если у вас есть языковая переменная, описывающая какую-то фразу на русском, и этой языковой переменной нет в английском исполнении, то на английском сайте будет показана пустая строка, и никак на это нельзя повлиять (во-многих случаях можно было бы оставить русскую фразу, чтобы не было пустот).

Механизм управления правами

Очень замудрили с этой подсистемой. Часто бывает сложно разобраться, почему ты выдал права на просмотр какой-то сущности, а пользователь не может ими воспользоваться. Например, чтобы дать право на редактирование инфоблока, нужно дать доступ к директории /bitrix/admin, выдать права для конкретного инфоблока и выдать права в главном модуле. Чересчур много операций нужно сделать, чтобы выдать права для одной сущности. А если прав не хватает, то без ковыряния в исходниках никак не получится понять - почему.

Конфигурирование

В битриксе нет централизованного хаба, который бы позволил управлять настройками системы. Настройки опять таки децентрализованы по всей системе. Опции есть в настройках модуля, в настройках компонентов, в COption (будучи не вынесенными в админку). В админке опции одного модуля могут быть разнесены по 3-4м разным страницам, которые находятся в совершенно разных местах. urlrewrite можно править через админку! Теперь еще и.settings и.settings_extra. Иногда совершенно не ясно, какие из них более приоритетны, очень часто не хватает пояснений для опций, непонятны взаимосвязи. Нет никакого нативного способа расшаривать конфигурацию между разработчиками.
Настройки бывают очень нелогичными. Иногда доходит до абсурда… посмотрите компонент бигдаты - разве его сможет настроить неподготовленный человек?

Интеграция с 1С

Это тот пункт в списке фич битрикса, на который клюет достаточно большое количество заказчиков. Битрикс обещает в 2 клика настроить двустороннюю интеграцию сайта с 1С, которая будет мгновенно доставлять контент и документы от одной системы к другой.
Да, оно действительно так и есть, но с несколькими оговорками.
Во-первых, чтобы сделать интеграцию «из коробки» без дополнительных усилий, нужно сделать все именно так, как написано в документации битрикса - построить каталог на сайте по тем правилам, которые предлагает битрикс и построить каталог в 1С, которые требует битрикс. В идеале - создать вообще все с нуля, и тогда может быть, у вас все заработает из коробки.
Во-вторых, Битрикс дружит не со всеми конфигурациями 1С из коробки. Стоит предварительно ознакомиться
В-третьих, идеального мира не бывает. Обычно у заказчика, который хочет сайт, уже есть розничный бизнес, а значит уже есть 1С, которая является огромной мусоркой. И эту мусорку приходится прокидывать на сайт. А чтобы на сайте не получилось такой же мусорки, требуется значительно доработать механизм обмена.
Очень часто требования заказчика сильно расходятся с тем видением продукта, которое сформировано у команды Битрикса, и тогда доработка механизма обмена может быть достаточно дорогой, по трудоемкости сопоставимой с разработкой уникального модуля обмена под конкретный случай.
Поэтому не нужно пытать иллюзий по поводу того, что вам удастся легко интегрировать сайт с 1С. Это все происки маркетологов.

Доработка обмена с 1С - это тоже отдельная тема. За организацию обмена каталогом отвечает класс \CIBlockCMLImport.- 5.7к строк. Один из главных методов, который чаще всего требует расширения - \CIBlockCMLImport::ImportElement, содержит больше 1к строк. Достаточно раз унаследоваться, пару раз обновить продукт на протяжении длительного времени, и можно получить неработающий обмен с 1С. Поэтому часто разработчики не лезут в этот класс и пытаются как-то влезть в процесс импорта с помощью обработчиков событий. Работать с обработчиками событий в битриксе, особенно в модуле инфоблоков - тоже не очень приятное занятие, хотя бы из-за того, что однотипные события устроены не однородно, а некоторых событий просто не хватает.
В общем с этим дела обстоят также печально, как и ранее.

Несогласованность

Мне порой кажется, что разработчики разных модулей не особенно то общаются между собой. Изучая исходники ядра натыкаешься на очень разнородные решения, которые можно было бы выполнить на одном движке, но они реализованы почему-то по разному.
Для примера можно взять свойства элементов инфоблоков и UserFields. И та и другая сущность по факту является дополнительным полем для другой сущности. Она имеет тип, имеет значение и описание. Значение хранится в отдельной(ых) таблице(ах) БД, имеют примерно схожий интерфейс доступа к данным. Так почему бы не сделать для них одинаковый интерфейс?
Вот в конце марта обновился модуль sale до последней версии, и там тоже обещали произвольные свойства для заказов. Неужели там теперь новый, третий интерфейс для работы со расширенными свойствами сущности?

Битрикс24

Это вообще отдельная тема для разговора. На почве этой системы часто возникает путаница. Есть 2 варианта исполнения Б24 - SaaS и Standlone. Есть маркетплейс для Б24, но в нем содержатся приложения только для SaaS версии! Если у вас коробочная версия, купленная за 200 кусков, вы не сможете поставить такое популярнейшие приложения, как конструктор документов , да и вообще вы не сможете на свой Битрикс24 поставить ни одно приложение из маркетплейса для Битрикс24. Вот такой парадокс.
Вместо этого в вашем Битрикс24 будет доступен маркетплейс от обычной версии. Там решений гораздо больше, но они сконцентрированы в основном вокруг Управления Сайтом, а не Б24.

Битрикс24, как мне сказали в отделе технической поддержки, это целостная система. Если вы вмешиваетесь в работу стандартных компонентов системы, то будьте готовы, что эта функциональность сломается при последующих обновлениях. Битрикс не будет рассчитывать на то, что вы дорабатываете компоненты портала, и это несмотря на то, что они официально отправляют своих клиентов к партнерам

К слову, дорабатывать компоненты в коробочной версии Б24 - та еще задачка. Компоненты, которые генерируют js код, который с помощью ajax обращается к php коду, который в ответ генерирует html+js. Это адовая смесь, в которую очень не хочется погружаться.

Документация

Документация по битриксу отстает от развития продукта на 1-1.5 года. Код очень слабо покрыт phpDoc"ами, и часто комментарий перед классом стоит исключительно «для галочки», будучи автоматически сгенерированным в IDE.
Сам стиль изложения документации в официальных источниках часто бывает слишком «вольным», а содержимое некоторых статей в документации может не иметь никакого отношения к самому битриксу.
Курс разработчика имеет очень много информации, однако формат, в котором разработчика знакомят с возможностями системы, не дает того уровня восприятия, который требуется. Если вы зайдете в Cookbook Symfony, то там все разложено по полочкам, расписаны все необходимые аспекты в зависимости от версии. Тогда как в битриксе курс обучения разработчика содержит непонятно по какому принципу структурированную информацию по старому и новому ядру, которая подается сначала отдельно, а потом вперемешку, от чего у начинающих возникает головная боль.

Организация процесса разработки

Из-за специфичности системы не так уж просто организовать удобный процесс разработки. Не самая свежая версия редакции Бизнес (что была под рукой) после установки занимает, вдумайтесь, почти 530 мегабайт
$ du -s *|sort -nr|cut -f 2-|while read a;do du -hs $a;done 523M bitrix 204K upload 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K license.html 4,0K web.config 4,0K urlrewrite.php 4,0K readme.php 4,0K license.php 4,0K install.config 4,0K index.php
Из этого объема добрая половина - это бинарники и установочники, которые в общем-то не нужны для версионного контроля. Вообще говоря, принято не версионировать битриксовое ядро. Разработчики Битрикса как бы сами гарантируют целостность ядра, управляют сами зависимостями версий разных модулей при обновлениях. Но это несет в себе сразу, как минимум, один большой минус - невозможно одной командой из версионного контроля развернуть полностью работающий проект, приходится собирать его по частям: исходники ядра доставать из битриксового бекапа, а исходники разработчиков - из git.
С базой тоже все не ладно. Если сами вы можете использовать миграции при разработке, то битрикс накатывает обновления в базу с помощью обычных скриптов, которые вы не можете контролировать. Поэтому при обновлениях все равно придется перекидывать бекапы баз от центрального хоста разработки к другим разработчикам.
Добрые люди, опять же, пилят инструменты , которые помогают это все организовать, но заставить битрикс следовать этим правилам к сожалению до сих пор не удается.
Официально битрикс разрешает иметь 2 копии одного дистрибутива. Один - для продакшена, второй для разработки. Если у вас несколько разработчиков на одном проекте - то вы, как бы, вне закона) На самом деле, достаточно отрубить машине с битриксом входящие и исходящие подключения с/на www.bitrixsoft.com , и тогда можно наклепать сколь угодно много копий разработки, просто они не смогут самостоятельно обновляться.

Коллеги

И последний вопрос, которого хотелось бы коснуться.
В связи с тем, что битрикс имеет низкий порог вхождения, среди компаний, которые предоставляют услуги на этом рынке очень много неквалифицированных кадров. Мне довелось повидать множество различных проектов за свою карьеру (суммарно более сотни), выполненных на 1С-Битрикс. Могу с уверенностью сказать, что 95% из них были выполнены «тяп-ляп». Очень редко попадались проекты, к разработке которых чувствовался подход, однако это были единицы. Это все очень печально.

Выводы

Конечно же, всех минусов в рамках одной статьи не рассмотреть. Каждый день натыкаешься на какие-то мелочи, которые ежедневно мешают работать. Но рассмотреть все такие мелочи просто невозможно, да и наверно ни к чему.

Какие тут можно сделать выводы. Битрикс - крайне сложная система в связи с тем, что имеет непродуманную архитектуру, множество изъянов, которые так и продолжают жить в продукте на протяжении длительного времени. С другой стороны Битрикс - это достаточно простая система, которая для старта требует гораздо меньший уровень квалификации, в отличие от фреймворков.
Поддержка этого продукта - весьма неблагодарное занятие, по сравнению с такими продуктами, как Symfony, Laravel, Yii. Продукт очень любит вставлять палки в колеса как неопытным, так и опытным разработчикам, что, в свою очередь, может отражаться и на стоимости услуг опытных разработчиков под Битрикс.

Жалею ли я о том, что так много времени потратил на работу с этой системой? Скорее да, чем нет. Разумнее было бы потратить это время на изучение чего-то более правильного и более логичного (чем я стараюсь активно заниматься сейчас). Но так уж получилось, что некому было меня направить в правильное русло в начале моего пути.

Если вы - начинающий php разработчик, то предпочтите Битриксу изучение фреймворков, таких как Symfony, Laravel, Yii, ZendFramework. Поверьте, в будущем это с лихвой окупится. Освоив любой из этих фреймворков вам не составит труда в будущем разрабатывать что-то под Битрикс. Если у вас нет выбора, то изучайте Битрикс, но в свободное время лучше все-таки пытаться погрузиться в мир фреймворков, чтобы поставить мозги на место.

Если вы - разработчик со стажем в Битрикс, но без опыта в других фреймворках, то обязательно окунитесь в другой мир, вам откроется очень много новых и полезных знаний, которые помогут вам в написании гораздо более качественных решений под 1С-Битрикс. Старайтесь использовать решения из других фреймворков в своих проектах, благо сделать это совсем несложно благодаря компонентному подходу последних и composer.

Если вы - заказчик, то не верьте маркетологам Битрикса. Ничего не будет так легко, как рассказывают в презенташках битрикса. И не вините в этом своих разработчиков, они тут не причем. Если вы хотите создать большой и сложный интернет-магазинище уровня эльдорадо/мвидео/спортмастер, то, возможно, Битрикс будет не самым лучшим выбором.

UPD. Видно, что статью прочитали сотрудники битрикса. В разделе про Маркетинг я писал, что в разделе Архитектура в курсе разработчика Битрикс написаны маркетинговые призывы. Теперь их там нет. Даже опечатались, видимо, торопились очень.

Спасибо за наблюдательность и зоркий глаз:)

Теги:

• 1с-битрикс
• cms
• web-разработка
• чулан
• hatebitrix
• нытики на хабре
• возьми себя в руки

Добавить метки

Статья, в которой рассматривается HTML-элемент section из категории sectioning.

Назначение элемента section

Элемент section используется для создания секции в документе, которая группирует некоторый тематический контент вместе. Для каждой секции в документе следует указывать её название (тему). Это, как правило, осуществляется с помощью заголовков (элементов h1 - h6).

Заголовок секции

Содержимое секции…

Элементы section , обычно применяются в следующих случаях:

• для разметки разделов внутри секции. Например, для разметки глав в статье, вкладок в диалоговом окне, разделов в диссертации и т.п.
• для группировки нескольких секций в одну тематическую группу. Например, для группировки последних новостей на сайте, комментариев к статье и т.п.

Таким образом, элемент section стоит применять для некоторого контента только в том случае, если он имеет заголовок и является частью чего-то другого.

Применение элемента section

Например, рассмотрим фрагмент кода страницы, содержащий статью с комментариями. Каждый из комментариев, оставленных пользователем на странице, содержит некоторый завершенный контент и, следовательно, может рассматриваться как элемент article . Но, в тоже время все комментарии представляют некоторую тематическую группу, и следовательно их можно поместить в элемент section , т.е. данный элемент сгруппирует все эти комментарии на странице вместе.

Название статьи

Комментарии

Заголовок комментария

Текст комментария...

Заголовок комментария

Текст комментария...

Название статьи Комментарии Заголовок комментария Заголовок комментария

Например, рассмотрим применение элементов section для создания разделов внутри элемента article:

Название книги

Первая глава

Вторая глава

Третья глава

Приложение A

Приложение B

Вышеприведенный пример будет иметь следующую структуру (outline):

Название книги Первая глава Вторая глава Третья глава Приложение A Приложение B

Ограничения при использовании элемента section

Элемент section в HTML 5 не является универсальным элементом для группировки содержимого, т.е. его не следует использовать для оборачивания любого понравившегося контента. Его основное назначение это добавление семантики в документ и создание его структуры (outline).

Когда автору необходимо сгруппировать контент, только для того, чтобы применить к нему стили или поработать с ним в сценарии JavaScript, ему в этом случае лучше всего будет воспользоваться элементом div . Элемент div в отличие от элемента section , не добавляет семантики в документ и не участвует в создании его структуры (outline).

Отличие между элементами section и article

Элементы section и article хоть и кажутся на первый взгляд очень похожими, но имеют различное семантическое значение. Элемент article предназначен для группирования контента, который представляет собой нечто завершённое, самостоятельное и которое может рассматриваться отдельно от остального содержимого страницы. А элемент section несёт в себе другой семантический смысл, он предназначен для группировки контента, который является составной частью чего-то другого.

Но как автору узнать, что собой представляет некоторый контент на странице? Давайте рассмотрим это на примере фрагмента статьи. Фрагмент - это часть статьи и, следовательно, для группировки его контента необходимо применять элемент section . Но этот же фрагмент, уже оставленный в качестве комментария, будет представлять собой нечто целое, завершенное. Следовательно, в этом контексте для его группировки можно использовать элемент article . Но рассуждать, конечно, можно и наоборот. Поэтому, какой элемент использовать для группировки контента, в большинстве случаев зависит от вашего субъективного мнения как автора. Но самое главное в этом подходе поддерживаться выбранной позиции. Поэтому чем автор будет более последовательным в создании структуры, тем он сможет больше смысла в неё вложить.