Раскрывающиеся строки таблицы: как показать детали и не потерять контекст

Раскрывающаяся строка помогает оставить в таблице только данные для быстрого сравнения, а редко нужные подробности показывать по запросу. При хорошем устройстве человек понимает, какую запись он открыл, что именно добавилось и как вернуться к списку. Для этого заранее разделяют краткий итог и детали, обозначают действие кнопкой и проверяют поведение с клавиатуры, на узком экране и после обновления данных.

Такой приём полезен, когда основная задача — сравнить много записей по нескольким общим признакам, но для решения иногда нужны дополнительные сведения об одной записи. Например, в списке заказов достаточно видеть номер, клиента, дату, статус и сумму; адрес доставки, состав заказа и историю изменений можно показывать при раскрытии. Таблица остаётся сканируемой, а детали находятся рядом со своим объектом.

Проверьте, что скрываемая информация вторична, а не обязательна для сравнения каждого ряда. Если без неё нельзя понять, какая строка выгоднее, безопаснее вынести признак в отдельную колонку или разрешить пользователю настраивать набор столбцов. Раскрытие не должно превращать обычное чтение таблицы в обязательную серию кликов.

Есть и другие причины выбрать отдельную страницу, боковую панель или диалог. Если у записи длинная форма, несколько независимых вкладок, сложные действия или уникальный маршрут работы, одна расширенная строка станет тесной. Она особенно уместна для короткого набора уточнений, связанных с одним рядом и нужных время от времени.

Сначала определите минимальный состав строки, который позволяет узнать запись и сравнить её с соседними. Используйте устойчивый идентификатор и несколько наиболее значимых полей. Для заказа это может быть номер, получатель, итог, дата и статус; для документа — название, владелец, дата изменения и тип. Не пытайтесь поместить в сводку всё содержимое объекта мелким текстом.

Затем сгруппируйте скрываемые поля по вопросам пользователя: «Что входит?», «Где и когда доставят?», «Кто менял запись?». В раскрытии сначала показывайте ответ на наиболее вероятный вопрос, а не повторяйте колонки сверху. Короткие подписи помогают прочитать значения вне контекста заголовков таблицы: например, «Адрес доставки» яснее, чем один адрес без пояснения.

Полезно ограничить подробности несколькими компактными группами: атрибуты, пояснение, история, доступные действия. Если каждую запись приходится разворачивать, чтобы найти критичное поле, пересмотрите состав сводной строки. Если панель становится заметно длиннее нескольких строк таблицы, вынесите полный профиль в отдельный экран, сохранив в раскрытии краткое резюме и ссылку на него.

Номер и короткое название — Полное описание. Идентификация остаётся быстрой

Статус и итоговая сумма — Состав, условия и пояснение к сумме. Сравнение не смешивается с расшифровкой

Дата и ответственный — История изменений. Журнал нужен только при проверке

Явный признак проблемы — Рекомендация или доступное действие. Важное не скрывается за нажатием

Это пример распределения, а не универсальная схема колонок. Проверяйте его на реальных задачах и данных: некоторые пользователи могут считать важным совсем другой признак.

Интерактивный элемент лучше располагать в отдельной колонке рядом с идентификатором или в начале ряда. У него должна быть понятная подпись или доступное имя, например «Показать детали заказа 1842». Один треугольник без текстового контекста может быть неясен, особенно если таблица содержит однотипные кнопки. Визуально различайте закрытое и открытое состояния значком, поворотом стрелки и изменением фона раскрытой области.

Используйте настоящую кнопку, а не делайте кликабельной всю строку. В строке могут быть ссылка на объект, флажок выбора и меню; клики по ним не должны случайно открывать детали. Если вся строка всё же служит поверхностью для действия, вложенные интерактивные элементы требуют ясной модели событий и управления фокусом. В типовом интерфейсе отдельная кнопка проще для мыши, сенсорного ввода и клавиатуры.

Сообщайте состояние программно. Для кнопки раскрытия WAI-ARIA APG описывает состояние `aria-expanded`: `false`, когда область скрыта, и `true`, когда она видна. При необходимости `aria-controls` связывает кнопку с областью. Клавиши Enter и Пробел должны активировать кнопку так же, как нажатие мышью. Следите, чтобы скрытое содержимое было действительно недоступно до открытия, а фокус не терялся после переключения. См. паттерн Disclosure WAI-ARIA APG и справку MDN по aria-expanded.

Раскрытые детали должны читаться как продолжение конкретной записи: визуально связывайте панель с рядом отступом, фоном или тонкой границей и сохраняйте заголовки полей. Не полагайтесь только на цвет. Если область вставляется отдельной строкой HTML-таблицы, сохраняйте нативную структуру таблицы и корректно связывайте содержимое с записью; не добавляйте роли `grid` или `treegrid` автоматически лишь ради кнопки раскрытия. Это другой, более сложный интерактивный паттерн с дополнительными правилами клавиатуры.

