Pull to refresh

Comments 15

Если фича сломалась в 15 версии хрома, почему вы не создали баг? В issue стоит 19 версия, а в ссылке на merged issue — 17. Чем раньше зарепортить баг, тем меньше мат ожидание даты его исправления.
Я и создал. Там 100500 багов про этот transform3d.
Сегодня появился новый интерфейс для репорта багов, который призван помочь ускорить их категоризацию и рассмотрение. Надеюсь ситуации когда важный баг висит по 6 версий, не попадая к ответственным за данную функциональность разработчикам, будут встречаться реже.
А у вас уже есть база регулярок? Быть может поделитесь наработками?
Не могу, коммерческая тайна :)
Да, мы некоторое время назад с грустью пришли к такому же выводу.

В копилку интересных артефактов: Android browser, элемент div с overflow: scroll. Метод scrollIntoView есть, ошибки не вызывает, ничего не делает. element.scrollTop существует, в него можно писать, тоже ничего не делает.
Андроидные браузеры — вообще песня с двумя припевами. 2.2, 2.3 и 4.0 — три разных браузера, блин.
А что мешает использовать оба подхода? Сначала выполнить feature detection, а потом по необходимости подкорректировать результат его работы на базе значения user agent.

Работы меньше чем при использовании только user agent (т.к. вместо описания всех рабочих фич для всех известных user agent будут описываться только глючные фичи для некоторых user agent). Плюс имеем все преимущества feature detection.
Но мы получим и недостатки обоих методов. Нам придётся хранить и базу регулярок для определения браузера по юзер-агенту, и базу выражений для детекта той или иной фичи.
.Я не согласен, что мы получим недостатки обоих методов. База регулярок по UA будет на порядок меньше и проще. Что касается кода для детекта, он хорош тем, что (почти?) универсален и не привязан к UA, так что он выглядит достаточно чистым и адекватным, и я не понимаю, почему подключение этого кода Вы относите к недостаткам. На мой взгляд всё будет как раз наоборот — при таком подходе мы обойдём недостатки обоих методов (ошибочно положительный детект неюзабельных фич и громадную сложную базу регулярок ограниченную фиксированным набором юзерагентов).
Я не понимаю, почему вы полагаете, что использование feature detection как-то уменьшит базу регулярок для определения версии браузера.
Потому, что вместо того, чтобы описать все поддерживаемые UA и все их фичи, которые можно использовать, достаточно будет описать только те UA, в которых некоторые детектящиеся фичи использовать нельзя (и только эти фичи для каждого такого UA). Такой список должен быть как минимум на порядок меньше, а скорее всего ещё меньше. И поддерживать его будет проще — вместо тестирования и добавления нового UA каждый раз когда выходит новая версия каждого браузера можно ограничиться пополнением этого списка по мере обнаружения новых багов.
Мы тогда говорим не о базе регулярок для определения версии браузера, а о том, как будут писаться условия на использование той или иной фичи (по версии браузера или по детекту фичи). База регулярок все равно останется той же.
Как первое, так и второе не спасет от регрессий. Следовательно, часть примеров из статьи обосновывается частично неверно (к примеру, transform3d). Или вы предлагаете отключать что-то не для конкретных версий браузеров, а для всей ветки браузеров, в коих замечено некорректное поведение по средством юзер-агента?
Разумеется, ничто не может спасти от регрессий.
Но отключить ту или иную фичу по условию на браузер/версию можно легко, а вот написать автотест на баг — бывает очень даже непросто, а иногда и невозможно.
Sign up to leave a comment.

Articles