Хлебные крошки

[s0rr0w]

Я просто не могу понять, ссылка с палкой разве не контент одного элемента?

Может и надумана, просто запутался

Разделитель не относится к контенту. Это визуальный элемент.

А что делать? Какова правильная замена этой поголовной ведомости на твой взгляд?

Создание тега <interactive> для меню, навигаций, тулбоксов и прочих элементов и создание

<tree>

<ti />

</tree>

Для многомерных и иерархичных интерактивных элементов.

А ведь, если присмотреться к крошкам как к структуре данных, они, по ходу дела, выходят не массивом вовсе, а именно что связным списком! И палка/стрелка — своего рода визуальное представление указателя на предыдущий (или следующий, смотря с какой стороны смотреть) элемент...

А если присмотреться к текстовой статье, то можно увидеть связанный массив абзацев. И тогда, следуя логике выше, статью нужно представлять как список, где в каждом LI должен быть свой P

[psywalker]

Создание тега <interactive> для меню, навигаций, тулбоксов и прочих элементов и создание

<tree>

<ti />

</tree>

Для многомерных и иерархичных интерактивных элементов.

Да, но ведь придумали <nav>, <menu> ?

Разделитель не относится к контенту. Это визуальный элемент.

Понял, спасибо.

[s0rr0w]

Да, но ведь придумали <nav>, <menu> ?

Я могу сказать только одно - идиоты.

[psywalker]

Я могу сказать только одно - идиоты.

[SelenIT]

psywalker,

где эта основная часть, что он имеют ввиду?

Четкого определения не нашел. Интутивно напрашиваются два варианта — либо весь body, либо контентная часть (без шапки, рекламы, украшательств и т.п.)...

пример, где правильно задействованы все эти свойства.

Сорри, но там же есть куча примеров — если "плюсики" в конце раскрыть...

Т.е. из этого описания смело можно делать вывод, что Хлебные крошки - это строка, и никак НЕ список?

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

s0rr0w

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

Я хотел сказать противоположное . HTML-ные списки — аналоги именно что массивов в программировании (OL — аналог индексного массива, DL — ассоциативного). Но крошки — всё-таки аналог не массива, а связного списка (не HTML-ного, а из программирования ), где элементы не просто лежат рядом, а конкретно указывают друг на друга. В HTML нет явной возможности это выразить (разве что честно воспроизвести глубину путем вложенности, как в двух последних примерах от Гугла), проще забить и положиться на естественный порядок. Как и с абзацами

[psywalker]

SelenIT

Спасибо за ответы.

пример, где правильно задействованы все эти свойства.

Сорри, но там же есть куча примеров — если "плюсики" в конце раскрыть...

А за это извиняюсь отдельно, не знал

А смотри кстати

<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
  <a href="http://www.example.com/dresses" itemprop="url">
    <span itemprop="title">Платья</span>
  </a> ›
</div>  
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
  <a href="http://www.example.com/dresses/real" itemprop="url">
    <span itemprop="title">Готовые платья</span>
  </a> ›
</div>  
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
  <a href="http://www.example.com/clothes/dresses/real/green" itemprop="url">
    <span itemprop="title">Готовые зеленые платья</span>
  </a>
</div>

Т.е. каждая ссылка помещена в див. А почему и разве это правильно?

И тогда сразу напрашивается вопрос: А почему тогда уж сразу НЕ список?

[rash]

Я могу сказать только одно - идиоты.

В целом с этим согласен, но хотелось бы еще чью-нибудь аргументацию услышать

Можно поподробнее, сравню аргументы со своими

Кстати, еще хотелось бы вернуться к «спискозадротству»: а чем это плохо, кроме избыточности? То есть понятно, что не стоит текст представлять списком абзацев, некоторые еще и лейаут на списках делать пытались, по крайней мере раньше, но чем это плохо, кроме избыточности? Может, какой-нибудь изощренный шаблонизатор позволяет проще всего генерировать списки (такого, разумеется, нет, я просто пытаюсь придумать причину, по которой может возникнуть такое желание), вот и размечают «как легче».

