Самый простой способ.
Поднимаете локальный сайт на своём компьютере.
Как это сделать - инструментов море.
Далее.Создаёте PHP файл, который проходит по всем вашим страницам и с помощью регулярных выражений вытаскивает все ссылки на файлы изображений. Вам останется только сохранить их.
Это называется - парсер.
Sli_M, так как canvas вы удерживаете в фиксированном положении, то стоит подумать о просчёте разницы pageY offsetY и позицией самого canvas относительно самого документа.
При fixed элемент прилипает к краям браузера, а не родительского документа.
vantic131, в этом случае matchAll быстрее. Он сразу даёт результат и его можно использовать, чем каждый раз запускать регулярку на проход по тексту.
Т. е. matchAll -запустили и сразу выбрали.
pw0ned, если есть ссылка на пациента - лучше её.
Я могу только ванговать, что у вас в var countDownDate = <?php echo $count; ?>;
И соответственно смотреть консоль
slave bb, https://habr.com/ru/post/214407/
А дальше вам решать.
Комментарий зачем - я дал в своём ответе.
Лично мне незачем смотреть исходный код всей страницы, если я знаю где, как и зачем вызывается тот или иной компонент в разработанном мною же шаблоне динамического контента. Его генерирует используемая CMS, но по установленным условиям, опять же.
До html5 люди же работали с дивами? я работал, поддерживаю, переписываю и т. д. Время заставляет. И, как бы, не терялись, не путались, а код держали форматированным. Вот если он не форматированный - это проблема. А на выдаче он у меня вообще в одну строку сжат.
xmoonlight, не не. Сразу не будет. Это процесс автоматический. Т. е. если мы присвоили undefined - сборщик ещё будет его держать и очистит только при следующем проходе. Если бы он бегал постоянно - ловили бы подвисания всегда. Во Flash сборщик тоже не бежал сразу, если удаляется объект или мы вызывали его непосредственно. Мы просто указывали первоочерёдность удаления/проверки, что вот мы его явно удаляем и он нам не нужен, но ни как его непосредственный вызов.
Sli_M, у вас просчёт, если canvas - то от положения над этим элементом, но его перекрывают другие элементы. соответственно событие теряется, не поднимается. Поэтому вешать надо на document. Но тогда offsetY будет равен офсету именно элементу, который вызвал событие поднял на document. Правильней было бы брать позицию курсора относительно страницы. Т. е. pageY.
Данные свойства доступны в переменной события, возникающие в функциях обработчиках. Например canvas.addEventListener('mousemove', e => {})
Где e - и есть передаваемое событие в функцию. И т. д. по коду.
Т. е section или article не могут иметь тот же main, header или footer?
Покажите большой проект, где программист может потеряться в разметке.
Ибо в большом, как вы говорите, или в малом, а я могу утверждать, этого не произойдёт. Ну если только вы не на статике.
xmoonlight, а я то думаю, что же это за пытливый ум, который вдруг!!! заботится о памяти в JS )))
Ну тогда мне не придётся объяснять про профайлер, как это было в FD )))
xmoonlight, ну так запустите бесконечный цикл. Откройте профайлер и смотрим.)))
Хотя от Chromenium и так в ужасе в плане употретбления памяти в общей сложности.... что зависания Flash от рукожопости разработчика приложения, просто детский лепет.
HTML5 и всё иже с ним просто пропиарен и все дружно похоронили хорошую технологию. Adobe не обиделся и все смотрим, что происходит на самом деле. Иной раз просто нельзя держать десять вкладок открытыми, ибо видюха загружена по полной по 3D.
xmoonlight, а почему не корректно?
Всё правильно. Переопределение функции. Старое значение функции (переменной) будет удалено в последствии и это правильно, т. к. объект/функция больше не доступны после переопределения и, соответственно, будут удалены.