крч сделал через functions php, woocommerce_before_thankyou. может кому полезно будет но как то это очень не очень в плане концепции решения. может альтернативы какие существуют? или плагины позволяющие настраивать детально конечную фазу оформления?
Причем тут настройки пользователей? Если вы сами пишите, что неверно указываете разрешение файла...
тут дело не в не верном разрешении файла. объясню иначе. не важно загрузим мы картинку в webp формате, которая в адресной строрке будет как img.webp или же загрузим как фактический webp, но который в адресной строке будет подписан как img.jpg
пользователь на сафари ее не увидит, мы это проверяли методом тыка. сафари просто не читает webp, и не важно как он представлен. возможно дело в версии, но если уже двое человек сообщили о проблеме на сайте с весьма скромной посещаемостью, то проблема очень актуальна. чуть позже напишу какая у них версия браузера
Safari поддерживает формат (с iOS 14 / macOS Big Sur)
если вы про настройки мак\сафари то тут проблема пользователей, а не моя личная. т.е. эта проблема у многих посетителей с сафари будет, не вывешивать же им окно всплывающее с просьбой сменить настройки
Chukcha#: они могут их учитывать в комплексе с микро разметкой
Давно.. проводил єксперимет с ХК
Без разметки но с классом breadcrumb[s] Г определил как ХК
с разметкой ul Г определил как ХК
без разметки, без класса
Нужно ли ХК в nav, мне кажется -нет
пагинацию положил в nav и забыл..
далее было прикольно меню без nav в сниппете не было навигационных ссылок обернул в nav - в сниппетах появилось, но не на долго. Повисело и пропало
ну и.. капитан-очевидец The nav element represents a section of a page containing primary navigation links to other pages or to parts within the page.
Т.е. основные навигационные на другие части и по странице
Как вариант, например табы обернуть в nav
Четкой "рекомендации" на видел.
я тоже склоняюсь к тому чтобы только главное меню запихать (максимум вторичную). ну или оглавление по статье, с активными ссылками.
пагинацию явно не стоит туда пихать, как и всякие элементы по типу пред\след статья.
а вот с крошками как то даже хз. все таки в качестве seo шизы может и есть смысл? чтобы наверняка обозначить что это именно навигация а не часть контента, тк там ключи вхожи и все такое. но с другой стороны если система у вас сама поняла что это крошки, может и классов с айдишникиами хватит в избытке. у вас кстати класс этот прям так и назывался? "breadcrums", т.е. распознает ли в теории система если он будет иметь вид tuda-suda-breadcrumbs-tipa
Про интересующие вас теги - попробуйте найти в хелпах интересующих вас ранжирующих систем, а не на просторах левых фантазий. У создателей искалок свои тараканы.
ну это да. найти бы еще как спросить. в яндексе пусто, они похоже не особо воспринимают html5.
aside же. Просто там именно с точки зрения семантики смысл трансформируется. А дивы - ну, это просто чебурашки html, всё и ничего
ну т.е. с точки зрения такого "блочного семантического" разделения на main и "сопутствующее" - aside для сайдбара уместен. с тз фактического содержимого - aside уже для не уникального сайдбара не подойдет.
Виктор Петров#: Отталкивайтесь от семантики. Важна зона Main Content. Сайдбары в этом смысле - тот самый aside. Хотя, по факту, когда всю эту балалайку затевали, о смартфонах и речи особой ещё не шло, так что и слово "сайдбар" уже тоже по сути анахронизм. aside оставляйте для "сквозняков", сносок, связанного контента - и должно быть хорошо (к тому времени, когда это вообще начнёт на что-то влиять).
получается сайдбары просто в дивах оставить оптимально? в контексте постановки вопроса
но как то это очень не очень в плане концепции решения. может альтернативы какие существуют? или плагины позволяющие настраивать детально конечную фазу оформления?
у одного только выяснить получилось safari 15.0
iOS 10.15.7
походу в версии iOS дело
Причем тут настройки пользователей? Если вы сами пишите, что неверно указываете разрешение файла...
тут дело не в не верном разрешении файла.
объясню иначе.
не важно загрузим мы картинку в webp формате, которая в адресной строрке будет как img.webp
или же загрузим как фактический webp, но который в адресной строке будет подписан как img.jpg
пользователь на сафари ее не увидит, мы это проверяли методом тыка. сафари просто не читает webp, и не важно как он представлен.
возможно дело в версии, но если уже двое человек сообщили о проблеме на сайте с весьма скромной посещаемостью, то проблема очень актуальна.
чуть позже напишу какая у них версия браузера
Поменять разрешение на корректное пробовали?
Safari поддерживает формат (с iOS 14 / macOS Big Sur)
т.е. эта проблема у многих посетителей с сафари будет, не вывешивать же им окно всплывающее с просьбой сменить настройки
они могут их учитывать в комплексе с микро разметкой
Давно.. проводил єксперимет с ХК
Без разметки но с классом breadcrumb[s]
Г определил как ХК
с разметкой ul
Г определил как ХК
без разметки, без класса
Нужно ли ХК в nav, мне кажется -нет
пагинацию положил в nav и забыл..
далее было прикольно
меню
без nav в сниппете не было навигационных ссылок
обернул в nav - в сниппетах появилось, но не на долго. Повисело и пропало
ну и.. капитан-очевидец
The nav element represents a section of a page containing primary navigation links to other pages or to parts within the page.
Т.е. основные навигационные на другие части и по странице
Как вариант, например табы обернуть в nav
Четкой "рекомендации" на видел.
ну или оглавление по статье, с активными ссылками.
пагинацию явно не стоит туда пихать, как и всякие элементы по типу пред\след статья.
а вот с крошками как то даже хз. все таки в качестве seo шизы может и есть смысл? чтобы наверняка обозначить что это именно навигация а не часть контента, тк там ключи вхожи и все такое.
но с другой стороны если система у вас сама поняла что это крошки, может и классов с айдишникиами хватит в избытке.
у вас кстати класс этот прям так и назывался? "breadcrums", т.е. распознает ли в теории система если он будет иметь вид tuda-suda-breadcrumbs-tipa
И про мета кейвордс слышали?
Про интересующие вас теги - попробуйте найти в хелпах интересующих вас ранжирующих систем, а не на просторах левых фантазий. У создателей искалок свои тараканы.
ну это да. найти бы еще как спросить. в яндексе пусто, они похоже не особо воспринимают html5.
на https://developers.google.com долго мучал поиск, но не нашел ничего конкретного
может у вас есть конкретика, где искать или куда спрашивать?
С aside +- разъяснили, но что до других вопросов? крайне header интересует, т.к. по описанию тега очень желательно чтобы он включал в себя h1.
Во первых, допустимо ли его дважды вставлять? если да, то у меня есть 3 следующих конструкции как пример:
первая, где мы помещаем header внутрь артикля и мейна, насколько это правильно?
вторая, где мы выносим h1 из артикля, насколько это будет корректно применимо к артиклю?
ну и третья, где мы выносим h1 еще и из мейна
aside же. Просто там именно с точки зрения семантики смысл трансформируется.
А дивы - ну, это просто чебурашки html, всё и ничего
ну т.е. с точки зрения такого "блочного семантического" разделения на main и "сопутствующее" - aside для сайдбара уместен.
с тз фактического содержимого - aside уже для не уникального сайдбара не подойдет.
как то это все очень странно.
Отталкивайтесь от семантики. Важна зона Main Content. Сайдбары в этом смысле - тот самый aside.
Хотя, по факту, когда всю эту балалайку затевали, о смартфонах и речи особой ещё не шло, так что и слово "сайдбар" уже тоже по сути анахронизм. aside оставляйте для "сквозняков", сносок, связанного контента - и должно быть хорошо (к тому времени, когда это вообще начнёт на что-то влиять).