понедельник, 28 января 2013 г.

Прижимаем футер к низу

Есть много вариантов прижатия футера к низу, большинство из которых заточены под корректную работу в ие6-7. Из-за этого они выглядят немного костыльными: либо добавляется пустой тег, либо указывается фиксированная высота футера.

Отказ от поддержки ie7 позволяет использовать гораздо более элегантное решение для прибития футера, которое основано на использовании свойства display: table/table-row.

Подсмотрено тут:

HTML


<div class="wrapper">
    <div class="content">
        <h2>Content</h2>
        <p>Lorem Ipsum is simply dummy text of the printing and
           typesetting industry. Lorem Ipsum has been the
           industry's standard dummy text ever since the 1500s
           when an unknown printer took a galley of type and
           scrambled it to make a type specimen book. It has
           survived not only five centuries, but also the leap
           into electronic typesetting, remaining essentially
           unchanged. It was popularised in the 1960s with the
           release of Letraset sheets containing Lorem Ipsum
           passages, and more recently with desktop publishing
           software like Aldus PageMaker including versions of
           Lorem Ipsum.</p>
    </div>
    <div class="footer">
        <h3>Sticky footer</h3>
        <p>Footer of variable height</p>
    </div>
</div>

CSS


html, body {
    height: 100%;
    margin: 0;
}
.wrapper {
    display: table;
    height: 100%;
    width: 100%;
}
.content {
    display: table-row;
    height: 100%;
}
.footer {
    display: table-row;
}

вторник, 8 января 2013 г.

Вендорные префиксы

Что такое вендорные префиксы знают все!
Вкратце: вот они родимые (основные):
  • -o- (Opera Software)
  • -moz- (проект Mozilla)
  • -ms- (Microsoft)
  • -webkit- (Apple)
Есть и другие, малоизвестные и не столько популярные, но нам для рассмотрения с головой хватит и этих. Думаю, никто не обидится, если я назову их "костылями"? Итак:

Стоит ли использовать префиксы?

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

Прежде чем кивать головами как собачки на панелькой доске, предлагаю обсудить несколько моментов. Начнем с истоков:

Спецификации и W3C

Префиксы появились в те далекие времена, когда спецификация CSS 2.1 сказала, мол, вот вам индикаторы, пусть они начинаются с "-" или "_", играйтесь на здоровье, это будут ваши персональные, уникальные свойства! И браузеры подумали: "Ачуметь! Дайте две!" Нет, конечно же браузеры не могут думать, если под словом "думать" не подразумевать искусственный интеллект и все такое. Подумали и обрадовались разработчики браузеров, что они могут извращаться по полной, и привнести это в свои детища!

Идея была отличная! На тот момент. Но крайне недальновидная.

Потихоньку начали появляться реализации новых свойств css3. Они появлялись в то время, как спецификации css3 ещё не было, не было даже кандидатов релизы, но об этом уже все говорили. Все ждали CSS3 спасения нововведений и уже начали внедрять новые свойства как модно нынче писать "на свой страх и риск".

Но, как мы знаем, воз и ныне там? w3c не торопилась: то ли из желания впихнуть максимум в новую 3-ю версию, то ли из желания угодить всем, то ли из-за собственной огромной неповоротливости.

Так вот, браузеры начали обзаводится новыми свойства со своими персональными префиксами. Типа и овцы целы, и волки сыты (и новые свойства есть в браузере, и спецификации не противоречат). Парадоксально, но именно благодаря этому браузеры стали на шаг впереди спецификации. И тут на горизонте появляется еще один вопрос: при такой сумасшедшей популярности новых свойств, стоило ли их писать с префиксами?

Рассмотрим несколько вариантов развития сюжета на примере border-radius.

Исходные данные: это новое свойство и его ни у кого ещё нет.

Вариант 1.
Один браузер решил, что это будут выпуклые уголки и реализовал у себя со своими персональными префиксами.
Будут ли верстальщики его использовать? Нет. Зачем использовать то, что работает только в одном браузере, тем более, что с костылем? Потому что для остальных надо по-прежнему использовать картинки.

Вариант 2.
Один браузер решил, что это будут вогнутые уголки, а не выпуклые. Сказано - сделано!  А потом другие браузеры это внедрили у себя, только с выпуклыми уголками. Первый браузер-бедолага посмотрел на это дело, подумал, как он нехило лоханулся и в следующем своем релизе поменял вогнутость на выпуклость. Всё равно на данном этапе разработчики не использовали бы данное свойство, а если бы использовали и ругались на неадекватность, то, как модно сейчас писать, "на свой страх и риск", да и вообще какие претензии? Самое главное, что браузер (ну вы поняли, что за ним стоят пчелки-программисты) осознал свою ошибку и исправился.

