Skip to content

Latest commit

 

History

History
128 lines (73 loc) · 13.1 KB

notes.md

File metadata and controls

128 lines (73 loc) · 13.1 KB

Жизнь полна сопадений. Как только я понял, что хочу сделать этот доклад, кто-то раскопал релиз сайта авиакомпании Ryanair и среди сообщества пробежали ссылки на их 3+ mb css.

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


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


Я недавно с Антоном Немцевым, чей доклад будет чуть позже, судил работы верстальщиков в UA web challenge — собственно как раз сегодня финал и пока все будут на афтепати мне прийдется еще попотеть и проверить финалистов.

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

Я всегда говорю, что профессия верстальщика вымирает, с чем многие несогласны.

Я попробую объяснить: сегодня недосаточно просто сверстать.

Когда-то это было очень важное умение — потому что нужно было хорошо знать отличия и хаки для разных браузеров, нужно было понимать как сверстать документ и логично, и валидно и с минимальных количеством экстра-разметки, которая используется только для оформления и еще добиться потом pixel perfect результата — титанический труд.

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

Одновременно выходит множество инутрументов: сборка, пре/пост процессинг, менеджеры пакетов, css-библиотеки, методологии — все это упрощает работу, но во всем нужно разбираться и разбираться хорошо. Если ты используешь инструмент, ты должен понимать как он устроен.

И так как с браузерами разбираться стало полегче, то верстка как профессия потихоньку расползается на дизайнера, результат работы которого прототип проектка на html/css/js или фронтенд разрабочтика, который одновременно пишет клиентский js, шаблоны, работает с API, разбирается в сборке, иногда еще пишет серверный код в рамках node.js.

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

Поэтому я считаю, что профессия вымирает, рынку не нужны люди, которые просто знают CSS.

И, внимание, сейчас важный момент — именно поэтому теперь CSS плохо знают намного больше людей, чьей профессией является в том числе и CSS, чем во времена до расцвета CSS3.

Лично я вижу в этом большую проблему.


Сейчас никто не пишет просто CSS и потому не всегда осознают результат. Вспомнили все файлик в начале.

Вторая часть проблемы: тот кто пишет css должен заниматься еще многими другими вещами, чтобы получать за это деньги. А значит его фокус будет постоянно смещаться в связанные технологии.

Я уверен, что профессиональный фроентенд разработчик должен знать CSS на очень высоком уровне, даже если в основном он пишет JS.

Точно также как понимать как работает браузер — прекрасный доклад был на эту тему на ХарьковJS и вопросы показали, что далеко не все понимаю как работает бразуер

Точно также как понимать что такое вебсервер и как его настраивать, как работает http, какие сбособы кеширования есть.

Оптимизация кода и статики — это вообще самая распространенная недоделка в работах, которые мы оценивали, почти никто не почеслася прогнать огромные картинки через оптимизаторы.

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


Камень предкновения, вечный вопрос: делать на css или на javascript.

  • Анимировать ли мне с помощью jquery или с помощью css анимаций?
  • Стоит ли мне рассчитать размеры этого элементы в js или установаить фиксированные размеры в css и надеятся что контент их не переполнит?
  • как показать попап: на css или js?
  • http://codepen.io/tyv/pen/rOVRrZ ... Это вечная борьба, сюда уверен каждый из вас допишет множество примеров.

Но только человек с хорошими знаниями и javascript, и css, и главное с приличным опытом ответит на эти вопросы правильно. Потому что нужно очень много понимать: от того насколько понятным будет ваше решение, до того насколько оно может стать bottle neck производительности вашего проекта.

Поделюсь наблюдением. Все-таки в большинстве случаев это CSS :) Если что-то можно сделать с помощью css и это не выглядит костылем — лучше это cделать с помощью CSS.


Как часто в проекте, где вам не нужно поддерживать старые браузеры вы использовали основанный на float или инлайн-блоках лэйаут только потому что у вас уже подключен какой-то фреймворк?

Это прямо болезнь — в CSS появляется функциональность, часто под давлением нас — разработчиков, и даже когда она поддерживается хорошо или же есть приемлемый способ деградировать (а в случае с флексбокс вообще проще некуда) — мы все равно хотим делать по старинке, потому что мы точно знаем как это работает.

В итоге я сегодня встречаю градиентные кнопки сверстанные картинкой.

Но зато спрайтом — чувствуйте иронию!


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

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

Основные проблемы с препроцессорами:

  • variables склонны иметь коллизии имен, особенно при использовании библиотек
    • ./examples/preprocessors/variables
  • mixin провоцирует дублирование свойств
    • /examples/preprocessors/mixins
  • extend провоцирует дублирование селекторов
    • ryanair.css
  • nesting провоцирует делать селекторы слишком специфичными, что становится тяжело поддерживать, когда вы хотите модифицировать какой-то элемент в зависимости от контекста
  • препроцессоры провоцируют программировать на css
  • для дебага нужна дополнительня инфраструктура с сорс-мапами

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

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

Если же ты пишешь так только потому, что только так и умеешь, то это повод взять старого доброго Мейреа и прочесть.


Ну вот, я наборсил, с первой частью покончили.

Теперь давайте поговорим о том, что нас ждет и что нужно изучать и понимать уже сейчас.

И начнем с внезапного. Я вам расскажу как происходит вертикальное выравнивание в анонимной строке.

Вы сейчас такие: чтоооо? Но уверен для многих случится небольшое откровение.

// demo


Давайте поговорим что нас ждет. А главное как нам понимать что нас ждет.