Андрей

layout viewport - это область на которой размещены все элементы страницы
visual viewport - это часть layout viewport-а, которая отображается в данный момент на экране.
viewport - задает размер layout viewport-а, для того чтобы при открытии на мобильном устройстве, ширина viewport-a была задана наиболее удобным значением, обычно это device-width. В этом случае страница будет вписана в размер экрана.

Давайте по пунктам постараюсь рассказать, как вообще надо работать во front-end.
1. Вы должны научиться думать блоками (блоками в потоке, выпадающими из потока, flex-блоками и тд и тп). Научиться можно только когда вы поймете как на самом деле надо верстать.
2. Начните с простой вёрстки. Возьмите макет в .psd (80% работы над каждым сайтом вы будете пользоваться PhotoShop и если вы его не знаете хотя бы на предбазовом уровне - печаль беда), импортируйте оттуда все нужные вам картинки ну и начинайте верстать шаблон поблочно, смотря где какой цвет шрифта, размер, жирность, размер блока, фон этого блока и тд и тп.
3. Зачем вы себе морочили голову gulp, sass, bootstrap когда ещё верстать даже нормально не умеете - я увы не понимаю. Вам ни один из этих инструментов не поможет пока вы не будете уметь именно верстать. На данный момент не думайте о технологиях, структуре и тд и тп. Просто сверстайте хоть какой-нибудь макет хоть как-то.
4. Общайтесь с людьми, которые вам могут помочь продвинуться в этой сфере. Таковых крайне много. Можете ко мне в скайп добавиться и узнавать некоторые вещи, можете к другим, к кому угодно фактически, наверно 60-70% верстальщиков с удовольствием поделятся с вами своим опытом
5. Пишите код аккуратно. Был тут недавно вопрос, в котором человек предоставил код, а там ни{ } нету, ни отступов нормальных нет, ну и половина ; просто потеряны, а в html теги применяются не по назначению вовсе. Нельзя так делать ни в коем случае, иначе ваш уровень не поднимется с уровня плинтуса.
6. Файловая структура: папки css images js и на уровне с этими папками лежат файлы .html либо .php всё. Если говорить о препроцессорах и сборщиках - не лезте пока в это, потом узнаете как только научитесь нормально верстать. Я думаю нет смысла объяснять что в папках тех должно лежать. Если вы считаете себя особенным - можете распределять внутри images картинки по папкам на составляющие, к примеру сделать папку отзывов, папку галерей каких-нибудь и тп, но я чаще так не делаю, не хочу чтоб дополнительные символы засоряли мне код и ухудшали читаемость.
7. Связывать между собой html и css судя по всему вы и так уже умеете и привязывать к ним js. Не знаю что вам мешает сверстать любой сайт если вы понимаете как устроены эти 3 технологии (а на них по факту всё и держится).

Итог: Забудьте про sass, gulp и прочее пока не сверстаете шаблонов 10, эти технологии вас никак не ускорят и никак вам не помогут пока вы не будете уметь просто верстать с шаблона .psd и писать нужные скрипты на js или jQuery хотя бы. Научитесь немного фотошопу и занимайтесь практикой. Найти те самые .psd вообще не проблема, их куча бесплатных в интернете.

Первый этап — подумать, надо ли это вам вообще. К хорошему дизайну на кривой козе не подъедешь.

Прежде всего: Майк Монтейро «Дизайн — это работа». Даже если не будете потом заниматься дизайном — книга все равно полезная.
Во многом избавляет от романтического подхода вроде «дизайнер — это художник».

Второй этап — учиться: смотреть и делать свое.
Только, во имя всех скандинавских богов, смотреть не на Behance и Dribble. Там красиво, конечно, стиль, все дела, но в конечном итоге 95% работ там просто картинки.
А веб–дизайн — в первую очередь сценарий. Дизайнер определяет то, как пользователь будет пользоваться сайтом: в его власти сделать интерфейс простым и ясным или запутать до невозможности.
Посмотрите работы бюро Горбунова, особенно процесс создания.

