FeNUMe

Вам на уровне JS нужно всем сообщениям с нужным айдишником навесить доп.класс и уже для него прописать стили в CSS. Но где именно этот класс навешивать так просто не подскажу, слишком мало инфы. Если я правильно понял, то у вас есть возможность в админке влиять на выдачу чата через свой код и существующие функции, потому стоит присмотреться к функции вывода сообщений и поискать возможность из нее получить ссылку на объект сообщения, а потом уже стандартно добавить класс.

Вы правы: через iframe блоки сайта никто не соединяет уже лет 20. В современных сайтах блоки хедера, футера, меню, контента верстаются отдельно и собираются в одну страницу, а вот каким образом тут уже есть варианты:

• самый простой - на уровне вебсервера с использованием SSI(Server Side Includes), но используется сравнительно редко;
  
• самый распространенный - когда бекэнд на лету собирает страницу перед отдачей клиенту, но это не ваш вариант;
  
• для статических же сайтов обычно используют либо "генераторы статических сайтов", либо настроенную систему сборки типа webpack/gulp, которая собирает css/js/html "блоки" в единое целое.
  

Так же сейчас популярны SPA(Single Page Application) сайты, в случае визиток инфа сразу же загружается со страницей, а там уже "разбивается" на разделы с помощью верстки/js/css, в случае чего-то более динамического инфа подгружаться на лету с помощью js.

Раз уж речь идет о SPA, то вы явно будете переписывать/дорабатывать бекенд для работы через API, а значит ничего не мешает написать клиенты на чем угодно что уже знают ваши разработчики. Естественно в идеале выбирать один инструментарий для использования во всех клиентах(веб/мобильный/десктоп). Из популярных сейчас вариантов можно посмотреть на ReactJS/ReactNative, но стоит учитывать что для вашей задачи это может быть просто оверкил.
Для оформления как раз лучше второй вариант, то есть готовая популярная css-библиотека, для которой просто написать свои темы.
Переживать о размере библиотек в SPA точно не стоит: первая загрузка будет достаточно долгой(не забудьте сделать индикацию), но потом все будет браться из кеша, да и страница обновляться ведь не будет, все данные будут подгружаться по надобности и рендерится уже на клиенте.

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

Если хотите как слева, то достаточно послушать Sergey Goryachev и использовать display: inline-block;.
Если как справа - поможет современный стандарт разметки flexbox, конкретно гуглить "flexbox masonry". Для поддержки древних браузеров придется использовать masonry плагин для jquery, или аналогичные js-решения.

"Правильный" способ это как раз переопределение стилей фреймворка. И это займет намного меньше времени, чем вырезание/переименовывание правил связанных с филдсетами. Можно конечно воспользоваться автозаменой, а потом отлавливать баги к которым это приведет.

Есть еще вариант getbootstrap.com/customize - сгенерировать свою сборку не содержащую правила для форм. Но если проблема только с филдсетами и легендой, то это не оптимальное решение.

Родное(native) не выйдет - биндингов к GTK/QT/итд я не встречал(правда и не искал, может есть). А вот самостоятельное(standalone) приложение сделать не проблема(node.js/tidesdk/titanium/итд)

rmcreative.ru/blog/post/svoy-inputtype=file

С разными размерами экрана вам помогут CSS media queries. почитать про них с примерами можно тут habrahabr.ru/post/141199/. А вот с зумом как быть не знаю, пожалуй только на лету переключать стили с помощью javascript отлавливая событие зума.