Viper

По данному примеру дать совет сложно. И уж точно не определить какой вариант будет более производителен и оправдан на конкретном проекте/сайте. Для каждого случая бывает по разному, исходя из сложности дизайна/UI, требований/желаний заказчика/руководителя и ожидаемой нагрузки. Изображения зачастую требуют дополнительного запроса к серверу, имеют больше вес и менее удобные в поддержке/при изменении. СSS3 тени в данном случае увеличивают количество ДОМ элементов на 1, обьем таблицы стилей и что, как по мне, единственно важное - требуют больше рессурсов при рендеринге(больше тень/размытие - дольше отрысовка), что может сказаться при анимациях на сайте или скроллинге. В итоге: изображения улучшают быстродействие, но замедляют загрузку страницы и часто усложняют поддержку(зависит от проекта). CSS3 ускоряют загрузку страницы и отлично отображаються на всех видах экранов(например, retina), но при этом плохо(иногда, очень) сказываються на быстродейтсвии. Что выбирать в итоге, решать исключительно Вам. Разница между этими техниками в производительности, в большинстве случаев, относительно мала. И обе эти техники имеют право на жизни в зависимости от условий, ИМХО.

"неуместно" - уж слишком категорично сказано, ИМХО) При определенной методологии построения классов, вполне себе уместно может быть. У меня лично, например, только позитивное отношение к такому именованию классов как и у программистов, с которыми приходилось работать. Возможно, дело в привычке и предпочтениях?) А можно пару аргументированных примеров(ссылок)?

Что вы подразумеваете под "текстовые логотипы"? Не важно каким образом был нарисован/создан логотип, распространяться, по крайней мере, в вебе он будет(и должен, ИМХО) как изображение. Почему, на мое мнение, это имеет значение: 1. Логотип - это эмблема компании, которая должна всегда и везде выглядеть идентично, что не может гарантировать шрифт в вебе из-за отличий в кроссбраузерном отображении. Да собственно и на различных устройствах из-за, например, отсутствия поддержки необходимого шрифта или технических проблем в его добавлении для корректного отображения. И тд. 2. Логотип лучше добавлять сайте в качестве изображения <img /> (не background, как мне иногда встречается) еще и для печатной версии страниц. 3. Логотип часто ищут в качестве изображения для использования его, например, в качестве партнера на сайте или биллера в терминальной сети. Встречал случаи, когда это вызывало проблемы и трату драгоценного времени с обеих сторон, если логотип был Шрифтом или Flash объектом. 4. Логотип, созданный с помощью шрифта, будет также масштабироваться как и другой шрифт на сайте при изменении настроек отображения именно шрифта, что может вызвать неудобства, если на это каким-то образом не повлиять.Поисковики не будут распознавать его как изображение, в большинстве случаях, появляются проблемы с распространением и тд. П.С. Не то, что бы логотип нельзя было технически реализовывать с помощью шрифта. Но зачем? Когда в этом и появляется необходимость, гуманнее, ИМХО, использовать SVG.

А если эта надпись являеться логотипом, то такой обьект должен быть изображением <img /> или, при необходимости, SVG обьектом, но не текстом, ИМХО.

Обзор jQuery-плагинов для стилизации селектов: http://habrahabr.ru/company/aiken/blog/114927/

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

Да, может. Но зачем? Любые пустые теги, созданные для стилизации, могут быть заменены на псевдоэлементы. И это, с точки зрения семантики и оптимизации, куда более правильно. В идеале, Да(ИМХО): теги не должны создаваться исключительно с целью оформления/стилизации. Но в первую очередь, нужно задумываться не о "красоте" и "правильности" кода, а о пользе этого кода для, например, пользователей, проекта или инвесторов. ИМХО.

Интересная статья в тему - http://web-standards.ru/articles/box-sizing/

Почему? В HTML5 это позволительно. Или опять что-то поменялось?

Этот баг актуален для всех версий IE Это решение для другого бага. Нужно вводить текст длиннее самого input'а, в этом случае горизонтальный padding перестает учитываться и текст "сьезджает" к бордеру - http://jsfiddle.net/4nJDr/

Думаю большинству знакомый баг в IE, когда при наборе длинного текста в input горизонтальный paddng не учитываться. И если в этом padding'е расположено фоновое изображение, то текст налазит на него. Обычно это решается дополнительным враппером/контейнером. Но как же не хочется для каждого такого поля добавляться дополнительный контейнер только, что бы исправить этот баг в IE. Существует ли решение этой задачи, без использования дополнительных тегов или js?