[SelenIT]

Т.е. каждая ссылка помещена в див. А почему и разве это правильно?

И тогда сразу напрашивается вопрос: А почему тогда уж сразу НЕ список?

Имхо, это, мягко говоря, не совсем правильно, и сделано чисто ради наглядности (чтобы показать, что <itemscope itemtype="http://data-vocabulary.org/Breadcrumb"> — это контейнер, контейнеры традиционно бывают блочными). Судя по тексту, это необязательно, можно и span юзать.

А не список — потому что парсеру Гугла это не нужно, ему хватает естественного порядка itemscope-ов в коде

Может, какой-нибудь изощренный шаблонизатор позволяет проще всего генерировать списки (такого, разумеется, нет, я просто пытаюсь придумать причину, по которой может возникнуть такое желание), вот и размечают «как легче».

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

Edited April 11, 2011 by SelenIT

[psywalker]

Имхо, это, мягко говоря, не совсем правильно, и сделано чисто ради наглядности (чтобы показать, что <itemscope itemtype="http://data-vocabulary.org/Breadcrumb"> — это контейнер, контейнеры традиционно бывают блочными). Судя по тексту, это необязательно, можно и span юзать.

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

[s0rr0w]

Я хотел сказать противоположное . HTML-ные списки — аналоги именно что массивов в программировании (OL — аналог индексного массива, DL — ассоциативного). Но крошки — всё-таки аналог не массива, а связного списка (не HTML-ного, а из программирования ), где элементы не просто лежат рядом, а конкретно указывают друг на друга. В HTML нет явной возможности это выразить (разве что честно воспроизвести глубину путем вложенности, как в двух последних примерах от Гугла), проще забить и положиться на естественный порядок. Как и с абзацами

Ааа, так это не "связанный список" а указатели! Да, верно.

Кстати, еще хотелось бы вернуться к «спискозадротству»: а чем это плохо, кроме избыточности? То есть понятно, что не стоит текст представлять списком абзацев, некоторые еще и лейаут на списках делать пытались, по крайней мере раньше, но чем это плохо, кроме избыточности? Может, какой-нибудь изощренный шаблонизатор позволяет проще всего генерировать списки (такого, разумеется, нет, я просто пытаюсь придумать причину, по которой может возникнуть такое желание), вот и размечают «как легче».

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

[rash]

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

То есть меню, навигацию и пр. стоит основывать на div'ах и span'ах? Гм, ну точка зрения ясна. Но с другой стороны я не могу понять, почему список разделов сайта в сайдбаре - это не данные? Это вполне нужные для функционирования сайта данные, это не оформление - навигацию нельзя просто убрать, сохранив функциональность сайта.

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

[novicheG]

При верстке руководствовался мыслями: список - есть "перечисление" элементов.

список каких-то дел; фрукт1, фрукт2, фрукт3, п.меню1, п.меню 2, - перечисления элементов, -> список.

в тексте "категория1, подкатегория2, подкатегория3 - содержат нужные для вас материалы" ("," - ключевой элемент) - идет перечисление элементов - здесь это список.

в "пути по сайту" "категория1 -> подкатегория2 -> подкатегория3" - НЕ перечисление элементов - это одна строка, по логике это ближе к "адресу", "адресной строке" где мы сейчас находимся. ИМХО.

Edited April 11, 2011 by novicheG

[psywalker]

novicheG

Да дружище, не зря ты меня всё таки попросил прокомментировать твою работу

[SelenIT]

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

Да уж, пример с микроданными красотой не блещет, то, что itemprop ссылки берется из href, а почти всех прочих элементов — из содержимого, сильно ограничивает. Но статус у этого раздела спеки пока лишь "last call", может, как-нибудь разрулят еще.

