Tashiro

Попробуй так изменить разметку:

...
      /* Добавим data-header="M" к .masonry-item*/
     <div class="col-lg-3 col-md-3 col-sm-3 col-xl-12 masonry-item" data-header="M">
          /* <li class="header">M</li>  Убрать из разметки*/ 
          ...
     </div>
     ...

В своем стиле сделать псевдо елемент :before :

.masonry-item[data-header]:before {
               content: attr(data-header);
               display: block;
               font-weight:bold;
          }

Как вариант можно скинуть data-header в первый li (не в li c класом header - его быть не должно), и поменять селектор на .masonry-item li[data-header]:before

P.S. В вопросе ставь код, а не скриншоты. Набирать наново лениво.

Это открытый тикет - https://github.com/angular/angular.js/issues/1460

В общем виде все решения сводятся к директиве, которая таймаутом проверяет значение инпута и обновляет модель. Там посмотрите по тикету - куча реализаций, например:

app.directive("watchAutofill", [
         '$timeout',
function ($timeout) {
    var INTERVAL_MS = 500;

    return {
        require: 'ngModel',
        link: function (scope, element, attrs, ngModel) {

            var timer;
            function startTimer() {
                timer = $timeout(function () {
                    var value = element.val();
                    if (value && ngModel.$viewValue !== value) {
                        ngModel.$setViewValue(value);
                    }
                    startTimer();
                }, INTERVAL_MS);
            }

            scope.$on('$destroy', function () {
                $timeout.cancel(timer);
            });

            startTimer();
        }
    };
}
]);

Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).

Кроме того ORM, как правило не исключает обращение к БД на уровне произвольных SQL запросов, оно лишь преобразуют результаты этих запросов в объекты модели предметной области (и наоборот), которые ничего не знают (в идеале) о таблицах, WHERE, HAVING и т. п.

ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().