Такое ощущение что вы уснули в 2010 и проснулись в 2016, а потом написали этот комментарий.
Win XP тащило все пережитки прошлого, вы как любитель делфи должны помнить WinAPI, а уж говорить о том что WinForms выигрывает против WPF — это вообще за гранью.
2 языка, вы серьезно? Даже последние версии делфи были заточены под .Net.
Silverlight сдох по той же причине почему сдох флеш — появился HTML5.
Вот за что стоит критиковать МS так это за то, что они не правильно прогнозируют развитие той или иной технологии и очень долго приходят к правильным решениям.
Когда-то давно профукали поддержку JS и веб-разработчики до сих пор смотрят на IE как на зло.
Потом профукали мобильный рынок и потянули за собой нокию
И точно так же паралельно профукали кроссплатформенность, хотя .Net именно первоначально под это задумывался, а реализовали только вот.
Вообще, не плохо чистит верстку, движок Gutenberg от WordPress. Создаешь минимальную тему с выводом поста, создаешь пост, сохраняешь. А далее переходишь по ссылке на сайт и копируешь чистый html. Конечно не так удобно как с онлайн редакторами, но зато все свое
Нет. Браузер знает фактический размер контейнера в котором рисует картинку (, <picture/>). Как он задан — второстепенный вопрос. Главное что итоговый размер известен браузеру.
Не согласен. Он узнает окончательный размер только при рендеринге всех соседних блоков и тогда сработает событие load. До этого блоки могут меняться, а если вы вообще никак явно не указали ширину то она будет нулевой.
Вот к примеру визуализация данной страницы, когда уходит запрос и когда закончен рендеринг. Запросы на картинки ушли на 2,2 сек, а применение стилей закончилось только 2,8 сек, а бывает что подключение стилей объявляют в футере и они отрендерятся (будет известен точный размер блока картинки) еще позже.
Вот можете сами убедиться о чем знает браузер и когда пример на codepen.io (Только открывайте с чисткой кэша)
А дальше откройте консоль к примеру этой странице на закладке network и посмотрите когда отработало событие DOMContentLoaded и load. В браузере большинство мелких картинок уже загружено еще до события DOMContentLoaded.
Я правильно понял: вы хотите чтобы браузер грузил url картинки в зависимости от ширины контейнера в котором находится эта картинка?
А вот если ширина контейнера не задана тогда что грузить, что-то по дефолту?
Идем дальше. Рядом с картинкой идет текст без переносов и он не помещается в свой блок, браузер начинает адаптировать его и уменьшает контейнер с вашей картинкой, что тогда, грузить еще одну миниатюру?
Ни разу не хватает. Я даже больше скажу это вообще не тот фактор который играет роль. Мне глубоков плевать какого размера окно.
Если у вас ширина картинок задана жестко то да ширина экрана вам и не нужна, но если вы знаете этот размер то можете туда и нужную картинку подставить. Ну разве что у вас этот размер меняется от ширины экрана но тут опять же, вы будете это делать через медиа.
Если у вас ширина контейнера(в котором будет картинка) задана относительно, то она точно зависит от ширины окна и тут снова медиа все решает.
Да бывают случаи когда заказчик хочет чтоб у него под все возможные ширины экрана были личные стили, но это уже зайоб заказчика и вот тогда приходится костылями на js решать, но чаще всего медиа достаточно.
Я потратил много времени на написание нормального Picture компонента, который, используя ResizeObserver, работает как надо (за исключением того что ResizeObserver очень ненадёжная штука). И у меня бомбит от того, что из каждого утюга пишут про то какой <picture/> хороший, при том какой он плохой. Прямо стыдно за коммитет, что они такую херню утвердили.
То есть вы сами говорите, что это не тривиальная задача, но хотите чтоб это встроили в ядро и оно само там как-то как догадывалось заранее кокой ширины будет контейнер. Я так понимаю, ваша реализация ждет рендеринга своего контейнера, а только потом начинает грузить картинку, а при ресайзе ее заменяет новой?
Браузер не может ждать пока отрендерится весь контент, чтоб точно знать ширину контейнера и определять, что ему грузить. Если бы так было то мы бы вернулись в 2000-е к IE который сначала текст отрисовывал, а потом по очереди грузил нужные картинки.
Собственно я это к чему все написал: во время загрузки ширина окна не меняется, она заранее известна и можно сходу понять какую картинку загрузить на основании media-правил, не ожидая когда оно там все отрисует.
С 5.1 версии WP для SVG файлов надо еще на хуке wp_check_filetype_and_ext изменить проверку заголовка, так как иногда в svg может отсутствовать заголовок xml, ну или ручками добавлять везде тот заголовок
Он с коробки специально фильтрует то что на 100% не поддерживается. Сделано это больше с целью обезопасить блогера, чтоб он не закидывал на сервер что не попадя.
Вот когда они начнут из коробки понимать WEBP, AVIF, HEIF…
Боюсь никогда, для генерирования этого (а WP из коробки как минимум нарезает миниатюры) всего надо в php добавлять библиотеки, и далеко не каждый хостер этим вообще будет заниматься.
Я тут один помню времена, когда не было flex и grid и колонки делались через float:left и это было очень прогрессивно, так как многие еще и таблицы использовали :).
Или для видео надо было мудрить флеш-плейер с js. А сейчас оно из коробки может показывать.
А уж про адаптацию под три-четыре браузера вообще вспоминать не хочется (хотя иногда приходится под сафари что-то доделывать)
Он ведь узнает это все когда загрузит картинку, а в вашем примере их три и получается надо грузить все три что узнать то что ему и не надо. Или я не правильно вас понял?
А все эти полумеры с srcset, sizes это прямо какой-то детский сад с очень ограниченным применением (мне пока ни разу не пригодилось, т.к. не было высеченных в скале layout-ов).
А зачем вам высеченный в скале шаблон, он же адаптивный должен быть и размера экрана как раз вполне хватает. Как правило выделяет два размера для ПК и моб, иногда еще один для планшетов(но чаще он совпадает с ПК). Я смотрю максимальную ширину для каждого шаблона и накидываю 20% чтоб не терялось качество, и вот под них пишем правила.
Все, браузер грузит только одну картинку. Гугл на 20% превышение ширины не ругается в своих оценках, скорость загрузки для мобильных заметно возрастает, контент не страдает.
У меня встречались случаи, когда надо не просто разные миниатюры одного изображения показывать, а абсолютно разные картинки под разные устройства и вот с этим Picture очень даже справляется. Это на много лучше чем пилить бекграундами с медиа в стилях.
А вот aspect-ratio и правда иногда не хватает, помню когда-то для магазина пришлось допиливать костыль на js
Удалось нагуглить что по ходу причина в том что я сижу под виндой.
env складываем переменные куда-то в ОС и при много-потокой обработке эти переменные в других потоках не доступны. По крайней мере я находил ишью где у людей схожая проблема. Самое простое это кешировать конфиги. но для локальной разработки не очень удобно, постоянно их обновлять.
Посмотрим, будут ли такие проблемы на серваке, а локально я уж переживу та и давно уже надо перейти в ubuntu хотя бы, а то аж не удобно :)
Извините, вопрос не по теме. Но может Вы подскажите в чем проблема.
Пару недель назад решил изучить и попробовать Vue в связке с Laravel (до этого SPA не делал) на одной из форм админки. Форма там сложная, надо в кучу данных собрать из 11-и таблиц с репитерами c взаимосвязанными селектами и вывести предварительные расчеты на фронте.
И вот из стора дергаю API. При загрузке формы там уходит сразу 7-м запросов (стоит их наверное объединить) и периодически один из них отвечает 422 статусом с ошибкой: No application encryption key has been specified.
Причем это происходит случайным образом (по крайней мере я не нашел фактора который на это влияет) для разны GET API и как правило только один запрос с ошибкой, остальные (предыдущие и последующие) -200. Просмотрел, у всех запросов одинаковые хедеры.
Все роуты для этих ajax прописаны в web.php.
Google естественно дает ответы только на то как сгенерировать key. Пока вижу решение просто делать повторный запрос, но как-то оно костыльно.
if (!empty($elements)):
foreach ($elements as $element):
// ...
endforeach;
endif;
или так :)
if (!empty($elements)) {
foreach ($elements as $element) {
// ...
}
}
И я еще могу понять, когда такие конструкции используют в шаблонизаторах, там и выбора особо нету. Но вот зачем так код писать в контроллере или даже при выводе html мне вот не понятно, типа чтоб в скобках не заплутаться?
При гуглении нашел единственное пояснение, что мол если писать в одну строку, без отступов, в блокноте, без подсветки синтаксиса, то вот тогда то будет проще :)
На сколько я понимаю, сейчас самым уязвимым местом становится браузер, который позволяет через скриптом вытащить кеш.
Почему все говорят о новых процессорах и обновлениях ОС и ничего про сами браузеры, можно ж на уровне браузера запретить выполнять операции с кешем? Да, что-то сломается но это терпимые потери по сравнению с проявившейся угрозой.
Или я все не правильно понял?
Win XP тащило все пережитки прошлого, вы как любитель делфи должны помнить WinAPI, а уж говорить о том что WinForms выигрывает против WPF — это вообще за гранью.
2 языка, вы серьезно? Даже последние версии делфи были заточены под .Net.
Silverlight сдох по той же причине почему сдох флеш — появился HTML5.
Вот за что стоит критиковать МS так это за то, что они не правильно прогнозируют развитие той или иной технологии и очень долго приходят к правильным решениям.
Когда-то давно профукали поддержку JS и веб-разработчики до сих пор смотрят на IE как на зло.
Потом профукали мобильный рынок и потянули за собой нокию
И точно так же паралельно профукали кроссплатформенность, хотя .Net именно первоначально под это задумывался, а реализовали только вот.
Но лучше уж поздно чем никогда.
Я так и не понял, редакс это плохо с точки зрения производительности или хорошо?
Вообще, не плохо чистит верстку, движок Gutenberg от WordPress. Создаешь минимальную тему с выводом поста, создаешь пост, сохраняешь. А далее переходишь по ссылке на сайт и копируешь чистый html. Конечно не так удобно как с онлайн редакторами, но зато все свое
Не согласен. Он узнает окончательный размер только при рендеринге всех соседних блоков и тогда сработает событие load. До этого блоки могут меняться, а если вы вообще никак явно не указали ширину то она будет нулевой.
Вот к примеру визуализация данной страницы, когда уходит запрос и когда закончен рендеринг. Запросы на картинки ушли на 2,2 сек, а применение стилей закончилось только 2,8 сек, а бывает что подключение стилей объявляют в футере и они отрендерятся (будет известен точный размер блока картинки) еще позже.
Вот можете сами убедиться о чем знает браузер и когда пример на codepen.io (Только открывайте с чисткой кэша)
А дальше откройте консоль к примеру этой странице на закладке network и посмотрите когда отработало событие DOMContentLoaded и load. В браузере большинство мелких картинок уже загружено еще до события DOMContentLoaded.
А вот если ширина контейнера не задана тогда что грузить, что-то по дефолту?
Идем дальше. Рядом с картинкой идет текст без переносов и он не помещается в свой блок, браузер начинает адаптировать его и уменьшает контейнер с вашей картинкой, что тогда, грузить еще одну миниатюру?
Если у вас ширина картинок задана жестко то да ширина экрана вам и не нужна, но если вы знаете этот размер то можете туда и нужную картинку подставить. Ну разве что у вас этот размер меняется от ширины экрана но тут опять же, вы будете это делать через медиа.
Если у вас ширина контейнера(в котором будет картинка) задана относительно, то она точно зависит от ширины окна и тут снова медиа все решает.
Да бывают случаи когда заказчик хочет чтоб у него под все возможные ширины экрана были личные стили, но это уже зайоб заказчика и вот тогда приходится костылями на js решать, но чаще всего медиа достаточно.
То есть вы сами говорите, что это не тривиальная задача, но хотите чтоб это встроили в ядро и оно само там как-то как догадывалось заранее кокой ширины будет контейнер. Я так понимаю, ваша реализация ждет рендеринга своего контейнера, а только потом начинает грузить картинку, а при ресайзе ее заменяет новой?
Браузер не может ждать пока отрендерится весь контент, чтоб точно знать ширину контейнера и определять, что ему грузить. Если бы так было то мы бы вернулись в 2000-е к IE который сначала текст отрисовывал, а потом по очереди грузил нужные картинки.
Собственно я это к чему все написал: во время загрузки ширина окна не меняется, она заранее известна и можно сходу понять какую картинку загрузить на основании media-правил, не ожидая когда оно там все отрисует.
Тут подробней
Боюсь никогда, для генерирования этого (а WP из коробки как минимум нарезает миниатюры) всего надо в php добавлять библиотеки, и далеко не каждый хостер этим вообще будет заниматься.
Я тут один помню времена, когда не было flex и grid и колонки делались через float:left и это было очень прогрессивно, так как многие еще и таблицы использовали :).
Или для видео надо было мудрить флеш-плейер с js. А сейчас оно из коробки может показывать.
А уж про адаптацию под три-четыре браузера вообще вспоминать не хочется (хотя иногда приходится под сафари что-то доделывать)
За статью спасибо про некоторые подходы не знал.
Так оно вроде так и работает
Прописал условия и вуаля
Он ведь узнает это все когда загрузит картинку, а в вашем примере их три и получается надо грузить все три что узнать то что ему и не надо. Или я не правильно вас понял?
А зачем вам высеченный в скале шаблон, он же адаптивный должен быть и размера экрана как раз вполне хватает. Как правило выделяет два размера для ПК и моб, иногда еще один для планшетов(но чаще он совпадает с ПК). Я смотрю максимальную ширину для каждого шаблона и накидываю 20% чтоб не терялось качество, и вот под них пишем правила.
Все, браузер грузит только одну картинку. Гугл на 20% превышение ширины не ругается в своих оценках, скорость загрузки для мобильных заметно возрастает, контент не страдает.
У меня встречались случаи, когда надо не просто разные миниатюры одного изображения показывать, а абсолютно разные картинки под разные устройства и вот с этим Picture очень даже справляется. Это на много лучше чем пилить бекграундами с медиа в стилях.
А вот aspect-ratio и правда иногда не хватает, помню когда-то для магазина пришлось допиливать костыль на js
env складываем переменные куда-то в ОС и при много-потокой обработке эти переменные в других потоках не доступны. По крайней мере я находил ишью где у людей схожая проблема. Самое простое это кешировать конфиги. но для локальной разработки не очень удобно, постоянно их обновлять.
Посмотрим, будут ли такие проблемы на серваке, а локально я уж переживу та и давно уже надо перейти в ubuntu хотя бы, а то аж не удобно :)
Извините, вопрос не по теме. Но может Вы подскажите в чем проблема.
Пару недель назад решил изучить и попробовать Vue в связке с Laravel (до этого SPA не делал) на одной из форм админки. Форма там сложная, надо в кучу данных собрать из 11-и таблиц с репитерами c взаимосвязанными селектами и вывести предварительные расчеты на фронте.
В шаблон блейда добавил токен в хедер
Прописал родительский тег
и подключил в футер собранный скрипт
В самом скрипте прописал автоматом передачу CSRF-токена
И вот из стора дергаю API. При загрузке формы там уходит сразу 7-м запросов (стоит их наверное объединить) и периодически один из них отвечает 422 статусом с ошибкой: No application encryption key has been specified.
Причем это происходит случайным образом (по крайней мере я не нашел фактора который на это влияет) для разны GET API и как правило только один запрос с ошибкой, остальные (предыдущие и последующие) -200. Просмотрел, у всех запросов одинаковые хедеры.
Все роуты для этих ajax прописаны в web.php.
Google естественно дает ответы только на то как сгенерировать key. Пока вижу решение просто делать повторный запрос, но как-то оно костыльно.
Подскажите пожалуйста в какую сторону рыть.
так
или так :)
И я еще могу понять, когда такие конструкции используют в шаблонизаторах, там и выбора особо нету. Но вот зачем так код писать в контроллере или даже при выводе html мне вот не понятно, типа чтоб в скобках не заплутаться?
При гуглении нашел единственное пояснение, что мол если писать в одну строку, без отступов, в блокноте, без подсветки синтаксиса, то вот тогда то будет проще :)
меня даже такое без скобок бесит
Возможно стоит немного почистить и саму базу в 2Гб
Почему все говорят о новых процессорах и обновлениях ОС и ничего про сами браузеры, можно ж на уровне браузера запретить выполнять операции с кешем? Да, что-то сломается но это терпимые потери по сравнению с проявившейся угрозой.
Или я все не правильно понял?