Что из этого список, а что нет.

[Zverushka]

Меню - список?

Слайдер из картинок - список?

Список новостей - это список?

Список отзывов клиентов на лендинге - список?

[npofopr]

Дак. Как вы захотите, так и будет.

У меню нынче свой тег есть, но да, чаще всего список.

Слайдер, от реализации зависит, чаще список.

Список новостей... ну смотря какой.

Список отзывов, это почти тоже самое что и список новостей (название, дата, анонс)

или вы не про ul?)

Edited October 28, 2013 by npofopr

[Zverushka]

Я про ul) Просто в соседней теме Алекс сказал, что из этого почти все не списки) Что и почему он уточнит завтра).

[lexxcode]

Меню это не список. Если это являет собой навигацию по сайту, то это тег nav и внутри него могут быть ссылки

<nav>
    <a href="#">Главная</a>
    <a href="#">О компании</a>
    <a href="#">Новости</a>
    <a href="#">Каталог</a>
</nav>

Само собой ссылки можно обвернуть в div, например, который не имеет никакого семантического веса, если без этого невозможно реализовать какие-то дизайнерские выверты.

Да, раньше это делалось списками. Но только потому, что более подходящей альтернативы не было. Но это, на самом деле, не список, совсем. Ссылки списком могут быть, в тексте, к примеру, перечисления использованных источников. Но в то же время это уже и не навигация по сайту, да и вообще не навигация как таковая. По этому в такой ситуации это будет списком.

Слайдер это не список. Вообще это какое-то за уши притянутое понятие "список слайдов" или "перечисление слайдов".

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

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

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

"Список новостей" (я так понял имеется ввиду лента новостей) -- ну снова таки, каждый новостной пост, самодостаточен. Проблема открыта, описана, закрыта. Все. Да бывает когда одна новость ссылается на другую, но это, так скажем, символическая ссылка. Абсолютно не имеет значение где находится одна новость относительно другой в выдаче. Вот меня заинтересовала новость о миграции тушканчиков, я ее беру и читаю. При этом мне не важно, что в Мексике ураган, а на Киев упал метеорит. Меня интересует насколько успешно мигрировали тушканчики. Так, что это ни разу не список. Каждый новостной пост можно оформить в тег article.

"Список отзывов клиентов на лендинге" -- отзывы принципиально то же самое, что и комментарии. Что такое комментарий? Это, как правило, четко сформулированная (ну да да не всегда люди четко формулируют свои мысли) мысль либо вопрос, относительно поста/товара/новости etc. С одной стороны комментарий представляет самодостаточную сущность, но не совсем. Комментарий довольно жестко привязан к посту. По этому сам пост оформляем в тег section, а внутри после содержимого поста создаем блок комментариев, в котором каждый комментарий оформляется тегом article. И все. Тем самым формально мы связываем пост и комментарии. Но при этом я могу удалить комментарий и ничего от этого по смыслу не изменится. Я могу с тем же успехом менять их порядок. Могут быть комментарии к комментариям, по такому же принципу вкладываем комментарии. Так мы получаем структурированное дерево комментариев. С четкими связями там где это нужно. Так, что применение article - да, организация узлов и дочерних им потоков комментариев - да. Списки - нет, не клеится оно тут. Потому что это не перечисление.

Что может быть списком, к примеру, я хочу собрать компьютер с нуля. Для этого мне нужны такие комплектующие:

• Материнская плата
  
• Процессор
  
• ОЗУ
  
• HDD
  
• Блок питания
  
• Видеокарта
  
• Кейс
  

Это список необходимых, либо уже выбранных, товаров. Я могу менять их порядок (поэтому ненумерованный список), но я не могу ничего из этого убрать (грубо говоря). Иначе у меня не получится собрать компьютер.

А вот когда ищу в магазине материнскую плату, то результат поиска уже не будет списком. Ибо там можно и убрать что-то и добавить, и посмотреть на конкретный товар, при этом мы ничего не заденем.

