Скажу прямо, к вопросам доступности я отношусь пока довольно скептически. Складывается впечатление, что это скорее веяние моды, чем реальное понимание необходимости. "Так надо", "Это хорошие практики", "Все так делают". К тому же, часто люди, ратующие за доступность, сами мало чего в ней понимают (камень не в автора статьи). Больше того, не ясно, как без реальных устройств и тестов проверить эту самую доступность. Я много слышу от разработчиков рассуждений о доступности, однако ни бизнес, ни аналитика, ни тестирование никоим образом в этих терминах не рассуждают, ни денег, ни времени на это не выделяется.
И отдельно хочется уточнить статистику. Есть ли данные, сколько из тех 10% населения России являются постоянными пользователями интернета?
Нарушена бизнес логика процесса, пропущена пара важных вызовов, не обработаны ошибки, в конце концов даже возвращается не то, что нужно. А в остальном всё нормально! =)
ну… я решил откатиться до f32 ))))) и теперь у меня вообще ничего не запускается ))) так что я скоро буду снова счастливым обладателем девственной f32 ))
Накатил f33 поверх 32 версии
Перестал работать vpn, который прекрасно работал с 26 версии
В сети ничего не нашел, кроме того, что да, есть проблемы и вот так вот попробуйте…
Перестал работать acstreamplayer даже через snapd. Пообщался с разработчиком пакета для снапа, он здорово помог, ейс я запустил
в общем, обновление мне нанесло серьезный урон
Применение mounted вместо created оправдано даже при получении данных для компонента, если используется ssr. Злоупотребление created в ssr приводит к утечкам памяти. Так что надо поаккуратнее с этим
ну как… у нас есть dom-узел, у него есть свойства, которые появляются при парсинке html-разметки. То есть, в разметке мы прописываем тегу атрибуты (attributes), которые в итоге отражаются в свойства (properties) dom-узла. Если нам надо навесить обработчик события на какой-то элемент, в данном случае номер телефона, то нам надо работать именно с dom-элементом. Я об этом.
Сафари поступает иначе. Он получает html. Во вкладке Network видно, какой был ответ от сервера. Затем меняет текстовую ноду с телефоном на ссылку с href=«tel: тра-та-та» затем парсит это в dom-ноду с соответствующими свойствами. То есть, можно было бы (если я нигде не ошибся) повесить обработчик на эту ноду на уровне dom-properties не меняя состава dom-дерева. Тут, я правда, не уверен, при сравнении во время гидратации, не будет ли расхождением разные свойства этой самой ноды…
по идее, эта информация может быть полезной для индексации
по крайней мере, в нашем случае
ну а так, наверное можно так сделать
даже любопытно, что получится в результате? будет ли сафари потрошить такой, сгенерированный, код. но страница, скорее всего не обрушится
На мой взгляд, в текущей реализации этого функционала в Сафари, это вряд ли возможно. Он меняет дом, меняет атрибуты, создает новые ноды в дереве. При таком раскладе гидратация невозможна.
Ну либо эту часть сайта генерить только на клиенте, чтобы сервер вообще не знал о наличии телефонов
Надо поэкспериментировать, пока под рукой нет подходящего девайса. Вообще, от «бизнеса» не было задачи делать телефоны кликабельными.
По идее, если ссылки сами по себе уже содержат указание на кликабельность телефона, вряд ли сафари будет в это дело вмешиваться. Другое вопрос, это, как бы, вообще не его дело, кликабельны телефоны или нет. Хочешь сделать такой функционал, решай вопрос на уровне DOM-свойств и событий, зачем подменять html?
А почему это антипаттерн? Можете поделиться какими-то источниками, которые это обосновывают?
Спасибо за статью!
Скажу прямо, к вопросам доступности я отношусь пока довольно скептически. Складывается впечатление, что это скорее веяние моды, чем реальное понимание необходимости. "Так надо", "Это хорошие практики", "Все так делают". К тому же, часто люди, ратующие за доступность, сами мало чего в ней понимают (камень не в автора статьи). Больше того, не ясно, как без реальных устройств и тестов проверить эту самую доступность. Я много слышу от разработчиков рассуждений о доступности, однако ни бизнес, ни аналитика, ни тестирование никоим образом в этих терминах не рассуждают, ни денег, ни времени на это не выделяется.
И отдельно хочется уточнить статистику. Есть ли данные, сколько из тех 10% населения России являются постоянными пользователями интернета?
нет ли на примете полноценного проекта, написанного на rxjs?
Да, сильно некорректно написал:
Тип монады тот же самый, но тип значения новый
Спасибо за замечание!
Я ж так и написал:
)))
Статья для тех, кто интересуется этим вопросом. Вас никто не заставляет их использовать
так и есть =) но руки до нее пока не дошли
Нарушена бизнес логика процесса, пропущена пара важных вызовов, не обработаны ошибки, в конце концов даже возвращается не то, что нужно. А в остальном всё нормально! =)
Перестал работать vpn, который прекрасно работал с 26 версии
В сети ничего не нашел, кроме того, что да, есть проблемы и вот так вот попробуйте…
Перестал работать acstreamplayer даже через snapd. Пообщался с разработчиком пакета для снапа, он здорово помог, ейс я запустил
в общем, обновление мне нанесло серьезный урон
То, что mounted родителя вызовется после ребенка, — это скорее всего. но не факт
правда слабо представляю себе, как это на практике починить
ну как… у нас есть dom-узел, у него есть свойства, которые появляются при парсинке html-разметки. То есть, в разметке мы прописываем тегу атрибуты (attributes), которые в итоге отражаются в свойства (properties) dom-узла. Если нам надо навесить обработчик события на какой-то элемент, в данном случае номер телефона, то нам надо работать именно с dom-элементом. Я об этом.
Сафари поступает иначе. Он получает html. Во вкладке Network видно, какой был ответ от сервера. Затем меняет текстовую ноду с телефоном на ссылку с href=«tel: тра-та-та» затем парсит это в dom-ноду с соответствующими свойствами. То есть, можно было бы (если я нигде не ошибся) повесить обработчик на эту ноду на уровне dom-properties не меняя состава dom-дерева. Тут, я правда, не уверен, при сравнении во время гидратации, не будет ли расхождением разные свойства этой самой ноды…
по крайней мере, в нашем случае
ну а так, наверное можно так сделать
даже любопытно, что получится в результате? будет ли сафари потрошить такой, сгенерированный, код. но страница, скорее всего не обрушится
Ну либо эту часть сайта генерить только на клиенте, чтобы сервер вообще не знал о наличии телефонов
По идее, если ссылки сами по себе уже содержат указание на кликабельность телефона, вряд ли сафари будет в это дело вмешиваться. Другое вопрос, это, как бы, вообще не его дело, кликабельны телефоны или нет. Хочешь сделать такой функционал, решай вопрос на уровне DOM-свойств и событий, зачем подменять html?