Leaderboard

1) По поводу id. Есть два немного отличающихся мнения. Первый — кардинальный. Это отказаться от использования id вообще, где это возможно (остаются только формы и ссылки-якоря). Смысл в том, кодеру возможно понадобиться навесить на какой-либо элемент id, для того, чтобы привязать его к скрипту. Возможно кодер имеет свои предпочтения в работе, когда он каждый id именует одной буквой алфавита. Однако если верстальщик нависил кучу id на элементы, то ему придётся внимательно следить за именованием, да и ещё пытаться не сломать стили. Второй вариант — более свободный. Он подразумевает использование id только для основных частей: шапка, боковые панели, подвал. Причём контейнер основного контента обычно стилизуют с помощью классов, мало ли что. К тому же у вас есть явная ошибка. В коде id="Header", а в css #header. Имена id и классов — регистрозависимые. Хотя может быть это хак для ie? И ещё у вас у многих элементов схожие названия. Нет, я понимаю, что это дело каждого, как назвать блоки, хоть двумя буквами, но всё же при таком наименовании есть большая вероятность спутать #header и #headerz. Рассмешило назавание #osnoval. Я не сразу догадался, что это osnova-left. Кстати, чисто логически это не основа, а sidebar. Одно дело, когда верстаешь одну страничку, но совсем другое, когда страница формируется с помощью CMS. Может так случиться, что вместе встретятся два блока с одинаковым id. Например, тот же блок #kreditline, вдруг будет страница, которая будет состоять из повторов одного блока. Тут как раз это приемлемо. Как вариант можно было сделать списком, но однако такой вариант тоже имеет право на существование. Использование классов, позволяет потом в блоке использовать вложенный див, если потребуется. Ещё вариант, забить на ie6 и использовать #kreditline > div. Тег img принято использовать, когда картинка непосредственно относится к тексту. Фотография, иллюстрация, схема ит.д. Всё, что относится к дизайну, должно выноситься в css. Проверить можно так: отключить css в браузере. Не должно остаться ничего дизайнерского. Можете и не оптимизировать. Во-первых, потому что это тестовая страничка и так удобнее её изучать, во-вторых, это же как бы малопосещаемый сайт. Вообще с оптимизацией css довольно интересная ситуация, так чего-то ощутимого она не приносит. Обычно страница тормозит от скриптов и больших картинок, но не от css. Возможная польза, это снизить нагрузку на сервер, но это обычно характерно для систем с большой посещаемостью, например Яндекс.

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

Чтобы юзер, отключив картинки, не кусал локти в попытках понять, что же там на картинке было =) Ну нехорошо пользователю навязывать открывание новых окон/вкладок. Он сам вполне в состоянии решить. Так что это хороший тон, не более. Хоть и навязанный

а вот это, кстати, в корне неверно. xhtml в принципе создаёт рамки только формальные, и его жёсткость не имеет особого смысла. Особенно strict. Вот примеры жёсткости: нельзя картинку без alt. Почему? нельзя ссылкам target. Почему? обязательно type для <script>. А часто бывают скрипты иные, чем js? Чаще одного процента от всех? Тогда почему не принять js типом скрипта по умолчанию? обязательно type для <style>. А бывают стили иные, чем css? А тогда почему надо их тип указывать? <a> может содержать только инлайновые элементы или просто текст. А почему? А если надо сделать например ленту новостей, в которой весь предпросмотр новости, включая текст, заголовок и картинку, должен быть ссылкой на детальный просмотр, то правильно будет весь предпросмотр завернуть в ссылку. А xhtml этого не позволяет. Что в этом правильного? обязательно xmlns. А зачем? Все те зачатки осмысленности набора тэгов, которые есть в xhtml, заимствованы из html4. Расширение набора тэгов чревато некоторыми сложностями. В результате используется оно очень и очень редко. В серьёзных проектах — никогда. Тогда зачем? Можно ещё множество вопросов «почему» и «зачем» задать. А ответы на них есть? Только не отмазки в духе некрософта, объясняющего, почему у них браузер не работает, а настоящие ответы. Ответов нет. Потому что этот стандарт разрабатывался консорциумом, имеющим весьма косвенное отношение как к разработке браузеров, так и к разработке сайтов. Взгляды W3C — это теория, не подтверждённая практикой. В ней может и есть что-то правильное, но не для нашей основной задачи — не для создания сайтов для жизни. Реальным потребностям отвечает другой стандарт, разрабатываемый производителями браузеров. Как правильно делать: академично или так, чтобы соответствовало реальным потребностям и отображалось в реальных браузерах? Аналогичный вопрос: согласно ПДД на красный свет светофора нужно стоять. Стоите на светофоре, и прямо в бок летит жена депутата с тонированными стёклами. Варианты: уехать на красный свет с опасного места или соблюсти формальные академичные правила и принять на себя сначала удар двух тонн дурости, а затем год ходить по судам, доказывая, что не верблюд. Какой правильный?

