Илья Пестов

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

У вас позиция (top или bottom) не установлена, следовательно при появлении свойства fixed положение на странице остается прежним, вот только отсчет ведется уже относительно окна браузера.
Без fixed (при узком браузере) расстояние до начала верстки 430 пикселей, после скролинга (при появлении fixed), top не устанавливается, следовательно 430 пикселей остается, но уже от окна браузера.

Я не применяю выравнивание с помощью top/right, top/bottom

а надо. Если присвоить top, то всё нормально становится.

А логика простая, начальные координаты position берутся относительно родителя, и по скольку aside на разном разрешении у тебя находится на разной высоте(из-за хэдера) по отношению к окну браузера/начала страницы, то position забирает эти координаты. Как-то так получается.

сглаживание шрифтов настраивается в ОС для kde например настройки в application appearance > fonts
ну и сам браузер сглаживать может (Opera)
также имеет значение порядок подключение веб шрифтов, попробуйте такой порядок

@font-face {
    font-family: 'Conv_Cuprum';
    src: url('../fonts/Cuprum.eot');
    src: url('../fonts/Cuprum.eot?#iefix') format('embedded-opentype'),
         url('../fonts/Cuprum.svg') format('svg'),
         url('../fonts/Cuprum.woff') format('woff'),
         url('../fonts/Cuprum.ttf') format('truetype');
         
    font-weight: normal;
    font-style: normal;
}

«Сколько стоит дом построить?»

Нет тут никаких «среднестатистических цен». Всё зависит от опыта разработчика, качества верстки (ее всё равно переверстывать под темплейты друпала) и «цены за час работы» конкретного разработчика.

Я бы оценил примерно так (при адекватной верстке):
1. 4-8ч
2. 4-8ч
3. 8-16ч
4. 8-16ч
5. 8-16ч

Итого 32-64ч или 4-8 рабочих дней, или (при сверической зарплате в вакууме в 80к) 29-58к рублей.

Так что моя «средняя цена» за всё — $1000-2000 в зависимости от подробностей ТЗ и качества вёрстки

Я не дизайнер, а программист, поэтому напишу немного с программистской точки зрения:
Как я понимаю, основной профит модели с выделенной компонентой lightness, например, заключается в возможности легко её варьировать. Т.е. если Вы задаёте цвет в RGB, то задать его же, но чуть темнее довольно сложно, а в моделях с выделенной яркостной составляющей гораздо проще.

Например: возьмём цвет #79D312. Ему соответствует HSL(88, 84, 45). Если мы увеличим lightness на 5, то получим #86EA14, что даже не близко к исходному RGB значению.

Соответственно, принцип работы приведённой Вами строки весьма прост — это затемнение исходного цвета.

Выше было правильно сказано, попробую дополнить.

Вы создаете ДОМ(calenderTrasform) и присваиваете margin-left / width в одном и том же event tick. И грубо говоря, ваш новый html приходит в live DOM уже с margin-left / width — то есть, браузер не фиксирует эти изменения, поэтому и не вызывается transition. А используя setTimeout, вы переносите присваивание margin-left / width в следующий тик в event loop — и после того, как ваша функция «клик» отработает, браузер между делом «познакомится» с новыми нодами в доме, и когда функция по таймеру изменит margin-left, браузер это зафиксирует и запустит transition. И таймер в данном случае является оптимальным решением — a без нужно браузер заставить пересчитать стили:

// ...
$('.calendarBody').html('<div id="calendarTransform">'+content+'</div>');
var $transform = $('#calendarTransform'),
       styles  = getComputedStyle($transform[0]);
styles['margin-left'];
styles['width'];

$transform.css({'margin-left': -step, 'width': step*2})}, 1);

Также это относится к удалению «display:none» — присваивание всех других стилей в том же тике, не будет расценено браузером как изменения.

Да, на 75% смотрится лучше.