Соответственно свои работы тоже нужно рассматривать с точки зрения полезного действия, а не внешней красоты. Эстетика — это третий этап.
Учиться значит читать, в первую очередь. Чтобы делать правильно — нужна система.
Читать лучше от общего к частному, начать стоит с этого:
Дональд Норман «Дизайн привычных вещей»
Виктор Папанек «Дизайн для реального мира»
Параллельно:
Генрих Альтшуллер «Найти идею»
37Signals «Getting Real»

Веб — это интерфейс, значит:
Джеф Раскин
«Новые направления в проектировании компьютерных систем», «Об интерфейсе»
Брюс Тогнаццини «Главные принципы интерактивного дизайна»
Якоб Нильсен «Веб-дизайн. Книга Якоба Нильсена»

Веб — это шрифт и текст, стало быть:
Ян Чихольд «Новая типографика»
Эмиль Рудер «Типографика»
Нора Галь «Слово живое и мертвое»
Саша Карепина «Искусство делового письма»

Веб — структура и верстка:
Тим Харровер «Настольная книга газетного дизайнера»
Мюллер-Брокман «Модульные сетки в графическом дизайне»

Оставлю за кадром книги по самоуправлению и переговорам, это уже другая фаза.
Про английский язык и умение верстать уже сказали, повторяться не буду.

JS не умеет копировать в буфер, обычно это реализуют с помощью костыля в виде маленькой кнопки на flash (например: zeroclipboard.org ).

Либо некоторые сайты открывают модальное окно с выделенным текстом, чтобы юзер скопировал его.

1) в ВЕБ в форме авторизации можно ли ставить птичку "запомнить логин и пароль"
2) в ВЕБ в форме авторизации можно ли ставить птичку "запомнить логин"

нет, если захочет, то хром/фокс спросят пользователя

3) нужно ли хранить ИП-адреса с которых были произведены авторизации

стоит. Если ты работаешь с деньгами - обязательно. Старайся не работать с деньгами без толкового TL, у которого можно уточнить детали

4) Нужно ли назначать expiration time для Токенов, которые выдаются для авторизации в мобильных приложениях iOS и Android?

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

5) если клиент совершает "LOGOUT" в мобильном приложении, убивать ВСЕ токены для этого клиента?

лучше спросить клиента отдельно. Установку по-умолчанию согласовать с заказчиком

6) Показывать в кабинете пользователя выданные токены, время выдачи и дату последнего использования?

стоит. Если оперируешь с деньгами - обязательно

Без понимания front-end пытаться заниматься бэкэндом бессмысленно, мне кажется. Я слыхал про существование (причём в больших крутых фирмах) web-бэкэндщиков, не понимающих HTML, но я с трудом представляю себе как это так (может они бизнес-логику пишут, отдают всё через SOAP и даже не смотрят что на выходе, но всё-равно как-то сомнительно), думаю в реальной жизни это невозможно. Если тебе больше нравится бэкэнд, то можно забить на изучение кроссбраузерной вёрстки и фронтэнд-фрэймворков, но хорошо понимать нормальный HTML/CSS/JS-код и иметь представление что там к чему, мне кажется, ты обязан.

Вам не нужна совместимость со всеми браузерами. Netscape уж точно не нужен :-P

Мне очень помогло ежедневное чтение статей по заданной теме с хабра и прочих ресурсов такого типа. И гугл. Просто море гугла. Не знаешь как что-то сделать — гугл. Знаешь, но считаешь, что не оптимально — гугл. Сделал, но работает не везде — гугл. Главное правильно подбирать запросы, ответы не всегда лежат на поверхности, но они почти всегда есть.

Сразу нужно узнать про такую вещь как css-reset, дабы нивелировать различия браузеров. Очень помогает. Кроме того, я бы прочитал все статьи с html-book.ru, а также про все теги и CSS-свойства (по возможности), ставя в приоритет наиболее популярные.

Можно заморочиться с методологией названий стилей, по типу БЭМ или MCSS, чтобы избежать проблем и путаницы (а они будут) в своих стилях.

