Сайт художницы

[ZI DAN]

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

[pashkje]

За адаптацию + тебе

[klierik]

За адаптацию + тебе

Какой смысл в такой адаптации?

Зайдет пользователь с телефона с 3G соединением, у которого 10МБ/сутки бесплатно и на одно только изображение потратит кучу трафика:

o1.png
Dimensions 346 × 859
File size 482 KB
URL http://kalininaolga.ru/Images/o1.png

То что сайт адаптируется под ширину экрана не говорит о том что верста адаптивная. Просто, к сожалению, применено пару @media правил кторые не несут практической пользы.

По сабжу: а вообще что обсуждаем? Или ты просто так выложил?

[ZI DAN]

а вообще что обсуждаем?

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

[klierik]

1. непонятно зачем в разметке использован класс:

<li class="stone"><span> ...

если в стилях обращение:

.menu div ul li

2. bigBlock -- плохое именование классов. используй .class-name формат.

по поводу адаптивности.

увидев это: http://kalininaolga.ru/news/mobile_site/ и поняв что сайл сожрал моего несколько МБ моего трафика я бы никогда не обратился к автору и рекомендовал оп одной просто причине: если на обычной домашней страничке, коих в интернете миллионы, в содержимом пункта меню сказано что сайт адаптирован под мобильники а он таким не является, то считаю правым расценивать это как самую настоящую лож. Если автору сайта "ложить" на мой трафик и его не заботит моё комфортное перебывание на его сайте то грош ему цена. Уйду и никогда не вернусь. Если даже на сайте врёт то что ждать в реале.

Данный сайт не адаптирован под мобильные устройства. У него всего лишь резиновый макет который был реализован при помощи инструмента @media.

[SelenIT]

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

Но дизайн симпатичненький

[ZI DAN]

1. Да, не заметил, спасибо.

2. Ну я бы не стал так однозначно утверждать. В стандарте разрешается использование заглавных букв. Да, названия классов нечувствительны к регистру. Однако мне ближе CamelCase, и особо веских причин отказываться от него я пока не нашёл.

3. С неполной адаптированностью согласен (в терминологии путаница вышла). Удалил новость про мобильные устройства.

полмегабайта для джипежки в четверть мегапикселя площадью — явный перебор

Там вообще-то .png с прозрачностью, поэтому никакого перебора нет. Делать .jpeg-ом — не вариант, т. к. фон сложный и меняющийся в зависимости от размера экрана.

Edited October 7, 2013 by ZI DAN

[SelenIT]

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

[ZI DAN]

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

Через Color Quantizer и подобные программы получается либо хреновое качество, либо несущественное сжатие. А учитывая очень плавную прозрачность в некоторых местах картинки, замороченный фокус с jpeg'ом тоже не даст не отличимой на глаз картинки (а глаз у меня достаточно придирчивый, особенно в сочетании с неплохим монитором).

[SelenIT]

Насколько я понял, фокус дает именно плавную прозрачность. Но опыт — критерий истины.

[121990]

А почему не используешь normalize или reset?

[lexxcode]

А почему не используешь normalize или reset?

Не использует и правильно делает

[121990]

Не использует и правильно делает

Почему?

Там даже универсального селектора нет. для отмены марджинов с паддингами по умолчанию

Edited October 7, 2013 by 121990

[lexxcode]

Почему? Там даже универсального селектора нет. для отмены марджинов с паддингами по умолчанию

Не нужно ничего сбрасывать, вообще. Я уже устал это объяснять. 100500 раз эта тема уже поднималась на форуме, поднимать ее в 100501 раз не вижу смысла. Люди все равно будут биться головой об стену и лепить эти глупости себе в css - пусть лепят, это ихнее дело.

[klierik]

2. Ну я бы не стал так однозначно утверждать. В стандарте разрешается использование заглавных букв. Да, названия классов нечувствительны к регистру. Однако мне ближе CamelCase, и особо веских отказываться от него я пока не нашёл.

я сто-о-о-олько раз объяснял почему не надо так делать... тут на форуме наверно 50+ моих постов на эту тему.

camelCase -- это плохо в вёрстке. это не программирование(!)

Скажу кратко: человек с детства обучается читать текс, как перечень слов, разделенные пробелом.

Запись camelCase заставляет вчитываться по-буквенно в каждое имя класса, в то время когда .camel-case будет читаться естественней и привычней для человека.

А вот теперь представь что у тебя более 30 less(css) файлов в которых более 20 структур с глубиной до 10 уровней.

Каждый раз всматриваться и вчитываться в имя класа это очень тяжело.

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

