Jump to content

dersmoll

Newbie
  • Posts

    4
  • Joined

  • Last visited

Everything posted by dersmoll

  1. Всегда пожалуйста, однако, я так просто не отстану Давайте, вернемся к спрайтам. Естественно, говоря о спрайте, я не имел в виду контентные картинки, это само собой. Я скорее имел в виду практически все элементы оформления и кнопки. К примеру - #about button.submit, #specs .button_order .note, #specs .button_order .send_order_inactive, социальные иконки в футере и значек емейла там же. Эти и другие иконки/кнопки вполне комфортно чувствовали бы себя в одном спрайте, параллельно снижая нагрузку на сервер. Туда же можно было бы добавить и лого, раз оно нигде не продублировано картинкой. На самом деле, это так себе решение, потому что при печати клиент и посетители не увидят, откуда же эта страница отпечана, кроме текстовой ссылки в углу. Я придерживаюсь мнения, что лучше дублировать фон логотипа картинкой, скрывая для скринов и показывая для принта. Сайт только выиграет в качестве. Ну, или как минимум продублировать текстом название и слоган под ним. По поводу минимизаций скриптов и стилей. На самом деле я сам не большой фанат жестких минимизаций и обычно на продакшене отдаю эту честь скриптам, но это не повод держать подключенными в хеде 10 разных js-файлов и 5 стилевых. Если их объединить в меньшее количество файлов, разделив внутри комментариями, интернет-канал только скажет спасибо На счет утяжеления стилей, не могу понять, почему такой код footer.pagefoot table.footer_content td.contactus лучше такого .pagefoot .footer_content .contactus Это было бы полезно, если у вас нет доступа к хтмл и работа ведется только из css, ну а так - теги отлично видны и в html. А вдруг вам по какой-то причине понадобится заменить таблицу на дивы или список - тогда придется делать замену по целому блоку стилей. (вдруг у клиента алергия на таблицы, у меня такие попадались )) ).
  2. А можно я еще вклинюсь. Выше уже вам писали, но обращу внимание еще раз на то, что страница сделана очень плохо с точки зрения быстродействия и оптимизации. Вес 2.4мб для главной страницы и 88 запросов к серверу? Если "следовать модному тренду", эта верстка в таком виде не выдержит никакой конкуреции - многие будут закрывать страницу еще до того, как она прогрузится. Во-первых, на странице куча графических объектов, а вы игнорите спрайты (ховер-эффекты к кнопкам не в счет). Помимо снижения нагрузки на сервер, вы избавитесь от неприятных эффектов, которые у вас можно заметить на иконке с глазом #benefits .expand a { background: url("/media/img/domes/benefits_eye.png") no-repeat scroll 0 0 transparent; } При наведении на нее мышью, она вообще исчезает, и появляется только после того, как догрузится, а это время зависит уже от скорости соединения. Куча неминимизарованного js, который следовало бы объединить в меньше файлов, пожать и опустить в самый низ кода. С css та же ситуация. Плюс, в стилях есть такие штуки, как footer.pagefoot table.footer_content td.followus aside.sociallinks div { display: inline; } зачем вам такое усложнение и лишние зависимости? Лучшей практикой было бы написание чего-нибудь типа .pagefoot .sociallinks div { display: inline; } Такая избыточность встречается по всей таблице стилей Например так footer.pagefoot table.footer_content td.contactus или так header#pagehead.small div.content hgroup.logo h4 Если возвращаться к изображением, то небольшие изображения в верхнем ротаторе по 200-170кб - это тоже не дело. Максимум по 50 кб на них должно хватить. Да и вообще, при желании страницу можно уменьшить до размера меньше 1мб, а скорость загрузки поднять раз в 5.
  3. да, я этот косяк помню. но все таки сверстал именно так как есть. потому что дизайнер не предусмотрел способа размножить фон заголовка по вертикали. то есть если я его тупо размножу через репит, то получится некрасиво("плитка"). Кстати интересно как поступил бы профессионал, если бы оказался в подобной ситуации. Часто случается, что дизайнер редко задумывается о дизайне, который выходит за рамки статического макета. Поэтому, часто приходится доделывать за него мелкие недоработки. Я думаю, что в этой ситуации можно было бы просто прибить фон к низу чтобы красная лента встегда была в нижнем правом углу, а стрелочка внизу, а сверху залить серым цветом. Плюс, сделаеть адекватный line-height, а отступы сверху/снизу - паддингом. Таким макаром можно добиться минимального адекватного отображения. Скорее всего, в этом вопросе сказывается то, что вы, возможно, не работали напрямую с какой-нибудь CMS - или не применяли на нее дизайн, или не забивали контент. Представьте себе ситуацию, когда вы отдали верстку программисту, он ее кое-как применил и начал забивать реальный контент. Все изображения, загружаемые в админке на выходе всегда будут IMG. И сейчас, где бы он не вставил переменную, которая выведет это изображение в блоке новостей, оно сломает ему дизайн этого блока. Плюс, если он не сильно шарит в CSS, то он не разберется, что это за блок такой <div class="icon icon2"></div>, и почему он отвечает не за дизайн элементов, а за контентный объект. Clearfix тоже может давать проблемы, типа ненужной зависимости от других колонок. Имхо, отдельный контекст всё-таки как-то понадежнее. Естественно, нет смысла вставлять clearfix везде, куда дотянутся руки. В блоках новостей или других списках вполне достаточно делать overflow:hidden, но добавлять его родителя блоков mainL и mainR, по моему, это преступление Тут лучше уж было бы сделать классический clear:both по ними, чем такое. Тем не менее, эта проблема возникает довольно часто, потому что всякие выпадушки-попапы как раз и лежат в блоках с position:relative Можно и обсудить, но исходя из своего опыта могу утверждать, что минимальный классический clearfix подходит для 95 случаев из 100
  4. А можно, я немного тоже покритикую. Первое, что бросилось в глаза - на странице куча графических объектов, а вы совсем не используете спрайты. Здесь их общее количество можно было бы уменьшить раз в 10, а у вас даже стрелочки ротатора - разные файлы. И какое уж тут попиксельное задротство, если сервер будет нагружен таким количеством запросов. Скрипты и библиотеки лучше подключать внизу. jshowoff.css я бы оформил в общий файл стилей, он не такой большой, чтобы его отдельно держать. В текстовых инпутах, таких как в поиске, лучше использовать нативный параметр placeholder с фиксом под ie. С заголовками в правом сайдбаре совсем все плохо: несмотря на то, что они идентичны, вы для каждого из них делаете отдельный класс .videonews h2, .calendar h2, .photogallery h2 и тд. Плюс, если вдруг в заголовке текст перепрыгнет на вторую строку, то все развалится. Мне кажется, тут нужно делать более универсальный вариант. CSS тоже ужасен в некоторый местах. К примеру, от таких строк .news3 .news3_body .news3_bodyM ul li .icon1 хочется плакать. Наверное, вы не сталкивались еще с поддержкой больших проектов. Да и среднего размера тоже. Из-за таких макарон приходится заново перепедаливать блоки стилей. Почему б не назвать эту иконку просто - .new3_icon1? Да и по сути - это не иконка. Ведь это же блок "наши новости", т.е. подразумевается, что там будет динамический контент с обновляемыми новостями, значит там должен быть img src. В том же блоке новостей стоило бы объединить в один блок с дату и раздел. В стилях можно найти еще много скверных вещей. Например, в стилях .videonews ul li.last .videonews ul li h3 ul li - избыточно. Вполне достаточно писать .videonews .last .videonews h3 Да и вцелом, css неаккуратен - пустые классы, разнобой в их названиях, закомменченые строки и опять же - излишняя избыточность. Но знаете, какой ваш самых большой грех? Вы не используете clearfix для очистики флоат потоков, хотя в стилях он предусмотрен, а тупо везде ставите overflow:hidden. Это чревато большими неудобствами на живом проекте. Сразу проблемы с печатью, с возможными лайтбоксами и тултипами, выпадающими шуками и всем таким. Возможно, вы возразите, что тз совсем другое и что вы просто хотели сделать pixelperfect-верстку. Однако, грош цена такой верстке, если ее не примут ни как тестовое задание, ни как заготовку к проекту. Вместо этого, вы оттачиваете вредные привычки, за которые в нормальных веб-студиях бьют по рукам.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy