Parse error: syntax error, unexpected ';' in /home/indigita/indigital.com.ua/www/wp-includes/pomo/translations.php(208) : runtime-created function on line 2
Web Standarts Days 2014 отзывы indigital.ua
Loader
Меню

ru

ua

en

code, верстка, Журнал, команда, стартап

Команда indigital.ua на Web Standarts Days 2014 Часть 1

Наши впечатления после

1522
4
следующий пост следующий пост

Прежде всего хочется сказать огромное спасибо выступавшим с докладами, организаторам и спонсорам небольшого праздника под названием “Web Standards Days” который прошел в Киеве, 6 декабря, в отеле “Турист”.

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

1. Вадим Макеев(@pepelsbey) и его доклад “Сколько нужно верстальщиков, чтобы вставить тег picture?”

Приятный флешбэк в прошлое относительно тега img. И вполне риторический вопрос, почему же данный тег устарел?

Ведь, если так разобраться: picture = img и надстройки(с)

К слову, отвечая на вопрос доклада, ответ: один вестальщик, но думающий(с) Небольшая ремарка: данный вопрос возник на основе шутки про поляков и лампочку.

Ключевой вопрос, а нужен ли Вам picture вообще?

Давайте узнаем, пройдясь по чеклисту: 1) будет ли поддержка ретины? 2) будет ли адаптивность? 3) формат! Что значит, будем ли мы использовать прогрессивные вещи как .webp? 4) будем ли мы кадрировать?

Чеклист имеет название РАФК(Ретина Адаптивность Формат Кадрирование). Громко, серьезно, круто!

В первых двух случаях мы даже не задействуем тег picture, а лишь пользуемся аттрибутами srcset и sizes.

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

Сложно не упомянуть предложенные автором плюшики: Sizer Soze - сайт позволящий определить сколько можно сэкономить в размере страницы используя правильные изображения отталкивая от вьюпорта браузера. Очень полезный инструмент для разработчиков. Picturefill

- JS библиотека позволяющая дать поддержку picture для старых браузеров. Чудестный инструмент. Статья на frontender magazine об элементе picture. Ссылка на саму презентацию.

Поехали далее. Следующий доклад:

2. Евгений Исаков(@is4kov) и его “Правила хорошего тона в HTML и CSS”

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

Невероятно крутое фото, которое поднимает настроение! :)

Смешное фото для поднятия настроения

Взято из самой презентации. Так что плюсик к кармочке автора :) Ключевые моменты: 1) читайте документацию ребята. Вы программисты или кто? 2) пользуйтесь гайдлайнами по вашему языку и принятыми правилами написания кода внутри вашего коллектива(если он есть конечно) 3) не ленитесь сделать качественный код. Костыли не выход 4) именования. Это боль и печаль смотреть на b-box-top-ispravit-bag. И все же, пишите понятно 5) пишите документацию! А еще лучше, пишите самодокументируемый код

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

А вот и ссылочка на статью. Рекомендуется любому фронт-энд деву, если не ради знаний, то чтобы просто не ржаветь.

3. Игорь Зенич(@delaz) и его: “Пишем БЭМ правильно”

Забудьте все что вы знаете о БЭМ. Вы ничего не знаете о БЭМ. Даже не так, просто процитируем автора:

“Вы совершенно не понимаете сути БЭМ. БЭМ — это не фреймворк «клац-клац и в продакшн». БЭМ — это не длинные CSS-классы. БЭМ — это не религия. БЭМ — это, в первую очередь, паттерн. Паттерн мышления и разработки. Но за 6 лет о нём нигде так и не написали понятным языком с примерами верстки обычных маленьких сайтов без BEMJSON, BEM Tools и вот этого вот всего. Я расскажу вам о своём 3-летнем опыте внедрения и использования БЭМ для жестокого мира аутсорса и про те грабли, на которые мы наступали”(с)

Без этого фото из доклада, просто нельзя дальше продолжать! :) Шикарная иллюстрация реакции публики

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

Ключевые моменты: 1) префиксы в БЭМ без БЭМ инструментов 2) сокращенные модификаторы 3) JS-блоки

Важным будет упоминание, реальных вещей по БЭМ: Сапегин Ребята из iDeus о БЭМ

Автор обязательно дополнит этот список, а мы двинем далее.

Так же, интересным к прочтению будет история Виталия Харисова из Яндекс: Виталий Харисов "История создания БЭМ. Кратко, сбивчиво и неполно.

А этот вопрос засел на долго: “Как назначаются стили для типографики? Не будешь же назначать каждому тегу какой-то класс?”(с) Artur Kornakov

Ответ, к которому я пришел отличается от ответа данного автором и от ситуации в Яндексе. Но это уже другая история.

Плюс обязательно ждем статьи автора в Frontender Magazine.

И, конечно же, сама презентация.

4. Роман Лютиков(@roman01la) и мега крутой доклад: “Доступный веб для всех”

Один из тех, докладов, который только становится актуальным в реалиях русскоговорящего интернета и не только, а где-то, в далеке уже нормирован, как минимум в государственной плоскости.

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

“Минимальная доступность всегда лучше чем ее отсутствие”(с)

-Дорога ли доступность? Нет, если внедрить ее сразу!

-Кто отвественнен за доступность? Нет, не только программист. Дизайнер, программист и контент менеджер и не только. Это групповая отвественность.

Какие есть программные решения: 1) увеличения изображения экрана 2) экранный диктор 3) инвертирование цвета 4) повышение контраста

Чем можно помочь при разработке: 1) обеспечением доступа с клавиатуры 2) понятной навигацией 3) легко читаемым текстом 4) правильной семантикой содержимого 5) совместимостью с другими инструментами

Отрекомендуем проект Романа: доступність.

И, конечно же, полный материал по ссылке.

Поделись

предыдущий пост предыдущий пост