2 колонки там - ну просто дизайнер выровнял по сетке, чтобы красивее было.
Но завтра менеджеру захочется вместо Signup today написать Signup today for free - и все поломается.
Сколько лет в вебе, никогда валидность не пригодилась :)
Прогнать код через валидатор, конечно, полезно - помогает найти ошибки и опечатки.
Но как самоцель - это блажь. Хотя когда-то тоже стремился добиваться полной валидности.
Заставить машину смешивать пантоны с чем-то ещё или между собой? Чисто технически можно, конечно. Но какой смысл?
Они придуманы как раз для того, чтобы избежать смешивания. Фирма предоставляет каталог готовых цветов, чтобы они совпадали у всех пользователей в любой точке мира. Чтобы можно было в фирстиле написать - "пантон номер такой-то" и он был бы одинаков хоть в Чикаго, хоть в Саратове. Потому что он смешан заранее и налит в банку.
А если начать их бодяжить, это ломает всю идею. Более того, ни один софт не сможет точно предсказать, что в результате такого смешивания получится - только реальные цветопробы.
Могут мылиться шрифты и вообще мелкие детали изображения. Причем поведение часто разное в разных браузерах и разных ОС. Это сильно завязано на железо, драйвера и прочее низкоуровневое шаманство, не угадаешь.
Некоторые браузеры мылят всегда. Некоторые мылят в процессе анимации, но по достижении заданного масштаба опять делают четко.
В некоторых случаях у шрифтов пропадает сглаживание, они становятся с зазубринами.
Тут прежде чем фиксить, сначала локализовать его надо... Я вот немного покрутил это дело в разных браузерах и воспроизвести не смог. Как фиксить то, не знаю что? Нужно искать закономерности, при каких условиях проявляется.
В прошлый раз я забыл добавить. Дело не только в размере - я имел в виду, что библиотека вообще должна избегать того, чтобы вмешиваться куда-то вне своей прямой функциональности.
Если я пишу продукт - я его знаю и контролирую, поэтому могу использовать любые полифилы, которые сочту нужным. Но библиотека может применяться разными людьми в разных окружениях, поэтому может вызвать непредсказуемые последствия, если полезет куда-то (даже из благих побуждений). А что если там уже используют полифил, но другой? Или что-то своё написали?
И если взять условную jQuery - там внутри нет полифилов, там именно костыли для старых браузеров. Просто костыли отлаженные и легитимизированные :)
Насчет полифилов тут уже предлагали. Но после небольшого обсуждения аффтор ответа психанул и всё удалил :)
Понимаете, с полифилами дело такое. Если говорить абстрактно - дело правильное, но в конкретных ситуациях всё может быть наоборот. Конкретно в моем случае я не хочу полифил по двум причинам:
1. Мне не нужны 95% его возможностей. В целом меня устраивает нативная поддержка Set/Map в IE11, не хватает только одной фишки в одном месте. Подключать ради этого полноценный полифил - это типа как тащить jQuery ради одного селектора. Если бы мне нужно было использовать его в полный рост - вопросов не было бы.
2. Я считаю, что полифилы нужно подключать в продуктовом коде, но не в библиотечном (а у меня второй случай). Библиотека должна по возможности минимизировать свой вес и внешние зависимости.
По логике как бы верно, но по факту порядок там есть.
"The forEach() method executes a provided function once per each value in the Set object, in insertion order." https://developer.mozilla.org/en-US/docs/Web/JavaS...
Дима Соколов: например? rosolovsky: флекс по сути предназначен для управления однонаправленным потоком, в двумерном позиционировании он не алё, эту нишу гриды должны вот закрыть попозже.
Но завтра менеджеру захочется вместо Signup today написать Signup today for free - и все поломается.