exessqd1

Что выгоднее, чтобы пользователь получал новую функциональность раз в год, или раз в месяц? Чем проще код, тем в нем проще искать баги, тем в нем сложнее эти баги делать, тем быстрее его модифицировать. Пользователю лучше, если продукт будет постоянно совершенствоваться, чем очень быстро рендериться. Сверстайте портал с полутора сотнями шаблонами, тогда поговорим. Добро пожаловать. Глупый вопрос. Я не делаю сайты, я делаю решения. И да, я все делаю для себя и под себя. Заказчики в восторге. Бугагага.. Пользователю пофиг насколько быстро это работает и как хорошо это выглядит, если оно не решает проблем пользователя. Это все равно что в туалете поставить автомат по продаже носков вместо аналогичного, но с туалетной бумагой. Перед верстальщиком не стоит задача “решения проблем пользователей”. Пробовал, неполучается. Научишь?

Новые технологии. Новые технологии это инструмент который делает нашу жизнь проще т.е помогает нам создавать что-то лучше, быстрее, чище. CSS3 просто позволяет нам делать вещи которые мы делали годами, только без лишней дерготни. Использование новых технологий оправдано когда новое решение которое полностью повторяет поведение старого решения, но легче в разработке или более эффективно в скорости, и не должно быть намного более трудозатратно по времени. То есть мы ходим по грани между чистотой и кроссбраузернсотью, скоростью. Но в любой ситуации всегда в приоритет ставим кроссбраузерность и скорость. "Удобные селекторы" - это явно не тот стандарт который стоит сейчас поддерживать, т.к. он несет явные убытки в виде быстродействия, использовать его нельзя будет ещё долго. Да нет, пользуйтесь, если вам конечно насрать на деньги клиента, то есть на кроссбраузерность и быстродействие. А что выгоднее: быстрый рендринг или маленькое количество html кода? Как сказал один человек: “Те, 5% процентов html кода которые мы сэкономим, все равно убьют картинки” Легкость поддержки BEM проекта, как любого другого проекта, зависит от предпочтений разработчика. Ты для кого сайты делаешь? Для себя? Пользователю совершенно неинтресно, какое количетво кода у тебя в проекте, ему важны две вещи "как быстро это работает" и "как хорошо это выглядит". Тех кто делает чисто и быстро, в ущерб пользователям, считаю ленивыми чудаками. Считать нифига не умеем. Садись, два. Ок, 46 раз. http://s3.dump.ru/viewer/5415190/ Нина Николаевна можно мне пять? Нет Артемка, все равно двойка. Но почему? Потому что твои родители не сдали деньги на ремонт класса. Это количество тегов реально не достижимо практически никогда. В моих проектах, где все построено путем догрузки в одну страницу, я максимум добивался 5к тегов. Смысла ты я вижу не уловил. Придешь на дополнительные занятия. Суть не в том какое количество элементов у тебя на странице, а в том что селектор по классу отрабатывает в 7 раз(!) быстрее чем по типу, в независимости от количества элементов на странице. наиболее эмоциональные слова были вырезаны

