Кот Учёный

Методология БЭМ придётся Вам по вкусу. Но, я так понимаю, в Вашем текущем проекте — уже поздно. Тем не менее, на текущем этапе разработки Вам будет полезно использовать эти принципы. Изучите вопрос. А Ваша проблема решается так:

@mobile: (max-width: 460px);
@tablet:  (min-width: 461px) and (max-width: 970px);
@desktop: (min-width: 971px);

// Значения придуманы от балды

.selector {
  @media @mobile {
    // ...
  }
  @media @tablet {
    // ...
  }
  @media @desktop {
    // ...
  }
}

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

Тем временем, где-то в идеальном мире:

/* Файл /bem/block/block.less */
.block {
  @media @mobile {
    // ...
  }
  @media @tablet {
    // ...
  }
  @media @desktop {
    // ...
  }
}

/* Файл /bem/block/__element/block__element.less */
.block {
  &__element {
    @media @mobile {
      // ...
    }
    @media @tablet {
      // ...
    }
    @media @desktop {
      // ...
    }
  }
}

Из диалога на discuss.atom.io стало ясно, что сейчас данной темой используется Fira Mono, а на момент скриншота использовался OS X Menlo font. В общем-то, это почти DejaVu Sans Mono, но если очень хочется, то можно поставить Meslo.

Не важно, где лежат шрифты — они отобразятся лишь в том случае, если нужный шрифт установлен на клиенте, или они подключены через @font-face. Браузер обработает это примерно так:

1. Опа, а у меня нет такого шрифта.
   
2. Где же мне его взять?..
   
3. О, вот — в @font-face указано, где он лежит.
   
4. Загружаю.
   

На самом деле последовательность немного другая — здесь показана логика на человеческом языке. Вам бы разобраться с пониманием основ, уделите внимание этому.

Спасибо за внимание к моему вопросу. Разобрался. Решение придётся показать в контексте упрощённого общего шаблона. Возможно, это поможет кому-нибудь в построении своей структуры документа.

<header class="header">
  <!-- Название сайта -->
  {% if page.layout == 'page' %}
  <p class="title">Вася Пупкин</p>
  {% elsif page.layout == 'intro' %}
  <h1 class="title">Вася Пупкин</h1>
  {% endif %}

  <p class="description">Кто такой Вася</p>
</header>

<main>
  <!-- Название страницы -->
  {% if page.layout == 'page' %}
  <h1 class="title">Заголовок страницы</h1>
  {% elsif page.layout == 'intro' %}
  <h2 class="title">Портфолио</h2>
  {% endif %}

  {{ content }}
</main>

<footer class="footer">
  <div class="contacts">
    {% if page.layout == 'page' %}
    <h1 class="title">Вася Пупкин</h1>
    {% elsif page.layout == 'intro' %}
    <h2 class="title">Контакты</h2>
    {% endif %}

    <!-- Кстати да, в <address> нельзя помещать заголовки и секционные элементы -->
    <address>
      <ul>...</ul>
    </address>
  </div>
  <div class="copy">
    <h1 class="title">Авторские права</h1>
    <p>&copy; Вася Пупкин</p>
    <p>И ещё чьи-то права</p>
  </div>
</footer>

Тогда при page.layout == 'page' W3C валидатор генерирует следующий outline:

- Заголовок страницы (h1)
    - Раздел1 (h2)
        - Подраздел1 (h3)
        - Подраздел2 (h3)
    - Раздел2 (h2)
- Вася Пупкин (h1)
- Авторские права (h1)

А если page.layout == 'intro', то:

- Вася Пупкин (h1)
    - Портфолио (h2)
        - Раздел1 (h3)
        - Раздел2 (h3)
    - Контакты (h2)
- Авторские права (h1)

Для Сергей Сунцев:
А по поводу злоупотребления <section> уже писали на Хабре, и в данном случае я думаю, что <footer> внутри <section> — это взаимоисключающие вещи. И, более того, тэг <section> априори подразумевает вложенность. То есть контент внутри него не может быть верхнего уровня. Даже валидатор напрягается по поводу присутствия <h1> внутри <section>, а в outline отображает такой заголовок как вложенный.

UPD: Прошу прощения, первая редакция ответа неверна — поленился разобраться. Вот код Вашего решения:

// Если просто регулярка, то:

var botLoginReg = /^(?!(login1|login2|login3)$)[a-z\d_]{5,16}$/i;

// Если есть массив с логинами (наверняка есть):

var botsLoginsArray = [
    'login1',
    'login2',
    'login3'
];

var botLoginReg = new RegExp(`^(?!(${botsLoginsArray.join('|')})$)[a-zA-Z\d_]{5,16}`, 'i');

Всё оказалось банально: вызов AJAX-запроса - асинхронный. Всё прекрасно работает, если добавить async: false в параметры запроса. Но синхронный AJAX - это не очень хорошо, поэтому порядок вызова методов нужно перестроить.

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

wget 'http://mirror.yandex.ru/ubuntu/dists/wily/main/binary-amd64/Packages.gz'

на удалённом сервере, увидел, что скорость до зеркала очень даже ничего. Позвонил провайдеру, мне сказали, что виноват роутер. Подключил кабель провайдера напрямую — получил скорость по тарифу. Скачал файл. Подключился обратно через роутер — скачал тот же файл с той же скоростью, а новый файл — снова медленно. Я так понимаю, как и догадывался Влад Животнев, у них там кеширующий прокси, но изначально причина не в этом. Оператор сказал мне, что проблема может быть в том, что сервер зеркала сам режет скорость, отвечая на серый IP, и что сейчас они назначат мне белый IP, мол это всё, что они могут для меня сделать.

wget 'http://mirror.yandex.ru/ubuntu/dists/wily/Contents-amd64.gz';
wget 'http://archive.ubuntu.com/ubuntu/dists/wily/Contents-amd64.gz';

# Скорость отличная.