А вариант с RDFa, имхо, вполне нормален — не лучше и не хуже, чем с привычными микроформатами, к тому же стандартный...

[Veseloff]

Я вот что про это всё думаю. Я всегда крошки делаю так

<div id="crumbs">
<a href="/">Mainpage</a>
»
<a href="/catalog/">Catalog</a>
»
<a href="/catalog/somecat/">Somecat</a>
»
<a href="/catalog/somecat/somegood">Somegood</a>
</div>

id у дива потому что я считаю, что этот блок должен быть единственным на странице. Хотя никто не мешает заменить id на class. Кроме ссылок и знака-разделителя внутри ничего не бывает, поэтому стилизацию разделителей делать можно в «#crumbs», а стилизацию ссылок в «#crumbs a». Если тут будут списки, то добавится собственно элементов (ul, li...) и стили станут немного длиннее. Возможно, это повиляеят на скорость рендеринга, добавит «веса» странице, но это всё фигня, я считаю. Я бы не стал делал крошки списком, поскольку не вижу в этом никакого смысла.

[s0rr0w]

То есть меню, навигацию и пр. стоит основывать на div'ах и span'ах? Гм, ну точка зрения ясна. Но с другой стороны я не могу понять, почему список разделов сайта в сайдбаре - это не данные? Это вполне нужные для функционирования сайта данные, это не оформление - навигацию нельзя просто убрать, сохранив функциональность сайта.

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

Моя основная мысль заключена в том, что нужно строго разделять контент и оформление.

[rash]

Ясно, в этом случае просто различные взгляды.

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

Насчет хлебных крошек - да, скорее не список. Убедил пример SelenIT'а с отображением без стилей. Без списка просто лучше.

[psywalker]

Насчет хлебных крошек - да, скорее не список. Убедил пример SelenIT'а с отображением без стилей. Без списка просто лучше.

Меня тоже кстати этот пример неплохо пошатнул моё мнение в сторону НЕ списка.

[Seva1986]

Читал читал думаю дай помогу вам!

Есть хорошие места там тепло и уютно всем квалифицированным верстальщикам (не квалифицированным там смерть! ) зовутся эти места спецификации!

Вот одно из них! http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-up

Там написано примерно следующие:

В этой спецификации нет специально тега для крошек, поэтому юзайте параграф и если нужно засуньте это всё в тег nav.

От себя добавлю:

это не первое место где они советуют использовать тег "p" потому что не предусмотрели другого , но в данном случае вообще нет вариантов как бы это сделать. Использовать "ul, li" не правильно так как они не одноуровневые. div span это пустые теги что они есть что их нет для семантики без разницы. Вариант с "section" для каждой ссылки, вложенные друг в друга будет не правильным по тому что они создадут каждая свой подраздел, а подраздел для одной ссылки это тоже самое что стрелять с базуки по тараканам , и тем более для выпадающего меню мы используем вложенные "ul, li, ul, li", а для каждой крошки "section" думаю как то не очень А использовать "ul, li, ul, li" для каждой крошки тоже не очень красиво разметки в два раза больше чем контента получается...

<div id="breadcrumb" >

<ul>

<li> <a href="http://dmoz.org/" shape="rect" >Top</a>

<ul>

<li> <a href="http://dmoz.org/Science/" shape="rect" >Science</a>

<ul>

<li> <a href="http://dmoz.org/Science/Biology/" shape="rect" >Biology</a>

<ul>

<li> <a href="http://dmoz.org/Science/Biology/Genetics/" shape="rect" >

Genetics</a>

<ul>

<li> <a href="http://dmoz.org/Science/Biology/Genetics/Genomics/" shape="rect" >

Genomics</a>

<ul>

<li>

<span>Pharmacogenetics</span>

</li>

</ul>

</li>

</ul>

</li>

</ul>

</li>

</ul>

</li>

</ul>

</li>

</ul>

</div>