И методология оценки эффективности тоже не помешала бы... Я думаю многим известно, что браузеры читают css справа налево поэтому при оценке эффективности селектора мы должны смотреть не только на количество элементов в селекторе но и на ключевой селектор то есть на последний. Например: .ingredient-details li { } В данном случае ключевой селектор это li. Эффективность этого li зависит от того сколько на странице ещё таких же li, чем их больше - тем больше браузер выберет(сматчит) элементов, тем медленнее отрисовка страницы. Браузеры сначала матчат все элементы на странице которые относятся к ключевому селектору а потом идут вверх по дереву пока не находят соответствия. Т.е здесь браузер сматчит все li на странице а потом пойдет вверх по дереву и сматчит все li относящиеся к классу .ingredient-details Скорость отработки этого селектора можно оптимизировать, уменьшив в нем общее количество элементов и количество элементов которые матчит браузер в соответствии с ключевым селектором, поехали Оптимизируем селектор Мы не знаем сколько классов .ingredient-details__item будет на странице но их должно быть явно меньше чем li, так что превращаем из .ingredient-details li { } в .ingredient-details .ingredient-details__item { } Здесь мы проставили на каждый li класс .ingredient-details__item Теперь этот селектор отработает быстрее т.к. ключевой селектор .ingredient-details__item матчит меньше элементов. Но здесь из-за 2 элементов в селекторе браузер лишний раз проходит по дереву, то есть мы как-бы говорим ему: "лисичка, хромик, деточка-опера, осел выбери-ка нам все .ingredient-details__item, ага, а теперь ещё все .ingredient-details__item которые относятся к .ingredient-details". Устанут детки яблоки перебирать, запыхаются. Этот селектор тоже можно оптимизировать, убрав .ingredient-details он нам не нужен, наш класс .ingredient-details__item и так напрямую относится к .ingredient-details и вне него существовать не может, превращаем из .ingredient-details .ingredient-details__item { } в .ingredient-details__item { } Теперь ключевым селектором является класс, браузер сразу выберет конкретные элементы относящиеся к этому классу, тем самым не будет матчить лишние элементы и лишний раз проходить по дереву. Правила Два главных правила скорости селекторов а значит скорости отрисовки страницы: 1. Скорость селектора напрямую зависит от количества сматченых ключевым селектором элементов. Например: Если у вас на странице будет 9999 span и 9999 .class, скорость у них будет одинаковая. Если у вас на странице будет 5000 span и 9999 .class, селектор по классу будет медленнее. Если у вас на странице будет 9999 span и 5000 .class, селектор по типу будет медленнее. (обычно так и бывает, но вряд ли в таких количествах^^) 2. Скорость селектора зависит от количества элементов в селекторе Например: .ingredient-details span { } отработает медленнее чем просто span .ingredient-details .ingredient-details__item { } отработает медленнее чем просто .ingredient-details__item { } Таблица эффективности селекторов * Украдено с CSS-tricks #main-navigation { } /* ID (Самый быстрые) */ body.home #page-wrap { } /* ID */ .main-navigation { } /* Class */ ul li a.current { } /* Class * ul { } /* Тег (Селектор типа) */ ul li a { } /* Тег (Селектор типа) */ * { } /* Универсальный (Самый медленный) */ #content [title='home'] /* Универсальные (Медленнее медленного) */ Цитата David Hyatt: * Украдено с CSS-tricks Контекстный селектор(селектор потомка) это самый дорогостоящий селектор в CSS. Он ужасно дорогой особенно если он идет вместе с селектором типа или универсальным селектором. Другими словами вот это катастрофа быстродействия: html body ul li a { } Зачем все это? Мы экономим миллисекунды, ну допустим прирост производительности за счет быстрых селекторов будет 200мс. Так и кому полезны эти 200мс? Может просто забить? Ан нет, как вы все знаете, jquery напрямую взаимодействует со страницей то есть когда например мы делаем .animate({"margin-top": "50px"}, "fast"); браузеру придется примерно 50 раз перерисовать страницу чтобы отработала анимация. (но и тут есть свои хитрости конечно) То есть прирост производительности в 200 мс увеличит скорость отработки и плавности анимации, может быть это будет не заметно на небольших страницах с небольшим количеством js, но на страницах больше 30кб с большим количеством анимации это будет ощутимо, даже очень. А в старых браузерах и подавно. Где-то у харисова была заметка что скорость отрисовки страницы, которая была сверстана независимыми блоками(нет медленных селекторов), в ie6-7 увеличилась в 3-5 раз, в ie8 в 2-3 раза, в остальных браузерах меньше но тоже ощутимо. Хочувсезнать: Страница отрисовывается(рендрится) при загрузке, или при работе javascript. Не только селекторами земля полнится На скорость отрисовки страницы влияет множество факторов например глубина DOM. Подробнее в книжке Мациевского "Реактивные веб-сайты". Как конретно померять скорость отрисовки? Вот например так: http://jsfiddle.net/E49EL/1/ http://banzalik.ru/labs/perf-test-classes/perf-test-classes1.html?reflow-meter Правда на разных компьютерах rewlow time будет разным, зависит от самой системы. Дополнительные материалы Та самая, знаменитая статья на 30 000 div'ов http://clubs.ya.ru/bem/replies.xml?parent_id=375&item_no=338&with_parent=1#reply-yacf-375 Firefox отрисовывает страницу CSS-triks про эффективный css http://css-tricks.com/6386-efficiently-rendering-css/ Мозила про эффективный css https://developer.mozilla.org/en/Writing_Efficient_CSS ещё http://www.shauninman.com/archive/2008/05/05/css_qualified_selectors#comment_3942 Видео на английском про эффективность селекторов