Вариант 3.
Несколько браузеров реализовало это свойство разными методами. Более сложный случай варианта номер 2. Пока что гипотетический, я еще не встречала настолько разную реализацию. Но в этом случае придется договариваться. Сложно, больно, но что делать? Именно для этого есть официальная спецификация, так что такие сложности можно было бы оставить до выхода кандидата в релизы.

Вариант 4.
Идеальный вариант, когда несколько браузеров одинаково реализовали каждый у себя со своим префиксом. Возникает вопрос: почему бы им изначально не использовать новое свойство без префиксов? Вы скажете, что на это нет спецификации. Ну так ее может и не быть ещё очень долго, но в действительности мы получаем следующие конструкции:

.box_rotate {
  -webkit-transform: rotate(7.5deg);  // Safari 3.1+, Chrome 
     -moz-transform: rotate(7.5deg);  // Firefox 3.5-15 
      -ms-transform: rotate(7.5deg);  // IE9+ 
       -o-transform: rotate(7.5deg);  // Opera 10.5-12.00 
          transform: rotate(7.5deg);  // Firefox 16+, Opera 12.50+ 
}

Т.е. по сути все поняли правильно, просто им сложно отказаться от префиксов или они боятся ошибиться, но в этом нет ничего плохого. Как я уже писала, не страшно ошибиться, главное уметь признать ошибку.

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

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

Сложности первой реализации

Под первой реализацией будем понимать первую реализацию нового свойства у браузера. И сложность состоит в том, что каждый браузер имеет свое видение. Вспомним пример про вогнутые и выпуклые уголки border-radius. Но это вымышленный пример, лучше посмотрим на реальный: поле даты с выпадающим календариком (прощай datepicker.js!):

<input type="date">

Как это выглядит на данный момент в винде:

Chrome:
Opera:
Safari:

Как мы видим, у каждого своя реализация. Сафари вообще не подумала о выпадающем списке, а две дурацкие "кнопочки" просто листают дни (примечательно, что в <input type="datetime-local" value="2013-01-06 12:01:00"> они листают минуты ^_^). На самом деле это неважно! Это первая, "прикидочная" реализация. И ничто не мешает поменять в следующих версиях, расширить добавить стилизацию через css.

Прелесть html в том, что у них нет "префиксов" и никого это не смущает. Если появится некий стандарт на данную форму, то они просто его внедрят! Всё просто. Css есть чему поучиться ;)

Валидация

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

Валидация предназначена для того, чтобы писать правильный код. Но разве она может проверить код на то, что он "с душком"? К тому же отвалидированный код не гарантирует, что сайт будет правильно отображаться и функционировать.

Лет 10 назад было модно ставить на свой сайт значки w3c css & html validation. Сейчас же этим никто не заморачивается.

Поддержка чужих префиксов

На данный момент возникает ещё одна абсурдность, когда браузеры начинают поддерживать чужие префиксы. Так, например, Opera заявила, что будет поддерживать -webkit-.

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

Даже w3c рассматривают как стандарт поддержку префикса -webkit всеми браузерами!
Это epic fail префиксов. Из некогда прогрессивной идеи они превращаются в довольно грубый артефакт, от которого следовало бы избавиться.

Сложность поддерживать префиксы

Если посмотреть на историю развития браузеров, то она будет пестрить и префиксами (с различными вариантам, вспомним фильтры в ie7 и ie8), и "чистыми" css-свойствами.

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

Хочу отметить, что эта сложность в первую очередь для разработчиков браузеров, а не для верстальщиков. Мы уже привыкли использовать less/sass, что даже не задумываемся о том, нуждается ли данное css-свойство в уточнении префиксом или нет. Мы пишем следующие конструкции и порой перегружаем код парой ненужных свойств:

@mixin experimental($property, $value) {
  -webkit-#{$property}: $value;
     -moz-#{$property}: $value;
      -ms-#{$property}: $value;
       -o-#{$property}: $value;
          #{$property}: $value;
}

@mixin border-radius($radius) {
  @include experimental(border-radius, $radius);
}

