Foundation-sites: Точка останова «вниз» или «только» по-прежнему применяется к верхней точке останова

Созданный на 30 мая 2018  ·  3Комментарии  ·  Источник: foundation/foundation-sites






Как сообщил @JasonMiller на https://github.com/zurb/foundation-sites/pull/10978#issuecomment -393301646, новая точность точки останова ( 0.0001em ) представляет новую ошибку во всех основных браузерах (Chrome , Firefox, Safari ...).

Что должно произойти?

Для следующего кода:

$breakpoints: (
  small: 0,
  medium: 640px,
  large: 1024px,
);

.test {
    <strong i="17">@include</strong> breakpoint(medium down) { ... }
}

Свойства должны применяться для medium and under , поэтому для разрешения строго ниже 1024px .

Что происходит вместо этого?

Благодаря контрольной точке 63.99999em округляется до 64em в большинстве браузеров для их вычисления точки останова, свойства по - прежнему применяются на large контрольной точке за 1024px точно.

Эта проблема связана с:

  • # 10978 Исправить проблему точности точек останова с меньшим глобальным размером шрифта (@JasonMiller)
  • # 10820 пробел show-for () и hide-for () с точной шириной точки останова (@Lazerproof)
  • # 10695 Элементы 'show-for-small-only' и 'hide-for-small-only' отображаются с определенной шириной (@hofuchi)

Возможное решение


Как видно из # 10978, нам нужна субпиксельная точность для работы с увеличенными браузерами. Но браузеры плохо обрабатывают субпиксельные медиа-запросы, и слишком высокая точность вызывает описанную выше проблему. Поэтому мы должны найти правильный баланс для максимальной поддержки.

После некоторого исследования их собственных проблем (https://github.com/twbs/bootstrap/issues/19197) я взглянул на то, как Bootstrap справляется с этим (cc @cvrebert @mdo). Вот описание их функции Sass breakpoint-max .

Максимальная ширина точки останова. Нулевое значение для самой большой (последней) точки останова.
Максимальное значение рассчитывается как минимум следующего меньше 0,02 пикселя.
чтобы обойти ограничения префиксов min- и max- и области просмотра с> дробной шириной.
См. Https://www.w3.org/TR/mediaqueries-4/#mq -min-max
Использует 0,02 пикселя, а не 0,01 пикселя, чтобы обойти текущую ошибку округления в Safari.
См. Https://bugs.webkit.org/show_bug.cgi?id=178261

Таким образом, они используют точность 0.02px , для нас это будет что-то вроде 0.00125em , что близко к 0.001 предложенному @JasonMiller. Я бы согласился принять эту константу, но нам все же нужно провести некоторые тесты, чтобы убедиться, что преобразование em-px правильно выполняется браузерами.

Ваше окружение


  • Используемые версии Foundation: develop
  • Название и версия браузера (ов): протестировано в последних версиях Chrome, Firefox, Safari.
  • Операционная система и версия (настольная или мобильная): macOS 10.13.5 (бета)

Контрольный список (все необходимое):


  • [x] Я прочитал и подписан на документ CONTRIBUTING.md.
  • [x] Других проблем, подобных этой, нет.
  • [x] Название выпуска носит описательный характер.
  • [x] Шаблон заполнен правильно.




PR open Sass Mixins scss 🐛browser bug

Все 3 Комментарий

У меня возникнет соблазн обратиться к подходу начальной загрузки - я предполагаю, что он уже будет тщательно протестирован этим сообществом, если он находится в производстве.

@JasonMiller Я согласен. Я открыл PR с 0.02px по этой причине. См. № 11315.

Отлично, спасибо за быстрое наблюдение!

Была ли эта страница полезной?
0 / 5 - 0 рейтинги