add standard for z-index #68 #73
Conversation
|
|
||
| - 0-9 — в пределах компонента; | ||
| - 10-19 — для элементов, расширяющих функциональность исходного компонента: всплывающие меню, подсказки; | ||
| - 20-25 — для элементов, относящихся к базовой структуре страницы или её специфичному функционалу: выезжающие меню, модальные окна. |
There was a problem hiding this comment.
почему у выезжающих меню и модальных окон выше индекс? Нам ведь нужно подсказки и всплывающие меню поверх них показывать
There was a problem hiding this comment.
то есть когда у статичной подсказки ползунка слайдера подсказка будет видна(без самого слайдера) поверх модального окна - это лучше?
There was a problem hiding this comment.
Или когда пункты навигационного меню можно открыть, хотя overlay модального окна должен не давать этого сделать
There was a problem hiding this comment.
то есть когда у статичной подсказки ползунка слайдера подсказка будет видна(без самого слайдера) поверх модального окна - это лучше?
да, если слайдер в самой модалке находится. Или подсказка. Вообще, я все штуки которые выходят за компонент рендерю наружу, в body, потому что иначе нужно гарантировать чтобы у всей цепочки контейнеров был overflow: visible чтобы показать этот компонент, а это накладывает серьёзные ограчения.
А у тебя видимо это стандарт подразумевающий что это всё структурно внутри рендерится но визуально находится снаружи. Мне кажется это худшая стратегия из за той необходимости overflow: visible
There was a problem hiding this comment.
А в чем собственно проблема? z-index же учитывает контекст наложения. С overflow: visible проблемой не сталкивался, потому что обычно такие штуки решал через абсолютное позиционирование.
There was a problem hiding this comment.
Спасибо большое за подробное пояснение. Что думаешь: можно добавить дополнительный пункт, описывающий данный случай и решение(добавив еще один диапазон для элементов, которые должны быть поверх диапазона 20-25, например: 30-40 ? Диапазон 10-19 тогда оставить для порталов из обычных(которые сами по себе не должны перекрывать другие компоненты) компонентов.
There was a problem hiding this comment.
Порталы используешь даже для таких элементов как: dropdown пункты навигационного меню у header? А если не используется React - добавляешь скрипты для позиционирования?
There was a problem hiding this comment.
если не используется React - добавляешь скрипты для позиционирования?
Ну я слава богу всегда использую реакт, поэтому не скажу тут.
Порталы используешь даже для таких элементов как: dropdown пункты навигационного меню у header?
Для этого скорее всего не стал бы через порталы делать. Портал нужен для низкоуровневых компонентов, элементы которых выходят за свою область типа всплывающей подсказки или всплывающего списка чтобы они всегда гарантированно показывались поверх остального. Эти элементы перестанут показываться если их вставить в край какой-нибудь таблицы с overflow: auto который нужен для скрола таблицы, или в край карусели с overflow: hidden который нужен для скрытия соседних слайдов.
Мне кажется что для стандарта тут слишком сложно, неполно и размыто получится. Тут получатся размытые категории для стандартизации, потому что могут быть разные контексты требований. На первый взгляд можно выделить такие категории:
- категория верхнеуровневых компонентов типа того же навигационного меню для которых можем гарантировать что контекст этих компонентов не сломает отображение меню;
- категория низкоуровневых компонентов, у которых есть элементы с контекстом наложения и которые не выходят за границы компонента;
- категория низкоуровневых компонентов у которых есть элементы с контекстом наложения и которые выходят за границы компонента.. Это те которые я через портал делаю.
Но нужно будет учитывать что, например, 3-ю категорию можно разными способами реализовать. Можно рендерить без порталов, но с применением алгоритма по поиску координат куда можно спозиционировать блок так чтобы он был виден. Для разных способов нужен будет разный подход к заданию индексов.
Ещё нужно учитывать что многие абсолютно спозиционированные элементы не должны показываться одновременно и соответственно их индексы не должны учитывать друг друга.
Мне кажется должны быть другие категории которые не описаны. Если человек возьмёт этот стандарт для такой категории, то он ему наоборот помешает, т.к. не решит проблемы и индексы заданные по стандарту не будут удовлетворять требованиям к результату, человек начнёт сомневаться что он правильно понял стандарт, прочитает ещё раз, начнёт спрашивать других, и всё это в конечном итоге займёт много времени.
Я думаю тут лучше бы подошёл формат статьи или доклада где ты бы описал проблему и способ её решения, такой формат был бы более понятен другим для восприятия и необязателен для случаев когда он не подходит. Потом люди бы могли перенять эту практику и ссылаться на статью или доклад когда считали бы что такой вариант решения хорошо подходит в их случае.
There was a problem hiding this comment.
Можешь, пожалуйста, привести пример категории/случая, который не вписывается в следующий алгоритм для z-index(для представленных тобой категорий будет следующее соответствие: 1 -> 10-19, 2 -> (-9)-9, 3 -> 30-39):
- диапазон < -9 для компонентов, которые должны быть ниже любых других;
- диапазон (-9)-9 для компоновки собственных элементов компонента, не выходящих за его пределы: наложение текста в картинках, range элементы range-slider-а;
- диапазон 10-19 для элементов компонентов, которые могут выходить за границы компонента или своего родителя, причем компонент сам по себе не предназначен для перекрытия других компонентов и есть гарантия что у всей цепочки контейнеров
overflow: visible: задуманные по дизайну декоративные элементы являющиеся частью блока позволяющие создать эффект не прямоугольной формы, всплывающие списки header-a; - диапазон 20-29 для компонентов, которые сами по себе должны находиться выше других компонентов: модальные окна, выезжающие из вне viewport меню;
- диапазон 30-39 для элементов компонентов, которые могут выходить за границы компонента или своего родителя, причем компонент сам по себе может быть как из диапазона (-9)-9, так и 30-39: подсказки для компонентов, календарь, dropdown список.
Стандарт больше рассчитан не на 100%-е определение конкретного значения z-index в каждом локальном случае, а на логическое разделение элементов на слои(диапазоны, из которых уже можно выбирать значения исходя из ситуации) - такое разделение должно помочь избежать проблем, когда из-за несогласованности разработчиков происходит неожиданное наложение из разных по категории элементов + когда выбор ограничен диапазоном, а не всеми доступными числами - проще выбирать и меньше путаница при росте количества компонентов.
Для написания статьи потребуется больше опыта, чтобы рассмотреть максимальное количество случаев, встречающихся в практике.
В случае если встретится какая-то неочевидная ситуация, то можно оформить новое issue и расширить стандарт на его основе. Да, это потенциально может добавить дополнительные трудозатраты в будущем(а может и не добавить), но проблем из-за общей несогласованности значений свойства в проекте больше, чем когда для 1 из разработчиков стандарт не подойдет под какой-нибудь unique случай.
There was a problem hiding this comment.
Можешь, пожалуйста, привести пример категории/случая, который не вписывается в следующий алгоритм для z-index(для представленных тобой категорий будет следующее соответствие: 1 -> 10-19, 2 -> (-9)-9, 3 -> 30-39):
Нет, мне сложно представить все случаи, просто предпологаю что они есть.
Стандарт больше рассчитан не на 100%-е определение конкретного значения z-index в каждом локальном случае, а на логическое разделение элементов на слои
Это уже не стандарт, а практика. Стандарт это штука которой должен соответствовать каждый проект, мне видится что далеко не каждому проекту он подойдёт, потому что, опять же, разные контексты. Если он не подойдёт то начнутся проблемы. Ты можешь гарантировать что из-за него не возникнет проблем?
но проблем из-за общей несогласованности значений свойства в проекте больше, чем когда для 1 из разработчиков стандарт не подойдет под какой-нибудь unique случай.
у меня вообще никогда не было проблем с индексами. В общем я против этого в стандартах. Если остальные находят это суперполезным - пожалуйста, добавляйте.
| - [2.15](2.15) `z-index` свойство назначать с учетом следующего алгоритма для значений: | ||
|
|
||
| - 0-9 — в пределах компонента; | ||
| - 10-19 — для элементов, расширяющих функциональность исходного компонента: всплывающие меню, подсказки; |
There was a problem hiding this comment.
почему мы не можем иметь те же индексы 0-9 что и в пределах компонента? Зачем переусложнять?
There was a problem hiding this comment.
чтобы логически отделить элементы видимые сразу от тех, что могут заезжать на другие блоки
|
|
||
| Мотивация: | ||
|
|
||
| - не придется задумываться над тем, какое значение назначить свойству; |
There was a problem hiding this comment.
а есть ли проблема такая вообще? Индекс пару-тройку раз используется чтобы показать одно поверх другого
There was a problem hiding this comment.
встречал пару раз неочевидные значения(999, 123456) из разряда: "ну чтобы наверняка перекрыл "
There was a problem hiding this comment.
Если разные разработчики создают компоненты: один модальное окно, другой - ползунки на слайдере накладывает. И им в лучшем случае придется договариваться, в худшем - будет неожиданное наложение
There was a problem hiding this comment.
Набросал примеров проблем, которые могут возникнуть: playground
#68