font-size пропишите, в IE шрифт маленький. Дефолтный размер, походу. PS Такое количество "синего текста", по-моему, смотрится кошмарно. PPS *завис* PPPS Ссылка "главная" на главной, по уму, не должна быть ссылкой. Аналогично - с остальными страницами. Где-то должно быть отражено текущее местоположение посетителя.

Исправил, спасибо за замечание, я просто не воспринял это сразу как ошибку, ну зато 10 минут времени потратил на развлечение, и по пробовал увеличивал шрифт в ИЕ7 на самый крупный - все хорошо. Единственное что хочется добавить, что если бы делал верстку сейчас, сделал бы процентов 80 по другому, может когда то и переделаю, хотя думаю лучше оставлять и потом смотреть на свои первые творения, да же сейчас меня позиционирование заставило улыбнуться . По поводу таблиц: наверное я еще не на той стадии развития в верстке, что бы можно было выбирать как лучше. Я учусь верстке слоями - значит я должен все делать на слоях, вот может через пару лет практики, я буду выбирать как мне легче (правильнее).

Очень интересная статья по построению сложного фона Принцип цикады и почему он важен для веб-дизайнеров

Хм, а я уж думала, что холивары таблица vs блоки уже давно в прошлом. Ан нет, иногда эта тема поднимается снова На самом деле ответ уже был дан выше, причем не один раз — всё зависит от поставленной задачи. Причем один и тот же шаблон, в зависимости от ситуации может потребоваться сверстать как на блоках, так и на таблицах. В принципе, что сегодняшняя на плавающих блоках, что таблицы — совсем не предназначены для разметки страницы. Блоки гибче для последующего изменения страницы, т.е. взаимного расположения элементов, особенно это начинаешь понимать, когда работаешь с cms (по крайней мере у меня), когда различные функциональные элементы страницы могут быть расположены в разных компонентах и пока найдешь нужный, бывает потратишь достаточно времени. Расположение же css всегда известно. И поменять 2-3 строчки в стилях всегда приятнее, чем копаться в разметке Таблицы же железобетонней и кондовей, а также обладают рядом преимуществ, о которых уже было сказано. Хз, о чем тут спорить. Есть задача - есть её решение, есть средства, которыми они достигаются. Если они удовлетворяют условиям задачи, то почему нет

Тогда браузер повиснет от количества элементов, и пользователь больше не зайдёт на этот сайт :-) Если серьёзно, то любой из вариантов требует вмешательства в код. Если количество блоков заранее не известно, то можно предположить, что они будут добавляться движком. Тогда каждому блоку можно генерировать id и там уже позиционировать. Хотя, да. Вариант с дополнительным обёрточным блоком лучше. Ещё есть вот такой вариант (работает только в Chrome, FF и последних версиях Opera 11.10 и Safari): http://serlutin.nxt.ru/example/multi-column.html Но нужно дождаться, когда вымрет IE9

А тут дело не в валидности. Нет никакой формальной ошибки в том, чтобы задать элементу id в чисто оформительских целях. И для одной тестовой страницы это вполне допустимо. Дело действительно именно в дальнейшей работе с этой вёрсткой. А тут нет чётких правил, разработчику оставлено принимать самому решение, как правильно именно в данном случае. Просто <div> — это какой-то совсем уж безликий элемент. А это явный навигационный блок. В современном html есть для того даже тэг специательный. Любители же устаревшего подхода вынуждены использовать везде либо безликие дивы, либо семантически притянутые за уши списки. Кстати, а чем обоснован выбор доктайпа? Тут уже Serlutin всё рассказал. Да так, что и добавить нечего. Действительно, вся оформительская чуть идёт фоном. Содержательные изображения, такие как иллюстрации к статьям, ставятся в <img>.

Стало интересно, насколько можно минимализировать этот макет в плане графики. На правах прикола — вот такое безобразие (пока FF4 only, о пиксельной подгонке речи нет, чисто демо идеи, делал очень впопыхах, через час в поход ухожу просто ). Интересно, в правильное направление я смотрю или мимо?..

прошу прощения, у меня тоже был цейтнот, даже не почитать толком форум было. Только вот про пятёрку Макс ошибся. Тут особо не за что ставить пятёрку. С одной стороны, вроде как всё работает — а это главное. С другой стороны код какой-то при этом… бывает и лучше, в общем. Удивило безумное количество id. Зачем? Хотя это быстро проходит, если делать не абстрактную вёрстку, а живые сайты. Интегрировать свою вёрстку с cms, а затем поддерживать сайт, меняя компоновку под вносимые практикой коррективы. Пару раз словишь косяки с несколькими одинаковыми id и запутавшимся в них js например — и вопрос насчёт целесообразности использования id в оформительских целях снимается. Меню набором дивов с одинаковыми классами… не сказать, что это прямо явная ошибка, но как-то некошерно. <img> для чисто оформительских целей — например, иконки в меню — сомнительное решение. Фоном было бы уместнее. Хотя <img> более оправдан, если планируется, что разделами будет управлять секретарша с доступом на специальную страничку в админке cms. Но рамка фоновой картинкой удивила. Использование position: absolute тоже удивило. Я, кстати, до сих пор не понимаю — зачем? Спрятанный под каким-то из блоков телефон тоже удивил. Перечислить случаи, когда номер телефона нужно скопировать, можно. А вот скопировать его почему-то нельзя. Почему? И, кстати, почему <sup> выскочил не по макету? Выглядит откровенно коряво. Это первое впечатление. Если нужны пояснения — не вопрос, сделаю. Только какие пояснения? Будут вопросы — отвечу.

