SM: фактическую ширину экрана на устройстве пользователя. Обычно хватает медиазапросов, даже для устройств с иной плотностью пикселей (если заморачиваться этим).
Erling: а зачем его загружать именно так? выкиньте собственно видео из попапа и добавляйте iframe со ссылкой на видео непосредственно перед открытием. Ссылку можно передавать через data-атрибут.
VZVZ: по-хорошему, конечно, чистый html возвращать не стоит ни в одной из реализаций API (хотя в некоторых случаях это может быть быстрее, например, в пагинации), но в целом, REST это не нарушает. Суть в том, что это концепция, который охватывает большой спектр возможных реализаций, а не конкретный набор технологических решений (в отличие от того же SOAP).
> JSON REST API, Cross-platform REST API
Имхо, тут человек хотел донести мысль о "REST API, возвращающем JSON". Необязательно изобретать термины, можно просто уточнить русским языком все, что этого требует)
VZVZ: стиль VK как раз относится к REST, т.к. фактически, у них есть только /user.delete, /user.create и т.п., а дополнительные параметры, очевидно, зависят от типа запроса (исключая токен). В user.delete используется GET, поэтому там передается ID, а в create - уже POST, поэтому там только токен. Опять-таки, токен иначе, как через get, не передать, а перемещать его между POST и GET данными в зависимости от запросов как минимум странно и ведет к лишнему коду в месте его проверки.
А вот второй пример лично я бы к REST не отнес, т.к. требование о прозрачности URL на мой взгляд выполнено плохо.
> когда с сервака можно запросить только сырые данные
Ну так и запрашивайте, возвращаемые данные не зависят от API. Это ведь всего лишь интерфейс доступа (в данном случае).
> AJAX не катит
Тоже не имеет значения, только проверку придется поставить другую, чтобы рядовой пользователь не мог баловаться с адресами API без токена, например. При запросах через AJAX сырые данные просто посылаются в вывод при помощи echo.
Антон Щербаков: а тут не обязательно парсить. Можно просто взять png, а скрипт наложил бы его на верстку в режиме умножения или разницы, не суть важно, чтобы расхождение было легче определить. Далее, определяем селектор в месте расхождения (phantom js это может), считаем размер расхождения в пикселах по 2м их 4х осей, и пишем в лог, в конце выдаем в консольку. Или что-то типа того, потому что времени порой отнимает порядочно)
У меня примерно такой же вариант) Но все равно, навскидку не скажешь - приходится в dev tools ручками подставлять значение. А, к примеру, разницу в расстоянии между двумя элементами можно просчитать автоматически.
Выглядит круто, но на практике точные и красивые значения в 270px, 20px и т.п. преобразуются в 273px, 17px и так далее, ибо, например, по факту у блока текста, кроме отступа, есть line-height, а дизайнер сделал отступ в 20 пикселов без учета этого расстояния. И так далее...
Александр Мальков: когда по две недели ждешь ответ на простейший вопрос на офф. форуме (где многие темы без ответов вообще), поневоле начинаешь понимать обратное. У того же WP или джумлы такого нет.
А сниппеты и плагины - это весь друпал. Только плагины в нем называются иначе, но сути это не меняет. В джумле сниппетов, кстати, нет, т.к. это лишнее.
werw: если три в одном - хорошее качество, быстрые сроки и цена ниже чем у остальных - проект гарантирован в 90% случаев. И совершенно не обязательно демпинговать в каждом проекте: три-четыре отклика, забрал проект, и все. Всему, конечно, есть пределы, но как правило, цены действительно очень большие, "за опыт", как говорится.
talas1234: чтобы читать неимоверно скудные доки, ждать ответа от хилого коммьюнити по 2-3 недели, бороться с адскими тормозами и адской бд (которые даже при кэшировании могут испортить жизнь), и писать сниппеты в процедурном стиле с какими-то идиотскими функциями - нужна железная воля и мазохистская любовь. Ах да, и устанавливать 20-30 плагинов (которые, как правило, тоже в процедурном стиле). По 2-3 плагина на каждую фичу - норма.
Да, но ссылки записаны в контенте страниц \ постов \ виджетов, то есть оптимальное решение - пройтись по всем постам в бд и дополнительно проверять на наличие ссылок перед сохранением. Далее, необходимо, как вы и указали, генерировать идентификатор для сессии пользователя, сохраняя его в таблице + добавляя rewrite rule для того, чтобы WP понял, что должна делать данная ссылка. 2-3 дня минимум.
А в рамках моих тикетов разработка плагина наименее предпочтительна) Поэтому я и спросил, может, такой уже имеется.
