Leaderboard

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

разве? http://htmlbook.ru/css/clip Internet Explorer до версии 7.0 включительно работает с другой формой записи, при которой значения координат разделяются между собой пробелом, а не запятой — clip: rect(40px auto auto 40px).

Это не сарказм) удалять сообщения нельзя, поэтому я неправильное решение затёр

Сделай у инпута такие свойства: -webkit-appearance: none; -webkit-border-radius: 0; border-radius: 2px;

вообще мне больше даже понравилось объяснение SelenIT'а. Если нам приходится избавляться от внешнего вида списков, то скорее всего это действительно не список. Вот если обращаться к спецификации по элементу nav Там нет строгой регламентации, что нужно применять только список для ссылок. Но навигация по документу выполнена в виде списка вложенного в nav. при этом в первом примерчике ссылки на страницы новостей, блога и форума, вообще оформлены в параграфе и без списка, просто ссылки насыпом. При этом списки ul и ol, явно применяются только лишь для каких-то текстовых данных. Но не для более сложных вещей. В общем, я могу конечно и ошибаться в своих суждениях, я этого не отрицаю и вообще сразу об этом сказал. Ну если тебя смущает блочный элемент внутри строчного, то в html 5 так можно. Если тебя смущает БЭМ, то тут скажем так, идея хорошая реализация через опу Ну и объективно для реализации той менюшки нафиг не нужно было городить всю это вакханалию) Да и вообще, вся эта семантика-шмемантика Есть еще один момент в моем понимании, что не стоит слишком усложнять вещи. Ну то есть мы обозначили навигацию навигацией тегом nav, и все. Если эта навигация не предполагает выглядеть как список, то и не нужен там список, а если предполагает, как в примере на w3c, то пускай будет список. Что касается поисковиков, тут я не могу сказать что-то конкретное по этому поводу, но по идее для поисковика присутствие или отсутствие списка в навигации, особой роли не должно сыграть. Так же как для устройств предназначенных для людей с ограниченными возможностями. Если это обозначено как навигация значит оно будет каким-то образом для них доступно.

В плане клиент-сервер и относительно сайтостроения это скорее так , чем не так. )) Для примера к какой области вы отнесете программиста-тестировщика? ))) Или к примеру javascript разработчика работающего с Node.js? =)) С каждым годом порог разделения размывается всё сильнее и сильнее. Но всё же программист это тот кто программирует. И программист кроме html и css обычно знает еще пучок других технологий(естественно не обязательно идеально и зачастую, именно чтобы было достаточно для их использования). И если верстальщик может позволить себе не знать языков программирования, то программисту порой знания о других технологиях жизненно необходимы. И тут не стоит сравнивать что лучше или хуже. Каждый занимается тем что любит и хорошо умеет. А все они вместе это именно веб-разработчики. А не верстальщики или программисты.

спасаться бегством )

1. меняем пароли к cms ftp панели хостинга, а так же пароли к ящикам почты. 2. занимаемся системой: а: ставим заплатки б: ставим фаервол и блокируем все соединения которые не знаем в: шерстим антивирусом хард 3. бекапим все файлы с хоста + базу. перезаливаем движок сайта с сайта разработчика той же версии + секур апдейты. Опять меняем пароли от сайта,фтп, почты и т.д 4. общаемся с поддержкой хостинга и узнаем детали. Попутно анализируем свои логи если таковые имеются 5. гуглим по вражескому коду, возможно вы не одиноки, а если так то возможно кто-то знает больше вас Все вышеописанное относится только к виртуальному хостингу

Меню это не список. Если это являет собой навигацию по сайту, то это тег 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 имеют достаточно расплывчатое описание. А те же списки, так уж исторически сложилось, долгое время приходилось применять там где это совсем не нужно, но другого выхода не было. Так, что как-то вот так