1. для каждого клиента создается отдельный сокет (то есть на n клиентов на сервере у нас открыто n сокетов и 1, сервер, принимающий новые соединения), которые можно хранить в общей куче.
2. вам доступны события, когда клиент разрывает соединения и т.д. Как только это произошло, можно выставлять статусы пользователей.
phonegap это по сути и есть inAppBrowser... Ваше приложение это ни что иное как webview, в котором открывается страничка. И да, вы можете открыть в нем ваш сайт.
Вообще я не вижу в этом вообще никакого смысла, так как вы можете сделать то же самое при помощи media queries и js.
добавьте для body или html класс no-js и при загрузке страницы удаляйте его силами собственно js. Логично что если у вас в браузере отключен js то класс останется на месте.
Берете n девайсов и проверяете. По другому увы никак. Со временем вы будете натыкаться на все больше и больше особенностей мобильных webkit и webkit в целом и вопросов будет возникать меньше.
вешаете обработчик на document, и по клику прячите попап.
При клике же на ваш этот блок, просто вызываете stopPropogation. Этим вы выключите дальнейшее всплытие события и не будете пускать ивент вверх по DOM дереву, собственно click не дойдет до document.
Модульность и разбиение на компоненты, отказ или минимизация каскадирования стилей. Если у вас в селекторах больше 4-х элементов то явно что-то пошло не так. Почитайте про БЭМ. Единственное что я бы не рекомендовал использовать этот подход в том виде в котором это подается, но идея вполне себе хорошая.
Что бы верстка не ползла при изменении клиентом контента нужно жесточайше его ограничивать в том что он может сделать (он же может разметку сломать). Для этого можно применить markdown.
да, возможно. Возьмите исходники (less, причем рекомендую вне зависимости от того планируете вы менять стили или нет, так или иначе править стили предется) и используйте только то что вам нужно.
vim + плагины. Вообще странные у вас доводы... настроить ватчер, браузер с livereload на второй монитор, и переключаться нужно будет только для работы с дебагером браузера...
что бы не больше 999 это не проблема, можно использовать Math.min(999, total)
вам нужно добавлять ведущие нули, функции для этого найти не проблема:
// использовать как-то так:
// $('#points').html(pad(total, 3, '0'));
function pad(n, width, z) {
z = z || '0';
n = n + '';
return n.length >= width ? n : new Array(width - n.length + 1).join(z) + n;
}
разрешений экрана сейчас так много, что смысла в этом нету. Нужно просто взять окно браузера, и уменьшать (или увеличивать), отслеживая реакцию. Если на каком-то этапе надо перегрупировать элементы, изменить размеры и т.д. - тогда для этого разрешения ставите блок и так далее... Словом только по мере необходимости. То что вы поставите несколько блоков под какие-то стандартные разрешения вас не спасет.
Если вы планируете разрабатывать на Си/Си++ или же какие-то средства разработки то да, стоит. А так боюсь вам ничего не поможет. Всегда полезно знать как все устроено на уровень ниже, например php разработчикам стоит знать как примерно работает то, на чем они пишут. Так же .net разработчики по хорошему интересуются в какого вида байткод потом конвертится их программа, что бы проще было найти узкие места... Ну суть вы поняли.
почти все популярные фреймворки имеют подобный bootstrap-проект. У yii скажем он идет из коробки, но он корявый, для symfony2/silex/laravel так же можно найти.