lnked

Попробуйте поставить после меню
<div style="clear: both;"></div>

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

Алексей, тут такое дело — дизайн это не про фотошоп.
Я тоже когда думал, что чем больше уроков по фотошопу я пройду, тем сильнее я дизайнер. Но вот дела обстоят так, что инструмент вторичен.

Теперь кратко — читайте про стратегию (хоть Сунь Цзы), про логику, про мышление людей, да даже строение букв откроет громадные горизонты.
Что читать? Берем грамотного дизайнера с блогом, ищем и вот например подборка — ludwigbistronovsky.ru/books

Там выше увидел, что по интерфейсам есть интерес. Тогда есть рекомендация одна, но для завершения курса вам потребуется ух сколько сил. Дерзайте. Скоро начало курса:
https://www.coursera.org/course/hciucsd

Вот когда будете знать Что рисовать, встанет вопрос Как. Только тогда имеет смысл заглянуть на всякие dribbble & behance.

Мы же помним, что margin и padding считаются от ширины контейнера? Пример

В JS нет ассоциативных массивов, как в PHP, для этого используются объекты

Используйте объекты, вместо массивов.

var images = {};
images[number] = response;

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

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

Внутри each() каждый elem — ссылка на натуральный DOM-элемент.

Так что либо так

$('.js-to-cart').each(function(i, elem) {
	console.log($(elem).attr('data-item'));
});

либо так

$('.js-to-cart').each(function() {
	console.log($(this).attr('data-item'));
});

А вот ещё несколько приёмов

$('.js-to-cart').each(function(i, elem) {
	console.log(elem.dataset.item);
	console.log($(elem).attr('data-item'));
	console.log($(elem).data('item'));

	console.log(this.dataset.item);
	console.log($(this).attr('data-item'));
	console.log($(this).data('item'));
});

Нужно помнить, что data() в jQuery — не совсем то же самое, что и data-атрибуты. Это — метод у jQuery-объекта, позволяющий хранить любой тип данных. Значение атрибута — лишь стартовое значение, преобразованное, по возможности, в наиболее подходящий тип (например, попробуйте задать в качестве значения атрибута массив).

$('.js-to-cart').each(function() {
  console.log($(this));
  console.log($(this).attr('data-item'));
});

через $(this) надо обращаться к атрибуту
console.log($(this).attr('data-item'));

var url = 'https://yandex.kz/images/?redircnt=1432190913';

//Вариант 1
var result1 = url.substr(url.lastIndexOf('/') + 1, url.length - 1);
result1 // => ?redircnt=1432190913

//Вариант 2
var tempArray = url.split('/');
var result2 = tempArray[tempArray.length - 1];

result2 // => ?redircnt=1432190913

Update В первом варианте второй параметр опцинален, опустив его, подстрока будет браться до конца строки. Поэтому этот вариант можно перезаписать короче. Спасибо Bhudh за подсказку.

var result1 = url.substr(url.lastIndexOf('/') + 1);

Не нужно центрировать текст паддингом сверху. Для этого есть нормальное решение.

input {
  line-height: 30px; // высота инпута
  padding: 0 15px;  // отступы по бокам
}

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

Если в кратце, то все печально :) На всех переходах фпс стабильно падает до 30 (и иногда ниже). Ваша цель - 60 фпс в среднем, и не ниже 40 на паре-тройке фреймов при переходах.
Если вы чайник в замерах веб-перформанса с помощью таймлайна (и дев тулс вообще), то вам сюда:
а) https://developers.google.com/web/fundamentals/per... - святой грааль.
б) https://www.udacity.com/course/browser-rendering-o... - по сути дела дополнение к текстовому варианту, но только в виде отличных видео и мини-тестами. Там же на udacity есть похожил курс от Григорика.
в) Искать другие годные статьи в дайджестах и блогах, пилить/изучать демки и все такое.
2) Очень беглый осмотр показал, что у некоторых элементов анимация происходит с помощью изменения таких свойств как left например (вылезающий и жутко тормозящий блок справа на 3 странице). В 90% случаев для анимации движения/перемещения/отображения прилично использовать только transform/opacity, особенно когда речь идет о больших элементах. С анимацией всяких left/top/width и подобных вещей для больших элементов можете вообще забыть о 60фпс.
3) Основную ставку вам надо будет делать на создание отдельных слоев для элементов, проще говоря юзать translateZ/backface-visibility. Но только юзать это надо с умом, и каждый раз все профилировать через таймлайн. В веб-перфе есть одна крылая фраза "Tools, not rules".

Ну на сайте который вы привели в пример используется метод requestAnimationFrame для запланирования перерисовки, что в итоге позволяет браузеру заранее произвести расчет для следующего кадра анимации, что в итоге дает большую плавность. Проблема только в том, что данный метод есть только в IE10+. Так что для нормальной поддержки пользовался этим кодом:

(function() {
    var lastTime = 0;
    var vendors = ['ms', 'moz', 'webkit', 'o'];
    for(var x = 0; x < vendors.length && !window.requestAnimationFrame; ++x) {
        window.requestAnimationFrame = window[vendors[x]+'RequestAnimationFrame'];
        window.cancelAnimationFrame = window[vendors[x]+'CancelAnimationFrame'] 
                                   || window[vendors[x]+'CancelRequestAnimationFrame'];
    }
 
    if (!window.requestAnimationFrame)
        window.requestAnimationFrame = function(callback, element) {
            var currTime = new Date().getTime();
            var timeToCall = Math.max(0, 16 - (currTime - lastTime));
            var id = window.setTimeout(function() { callback(currTime + timeToCall); }, 
              timeToCall);
            lastTime = currTime + timeToCall;
            return id;
        };
 
    if (!window.cancelAnimationFrame)
        window.cancelAnimationFrame = function(id) {
            clearTimeout(id);
        };
}());

В свое время именно это помогло мне избавиться от тормазов при анимации.