@mixin box-shadow($bs) {
  @include experimental(box-shadow, #{$bs});
}

Будущее, в котором нет префиксов

Итак, что мы имеем на данных момент:

Если посмотреть на те css3-свойства, которые мы уже сейчас используем: css3please.com, то станет ясно, что браузеры правильно и одинаково понимают их. А это значит, что мы развиваемся почти по 4-му идеальному варианту.

.box_gradient {
  background-color: #444444;
  background-image: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999)); // Safari 4+, Chrome
  background-image: -webkit-linear-gradient(top, #444444, #999999); // Chrome 10+, Safari 5.1+, iOS 5+
  background-image:    -moz-linear-gradient(top, #444444, #999999); // Firefox 3.6-15
  background-image:      -o-linear-gradient(top, #444444, #999999); // Opera 11.10-12.00
  background-image:         linear-gradient(to bottom, #444444, #999999); // Firefox 16+, IE10, Opera 12.50+
}

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

Новые свойства с префиксами? Fuuuuu!!!

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

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

1. filters
Позволяют применять простые фильтры как к изображениям, так и блокам (первое изображение - оригинал):

img { -webkit-filter: brightness(-30%); }
img { -webkit-filter: grayscale(100%); }
img { -webkit-filter: sepia(100%);     }
img { -webkit-filter: blur(3px);     }
img { -webkit-filter: invert(100%);     }


2. masking
Маскирование, тут всё понятно из названия и наглядно из примера ниже:

.mask {
-webkit-mask-box-image: url(mask.png);
}


В целом ужасно хотелось бы посмотреть на css лет эдак через 5.
Станет ли он похож на язык программирования? Введут ли переменные? Что из яваскриптовых функций он перетащит в себя?

Пока ясно одно: не нужно бояться экспериментировать и не нужно тащить артефакты прошлого.


HACK-week и pageless

HACK-week

Хак-вик - это неделя свободной разработки в рамках проекта. Очень простая, но замечательная идея, которая состоит в том, чтобы отречься от рутины и заняться тем, чем всегда хотелось, но никогда не доходили руки. Это может быть что угодно:
  • рефакторинг (небольшие улучшения, на которое никогда не хватает времени в режиме надо срочно-срочно)
  • добавление нового функционала с использованием новых библиотек
  • улучшение старого с новыми технологиями, возможно, с другой бд
  • добавление тестов или тотальная переработка существующих
  • увеличение быстродействия проекта
  • и многое-многое другое, что, возможно, хотелось бы пощупать применительно к данному проекту.
Хак-вик - это возможность найти для себя что-то интересное и воплотить в жизнь.
На мой взгляд это отличная практика, это возможность почувствовать себя не только карандашом в руке заказчика, но и архитектором. Появляется более трепетное отношение к проекту, как к своему детёнышу. Появляется соучастие и сопереживание, то, о чем говорил Тим Леберехт ("Как правильно терять контроль над своим брендом").

Ты из кодера превращаешься в Создателя минимум на три недели. Почему три? Потому что минимум неделя, а то и две до хак-вик можно потратить на придумывание Идеи: чем же можно заняться. Идея должна быть привлекательной для заказчика. Она не должна быть слишком сложной, чтобы успеть справиться за неделю, но и не слишком простой; достаточно интересной, чтобы чувствовать энтузиазм и удовлетворение по её завершению.

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

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

Лично для меня это была моя самая продуктивная неделя.

Pageless

На своем первом хак-вик я выбрала несложную задачку: добавить бесконечную прокрутку, т.е. автоматическую подгрузку данных, как это происходит в твиттере.
Я использовала явасриптовый плагин pageless, который отлично интегрируется с рельсами. Хотя пришлось дописать некоторые вещи:
  • добавилась кнопка "Show more results", явно предлагающая пользователю показать остальную часть данных, которые в дальнейшем будут автоматически подгружаться при прокрутке
  • при бесконечной прокрутке для табличных данных хорошо оставлять шапку вверху (здесь отдельные благодарности, симпы и лафки тегу thead)
  • и соответственно добавление кнопки 'To top', которая перенесет пользователя в верх страницы в случае, если он просмотрел уже большое количество данных.

Update:


О результате: http://blog.buyfolio.com/can-you-hack-it/

пятница, 4 января 2013 г.

Лучшее из 2012

IT событие
KyevJS конференция
Событие
Zillow приобрела Buyfolio
Курсы
"Software Engineering for SaaS" on www.coursera.org
Приложение
Reader128k
iPhone приложение
Instagram
Инструмент
Sublime Text 2
Инструкция по эксплуатации
Samsung
Гаджет
iPad mini
Ожидание
Samsung Galaxy Camera EK-GC100
Фильм
"127 Hours" (2010)
Книга
Стивен Хокинг. Краткая история времени от большого взрыва до черных дыр (1988 г.)
Музыка
PSY - GANGNAM STYLE
Ачивки
Получить легендарку "Клыки Отца" и бросить WoW = completed!
Разочарование
Современное искусство: в Изоляции, выставка в Грин-Плазе и галерее «АртДонбасс»
Впечатление
Красная пещера в Крыму
Город
Одесса

Команды Emacs

При работе в консоли мы используем команды Emacs, но редко когда что-то сложнее [CTRL-R] для поиска по истории. Хотя зачастую возникает неп...