раработка/создание уникального темплейта(template) на базе CMS системы, например)

JS здесь не нужен, на сколько я понял задачу: .carousel { -o-user-select: none; -moz-user-select: none; -webkit-user-select: none; user-select: none; }

1. ссылки в #h-nav не должны выделяться при наведении на отступы. 2. очень много ID, стилизовать лучше исключительно через классы, а ID оставить для скриптов. 3. последние новости сверстаны не семантично и не правильно через список определений. DL служит для других целей и должен содержать последовательность из тегов DT, DD. 4. тег SECTION не семантично использовать в качестве контейнера/врапа 5. названия элементов не семантичные(усложниться поддержка): n-top, n-bot-b, aslast, тд... Все зависит от требований. Если бюджетка и не требуется оптимизация, js, то ~4 часа(можно за ~2-1.5). Если требуется высокое качество, оптимизация, js скрипты и тд., то ~10-14(можно за ~6-7). ИМХО. П.С. Нормально, ИМХО.

Не все так просто) Если даже и будет известна высота блоков, то остается еще такой нюанс как прозрачность фона)

Если говорить про Pixel Perfect в верстке, то обычно, подразумеваться попиксельное соответствие размеров блоков, отступов чего-либо и тд., но не шрифтов и учитывать, что текст будет "растягивать" блоки. Заказчику нужно это объяснять, если он услышал модное слово и захотел его поддержку.

Да, так лучше. А в идеале лучше дать ссылкам классы и через них менять стили. Но это не ошибка, а "путь" достижения лучшего результата, который используеться в зависимости от требований. Имеет значения, обычно, для больших нагруженых сайтов. Почему? Вкратце: чем длинее каскад селекторов, тем дольше будут применяться стили. Подробнее: _http://www.xiper.net/learn/css/efficient-css/efficient-css-selectors.html Если максимизировать использование классов, то так же упроститься поддержка проекта, ре-дизайн и тд.. Возможно, вы не поняли. Я имел ввиду, что этот текст полностью не виделяеться обычным путем. Изображения частично его перекрывают.

В данном случае, проще всего(ИМХО) будет так: three-columns-container { overflow: hidden; }

1. Для стилизации лучше не использовать ID, а оставить их программистам. В верстке лучше пользоваться исключительно class. 2. <div class="clear-fix"></div> - старайтесь не использовать "пустышки" для очистки потоков. Это не гуманно) 3. логотип я бы поместил в <h1>, его не хватает на странице, ИМХО. 4. селектор * очень медленный, существуют более оптимальные и гуманные ресеты.

1. Попытайтесь выделить номер телефона и текст - "Согласно Лицензии на оценочную..." 2. Отсутствуют hover у ссылок 3. <br> между тегами - плохо и бессмысленно. 4. footer section p, .address {... padding-left: 0 !important; ...} - зачем !important? 5. .blockNav nav ul li a - старайтесь избегать длинных каскадов

1. подсказка в поле search не убираеться при фокусе, лучше делать через атрибут placeholder или js. 2. отсутсвуют ховеры в навигации слайдеров 3. .categorie ul li a, большая вложенность - плохо. 4. иконки соц. сетей лучше делать через BG, ИМХО. Проще манипулировать и возможность сделать их спрайтом. 5. type="text/javascript" и type="text/css" можно не писать в HTML5 6. Писать стили в теле документа - плохо. П.С. В целом - неплохо, ИМХО.

Почему? Background всего лишь нужно выровнять по bottom

1. А если, например, такой вариант/идея: у врапа будет background - эти самые точки. Внутри будут расположены 2 элемента: один - слева, второй - справа. У которых будет белый background, перекрывающий точечный background врапа. Это подойдет как для фикса, так и для резины.

Столько, сколько за него заплатят. Да, ИМХО.

Ничего. На больших и сложных проектах обычно не целесообразно грузить весь набор стилей, так как все они не используються всегда(например, popup'ы). В Яндексе, насколько я помню, даже каждая самостоятельная кнопка имеет свой файл стилей. Сделано это ради упрощения поддержки и работы над проектом, а так же для того, что бы грузить только те стили которые необходимые в определенный момент.