P.S. Все выше сказанное является моим пониманием всего этого добра и трактовкой описаний некоторых элементов HTML5. Со мной можно соглашаться, можно не соглашаться. Это ваше право, я ничего не навязываю, никому. По скольку вся эта тема весьма мутная, на самом деле. Новые элементы html имеют достаточно расплывчатое описание. А те же списки, так уж исторически сложилось, долгое время приходилось применять там где это совсем не нужно, но другого выхода не было. Так, что как-то вот так

[mrnobody]

Потихоньку начинаю понимать ). alexriz спасибо за объяснение.

Edited November 1, 2013 by mrnobody

[Zverushka]

А где-нибудь есть официальные рекоммендации как применять списки?

Я так поняла идея Алекса в том, что список по сути в первую очередь односложный текстовый элемент (ну на крайний случай картинка).

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

[Mister-N]

alexriz, а разве к примеру:

<ul>
<li><a href="#">Главная</a></li>
<li><a href="#">Новости</a></li>
<li><a href="#">Контакты</a></li>
</ul>

чисто сематически не список?

Edited November 1, 2013 by Mister-N

[SelenIT]

В спеке есть такое

Примечание. Хотя вкладывать заголовки (напр. h1) внутрь элементов li является допустимым, с большой вероятностью это не передает ту семантику, которую имел в виду автор. Заголовок начинает новую секцию, поэтому заголовок в списке неявно разделяет его между несколькими секциями.

Отсюда лично я вывожу для себя правило, что если у последовательных сущностей есть заголовки, то они, скорее всего, не список. Обычные разделы документа (напр. главы в книге) мы же в список не заворачиваем — так и здесь.

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

Исключение, на мой взгляд — сущности, явно отсортированные по опред. параметру (напр. товары в каталоге, упорядоченные по цене или по рейтингу). Там уместен упорядоченный же список ol (и дефолтная нумерация беды не сделает).

[lexxcode]

alexriz, а разве к примеру:

<ul>
<li><a href="#">Главная</a></li>
<li><a href="#">Новости</a></li>
<li><a href="#">Контакты</a></li>
</ul>

чисто сематически не список?

Я не очень понял вопрос. Список это список, навигация это навигация. Не нужно их смешивать

[mrnobody]

SelenIT Вы говорите о сущностях. А что это такое, можно по подробнее? Я уже встречаю эти сущности на форуме не первый раз, но так и не могу их представить. Сущность это определенный блок, который состоит из нескольких элементов? Я правильно понимаю? Edited November 1, 2013 by mrnobody

[lexxcode]

SelenIT Вы говорите о сущностях. А что это такое, можно по подробнее? Я уже встречаю эти сущности на форуме не первый раз, но так и не могу их представить. Сущность это определенный блок, который состоит из нескольких элементов? Я правильно понимаю?

Это в первую очередь способ мышления. Думать тегами - плохо. Думать элементами (сущностями) - хорошо.

Вот взять муху. Это сущность которая наделена рядом свойств, может летать, кушать, размножаться. Но так же муха состоит из компонентов, можно разорвать ее на крылышки, лапки и туловище.

Так же и тут, вот есть пост в этой теме. Это сущность, у нее есть id, текст сообщения и еще вложенная сущность описывающая автора поста. Кнопка отправки сообщения тоже сущность, хоть и простая, не имеющая вложенных компонентов. Но так же имеет ряд свойств, может менять свой вид, содержит текст, может обрабатывать события, и так далее.

То есть понятие сущности позволяет абстрагироваться от реализации, я бы так сказал.

[Zverushka]

Почему слайдеры через ul идут. Очень много реализаций слайдеров, где вообще нельзя использовать div, а они заточены на ul и разметка должна быть ul, иначе он просто не будет работать. Собственно так и повелось у меня использовать для слайдеров. Другой момент. что мои слайдеры не набор картинок, а часто например, список выполенных работ в виде фотографий, что очень смахивает самое по себе на список UL.

И я не пойму про OL - упорядоченный список товаров. То есть семантически он, когда упорядоченный- то OL, а если не упорядоченный - то уже не список? Или упорядоченный он тоже не список, но используется список только ради удобной нумерации? (кстати нумерации наверное можно на любой элемент повесить в хтмл...)...

