Comments 15
Если фича сломалась в 15 версии хрома, почему вы не создали баг? В issue стоит 19 версия, а в ссылке на merged issue — 17. Чем раньше зарепортить баг, тем меньше мат ожидание даты его исправления.
-5
Я и создал. Там 100500 багов про этот transform3d.
+4
А у вас уже есть база регулярок? Быть может поделитесь наработками?
0
Да, мы некоторое время назад с грустью пришли к такому же выводу.
В копилку интересных артефактов: Android browser, элемент div с overflow: scroll. Метод scrollIntoView есть, ошибки не вызывает, ничего не делает. element.scrollTop существует, в него можно писать, тоже ничего не делает.
В копилку интересных артефактов: Android browser, элемент div с overflow: scroll. Метод scrollIntoView есть, ошибки не вызывает, ничего не делает. element.scrollTop существует, в него можно писать, тоже ничего не делает.
0
А что мешает использовать оба подхода? Сначала выполнить feature detection, а потом по необходимости подкорректировать результат его работы на базе значения user agent.
Работы меньше чем при использовании только user agent (т.к. вместо описания всех рабочих фич для всех известных user agent будут описываться только глючные фичи для некоторых user agent). Плюс имеем все преимущества feature detection.
Работы меньше чем при использовании только user agent (т.к. вместо описания всех рабочих фич для всех известных user agent будут описываться только глючные фичи для некоторых user agent). Плюс имеем все преимущества feature detection.
+2
Но мы получим и недостатки обоих методов. Нам придётся хранить и базу регулярок для определения браузера по юзер-агенту, и базу выражений для детекта той или иной фичи.
0
.Я не согласен, что мы получим недостатки обоих методов. База регулярок по UA будет на порядок меньше и проще. Что касается кода для детекта, он хорош тем, что (почти?) универсален и не привязан к UA, так что он выглядит достаточно чистым и адекватным, и я не понимаю, почему подключение этого кода Вы относите к недостаткам. На мой взгляд всё будет как раз наоборот — при таком подходе мы обойдём недостатки обоих методов (ошибочно положительный детект неюзабельных фич и громадную сложную базу регулярок ограниченную фиксированным набором юзерагентов).
+1
Я не понимаю, почему вы полагаете, что использование feature detection как-то уменьшит базу регулярок для определения версии браузера.
0
Потому, что вместо того, чтобы описать все поддерживаемые UA и все их фичи, которые можно использовать, достаточно будет описать только те UA, в которых некоторые детектящиеся фичи использовать нельзя (и только эти фичи для каждого такого UA). Такой список должен быть как минимум на порядок меньше, а скорее всего ещё меньше. И поддерживать его будет проще — вместо тестирования и добавления нового UA каждый раз когда выходит новая версия каждого браузера можно ограничиться пополнением этого списка по мере обнаружения новых багов.
+2
Как первое, так и второе не спасет от регрессий. Следовательно, часть примеров из статьи обосновывается частично неверно (к примеру, transform3d). Или вы предлагаете отключать что-то не для конкретных версий браузеров, а для всей ветки браузеров, в коих замечено некорректное поведение по средством юзер-агента?
+1
Sign up to leave a comment.
Небольшая заметка о feature detection