Вот интересный сервис, выполняющий описываемое в статье вращение объекта, чтобы понять, насколько он отклоняется от центра (если лень возиться с плагинами и прочим). Пользоваться, разумеется, надо с умом, так как, как и говорилось, способ подходит не для любой фигуры
А по первому — по статье вырисовывается подход, при котором компоненты вручную переворачиваются и проверяются там где нужно. Видимо, это из-за того, что в идеале хотелось иметь возможность держать на одной странице как RTL так и LTR компоненты? Может, добавить пример, как это могло бы выглядеть?
Для полноты картины читателям я бы рекомендовал рассмотреть подход, при котором весь CSS автоматически переворачивается, и следить надо только за исключениями (калькулятор, поле ввода телефона и прочие чисто LTR компоненты). Все приложения, конечно, уникальные, и у всех есть свои нюансы, но, честно говоря, впервые слышу что автоматическое переворачивание принесло больше проблем.
Также хочется предостеречь от использования глобального text-align на HTML. Желание поставить выравнивание текста на самый верх документа кажется поначалу логичным, но проблемы начнут возникать, как только в интерфейсе появится текст противоположной направленности (арабское имя или адрес в англоязычном, или, например, русское слово — в арабском интерфейсе). Наше общение с переводчиками на иврит и арабский показало, что хотя юзеры там уже привыкли к самым диким сочетаниям направления текста, наиболее привычно им читать по правилам языка. То есть носителю арабского, понимающему английский, наиболее удобно видеть арабский текст справа, а латиницу — слева (хотя и здесь будут исключения).
И в этом случае глобальный text-align начинает портить жизнь. Победить его можно c помощью text-align: initial, но, увы, это свойство не поддерживается в ИЕ<=11. Я бы предложил вообще не ставить его — браузер сам разместит текст как надо
Спасибо за пример со шрифтом — тоже нахожусь сейчас в стадии поиска подходящей альтернативы для арабского — попробую ваш подход.
А по поводу переворачивания стилей — возможно, я что-то упустил, и в статье указаны причины конкретного подхода, но вы не пробовали использовать какие-то плагины для отзеркаливания CSS или, как альтернативу, значения start и end для выравнивания, отступов и т.п.?
Ну так можно сказать про любое изменение CSS при любом подходе.
Нам в работе избегать такого позволяют несколько вещей:
— использование как можно более простых компонентов и грамотное их использование с учетом специфики проектов
— поддержание этих компонентов нейтральными и изолированными
— vrt-тесты на сами компоненты и их композиции
Вообще дизайн-систем довольно много в открытом доступе (ссылки есть в начале статьи), даже если их код скрыт. Как минимум можно ориентироваться на их подходы, а уж написать простой скрипт, который будет превращать один массив в другой под необходимые нужды, мне кажется, не очень сложно
Нам было бы не жалко, но по большому счету это не имеет смысла, так как несмотря на то, что все используют одни и те же компоненты (идеологически), у всех разные требования к ним. У кого-то у кнопок будут тени, у кого-то — позиция иконки, у кого-то — еще какие-нибудь параметры. Поэтому Кристиано говорит в первую очередь об идее.
Поделиться непосредственно дизайн-системой, возможно, стоит, но она пока тоже довольно специфичная. А вот про то, чтобы открыть какие-то внутренние инструменты для работы с токенами, мы подумаем. Тем более, что у нас команда увеличилась, и ресурсы на поддержку открытого кода могут быть. Я передам идею разработчикам.
Кнопка была одним из первых компонентов в дизайн-системе, поэтому (хотя казалось бы, должно быть наоборот) токенов для нее достаточно мало — высота, толщина границы, радиус скругления. Все остальное, на самом деле, там особо и не нужно. Текст внутри — это отдельная компонента со своими токенами, иконка — тоже. Чего не хватает и стоило бы добавить — например, отступ между иконкой и текстом, внутренние отступы. Это значения, естественно, тоже не захардкожены в стилях, но для них используется совсем абстрактный токен $token-spacer
Элементы ввода (input, textarea ) — там токенов чуть больше. Тоже как минимум высота, внутренние отступы, ширина границы. Но при этом мы не можем использовать внутри компоненты типографики. Также размер иконок в полях обычно фиксированный. Это привело нас к хранению размера шрифта, line-height, размера иконки. Все остальное уже зависит от этих значений обычно.
Строки — это специальная компонента типографики, которая может иметь один из нескольких типов — H1, H2, P1, P2, P3 и т.д. (на самом деле, это почти все, что нам надо). И для каждого типа токенов 2 — размер шрифта и высота линии
На начальных этапах развития системы мы больше использовали абстрактные токены ($token-spacer) для отступов, т.к. боялись чрезмерно усложнить систему, плюс потребителей ее было не очень много. Последние компоненты описываются уже только специфическими токенами (которые уже могут быть связаны с универсальными — $token-input-padding-horizontal = $token-spacer-small), т.к. мы поняли, что это не страшно и более удобно, особенно когда надо поменять стиль на всех компонентах на всех платформах одновременно.
javier.xyz/visual-center
А по первому — по статье вырисовывается подход, при котором компоненты вручную переворачиваются и проверяются там где нужно. Видимо, это из-за того, что в идеале хотелось иметь возможность держать на одной странице как RTL так и LTR компоненты? Может, добавить пример, как это могло бы выглядеть?
Для полноты картины читателям я бы рекомендовал рассмотреть подход, при котором весь CSS автоматически переворачивается, и следить надо только за исключениями (калькулятор, поле ввода телефона и прочие чисто LTR компоненты). Все приложения, конечно, уникальные, и у всех есть свои нюансы, но, честно говоря, впервые слышу что автоматическое переворачивание принесло больше проблем.
Также хочется предостеречь от использования глобального text-align на HTML. Желание поставить выравнивание текста на самый верх документа кажется поначалу логичным, но проблемы начнут возникать, как только в интерфейсе появится текст противоположной направленности (арабское имя или адрес в англоязычном, или, например, русское слово — в арабском интерфейсе). Наше общение с переводчиками на иврит и арабский показало, что хотя юзеры там уже привыкли к самым диким сочетаниям направления текста, наиболее привычно им читать по правилам языка. То есть носителю арабского, понимающему английский, наиболее удобно видеть арабский текст справа, а латиницу — слева (хотя и здесь будут исключения).
И в этом случае глобальный text-align начинает портить жизнь. Победить его можно c помощью text-align: initial, но, увы, это свойство не поддерживается в ИЕ<=11. Я бы предложил вообще не ставить его — браузер сам разместит текст как надо
А по поводу переворачивания стилей — возможно, я что-то упустил, и в статье указаны причины конкретного подхода, но вы не пробовали использовать какие-то плагины для отзеркаливания CSS или, как альтернативу, значения start и end для выравнивания, отступов и т.п.?
Нам в работе избегать такого позволяют несколько вещей:
— использование как можно более простых компонентов и грамотное их использование с учетом специфики проектов
— поддержание этих компонентов нейтральными и изолированными
— vrt-тесты на сами компоненты и их композиции
Поделиться непосредственно дизайн-системой, возможно, стоит, но она пока тоже довольно специфичная. А вот про то, чтобы открыть какие-то внутренние инструменты для работы с токенами, мы подумаем. Тем более, что у нас команда увеличилась, и ресурсы на поддержку открытого кода могут быть. Я передам идею разработчикам.
Элементы ввода (input, textarea ) — там токенов чуть больше. Тоже как минимум высота, внутренние отступы, ширина границы. Но при этом мы не можем использовать внутри компоненты типографики. Также размер иконок в полях обычно фиксированный. Это привело нас к хранению размера шрифта, line-height, размера иконки. Все остальное уже зависит от этих значений обычно.
Строки — это специальная компонента типографики, которая может иметь один из нескольких типов — H1, H2, P1, P2, P3 и т.д. (на самом деле, это почти все, что нам надо). И для каждого типа токенов 2 — размер шрифта и высота линии
На начальных этапах развития системы мы больше использовали абстрактные токены ($token-spacer) для отступов, т.к. боялись чрезмерно усложнить систему, плюс потребителей ее было не очень много. Последние компоненты описываются уже только специфическими токенами (которые уже могут быть связаны с универсальными — $token-input-padding-horizontal = $token-spacer-small), т.к. мы поняли, что это не страшно и более удобно, особенно когда надо поменять стиль на всех компонентах на всех платформах одновременно.