klierik

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

А проблема в чём?

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no"> С этим будет так: http://take.ms/sb8I6

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

Для каких целей?

Скорее баг с сайтом, так как данная ошибка, в данной формулировке, — невозможна

Потому что указываются значения которые влияют на горизонтальное положение блока, но никак не вертикальное. Может из-за не знания а может для явного указания величин. По-разному бывает.

Потому что на -xs- кол-во колонок равно 12: http://take.ms/AS22z

Потому что этот код не заставит браузер работать именно так. То что "auto" позволяет выровнять по-гориизонтали вовсе не означает что поведение повторится по-вертикали. Для этого существуют другие способы: https://jsfiddle.net/dL3rjrqk/

В проекте может и будет присутствовать огромное кол-во компонентов и, как правило, нет документации по пользованию ими. Может случится так что новый разработчик будет создавать новый код, просто потому что не знает что где-то такой компонент уже существует. Использование фреймворка же помогает стандартизировать, как минимум, базовые компоненты приложения. В данном случае будет создан файл _navs.scss в котором будут описаны лишь изменения дефолтного поведения компонента. Сильный профит вот в чем — тебе понадобится лишь визуально изменить его внешний вид, но тебе не надо создавать компонент с нуля. Да, я соглашусь что в .css на первых порах ты получишь родные стили которые ты перепишешь в своем кастомном файле (это — недостатки пользования фреймворков). Да, мы получим на выходе дублирование стилей. Но это решаемо тем же CSSO. Это издержки, не идеальная ситуация, не самое комфортное управление кодом. Но, профит получить из коробки рабочий компонент здесь и сейчас (хоть и надо подпилить напильником) очень подкупает. А вот в тех случаях когда компонент Bootstrap уж слишком разнится с поставленной задачей — проще воспользоваться сторонним ПО. А еще можно пойти дальше. На пример допустим что любое конфигурирование компонента — это набор настроек (считай — переменных), которые задают внешний вид. Если бы таков был фреймворк (хотя. в таком случае правильнее назвать "библиотека готовых решений"), тобыла бы решена проблема с переписыванием стилей. Но появились бы издержки на конфигурировании, зато получили бы высокую прозрачную гибкость. В рамках Bootstrap сегодня (да и в ближайшие 3 года так точно, опираясь на 4.х) такого подхода в нём не будет. Но, можно ведь пойти иным путем — между приложением и фреймворком создаётся "интерфейс", который задает весь тон остальному коду. Этот микс позволяет добавлять\удалять из системы "тяжелые" части кода. Уже через пол года может случится так что редко используемый компонент системы ты напишешь с нуля, попросту забыв о том что он существует.

Если вам постоянно требуется править стили Bootstrap — вы не умеете пользоваться данным инструментом. А документацию по поддержке так же напишешь? С примерами кода, на английском, да? Или разработчику, который прийдет после тебя, прийдется изучать в начале твой код, что бы писать аналогично ему? У тебя, по всей видимости, нет опыта написания проекта весом от 700 часов (front-end) с последующей поддержкой, хотя бы, 5+ лет. Иначе данные слова даже не прозвучали бы. Я работаю над такими проектами, но ни один тебе не будет известен, так как это рынки USA/AU/Eu Хотя на рынке СНГ можно упомянуть www.yakaboo.ua. Но то что сейчас творится в коде и то что было сделано изначально — совершенно разные вещи. Последующая разработка, по всей видимости, шла без какого либо анализа существующего года. Писали как есть, как умеют. Более того, судя по тому как написано, предполагаю что писал бекенд, так как уж слишком топорная логика "в лоб". На базе Bootstrap я пишу темы для магазинов, весом от 160+ часов и выше последние лет 5+, и хорошо понимаю какие он накладывает ограничения (+ как их решать), а так же понимаю его преимущества (особенно для долгоиграющих проектов). Я не буду рекомендовать его использовать везде, но зная его хорошо — знаешь где и зачем его следует применять.

Как вариант — http://take.ms/ktZe8 Ах да, и вот тут http://take.ms/MRccl стили поломаны.

На пример вот так: https://jsfiddle.net/klierik/c69mzgxs/3/

а откуда такое предположение?

http://take.ms/vUgfa

Всё просто — присутствуют изменения в стилях: http://take.ms/EyNvt

В примере нет никакого адаптива. А то что у тебя локально я не имею возможности узнать. Если в пример https://jsfiddle.net/aw0qvc0e/5/ добавить Bootstrap то всё работает ровно так как и должно работать (как уже было сказано выше): http://take.ms/1VPYm

Кажется ты не понимаешь как работает Responsive. Не важно какой ширины <div>, важно какой ширины экран. На скрине у тебя показана работа класса "col-xs-12" — ширина 100%. То есть — все правильно работает.

Я не вижу проблемы. По указанному выше примеру на jsfiddle правая часть не сбрасывается под левую.

По ftp или через админку

Правь скрипт который отвечает за стоимость

Оба эти сайта в iPhone 7 листаются вперед\назад точно так же как и любой другой сайт.

Попробуй "/" вместо "\" использовать в пути к картинке

Что бы «двигать», а точнее скроллить, можно использовать overflow:auto;

Ты говоришь о скачке — перемещение с платформы на платформу, что не отвечает действительности. В реале же чат присутствует на нескольких платформах. Каждый выбирает для себя ту где ему удобно, и не более того. А что касается потери аудитории — данное предположение так же не отвечает действительности. Что в скайпе, что в телеграмме, что в гиттере свой круг пользователей, которые не охотно хотят перелазить на другие платформы.