Edited November 1, 2013 by Zverushka

[lexxcode]

http://bxslider.com/ <--- глубоко индифферентно что ты в него вставишь

Ну хорошо это галерея твоих работ в виде слайдера. почему вдруг это список?

[Zverushka]

Это перечисление моих творений, выполненное в визуальной форме, связанное общим смыслом - это примеры моих готовых работ. Если бы можно было записать текстом - я бы записала - работа1, работа2, работа3. А так эту роль выполняют картинки.

И зачем автор бхСлайдера, как многие другие, делают это все через UL? Для чего? Они все не разбираются в html?

Edited November 1, 2013 by Zverushka

[lexxcode]

Слайдер может быть и списком, я об этом писал. Зависит, от того какой смысл в этом всем заложен. Что касается просто листалки картинок, то не список это нифига. С тем же успехом эти фотки можно было просто положить на странице все. По смыслу бы ничего не изменилось вообще.

А работы, ну хз. Если это просто показывает что ты когда либо делала, то я бы не делал это списком. А вот допустим если работы иллюстрируют некий прогресс твоих способностей как специалиста, то вероятнее список.

Если с новостями все довольно понятно, то со слайдерами тут могут быть массы смысловых вариантов, по этому может быть по разному. Я, в данном, случае не могу сказать, что слайдер однозначно не список или однозначно список. Это было бы не правильно.

[advokatua]

Это перечисление моих творений, выполненное в визуальной форме, связанное общим смыслом - это примеры моих готовых работ.

Дык, выше уже писалось, что это не повод для списка. Если удалить любую твою работу из этого "списка" никто даже и не заподозрит чего-то неладного. Это тот же "список"/лента новостей.

С меню все равно остаются непонятки. Если меню это не список, значит любой элемент может быть исключен из набора и остальные элементы не потеряют своего смыслового контекста, как тот пример про тушканчиков.

Ок. у нас онлайн шоп и имеем такое меню:

Домой / Каталог / Вопрос-ответы / Отзывы / Контактная информация

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

В то же время, меню сайта http://htmlbook.ru/ - Основное | HTML | CSS | Сайт, как таковой зависимости не имеет (по крайней мере на первый взгляд). Удаление любого пункта не повлечет за собой потерю или разрушение остальных функций сайта.

PS. По сути, выходит онанизм ради онанизма. Никому это не надо и никого это не в мире не спасает (на данный момент), но не думать об этом типа нельзя.

Edited November 1, 2013 by advokatua

[Zverushka]

А вот допустим если работы иллюстрируют некий прогресс твоих способностей как специалиста, то вероятнее список.

Так для этого и существуют 2 вида списков - упорядоченный и неупорядоченный. Если работы возрастают по прогрессу - это уже упорядоченный OL, а если просто набор и не важно в каком порядке - то UL. А ты получается считаетшь, что любой список должен быть в чем-то упорядочен.

А если посмотреть на все это с другой стороны - как отразится на пользователе и на поисковых системах, если я сделаю списком

- меню

- слайдер

- список новостей в aside (обзор)

- каталог товаров

- примеры кровельных работ (фотографии).

Как это повлияет?

Мне как разработчику удобнее в коде видеть ряд столбиков ul li, чем непонятные div - как-то сразу видно, что это набор однотипных значений, а с div надое еще думать, что это и разбираться.

[advokatua]

Прошуршал пачку сайтов:

Гугл - боковая менюшка списком

Яндех.com - верхние табы таблицей!

Яндекс.ру - дивами

Далее пролистал 7-8 сайтов у Лебедева. Часть на списках, часть на дивах и часть на обычных ссылках "а".

http://www.verona-mobili.ru/ тут вообще часть ссылок "а" в параграф "p" обернута.

Заодно жестяк нашел (или может я просто чего-то не знаю).

Кто догадается что здесь не так в корне, тому лайк

<a class="b-header__nav-item i-link" href="http://www.ma-ma.ru/about/">
    <span class="i-link__decoration">
        <div class="b-header__nav-link i-link">
            <span class="i-link__decoration">О клинике</span>
       </div>
    </span>