Абсолютно, в будущем запретят ставить класс на h2? Ещё раз, медленно, внимательно, инфографика. Ещё раз, медленно, внимательно, инфографика. Тест на длинные слова: вставляешь в любой элемент "очеееееееееееееееееееееееееньдлиннннннннннннннннннннннноесловооооооооооооооооооооооооо" Текст должен не выходить за пределы блока а перескакивать на другую строку. Имеется в виду gracefull degradation, чтобы css3 вещи в старых браузерах отображались упрощенно но красиво. Конкретно по пункту: "Все решения которые можно с fallback'ом реализовать на css3 сделаны на css3" У тебя маленькие кнопочки "+ - ?" сделаны картинкой хотя можно было бы сделать и на css3. Мелочь а неприятно. Окей Почему не будет? "Потому что я так сказал" - psywalker Ну а с остальным ты я вижу согласен.

По каким критериям можно оценить качество верстки? Независимые блоки, oocss, списковая семантика - это все методы, но по каким критериям можно обьективно оценить качество верстки? Есть несколько универсальных критериев: Кроссбраузерность Скорость Количество неэффективных селекторов Количество запросов к серверу за картинками Общий размер картинок Общий размер проекта Экстраразметка Менее значимые вещи: Доступность: Работает без javascript На полях где нужно проставлен required Использование безопасных шрифтов Тест на длинные слова Вместе с input'ом используется <label for=""> (здесь конечно не full WCAG чек-лист, но и этого хватит.) Масштабируемость: Элементы которые должны быть текстом - текст Все решения которые можно сделать с fallback'ом на css3 сделаны на css3 Кнопки тянутся Вот небольшая инфографика по пунктам с сравнением работ exessqd и psywalker.

Шоколад, как говорится, не виноват.

Домыслами оперируешь, я дал форму. Если форма не работает без js это говорит только о профессиональном уровне исполнителя.

