Алексей Струков

Тут используется паттерн передачи параметров через один объект options
В самом низу самовызываемой функции - это конструкция типа (function(){}()) скорее всего есть такая строка:
}(options))
Здесь передается обьект со свойствами tabNavigationList и прочие. Потом он принимается в функции tabs, эти свойства из него считываются и по содержащимся в них строках ищутся элементы на странице.
Сначала находится el - это видимо контейнер. Потом поиск элементов продолжается внутри уже этого контейнера. Тоесть если мы сначала нашли el внутри документа (document.querySelector), то потом ищем вложенные в него элементы через el.querySelectorAll (поставив el вместо document, мы ограничиваем поиск содержимым этого элемента, а не всем документом как это было в первом случае)

Попробуй вместо matrix[i-1][j] написать matrix[i === 0 ? 0 : i - 1][j]
Либо через max(i - 1, 0) - так даже более изящно.

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

row (горизонтальный блок на сайте)
col (делит row на несколько секций)
wrap (оборачивает компонент, который находится внутри col)
item (сам компонент)
text (текст, который находится внутри компонента)

У каждой категории классов есть свой набор свойст которые к нему применяются. Например сетка работает с col-классами и следовательно, когда я вижу класс типа .col-width-50-s, то я знаю что тут структурный стиль для сетки, в котором присваивается ширина 50 процентов на мобилах. А класс item-table_caption это заголовок компонента-таблицы.
Когда в голове создашь свою иерархию классов, то проблем с названием селекторов не будет и их очень легко читать/писать станет.

У такого подхода есть как плюсы, так и минусы.
Плюс - вы берете самые интересные решения из разных методологий и создаете инструмент под себя (мне нравится атомарный подход, mcss и bem, но у всех них есть свои недостатки)
Минус - другие разработчики не всегда могут читать ваш код также легко как и вы. Однако, как показывает практика, методологии приходят и уходят и возможно изобретенный вами подход станет новым стандартом в будущем)

Такое лучше на svg делать.
Сложные фигуры на css это баловство. Если заказчик хочет такую сложную штуку, то завтра он может попросить сделать ее еще сложнее (по закону Мерфи обычно так и бывает) и один хрен придется делать потом на svg. Так зачем тратить время на css-костыль и оттягивать неминуемое?)

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

Поставь этим инпутам type=text и например pattern=[0-9]+ (надо тестировать и подбирать паттерн под свои нужды)
Чтобы форма точно не проходила, надо использовать валидацию через js.
Встроенная html5 валидация работает не везде одинаково, а на айфоне вообще не обращает внимание на атрибуты required и отправляет пустые поля на сервер.

User-scalable=no перестал поддерживаться в ios10(и возможно на некоторых других платформах). Признан плохой практикой.

Вес такой-же как и у классов