Есть два рабочих варианта: разрешить открыть несколько записей либо держать открытой только одну. Несколько раскрытий удобны, если пользователь сопоставляет подробности двух-трёх объектов. Но они быстро удлиняют список и отодвигают соседние результаты. Единственная открытая строка сохраняет компактность, однако закрывает текущую запись при открытии следующей. Выбор зависит от задачи, а не от эстетического предпочтения.

Для сравнения предложений или товаров обычно стоит проверить вариант с несколькими открытыми строками и дать пользователю закрыть каждую отдельно. Для очереди обработки, где сотрудник поочерёдно разбирает один заказ, может быть понятнее единственная активная запись. Если переключение закрывает прежнюю строку, оно не должно менять выбор чекбоксов, сортировку или фильтр без объяснения.

Состояние раскрытия связано с конкретной записью, а не с номером видимого ряда: после сортировки третьей станет другая запись. Привязывайте состояние к устойчивому ID. При фильтрации, переходе на следующую страницу или обновлении набора данных решите, сохранять ли раскрытые записи. Для коротких списков запоминание помогает продолжить работу; при смене контекста сброс может быть ожидаемее. Главное — не допустить, чтобы панель одного заказа оказалась под строкой другого.

Раскрытие не должно ломать выбранный диапазон или позицию чтения. Виртуализированные списки иногда повторно используют DOM-строки; в них особенно важно привязывать состояние к идентификатору объекта и проверять его после прокрутки. Для подгрузки подробностей предусмотрите загрузку, пустой ответ и ошибку. В самой панели покажите, что происходит, дайте повторить запрос, если это уместно, и не заменяйте сводные данные мерцающей заглушкой.

На узком экране широкая таблица часто превращается в набор карточек. В таком виде раскрытие может стать аккордеоном внутри каждой карточки, но кнопка всё равно должна быть рядом с понятным резюме. Проверяйте длинные названия, локализованные значения и масштаб текста: кнопка не должна уезжать за экран, а важные поля не должны исчезать после переноса. Если строку приходится горизонтально прокручивать, доступ к раскрытию должен оставаться очевидным.

Пройдите интерфейс без мыши: переведите фокус на кнопку, откройте и закройте область Enter и Пробелом, проверьте порядок фокуса внутри подробностей и возврат к месту действия. Проверьте, может ли пользователь отличить несколько открытых строк. При изменении состава данных отдельно протестируйте удаление раскрытой записи и повторную загрузку. Эти сценарии ловят ошибки, которые не видны на неподвижном макете.

**Скрывать ключевой статус.** Если пользователь должен сравнивать строки по сроку, риску или сумме, не помещайте этот показатель только в детали. Иначе решение потребует раскрыть каждый ряд.

**Открывать детали нажатием на весь ряд.** Такое поведение конфликтует со ссылками, флажками и меню. Явная кнопка делает действие предсказуемым и доступным с клавиатуры.

**Менять порядок строк из-за локального состояния.** После сортировки или обновления раскрытие по индексу может прикрепиться к другому объекту. Храните его по стабильному идентификатору.

**Повторять таблицу внутри панели.** Дублирование колонок не объясняет объект и увеличивает высоту. Покажите только дополнительный контекст с короткими подписями.

**Добавлять анимацию без пользы.** Длинное движение задерживает доступ к данным и может мешать людям, чувствительным к анимации. Простое изменение состояния обычно достаточно; если используете переход, уважайте системную настройку уменьшения движения.

Не обязательно. Разрешите несколько открытых строк, если пользователи сравнивают детали нескольких записей. Оставляйте одну активную, если задача обычно состоит в последовательной обработке одного объекта. Проверьте решение на характерных рабочих сценариях.

Добавьте доступное имя, которое сообщает действие и идентифицирует запись: «Показать детали заказа 1842». Видимая подпись необязательна, но один и тот же текст «Подробнее» у десятков кнопок хуже ориентирует при навигации между элементами.

Да, если подробности содержат длинную историю, редактируемые поля, вложенные сущности или несколько этапов работы. Раскрывающаяся строка подходит для краткой расшифровки; она может содержать ссылку на полный профиль.

Это определяется сценарием. Если пользователь сравнивает соседние страницы, сохранённое состояние по ID может помочь; если набор стал другим после фильтра, сброс понятнее. Не восстанавливайте состояние по позиции ряда.

`<details>` — нативный HTML-элемент для раскрываемого содержимого, но он не всегда естественно вписывается в ячейки и структуру табличных строк. Прежде чем применять его, проверьте валидность разметки, семантику таблицы и доступность во всех целевых браузерах; отдельная кнопка с соседней панелью часто яснее.

Смотрите на самый плотный реальный фрагмент: длинное название, несколько подписей и значение с цифрами. Для проверки собственного рукописного начертания подготовьте шрифт в Fontgenerator, затем оцените его в макете на короткой сводке и раскрытой панели, а не только на крупном заголовке.

Раскрывающаяся строка работает, когда сводка остаётся полезной сама по себе, а дополнительная область даёт короткий ответ о конкретной записи. Разделите эти уровни, сделайте кнопку доступной, привяжите состояние к ID и проверьте поведение после изменений набора данных. Если подробности выросли в отдельный рабочий сценарий, покажите его на отдельном экране.