И самое главное — нужно просто постоянно верстать. Можно проходить какие-нибудь уроки или ставить себе самому задачи. Если повезёт, можно просто попасть в неплохую фирму и развиваться там. В идеале в фирме должен быть наставник, который поможет-подскажет.

А в какой-то момент, набравшись определённого опыта, начинаешь без проблем решать любую поставленную задачу, потому что уже безошибочно разбираешь в уме страницу на более мелкие блоки и сразу видишь, что и как можно сделать. Вариантов решения одной и той же задачи зачастую очень много. И чем дальше, тем больше, потому что старые браузеры постепенно отмирают, а новые, кто-то медленнее, кто-то быстрее, но стараются соблюдать спецификацию.

Ещё при вёрстке очень неплохо бы использовать специальный сайт, который расскажет, что и где поддерживается. Очень помогает и очищает код от всяких лишних вендорных префиксов, которые в уроках и на форумах любят иногда писать в диких количествах, в том числе и несуществующие.

На мой взгляд базисные знания следующие:

1) Клиентская верстка и стили (html, css). Можно пробежаться глазами хотя бы по теме. Почитать про правила верстки.
2) Клиентская логика, работа с DOM (Javascript, Jquery). Важная тема — стоит уделить ей время.
3) Теория распределенных приложений. — Веб приложения чаще всего являются распределенными. Поэтому стоит изучить архитектурные принципы распределенных приложений. API и т.д.
4) Базы данных (SQL, etc.) — Конечно начать стоит с классического сиквела — но стоит посмотреть и шире — например на nosql решения.

Далее стоит выбрать технологическую платформу. С вашим бэграундом вероятно стоит посмотреть в сторону Microsoft ASP.NET MVC. Это великолепное решение и погружение в обширный мир разработки в рамках решений MS. У них сейчас самые развитые языки программирования (C# 5.0), самые развитые инструментальные среды (MS Visual Studio), одна из самых совершенных виртуальных машин (.Net).
Решение удобнее всего для серьезных и масштабных проектов, хотя и для небольших вполне подойдет.
Следующий кандидат — Ruby on Rails. Это развитое решение с замечательным языком программирования и отличными каркасными решениями, заточенное именно под веб. Возможно лучше подойдет для небольших приложений — но и промышленные продукты без проблем потянет.
Он также очень распространен.
Ну и конечно PHP. Язык программирования данной технологической платформы отстает от требований к разработке больших решений — он скорее подходит для написания скриптов. Однако существует колоссальное количество каркасных решений для данной платформы, которые позволяют реализовывать даже приличного объема продукты. Кроме того данное решение наверное самое распространенное из всех.
И оно потихоньку подтягивается до уровня платформ для разработки промышленных продуктов.
Существует также множество других решений. Например огромный мир Java и решения на базе серверного Javascript.

Скоп работ будет состоять из следующих частей:

1) Клиентская часть (html, css, javascript). Тут вам понадобятся знания по верстке как раз и жаваскрипту. Также следует использовать различные базовые решения и фреймворки. Эта как раз та часть, где слишком глубокие знания (например использование чистого некроссбраузерного javascript) могут быть вредны и лучше все базировать на готовых платформах.
Часто эта часть в web приложениях бывает больше чем хотелось бы.

2) Серверная часть. Тут все определяется технологической платформой описанной в предыдущем абзаце. В веб приложениях как правило немного серверной логики — почти все можно заменить на внешние библиотеки. Но у разработчиков десктопных приложений всегда есть соблазн развивать именно эту часть потому что она им знакома — не поддавайтесь. Специфическая для проекта серверная логика нужна не очень часто. Если ее много — значить кто то увлекся велосипедами. Тоже касается разработок API и систем взаимодействия с внешними сервисами.

3) Базы данных. Конечно обязательно! стоит использовать развитые ORM системы. То есть нужно их изучить под выбранную вами технологическую платформу. Ну и конечно базовые знания баз данных тут тоже очень понадобятся — сиквел, реляционная модель и все остальное.

Дерзайте. Я за вас болею.