Хорошо, вот пример: http://serlutin.nxt.ru/example/no-table.html Сделал за 11 минут, профессионал сделал бы быстрее. Если что это пример с реального сайта, только там всё реализовывалось на js. За сколько вы такое сделаете на таблицах?

Почему верстать таблицами плохо: это ненужные и неоправданные нагромождения. Чаще всего требуется некий выворот мозгов наизнанку, чтобы выданный для вёрстки макет представить в виде таблицы. Просто потому что это противоестественно. А притягивание за уши противоестественных решений неминуемо ведёт к глючности и сложности поддержки. Почему в отдельных случаях всё же хорошо использовать таблицы именно для расположения элементов: таблица — это цельная конструкция с жёстко заданным расположением элементов. таблица обладает некоторыми такими свойствами, которыми не обладают другие элементы. Когда взаимное расположение элементов должно обладать именно свойствами, характерными для таблицы, располагать их без таблицы имеет смысл разве лишь ради разминки для мозгов.

Уже не нужно вроде бы?

+1 за css3 и в топку старых ослов.

CSS3 border-radius (-moz-border-radius, -webkit-border-radius, -khtml-border-radius) и забейте на ie вплоть до 8 версии еще есть интересное решение, но там нужно мусорить в верстке

Знать надо только обязательные атрибуты, например, надо знать, что у тега <img> обязательно должны быть src и alt. Необязательные, а тем более те, которые можно заменить в css знать не нужно. Если есть желание устаиваться на работу, то плох тот работадатель, который на собеседовании будет спрашивать про атрибуты тегов — не надо к такому идти работать. Правильный работодатель посмотрит на «портфолио» и/или даст тестовое задание, которое покажет ваши реальные навыки.

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

ну так-то да, но с дивами гибше выходит. 1. когда например неизвестное количество идущих параллельно в ряд элементов. таблица с такой галерей будет распирать по горизонтали страницу. (были случаи в жумлах и битриксах - там многие компоненты генерят таблицами представления товаров/новостей/картинок/чего_угодно, а на меньшем чем у затейника идеи экране всё это выглядит ужасно) 2. дивы можно позиционировать как душе угодно, стилями перелопатить страницу на дивах под любое разрешение/представление, хоть верх тормашками справа налево. а таблица это как топором вырублено, уже никак не изменишь. не должно представление данных так зависеть от структуры, а таблица задаёт самую что ни на есть жёсткую структуру. имхо путаница с флоатами/прилипанием - это наоборот возможности добавляющие гибкости, хороший инструмент в умелых руках. я люблю всякие фиксированные элементы вставлять. независимые от количества содержимого контента. Если же ваять простые двух-трёхколоночные шаблоны то с таблицей без условно проще. ЗЫ: sympler, а вы не тролль часом

Учи сь работать в фотошопе боковые градиенты у тебя - кака Забуть про лорем ипсум, наши сайты пишутся кириллицей, нужно под неё адаптировать. Html код в целом чистенький.

Подскажите мне чайнику! хочу сделать на сайте ссылку скачать файл- ехе!делаю в денвере и висте.не знаю как.в опере нтмл работает а в папку хоум ставлю-нет. КАК????ё ма ё замучалась я ёйки блин :) нет никого

То есть вы считаете, что, например, предложение: "Груз зафиксирован на грузовике и перемещаеться вместе с ним" не имеет смысла? Употребление антонимов в одном предложении для Русского языка - это неотъемлимая часть великого и могучего. Смысл моего первого поста понятен.

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

ваш ответ буду вставлять вместо lorem ipsum - много буковок, и ни одной по делу, голая теория... которую я в первом посте в первых строчках сказал, а вы просто переиначили... мы ведь и пытаемся выяснить какие ИМЕННО "некоторыми такими свойствами, которыми не обладают другие элементы" обладает таблица и наоборот????? и разжуйте мне что за: 1. ненужные и неоправданные нагромождения? 10-20 лишних буковок никому не навредят, лучше одну картинку в контенте оптимизировать... вместе с цсс и тд 2. выворот мозгов наизнанку, в каких случаях? чур только не абстрактные примеры! 3. разминки для мозгов? тоже в каких случаях? я любую таблицу закрытыми глазами нарисую, даже не включая мозг, также и с дивами. я только выясняю почему все таки дивами правильно а таблицами вредно для здоровья? ЕДИНСТВЕННЫЙ минус - жесткая привязка. но как будто к у нас никогда нет доступа к html но при этом всегда к css.... я и не за и не против, но я не вижу реальных минусов у таблиц, за которые их похоронили!!

Запустил ваш макетик в 7 IE, жесть..., а так ну не знаю смысл тогда вообще было в нем использовать графики??