• Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    Рустам Байназаров, прошу прощения, насчёт 980 похоже я и правда ошибся. Скорее всего, это была высота. Я перепроверю ещё раз, но скорее всего, вы правы.

    P. S. На самом деле, несмотря на это недавно я столкнулся с диким багом, который был и на реальных телефонах у людей, и в режиме эмуляции, причём в обоих браузерах. Это заставило меня слегка усомниться в адекватности телефонных версий браузеров =) Если вкратце - шрифт, заданный в стилях как шрифт одного размера, отображался в очень разном размере на одной и той же странице. И единственным способом это исправить было изменение типа родителя с display: inline-block на display: block, или что-то вроде того. Даже нет, ещё забавнее - просто вставка дополнительных <br> так, чтобы явно ограничить строку одним блоком, помогала. Иными словами, браузер почему-то самовольно решал, что надо напихать в одну строчку кучу контейнеров (3 штуки), сжать их по ширине и высоте, а контент пропорционально зуммировать в меньшую сторону (картинки, ссылки, всё сохраняя пропорции), игнорируя(!) выставленные размеры для картинок и размер кегля для ссылок. Я так и не понял, что это было, и какой стандарт разрешает такое поведение.
  • Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    Рустам Байназаров, информация с Твича, который корёжится в Firefox 45, 47, 49 и 50, но нормально отображается с версии 51. Я даже для него CSS fix лично писал, чтобы поправить эти глюки. На userstyles лежит. Вы сами скачайте portable версию из названных выше и откройте любую страницу, поймёте о чём я говорю.

    Я спокойно все сайты уже три года верстаю на flex

    Круто, что вы умеете flex, но видимо вы в своих проектах просто не используете те свойства, на которых возникают кроссбраузерные несовместимости. Причём что характерно, у Chrome соответствующих по времени и даже более старых версий этих проблем нет... Это именно баги лисы.

    UPD: К сожалению, баг на твиче больше не воспроизводится, теперь и без моего фикса там почти идеально выводится всё. Но он у них был как минимум год. С осени 2018-ого, и весной этого года ещё присутствовал. Жаль я скриншот не сохранил, теперь только через WayBackMachine если смотреть...
  • Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    Рустам Байназаров, так выдаёт Chrome в режиме эмуляции... Возможно, это его баг, я не знаю. На самом деле, на реальном телефоне цифры скорее всего будут похожи. Завтра протестирую на Samsung A7 2017 и скажу результат :)

    Android 2.3? Вы из какого года? :)) Какой у вас пласт клиентов? Это вы из статистики взяли, что у вас куча народа заходит с 2.3 или из головы?

    Ну у меня например 2.3, отличная операционка. Ничего лишнего, к железу не требовательна. Уже 4.0 кстати железо не тянет, которое с 2.3 прекрасно справляется.
  • Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    Анита Ковалева, спасибо, вот только не очень понятно, во что выльется использование этого метода в браузере, который не понимает саму директиву, надо тестить.

    Насчёт цены - да заказчик ни на чём не настаивает и ничего не требует. Мне самому совесть не позволит сделать иначе, независимо от цены. Знаете, для меня есть минимальная планка качества. Сайт должен работать везде или почти везде (это если вам захочется вставить сарказм про корректную поддержку IE 6.0 или Opera 9.x, например).

    И потом, за что брать в 3 раза больше, если как вы сами сказали, достаточно просто сделать вторую версию на float-ах (а можно ей и ограничиться)? Если не брать старые IE - то и float уже излишество, хватит inline-block, которые я обычно использую.

    Я почему хочу перейти на Bootstrap - думаю, что система с предопределёнными именами классов реально сэкономит усилия и позволит делать вёрстку быстрее. Полагаю, можно найти более старую версию, которая работает не на флексах. Это уже буду смотреть по ходу изучения.
  • Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    Рустам Байназаров, во-первых, кажется при тесте на реальном SGS 4 Mini было больше 920 или 940 (но это было давно, не берусь утверждать, может 640 было всего). Во-вторых - откройте режим эмуляции в Хроме, и поставьте какой-нибудь IPhone или Google Pixel... И сами увидите

    Да, вьюпорт один, я криво выразился. Имелись в виду виртуальные точки (в противовес реальным пикселям матрицы).
  • Как правильно адресовать стили для мобильных телефонов?

    @popov654 Автор вопроса
    И чем мне поможет для поддержки тех же старых Андроидов и Safari @supports?..
    Я не знал про неё, каюсь, но вот я загуглил сейчас: https://habr.com/ru/post/178021/
    Появилась весной 2013-ого года. Что прикажете делать с дефолтным браузером на Android 2.3 (по сути единственным быстрым, который не лагает на лоу-энд и мидл устройствах того времени), ведь он был выпущен в 2011-ом? Также насколько я знаю, флексы начали разрабатывать в середине-конце 2012-ого, гриды вообще начали появляться только летом 2014-ого (сначала в Firefox, чуть позже в Хроме).

    Это всё сильно мимо... Проблема даже не в IE, у него рыночная доля давно падала, ещё до того, как его заменил Edge. Проблема например в том, что в Chrome 21 нормально не работают флексы. В Firefox до версии 51 они тоже работают с огромными косяками и сбоями. В старых операх на движке престо - их поддержки вообще нет, насколько я знаю, чисто по датам. А совсем мне не нужно, чтобы мой сайт во всех этих браузерах отвалился или покорёжился.

    Не говоря о том, что в принципе @supports не поможет решить проблему с сайтом, сделанным на флексах (не важно, вручную или через последнюю версию Bootstrap) в браузере, где флексов нет вообще. @supports даже не знаю где может помочь. Где-то, где нужно не допустить применение новых правил более старым браузером, чтобы не искорёжить дизайн? Может, на стыке Firefox версий 50-51 это было бы актуально при условии, что мы пытаемся тьюнить существующую вёрстку на флексах под новый исправленный движок (и то не уверен, там нет нового CSS свойства, за которое можно было бы "зацепиться" логически), в остальных случаях - чисто способ уменьшить число ошибок CSS, выводимых в консоль, в любом случае браузер проигнорирует все свойства, которых не знает.

    Про бутстрап - ну да, его хвалят именно за сетку. Хотя как я понял он тяжёлый, и тащит за собой не менее тяжёлую jQuery. Это как бы минус, но если сильно упростит вёрстку - я не против рискнуть, интернет сейчас довольно быстрый у всех.

    Про сборщик - уточните пожалуйста, я не понял, какой мне использовать и как, чтобы избежать описанных проблем.

    И вы не ответили, правильно ли я сужу, что определять тип устройства по dpi - надёжнее, чем по ширине вьюпорта?
  • RESTful API и MVC — что это?

    Станислав Макаров, спасибо.

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

    Вот здесь немного не понял. Голый HTML ведь тоже не предназначен для чтения человеком в "сыром" виде. Браузер не только стилизует эти данные, но и компонует их, позиционирует, а также трансформирует в некоторых пределах, если нужно. Точно так же теоретически и JSON может быть прочитан человеком при большом желании. Я просто к тому, что грань очень тонкая.

    и что мы можем ценой высокой стандартизованности сетевого взаимодействия (в том числе ценой использования протоколов HTTP, форматов данных вроде JSON и т.д.) наладить "разговор" двух очень непохожих машин достаточно быстро и с надеждой что это просто так не сломается в один прекрасный день

    Мне кажется, на практике не всё так просто. В смысле, если у нас есть "две непохожие машины в вакууме", требования соблюдения JSON мало. Обе конечные точки должны понимать семантику передачи данных. То есть где у нас какие данные лежат, каких типов, и что они значат. Ваш пример - это как попытка сделать SQL базу данных без схемы таблиц. Нужен какой-то способ описать для этих машин схему передаваемых данных так, чтобы они её понимали... Что-то похожее на DTD в HTML.

    Кстати, я читал про похожие разработки, только там использовался вовсе не JSON, а обычный HTTP. Что-то вроде FOAF и аналогов...
  • Рассылка спама через веб-интерфейс gmail. С чего бы?

    J_o_k_e_R, в серьёзных системах куки всегда привязаны к IP. Никак не мог злоумышленник использовать ваши куки на другом IP для авторизации... Так что мне видится более вероятной версия с троянцем
  • RESTful API и MVC — что это?

    применяют и для "веба машин"

    Прошу прощения, а что такое "веб машин"? Можно увидеть какие-то реальные примеры? Я вот правда не очень понимаю, о чём речь.
  • На чем (за счет чего) рендерится html? Почему svg рендерится не с помощью видеокарты?

    Drovosek01, когда GIF-ки только появились в ВК в 2013-ом, такого не было. Сейчас проверил - Вы правы, наверное недавно эту возможность добавили, как раз ради повышения производительности. Но кстати если убрать в конце ссылки параметр &mp4=1 и открыть источник в новой вкладке - то будет именно GIF.
  • На чем (за счет чего) рендерится html? Почему svg рендерится не с помощью видеокарты?

    на большей части сервисов - нет
    Сорри, не знал. Я говорю про те, что в вк кидают, там в основном гифки)

    я уверен, что гугл будет рад вашим практическим советам по ускорению хромиума. Мозилла также
    Они же и так работают довольно быстро) Не верите - скачайте Оперу Presto или откройте IE8 или даже IE9, и сравните с Chrome даже допустим версий 38-40 (не самых новых). Неужели не ощущаете разницу? У Mozilla всё печальнее было до версии 57, тут согласен. Да и сейчас есть проблемы, но скорее с совместимостью, чем со скоростью.

    Средний гиф - 10-50 сек
    Да, я видел гифки и на 40-50 секунд. Но всё-таки там имхо не так много динамики, часто много планов, которые длятся относительно долго почти без изменений. В GIF же можно задавать произвольную задержку перед отображением следующего кадра (пруф). В любом случае, видео-кодек такой контент жмёт лучше (причём не портя цветность), тут спорить не с чем :)
  • Почему MySQL работает медленно на локальной машине (windows)?

    Извиняюсь за некропостинг, но мне тоже стало интересно. Нашёл вот эту статью. Читаю следующее:

    По тестам разработчиков OLS обходит примерно на 20% FastCGI, на 50% — mod_php и на 75% связку nginx + PHP-FPM.

    А теперь глупый вопрос: разве FastCGI быстрее чем mod_php для Apache? В той литературе, что я читал (правда, те книги были года 2005-ого) утверждалось ровно обратное, что Apache Module - менее стабильный и надёжный способ (в случае чего может упасть весь веб-сервер, плюс возможны проблемы с выводом ошибок в браузер), но существенно более быстрый, поскольку в этом случае php работает как часть процесса Apache, а не общается через сокет, или что-то вроде того.

    Какой способ всё-таки правильнее для Apache, FastCGI или подключение модуля? Лично я под виндой для разработки всегда использовал второй, однако на современных вебхостигах часто вижу подключение через FastCGI как единственный доступный вариант.
  • На чем (за счет чего) рендерится html? Почему svg рендерится не с помощью видеокарты?

    они у вас, уважаемый, не тормозят потому как они все в мп4

    Простите, кто в mp4 у меня?.. Мы про гифки изначально говорили. Они именно в GIF

    Проблемы в том, что гиф не видео, и обрабатывается как набор картинок

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

    В ие6-7 тормозило если жс криво написали.

    Гифки там тормозили всегда. Как и JS, активно работающий с DOM (например, переставляющий на лету строки в большой таблице).

    гиф в 50мб ~ 1Mb mp4 === средненький гиф

    Простите, ЧТО?.. Даже 5-6 Mb - это уже ОГРОМНЫЙ гиф. Средненький - это 1-2 метра. Вы не забывайте, что в GIF обычно небольшой размер кадра и сильно порезанная палитра (обычно 256 цветов).
  • На чем (за счет чего) рендерится html? Почему svg рендерится не с помощью видеокарты?

    А что такого браузер с картинкой сделать может? Если б мог, то гифки б не тормозили как ад

    Простите, но они вроде и не тормозят, если их не очень много на странице)
    Вообще говоря, проигрывание гифки - это простая и лёгкая по нагрузке операция для процессора, если сравнивать, например, с воспроизведением полноценного видео в 48 или 60 fps (потому что там довольно тяжёлый декодинг и в разы большее разрешение). Но даже такое видео неплохо проигрывается на не самых мощных компах, если видеоплеер "умный" и грамотно работает с видеокартой и её возможностями по ускорению отрисовки/декодирования. Да даже при программном декодировании на CPU можно смотреть видео в 60 fps Full HD абсолютно без фризов на Intel Core i5 2500K (4 ядра по 3.3 GHz). Фризы начнутся только тогда, когда проц сильно загружен, напимер в фоне висит свёрнутая игра и жрёт 40-50 процентов CPU. В самом деле, для плавного воспроизведения гифки нужно просто создать буфер в RAM, где будет храниться каждый следующий кадр (можно имхо даже не париться с перенесением этих битмапов в память видеокарты, 60 fps должно потянуть и так).

    Проблемы скорее всего возникают потому, что когда гифок много, и они не синхронизированы (а браузер такие вещи обычно не синхронизирует), получается много-много таймеров, и итоговый фреймрейт (то есть частота, с которой нужно перерисовать весь экран) начинает сильно превышать 60 раз в секунду. Либо могут быть просто плохо настроены размеры кэшей разработчиком (никто их не настраивает под такой редкий кейс, когда на странице разом 200-300 анимаций крутится разом, настраивают под повседневное использование).

    Вот если вспомнить времена IE 7-8 - там вообще тормозило всё жуть. Даже при том, что браузер пытался всё синхронизировать. В новых браузерах с этим вроде почти ок (но я не говорю про гиф-видео, когда размеры гифок по 5-7 мегабайт).
  • С какой книги начать изучение javascript?

    есть ли разница читать книгу 15 года

    Я начинал вообще по книге 2004-ого года :) Остальное добирал по ходу дела. И да, когда я изучал, было начало 2008-ого, но я бы не сказал, чтобы этот срок как-то очень ощущался.
  • Хорошие книжки по JavaScript?

    а в том, что знание ES6 необходимо для прохождения собеседования

    Да знаю я его. Только вот пользоваться на практике - крайне не рекомендую. А зачем это на собеседованиях - вопрос к собеседующим :)

    Можно и на PHP 5, и на Java 6 писать.

    Так я и пишу. В чём проблема-то?

    Код чаще приходится читать, а не писать.

    Печальная у вас работа, если чаще приходится читать. Такое обычно касается тимлидов или людей, часто делающих код-ревью. Чужой код воспринимается плохо, намного хуже чем свой - даже если он хорошо или почти хорошо написан. Это по моему опыту) Ну и ещё это касается ленивых программистов, страдающих любовью к использованию сторонних библиотек и фреймворков - там да, часто что-то работает не так, как хочется, приходится вникать и допиливать.

    А стандарт вышел достаточно давно, чтобы на нем успели написать мегатонны кода.

    Согласен, но никто не мешает использовать более старые версии продуктов, которые выходили (и до сих пор работают на любых браузерах) до появления ES6.

    И отказ от изучения столь кардинальных нововведений в языке является остановкой в развитии, другими словами, профессиональным суицидом.

    То есть? Суицид в чём именно? Назовите хоть одну задачу, которую нельзя решить на ES5 (или которая решается в несколько раз или на порядок сложнее). Тогда у нас будет более предметный разговор. Пока вы просто сотрясаете воздух :) Такое ощущение, что вы больше теоретик, чем практик. Практику никогда не мешает отсутствие каких-то новых модных плюшек, потому что у него цель - сделать результат, а не наслаждаться процессом и собственной крутостью. И да, если текущая версия языка что-то делает плохо или не делает совсем - есть сторонние библиотеки, которые делают это, и делают хорошо. jQuery, loDash, mooTools, Ember, Angular, etc.
  • Хорошие книжки по JavaScript?

    Человек банально не устроится на работу - на каждом собеседовании на позиции JS/fullstack Developer задают вопросы по ES6

    ну так откуда ж я знаю, зачем они это делают. Можно вполне нормально и на ES5 писать код, там нет особых проблем. Хотя промисы конечно порой очень выручают.

    А вообще непонятна неприязнь к стандарту, вышедшему три с половиной года назад

    так дело не в том, когда он вышел, а в том, что он слишком многие концепции изменил в языке. Которые изначально делали JS тем, чем он был. Например, попытка запихнуть синтаксис наследования на классах, как в Java, и лямбды как в Haskell/F#.
  • Хорошие книжки по JavaScript?

    Strannyk, "поддержка старых браузеров требуется все реже" - в целом согласен. Но проблема в том, что тут старые - это не старьё-старьё вроде IE8 или Opera Presto. А даже, например, Chrome 48 и ниже (всё, что вышло до января 2016-ого). То есть уже в браузерах трёхлетней давности расчудесный код с let и const вне strict режима безнадёжно зафейлится, превратив весь ваш суперсовременный и динамический сайт в "кирпич" в виде белого полотна. Транспайлер для профи подключить несложно, но тут встаёт вопрос, как много фич от ES6 нам реально нужно. Если это замена var на const в 2-3 местах и всё - то имхо игра вообще не стоит свеч.

    "а насущная необходимость" - а вот тут несогласен абсолютно. Нет такой необходимости вообще ни разу. Хотя для анализа чужого кода, конечно, бывает полезно знать, что такое стрелочная функция и Promise.

    "(фреймворки и пр.) заточены под ES6" - тоже не соглашусь. Когда мы пишем на фреймворке, мы используем синтаксис фреймворка (в основном), а не синтаксис чистого ES5 или ES6. А если фреймворк тупо требует новый браузер для работы, потому что сам написан с использованием ES6 - тут конечно печалька. Или искать более старую версию для кроссбраузерности, или пытаться прогонять через транспайлер сам фреймворк... Я лично таким не занимался, слава Богу.
  • Почему говорят, что Javascript сделан на коленке?

    makarychev13, ну вот видите, сколько разных сущностей. Ещё и кортежи)

    А ведь в жизни намного чаще нужна именно переменная длина. Вы сами сказали, что есть списки - окей, но тогда не проще ли пользоваться ими всегда? Я вот иногда для себя что-то пишу на Java SE, так я уже не помню, когда в последний раз использовал обычный массив. Как правило нужны именно Vector или ArrayList коллекции. Там длина как раз переменная.
  • Как создать подобный слайдер?

    Максим Тимофеев, "Тогда что Вы преподаете? Что-то совершенно другое?" - да нет, как раз HTML, CSS и JavaScript. Но именно сам язык, а не либы. Уровень владения - довольно хороший. Я даже год назад написал работающий интерпретатор JS с полной поддержкой возможностей ES5 и частичной - ES6. Ну и опыт программирования на JavaScript и PHP года с 2009-ого примерно.

    "Я не видел нормального мидла в web, который бы получал меньше 10-15$ в час" - я не говорю про компании, я писал про фрилансерские сайты. Там всегда платят меньше :)
    Что до компаний... Туда не всегда так уж просто устроиться. Хотя бы из-за больших требований по знанию больших библиотек уровня jQuery и сложнее.