хотя если хлебные крошки будут смешаны с навигацией и содержать по несколько ссылок в каждом пункте, например выпадающие по ховеру, то нужно юзать "ul, li, ul, li"

Вот так както!

Edited July 31, 2011 by Seva1986

[SelenIT]

Seva1986, спасибо за ссылку на whatwg! Надо же, как я такое прозевал...

Пример со вложенными section-ами (да еще в figure) я изначально приводил как абсурдный по смыслу и иллюстративный по сути . А вариант со вложенным списком (или хотя бы вложенными спанами), на мой взгляд, единственный способ однозначно передать отношение вложенности машиночитаемым образом (что подтверждает Гугл своим примером микроразметки для потенциально неоднозначного случая). В прочих же ситуациях, и вправду, чем проще — тем лучше, а что может быть проще обычной строки в абзаце?..

[Seva1986]

Seva1986, спасибо за ссылку на whatwg! Надо же, как я такое прозевал...

Пожалуйста!!!!

Но гуглу пофиг на расшириную разметку микроформаты и т.д.

http://www.google.com/support/webmasters/bin/answer.py?hl=ru&answer=99170

(Примечание. Разметка данных для расширенного описания веб-страницы не повлияет на рейтинг страницы в результатах поиска. Google не гарантирует, что разметка или любая конкретная страница или веб-сайт будут использованы в результатах поиска.)

А хлебные крошки нужны 1) для юзера, 2) для поисковика для лучшей индексации... так как обоим пофиг расширенную разметку, но не пофиг на лишние теги (мусор в разметке чучуть медленее грузиться страница, и для того же гугла один из факторов ранжирования это: соотношение разметки и контента, да и вообще лишние теги это зло! )

Единственный смысл в этих микроформатах это если сайт будут обрабатывать особые парсеры (которые будут её понимать и что то делать с этой разметкой)...

Edited July 31, 2011 by Seva1986

[Shift-Web]

>> Да уж, пример с микроданными красотой не блещет, то, что itemprop ссылки берется из href, а почти всех прочих элементов — из содержимого, сильно ограничивает. Но статус у этого раздела спеки пока лишь "last call", может, как-нибудь разрулят еще.

А чем тут блистать? Теги(обёртки) роли не играют(и для RDFa и для microdata, исключением являются мкроформаты). Важна вложенность и правильная расстановка контекста(атрибутов). Ссылка может содержать рел или рев, но это совсем не обязательно, при этом анкор ссылки должен восприниматься отдельным элементом(описывает заголовок\именование), а сам элемент <а> указывает на связь(href) и тип отношения(rel). Но тоже не всегда. Чтобы как-то обозначить логически "секцию" они обёрнуты в отдельный элемент с указателем на профайл(читайте namespace). Суть одинакова, реализация немного разнится.

{чета много понаписал, короче это обычный граф, не парьте мозг}

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

>> (которые будут её понимать и что то делать с этой разметкой)...

Уже давно понимают и делают. Посмотрите на тему определения быстрых ссылок яндексом. Там есть кое какие намёки на то, что логика должна соблюдаться. При чем описано всё довольно простым языком.

анкор => title

p.s: нифига не список.

Edited July 31, 2011 by Shift-Web

[Seva1986]

Уже давно понимают и делают. Посмотрите на тему определения быстрых ссылок яндексом. Там есть кое какие намёки на то, что логика должна соблюдаться. При чем описано всё довольно простым языком.

Ну и? а я что сказал что досихпор не понимают?

Эта фраза не тоже самое, что вы написали, говорит?

Единственный смысл в этих микроформатах это если сайт будут обрабатывать особые парсеры (которые будут её понимать и что то делать с этой разметкой)...

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

Edited August 1, 2011 by Seva1986

[Shift-Web]

>> Эта фраза не тоже самое, что вы написали, говорит?

Каникулы ещё не закончились?

[Seva1986]

Каникулы ещё не закончились?

Вы о чём? какие каникулы?