А если, не дай Бог, его что-то будет поддерживать после тебя -- недоброе слово в твою сторону будут очень часто мысленно отсылать.

[lexxcode]

Вообще не вижу проблемы в camelCase записях, прям абсолютно никаких затруднений в восприятии у меня не возникает

[klierik]

.checkitoutWrapper .checkoutSingle .sameAsBilling .sameAsBillingOverlay

vc

.checkitout-wrapper .checkout-single .same-as-billing .same-as-billing-overlay

.checkitout .reviewContainer .formList .orderComments

vc

.checkitout .review-container .formList .order-comments

ну или:

.checkitout .checkout-step .gift-messages-form .allow-gift-messages-for-order-container .form-list .field,

Между словами должны быть расстояние -- это обусловлено стандартом чтения текста.

Чтение текста и его идентификация:

LoremLpsumIsSimplyDummyTextOfThePrintingAndTypesettingIndustry

и

Lorem Ipsum is simply dummy text of the printing and typesetting industry

существенно отличны.

И не будем забывать что мы, как правило, не читаем слова по-буквам, и читаем целиком.

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

Пробе́л — интервал между буквами, обозначающий границы слов во многих системах письменности.

Можно еще зацепить тему и сравнить "-" и "_" но это другая тема.

Так же я опущу тот фак что вероятность допустить ошибку в имени, набирая код, camelcase больше чем в camel-case.

Написанный код должен быть максимально простым для восприятия любым разработчиком.

аЭтоГоворитОтомЧтоКодДолженБытьМаксимальноПриближенКстандартномуВосприятию разработчиком, то бишь человеком, который каждый день, утром, днем, вечером, ночью читает текст в интернете, в метро, маршрутке, этикетках, газетах, форумах, блогах, и прочих интернетах страны который имеет стандарт написания и является родственным, в отличии от остальныхАльтернативныхПредложеныхИТобществуФорматовНаписания.

ps: моё имхо, основанное на моём личном опыте, является рекомендацией и только.

[lexxcode]

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

[klierik]

что нужно писать не ОывфШовфиИофыпвИОывфыв

такого примера я не приводил.

выдержки из CSS были из реального проекта.

[ZI DAN]

Даже не хочу влезать со своим мнением в этот срач. Просто открыл для интереса главную Яндекса и обнаружил там вот такие вещи :

class="b-disk-uploader__statuses_wrap i-hidden"

А Гугла такие:

class="gb_s evenMoreLink"

Вот же говнокодеры там сидят)

Т. е. у Гугла я обнаружил как минимум три нотации на одной странице (верблюд, дефис и нижнее подчёркивание), а у Яндекса две, но комбинированные в рамках одного названия класса.

Edited October 7, 2013 by ZI DAN

[Bassline]

Даже не хочу влезать со своим мнением в этот срач. Просто открыл для интереса главную Яндекса и обнаружил там вот такие вещи :

class="b-disk-uploader__statuses_wrap i-hidden"

А Гугла такие:

class="gb_s evenMoreLink"

Вот же говнокодеры там сидят)

Т. е. у Гугла я обнаружил как минимум три нотации на одной странице (верблюд, дефис и нижнее подчёркивание), а у Яндекса две, но комбинированные в рамках одного названия класса.

Вы действительно считаете, что в яндексе сидят говнокодеры?

[ZI DAN]

Это был сарказм.

[klierik]

class="b-disk-uploader__statuses_wrap i-hidden"

Прежде чем встревать, как ты выразился, в срач, хорошо бы иметь представление о БЭМ, который ты так уверенно процитировал.

Что же касается гугла, то он сжимает свой код и использует регистрозависимость CSS менно для этого.

И то что у него во фронте никоим образом не относится к дев версии.

По поводу .evenMoreLink -- ничего не скажу. Возможно старый код или элемент из набора симплов которые сжимать избыточно. А может быть та кбыло проще в рамках какой-то задачи для разработчика.

[Bassline]

Это был сарказм.

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

[ZI DAN]

Общее представление о БЭМ я имею. Но пока необходимости использовать эту методологию нет (я не вхожу в команду из 100 человек, которая работает над одним сайтом). Из примера Яндекса и Гугла следует, что разработка в большой команде всё равно приводит к нарушению «общепринятых правил» именования и установлению внутренних правил для проекта. Так зачем тогда утверждать, что одна нотация правильная, а другая — нет, если всё зависит от конкретного проекта?

А может быть так было проще в рамках какой-то задачи для разработчика

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

P. S.

Всё-таки влез в срач)

Edited October 7, 2013 by ZI DAN