Comments 47
С таким набором поддерживаемых браузеров можно еще и использование Flexbox добавить. В качестве прогрессивного улучшения, например.
Мы на продвинутом интенсиве это сделаем. Эти критерии для базового — там флексбоксы не разбираем, поэтому не добавили в критерии.
Давно хотел узнать почему такое странное отношение к флексбоксам — все постоянно говорят, что это не для новичков? И выходит что прогрессивный простой интуитивно понятный механизм отодвигается как нечто сложное, а новичкам захломляют мозг этим адом инлайнблоков и флоатов место которым где-нибудь на свалке истории.
Любой новичёк может попасть в «группу поддержки» старого проекта, где о IE6 ещё не забыли, и без понимания того как работают float, inline-block он ничего не сделает.
Flexbox — это магия, он просто работает, и вы не получите используя его (на начальном уровне) представления о том, что представляет из себя веб страница на самом деле, например если говорить о таких вещах как «поток», да и CSS в полной мере вы не поймёте и не начнёте его использовать на 100% без знания основ.
Flexbox — это магия, он просто работает, и вы не получите используя его (на начальном уровне) представления о том, что представляет из себя веб страница на самом деле, например если говорить о таких вещах как «поток», да и CSS в полной мере вы не поймёте и не начнёте его использовать на 100% без знания основ.
Спасибо! Полезно при работе с фрилансом, как список требований и проверочный список.
Насчет «основное должно работать без JS», признаюсь каждый раз задумываюсь. Сложно представить устройство пользователя, на котором выключен JS. Соцсети некоторые синие без него просто не открываются. Я согласен, что если что-то не сработает на сайте компании из-за выключенного JS — это потеря клиента. Но маниакально все все делать/проверять в двух варианта с- без- JS — тоже вопрос.
Наверно, тут нет общего правила.
Насчет «основное должно работать без JS», признаюсь каждый раз задумываюсь. Сложно представить устройство пользователя, на котором выключен JS. Соцсети некоторые синие без него просто не открываются. Я согласен, что если что-то не сработает на сайте компании из-за выключенного JS — это потеря клиента. Но маниакально все все делать/проверять в двух варианта с- без- JS — тоже вопрос.
Наверно, тут нет общего правила.
Общего правила определенно нет. Но опять же, делать «основное должно работать без JS» применимо далеко не к каждому проекту.
Тут явно решает вышестоящая шизофрения. Поскольку это все субъективно, якобы нет js потеря клиента. Да уж фактор так фактор) Вот почему клиенты то уходят) По мне это одна из сотен мелочей, которые можно бесконечно дорабатывать и предполагать заместо статистики, которую собрать почти невозможно. Каким образом может быть отключен JS? ну ну как? Плагин стоит? Вирус? Старая или сломанная аппаратура? Ну клиент значит нищеброд, а это не клиент тогда. Наоборот — в плюс.
Поддержка старого хлама крупнейшими компаниями тянет за собой клубок старого барахла которое вынуждены поддерживать всем миром, компаниями ниже.
Почему нельзя начинать рассуждения о факторе потери клиентов с вероятности ошибок в усложении техническим систем. Чем проще система, тем проще с ней работать тем меньше ошибок она вероятно породит. Чем сложнее система (не значит удобнее клиенту), тем больше времени на нее нужно и как следствие инертность реализации нового сервиса(услуги) увеличивается, а значит клиент ждет. К дизайну практически нет возражений — субъективно нравится начальству — в проект. Тайна привлечения клиентов нарисована, осталось разработчикам не поломать ее.
Ответом тут будет только возможность сотрудника уделять свое время на мелочи все свое рабочее время. И потом он может троллить коллег, дескать ленятся.)) Мне кажется это таится в личном ощущении «хорошо сделанной работы» вот есть миллион факторов которые вы видите, и выполняя 3 года часть в 600 тысяч, сегодня ощущаете их уже как 10 и вам нужна новая рутина для ощущения «хорошо выполненной работы». А если вы делаете множество вещей, особенно разговор с клиентом который может просто вырубить на сутки голову, вам эти 600 000 как весь миллион…
Поддержка старого хлама крупнейшими компаниями тянет за собой клубок старого барахла которое вынуждены поддерживать всем миром, компаниями ниже.
Почему нельзя начинать рассуждения о факторе потери клиентов с вероятности ошибок в усложении техническим систем. Чем проще система, тем проще с ней работать тем меньше ошибок она вероятно породит. Чем сложнее система (не значит удобнее клиенту), тем больше времени на нее нужно и как следствие инертность реализации нового сервиса(услуги) увеличивается, а значит клиент ждет. К дизайну практически нет возражений — субъективно нравится начальству — в проект. Тайна привлечения клиентов нарисована, осталось разработчикам не поломать ее.
Ответом тут будет только возможность сотрудника уделять свое время на мелочи все свое рабочее время. И потом он может троллить коллег, дескать ленятся.)) Мне кажется это таится в личном ощущении «хорошо сделанной работы» вот есть миллион факторов которые вы видите, и выполняя 3 года часть в 600 тысяч, сегодня ощущаете их уже как 10 и вам нужна новая рутина для ощущения «хорошо выполненной работы». А если вы делаете множество вещей, особенно разговор с клиентом который может просто вырубить на сутки голову, вам эти 600 000 как весь миллион…
Общее правило есть. Если базовый функционал может работать без JS, он должен работать без JS. Если контент может быть доступен без JS, то он должен быть доступен без JS. В 90% случаев такая реализация совсем не трудоёмка. Но есть две тонкости:
1. Если JS являются неотъемлемой частью базового функционала (те же Яндекс.Карты), то, конечно, без JS ничего работать не будет. И тут париться не надо.
2. Насколько стоит усложнять базовый функционал, чтобы он был похож на версию c JS. Здесь все тонкости. Пример: магазин пиццы. В нём есть конструктор пиццы на JS (размер, тесто, добавки, пересчет цены и т.д.). Без JS на месте конструктора обычное текстовое поле, куда пользователь впишет «мне маргариту с двойным сыром». Сложно такой базовый функционал сначала реализовать, а затем его расширить на JS?
1. Если JS являются неотъемлемой частью базового функционала (те же Яндекс.Карты), то, конечно, без JS ничего работать не будет. И тут париться не надо.
2. Насколько стоит усложнять базовый функционал, чтобы он был похож на версию c JS. Здесь все тонкости. Пример: магазин пиццы. В нём есть конструктор пиццы на JS (размер, тесто, добавки, пересчет цены и т.д.). Без JS на месте конструктора обычное текстовое поле, куда пользователь впишет «мне маргариту с двойным сыром». Сложно такой базовый функционал сначала реализовать, а затем его расширить на JS?
Да какая потеря клиента, маловероятно.
Кто может отключить JS, тот может и включить его.
У всех остальных он есть.
Кто может отключить JS, тот может и включить его.
У всех остальных он есть.
Очень крутая статья! Спасибо!
А все началось с того, что дизайнеру не нравилось как выглядят иконки на ретина дисплеях.
> Спрайты для изображений или иконочный шрифтУже год используем иконочный шрифт и не разу не пожалели.
Слишком сложное и сомнительное требование, особенно насчёт иконочных шрифтов — очень сомнительная технология
А все началось с того, что дизайнеру не нравилось как выглядят иконки на ретина дисплеях.
А вы специально подготовленный для ретины шрифт используете или свой? Говорят, бывают небольшие проблемы с отображением на ретине.
По началу думали свой шрифт создать, а потом решили использовать готовый сервис для генерации набора иконок (fontastic) на выходе получаем шрифт в разных форматах + файл css для подключения. Провели много тестов. Все современные браузеры отлично все отображают в том числе и мобильные.
Спасибо.
Очень хорошая статья :)
Очень хорошая статья :)
Отличная статья — буду стараться придерживаться этих критериев.
Один вопрос — в разработке своего сайта вы их придерживались сами?
Один вопрос — в разработке своего сайта вы их придерживались сами?
Да, наш выбор — IE10+. Ученикам мы рассказываем, как отбиваться от вёрстки под более старые версии.
Если можно, вкратце. Как отбиваться?
UFO just landed and posted this here
Циферками, договором
Это подходит для больших студий.
Обычный фрилансер из-за завышенных циферек может потерять клиента. Клиент найдет студента Васю, который за скромный прайс сделает поддержку, хоть шестого IE. И заказчику уже будет не важно, что все работает на костылях и в коде полная каша. Потому что заказчик видит только картинку в своем старом браузере, и ему плевать, как и что под капотом.
Я думал, может есть какие-то другие адекватные методы отбиться от старых версий IE.
UFO just landed and posted this here
Про IE6, это я так просто сказал, для примера. На самом деле да, никому это уже не надо.
Но меня интересовал вопрос по фразе из статьи. Чтобы именно IE10+ и не старее. Чтобы Флексбокс можно было использовать. Вот тут какие доводы для клиента могут быть? Я, например, ничего не могу придумать, кроме как: «Мне так удобнее, новая технология позиционирования и пр.». Но заказчику плевать на эти наши флексбоксы и наше удобство.
А договор, это только при личной встрече, что для фрилансера может быть проблемой.
Но меня интересовал вопрос по фразе из статьи. Чтобы именно IE10+ и не старее. Чтобы Флексбокс можно было использовать. Вот тут какие доводы для клиента могут быть? Я, например, ничего не могу придумать, кроме как: «Мне так удобнее, новая технология позиционирования и пр.». Но заказчику плевать на эти наши флексбоксы и наше удобство.
А договор, это только при личной встрече, что для фрилансера может быть проблемой.
UFO just landed and posted this here
Мне тоже приходится на реальных проектах, в большинстве случаев, отказываться от Флексбокса. Именно из-за желаемой поддержки IE8 или 9. Но, что касается необкатанности и костылей, то не согласен. Вполне все адекватно работает. Префиксы не забывать просто и все. Разумеется, это пока не для больших проектов. Но для среднестатистического лендинга вполне подходит.
По поводу почты. Побойтесь Бога, какая почта? Грубо говоря, на FL или Фрилансим заказ на верстку лендинга за 3–4 тысячи, дедлайн вчера. Ну и какие тут договора и почта. Электронная еще может быть.
Все таки вы, вероятно, имеете в виду более серьезные проекты «под ключ», со сроком сдачи не меньше месяца.
По поводу почты. Побойтесь Бога, какая почта? Грубо говоря, на FL или Фрилансим заказ на верстку лендинга за 3–4 тысячи, дедлайн вчера. Ну и какие тут договора и почта. Электронная еще может быть.
Все таки вы, вероятно, имеете в виду более серьезные проекты «под ключ», со сроком сдачи не меньше месяца.
Можно подумать, что это заказчики такие прям дураки.
Да заказчики просто смотрят статистику и видят, что ие 8 и 9 все еще дорого игнорировать.
Да заказчики просто смотрят статистику и видят, что ие 8 и 9 все еще дорого игнорировать.
UFO just landed and posted this here
Это критерии для базового интенсива, мы в них не включаем то, что на базовом не разбираем. А вот на продвинутом расширим критерии, добавив адаптивность, БЭМ, SVG, Flexbox, оптимизацию.
Префиксы же штука универсальная, они для новых фич всегда будут появляться, поэтому принцип их использования надо знать.
Будем признательны, если вы напишете, какие критерии уже не актуальны, мы их переработаем.
Префиксы же штука универсальная, они для новых фич всегда будут появляться, поэтому принцип их использования надо знать.
Будем признательны, если вы напишете, какие критерии уже не актуальны, мы их переработаем.
Смущает несколько моментов.
К чему такая принципиальность и требование к использованию нормалайза, либо резета? Как показывает практика от этого куда больше головной боли, ежели чем пользы. Да, я не отрицаю того, что в нём есть доля пользы, но как по мне куда проще рассказать, что действительно стоит изначально обнулить, а остальное можно бы и оставить, тогда человек хоть будет уметь различать базовые состояния тэгов и их стили уже после переопределения. И очевидный минус в том, что стили определённые нормалайзом всё равно по ходу верстки переопределяются, итого получается двойное переопределение.
Почему нигде не упоминается о гифах, которые тоже имеют право на жизнь.
Давайте посмотрим правде в глаза — Стайлгайд — это миф =)) Он практически всегда бывает, если разработка ведётся над одним проектом, но если же это поток сайтов, которые требуется верстать, то его можно увидеть в одном из десятка сайтов.
Так же не встретил ничего касаемо — доктайпа, мета, медиакверис.
К чему такая принципиальность и требование к использованию нормалайза, либо резета? Как показывает практика от этого куда больше головной боли, ежели чем пользы. Да, я не отрицаю того, что в нём есть доля пользы, но как по мне куда проще рассказать, что действительно стоит изначально обнулить, а остальное можно бы и оставить, тогда человек хоть будет уметь различать базовые состояния тэгов и их стили уже после переопределения. И очевидный минус в том, что стили определённые нормалайзом всё равно по ходу верстки переопределяются, итого получается двойное переопределение.
Почему нигде не упоминается о гифах, которые тоже имеют право на жизнь.
Давайте посмотрим правде в глаза — Стайлгайд — это миф =)) Он практически всегда бывает, если разработка ведётся над одним проектом, но если же это поток сайтов, которые требуется верстать, то его можно увидеть в одном из десятка сайтов.
Так же не встретил ничего касаемо — доктайпа, мета, медиакверис.
UFO just landed and posted this here
Какой то странный комментарий… Лучше бы ничего не писали. Речь шла о нормалайзе, о нём я и написал.
UFO just landed and posted this here
Кажется вам просто скучно и нечего делать, и вы спамите абсолютно всем комментариями, при чём по делу и без.
UFO just landed and posted this here
Нет уж извиняйте, разница довольно таки большая между «самописными или нет». Одно дело — когда вы не знаете как привести стили сайта к кроссбраузерному виду и слепо лепите целый reset.css файл. Другое дело, когда вы знаете тонкости поведения того или иного тэга, можно основу взять даже ваш пример, где можно обойтись простым input, textarea, button { font-family: Arial;}, а не подключать целый css ради этого…
И я думаю, что любой продвинутый верстальщик (фронтэндер) с опытом составляет свой шаблон для старта вёрстки, в котором прописаны корректировочные стили.
И я думаю, что любой продвинутый верстальщик (фронтэндер) с опытом составляет свой шаблон для старта вёрстки, в котором прописаны корректировочные стили.
1/4 от текста — набор мифов.
Сильно не вычитываю, на вскидку, попробуем оценить некоторые перлы:
>Один стилевой файл на все страницы
Жесть. Вы при обучении не рассказывает о препроцессорах, сбрщиках CSS и всех заставляете все топтать в 1 пузатый CSS файл?
>… как отбиваться от вёрстки под более старые версии.
Корпоративные клиенты всем расскажут как отбиться от вас…
>Ссылки сделаны не тегом , а другими тегами.
Простите, а каким ещё тегом можно сделать ссылки?
>Нельзя использовать !important в CSS.
В ООН и W3 консорциуме стоит его вообще запретить, навсегда
>Необходимо подключить все скрипты непосредственно перед .
Жесткач… А все ли и обязательно до body?
Сильно не вычитываю, на вскидку, попробуем оценить некоторые перлы:
>Один стилевой файл на все страницы
Жесть. Вы при обучении не рассказывает о препроцессорах, сбрщиках CSS и всех заставляете все топтать в 1 пузатый CSS файл?
>… как отбиваться от вёрстки под более старые версии.
Корпоративные клиенты всем расскажут как отбиться от вас…
>Ссылки сделаны не тегом , а другими тегами.
Простите, а каким ещё тегом можно сделать ссылки?
>Нельзя использовать !important в CSS.
В ООН и W3 консорциуме стоит его вообще запретить, навсегда
>Необходимо подключить все скрипты непосредственно перед .
Жесткач… А все ли и обязательно до body?
«Абзацы должны быть абзацами, а не <br><br>.» Я тоже так считаю, но почему все посты на хабре отбырбырены?
FYI Критерии качества, связанные с Section 508 [1], могут оказаться весьма полезными даже, если к Веб-сайту и не предъявляются повышенные требования для обеспечения возможности взаимодействия с людьми с ограниченными возможностями. Например, отдельные критерии из этого списка [2] могут весьма положительно повлиять на качество большинства Веб-сайтов.
[1] en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973
[2] webaim.org/standards/508/checklist
[1] en.wikipedia.org/wiki/Section_508_Amendment_to_the_Rehabilitation_Act_of_1973
[2] webaim.org/standards/508/checklist
> Допускаются различия в 5 пикселей по высоте и 2 пикселя по ширине.
в реальной жизни дело приходится иметь как правило скорее с набросками, без особо дотошного выравниванивания по сетке, странной высоты строки и прочих прелестей. Когда начинаешь такое верстать ты либо пытаешься причесать все косяки дизайнера и внести какую-то логику в код, либо запиливаешь все сомнительные места в пикселях.
Второй подход это то, от чего нужно сразу избавляться.
в реальной жизни дело приходится иметь как правило скорее с набросками, без особо дотошного выравниванивания по сетке, странной высоты строки и прочих прелестей. Когда начинаешь такое верстать ты либо пытаешься причесать все косяки дизайнера и внести какую-то логику в код, либо запиливаешь все сомнительные места в пикселях.
Второй подход это то, от чего нужно сразу избавляться.
Нельзя использовать вложенность селекторов больше двух.
Как по мне, это странное ограничение. Лучше пусть будет множество вложений, но часто используемые слова не должны быть классами первого уровня. Как то .right, .left или .hidden весьма чётко ограничены и не должны быть трактованы иначе, кроме
float:left, float:right, display:none
ul.mymenu>li>ul>li { }
UFO just landed and posted this here
Всё остальное в PNG.
SVG умышленно или случайно не указан?
Sign up to leave a comment.
Что такое хорошо: как мы разрабатывали критерии для оценки качества вёрстки веб-проектов