</a>

сайт http://www.ma-ma.ru/

Edited November 1, 2013 by advokatua

[lexxcode]

вообще мне больше даже понравилось объяснение SelenIT'а. Если нам приходится избавляться от внешнего вида списков, то скорее всего это действительно не список.

Вот если обращаться к спецификации по элементу nav

Там нет строгой регламентации, что нужно применять только список для ссылок. Но навигация по документу выполнена в виде списка вложенного в nav. при этом в первом примерчике ссылки на страницы новостей, блога и форума, вообще оформлены в параграфе и без списка, просто ссылки насыпом.

При этом списки ul и ol, явно применяются только лишь для каких-то текстовых данных. Но не для более сложных вещей.

В общем, я могу конечно и ошибаться в своих суждениях, я этого не отрицаю и вообще сразу об этом сказал.

Кто догадается что здесь не так в корне, тому лайк

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

Да и вообще, вся эта семантика-шмемантика Есть еще один момент в моем понимании, что не стоит слишком усложнять вещи. Ну то есть мы обозначили навигацию навигацией тегом nav, и все. Если эта навигация не предполагает выглядеть как список, то и не нужен там список, а если предполагает, как в примере на w3c, то пускай будет список. Что касается поисковиков, тут я не могу сказать что-то конкретное по этому поводу, но по идее для поисковика присутствие или отсутствие списка в навигации, особой роли не должно сыграть. Так же как для устройств предназначенных для людей с ограниченными возможностями. Если это обозначено как навигация значит оно будет каким-то образом для них доступно.

[advokatua]

Ну если тебя смущает блочный элемент внутри строчного, то в html 5 так можно

Именно.

HTML5, да, а как же

У чуваков сайты от миллиона рублей, а они такое творят. Видимо это какой-то совсем высший Дзен до которого мне пахать как папа Карло.

Там оказывается все вложенности в ссылках в инлайн переводятся, но ведь это все равно не повод.

a * {
display: inline;
margin: 0;
padding: 0;
}

Видимо что-то с дизайнерской стороны намудрили.

БЕМ тоже забавный. Вчера читал о нем весь день, смотрел всякие семинары, в частности от главного верстальщика Яндеха. По сути, на уровне студии и куче куч людей работающих над сайтом он должен круто помогать, но в коллективе из 3ех человек (диз-верстальшик-программер) это больше на жесть походит. Хотя, может это на первый взгляд так.

Edited November 1, 2013 by advokatua

[lexxcode]

HTML5, да, а как же

что не так, по твоему? сейчас это вполне себе разрешено. Строго говоря это даже в html4 проблем не вызывало, кроме ругани валидатора.

ааа блин, я картинку не связал с тем, что ты сказал ахах, ну да, вообще-то. Я что-то не обратил внимание. Просто когда открыл страницу, сразу клацнул на ссылке проинспектировать, оно в девтулзе перешло туда по коду, и доктайп остался за границей экрана, и я не посмотрел Ну да, тогда с точки зрения доктайпа бредок. Но с точки зрения браузера пофиг, в любом случае он парсит html по современному стандарту. На сколько я понял, вроде товарищ SelenIT кидал ссылку по этому поводу. Но я не знаю просто по какому запросу найти эту инфу.

У чуваков сайты от миллиона рублей, а они такое творят. Видимо это какой-то совсем высший Дзен до которого мне пахать как папа Карло.

Да нам этого не понять

БЕМ тоже забавный. Вчера читал о нем весь день, смотрел всякие семинары, в частности от главного верстальщика Яндеха. По сути, на уровне студии и куче куч людей работающих над сайтом он должен круто помогать, но в коллективе из 3ех человек (диз-верстальшик-программер) это больше на жесть походит. Хотя, может это на первый взгляд так.

Не, как подход, весьма хорош, тут бесспорно и да для малых команд все инструменты БЭМ будут слишком переизбыточны, хоть сам яндекс часто говорит обратное. Но вот с синтаксисом они наворотили конечно ппц. Идея идет от обычного АНБ подхода. Я в свое время пробовал БЭМ применять, но километровые классы меня огорчали как Винни-пуха длинные слова. Я для себя некоторые фишки почерпнул, конечно. Но использую свой подход к написанию классов.