Дружище, а объясни вот этот пункт плиз, поподробнее. Знал что ты спросишь. Итак, поподробнее: Семантика. WTF?? Человек визуально может легко понять для чего предназначена та или другая область страницы(будь то навигация, заголовок, область контента, отдельная секция страницы) программе это сделать совсем не просто. Она видит страницу без семантики как сплошной голый текст. Чтобы помочь программам разбираться в текстах для людей и была придумана текстовая семантика: Я <a href="http://ya.ru">ссылка</a><br> Я <em>эмоцианальный</em><br> Я <strong>важный</strong><br> Я <small>второстпенный</small><br> Я <s>неточен</s><br> Я <cite>название работы</cite><br> Я <q>цитата</q><br> Я <dfn>термин</dfn><br> Я <abbr title="Сокращение названия в тексте">Абревиатура</abbr><br> Я <time>время 2009-10-21</time><br> Я <code>код</code><br> Я <var>переменная</var><br> Я <samp>програмный вывод</samp><br> Я <kbd>названия клавиш</kbd><br> Я ^{нижний индекс}<br> Я _{верхний индекс}<br> Я <i>доп-выделение</i><br> Я <b>ключевое слово</b><br> Я <u>замечание</u><br> Я <mark>подсветка</mark><br> то есть элементы разметки отражают смысл содержимого а не его оформление. Оформление нужно людям, программам нужен смысл. В HTML5 пошли ещё дальше и придумали структурную семантику: <section> <nav> <article> <aside> <hgroup> <footer> <address> Чтобы программы могли отличать не только текст но и области содержимого. Кому это нужно? На данный момент это нужно двум типам программ: 1. Альтернативным устройствам (речевые браузеры - тип программ которые читают текст с экрана монитора, для слепых людей) Человек использующий речевой браузер уже сейчас может, на странице размеченной структурными тегами, быстро переходить от одной части страницы к другой не читая при этом весь текст(особенно если это seo текст ^^). 2. Поисковым роботам Чтобы лучше индексировать сайт, пока не работает. Т.е. сейчас причина использовать html5 семантику может быть только одна - чтобы с речевого браузера код был прочитан правильно. Теперь самое интересное "Тестировал ли ты свою верстку в речевом браузере? ^^" ... Конкретно по решению подключить html5shiv(javascript'овый fallback). Зачем было это делать? Ну наверно ты хотел чтобы твои красивые теги можно было стилизовать в старых браузерах(ie8<=). Зачем использовать структурные html5 теги мы вроде разобрались, но тут возникает другой вопрос Если html5 структурные теги нужны только роботам и речевым браузерам, зачем их стилизовать? Ответ: "А почему бы и нет? В старых браузерах будет работать и речевые браузеры не обидим." АВОТНЕТ! Речевым браузерам конечно все равно, но в старых браузерах без javascript или с загружающимся javascript страница будет сломана. Возможные решения? 1. Забить на старые браузеры (использовать теги без html5shiv) 2. Забить на речевые браузеры (не использовать html5 теги) 3. Не стилизовать html5 семантику просто обернуть в неё свой код. Как обернуть? Например так: Было: <article class="content"></article> Стало: <article><div class="content"></div></article> При этом сайт будет доступен для читалок, не ломаться с загружающимся javascript и корректно отображаться без javascript. Собрано из моих старых комментариев.

После драки конечно кулаками не машут, но psywalker 1. 49 запросов к серверу, то есть по запросу за каждую картинку. 2. Полное отсутствие поддержки ie6,ie7. (раз уж отказался от ie6, ie7 спрайт поклеить вдвойне проще - не надо чистить альфа прозрачность) 3. Без javascript форма не то что не раскрывается, она вообще не отображается. (в среднем пользователей без js больше чем пользователей ie6) 4. <!--[if lte IE 8]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]--> - ну еп! - отсутствие понимая зачем нужна семантика html5. Из маленького: 1. Лишний код для каждой отдельной подсказки ошибки. Ну и какбы, конкурс не на javascript, и не на юзабилити, а на html,css и оценивать его стоит только по критериям html,css.

exessqd1 http://t2.promo-mk.ru/iform/index_1.html прямая ссылка

прямую ссылку на свою форму не успел добавить в отдельную тему http://t2.promo-mk.ru/iform/index_1.html прошу перенести.

http://t2.promo-mk.ru/iform/index_1.html

Неа

ну плохому танцору как известно

http://gentleface.com/free_icon_set.html иконки из макета фулсет. Можешь свои добавить, суть не иконках.

Все в макете слой64, слой 71

1. На выбор. 2. Да, переход на следующую вкладку. 3. Двигаться я думаю? 4. Переход на соответствующую вкладку. + состояния :focus,:active,:hover в макете не оформлены, включаем фантазию.

Доработаный вариант формы http://s3.dump.ru/viewer/5384656/

Вот эти 3 все что есть: http://dump.ru/file/5384198 http://dump.ru/file/5384541 http://dump.ru/file/5384542

Доделал форму для конкурса по верстке http://s3.dump.ru/viewer/5384199/ psd здесь http://dump.ru/file/5384198

За юзабилити нужно 1 место отдать d4rk5eed'у

Голос за s0rr0w, но правда где-то посередине.

Запутался куда отправлять работу, спешил ) Будет ли принята работа? http://dump.ru/file/5379905 первое сообщение оставил на у тебя на стене 13:58 москва

Актуальные браузеры?

Футболку давай! нафиг рейтинг...