[SelenIT]

И я не пойму про OL - упорядоченный список товаров. То есть семантически он, когда упорядоченный- то OL, а если не упорядоченный - то уже не список? Или упорядоченный он тоже не список, но используется список только ради удобной нумерации? (кстати нумерации наверное можно на любой элемент повесить в хтмл...)...

Я смотрю на то, что добавляет та или иная разметка. Упорядоченный список — единственный способ присвоить сущности порядковый номер на уровне самой разметки (не считая микроданных и прочих расширений), это бывает важно, особенно для постранично разбитых перечислений. Неупорядоченный список сам по себе своим элементам никакой машиночитаемой семантики не добавляет, и чем крупнее сущность, тем объединяющая роль списка менее очевидна. Для перечисления ингредиентов кулинарного рецепта, например, списочная природа очевидна (без списка это были бы просто непонятные обрывки слов), но уже для рекламного отрывка, в котором каждый абзац описывает одно преимущество чего-либо, разница между списком и просто последовательность абзацев начинает стремительно ускользать. Если же сущности являются самостоятельными секциями, список, имхо, становится избыточным, как для глав (разделов) в книге (наличие разделов уже подразумевает объединенность их в нечто более общее).

Честно говоря, я бы и для товаров от списка отказался, но меня Хикси уговорил

[Zverushka]

БЕМ тоже забавный. Вчера читал о нем весь день, смотрел всякие семинары, в частности от главного верстальщика Яндеха. По сути, на уровне студии и куче куч людей работающих над сайтом он должен круто помогать, но в коллективе из 3ех человек (диз-верстальшик-программер) это больше на жесть походит. Хотя, может это на первый взгляд так.

Тоже самое. Я раза 3-4 пыталась осмыслить БЭМ, смотрела семинары, читала, потом смотрела этот кодддд... так называемый. И понимала, что даже на стадии просмотра написанного кода классов, сталкиваюсь с чем-то мозгодробительным и схватывала скрежет мозгов, похожий на головную боль. Пока от проектов "сделать с БЭМ" шарахаюсь. Слав богу заказов и без этого хватает....

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

 

Упорядоченный список — единственный способ присвоить сущности порядковый номер на уровне самой разметки (не считая микроданных и прочих расширений), это бывает важно, особенно для постранично разбитых перечислений.

 

 

Почему же, можно любой элемент считать.

http://cssdesk.com/fRqP9

[cyklop77]

вставлю свои пять копеек

как уже говорили на этом форуме не раз, практического толку от семантики не много. а списки(по крайней мере сейчас и в ближайшие несколько лет) очень помогают экономить время так как большинство CMS по дефолту выдают различные меню, новости и т.п. именно списками. лезть в код и изменять вывод можно, но отнимает время(деньги)

Edited November 3, 2013 by cyklop77

[lexxcode]

Тоже самое. Я раза 3-4 пыталась осмыслить БЭМ, смотрела семинары, читала, потом смотрела этот кодддд... так называемый. И понимала, что даже на стадии просмотра написанного кода классов, сталкиваюсь с чем-то мозгодробительным и схватывала скрежет мозгов, похожий на головную боль.

 

Там просто, если использовать БЭМ в полной мере, многие вещи сильно автоматизированны. То есть разработчику не приходится писать эти несуразные классы самому. Это все компилируется на этапе сборки. А разработчик просто создает модули и структуру папок и файлов с не большими кусками кода.

Но по правде сказать, как по мне, все равно это мозгодробильня Но модульность, при разработке даже верстки, иногда может быть полезна, если не зацикливаться на это так сильно как это сделано в БЭМ. А то потом получаются, как выше пример был, элементарная менюшка, а там 100500 абсолютно не нужных элементов скомпоновано

[SelenIT]

можно любой элемент считать

 

Чисто визуально — да, можно. Но мы ведь, кажется, начинали спор про семантику

на уровне самой разметки?