Слить main: стороны сообщений поверх строки ввода iOS
Обе ветки правили строку ввода чата ради одной и той же полосы помощника форм над клавиатурой iOS. ADR-064 из main считал триггером элемент form и вынес поле наружу; на устройстве не помогло — полоса бывает у input и textarea всегда. ADR-069 отсюда заменяет поле редактируемым блоком, это и есть «следующий шаг» из следствий ADR-064. Что взято: - строка ввода — редактируемый блок (ADR-069/071), контейнер div с role="form" и кнопка type="button" (ADR-064); - лента — поток со сторонами, feed-list (ADR-065), не сетка; - brief.md: safe-area из ADR-075 и стороны из ADR-065 вместе; - app.css: правило 44 px для блока ввода; .author:empty из медиазапроса убран — main вынес его на верхний уровень, сетки больше нет. Убран слушатель submit: контейнер стал div, событие не случается. ADR-064 и ADR-069 связаны ссылками в обе стороны. sw.js VERSION → v6: клиент отличается от обеих версий, где стоял v5. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QR8uS3zGkybzWRW4GEY1oz
This commit is contained in:
Claude Opus 5
@@ -0,0 +1,30 @@
|
||||
# ADR-064: строка ввода — div, а не form
|
||||
|
||||
Уточняет `docs/ui.md`, «Доступность»: `form` в списке семантики держит `role="form"`, а не элемент `<form>`, — для строки ввода чата.
|
||||
|
||||
Пересмотрен [ADR-069](069-message-input-is-editable-block.md). Диагноз здесь неверен: полосу помощника форм iOS рисует не из-за `<form>`, а для любых `input` и `textarea`, — вынос поля из формы её не убрал. Контейнер `div` с `role="form"` и кнопка `type="button"` остаются, `textarea` заменён редактируемым блоком — тем самым «следующим шагом», который записан ниже в «Следствиях».
|
||||
|
||||
## Контекст
|
||||
|
||||
Тест с реальными пользователями (iPhone, Safari и Chrome): над клавиатурой при фокусе в строке ввода всплывает системная панель навигации между полями — «‹ ›» и «готово», около 50 px. Полю переходить некуда — оно на экране одно, — а место съедено.
|
||||
|
||||
Панель — не наша вёрстка, это поведение WebKit для полей, лежащих внутри `<form>`. Строка ввода была оформлена именно так: `<form class="compose">` с `<textarea>` и кнопкой `type="submit"`.
|
||||
|
||||
Дорогой вариант — `contenteditable` вместо `textarea` — снял бы панель гарантированно, но потребовал бы вручную переписать то, что сейчас даёт браузер бесплатно: placeholder, обрезку на 4000 символов, автовысоту, и обязательно — очистку `paste` до текста, потому что `contenteditable` иначе вставляет форматированный HTML, а `innerHTML` в клиенте запрещён (CLAUDE.md).
|
||||
|
||||
Дешёвый вариант — вынести поле из `<form>` — не трогает ничего из этого: `textarea` остаётся `textarea`.
|
||||
|
||||
## Решение
|
||||
|
||||
- `<form class="compose">` → `<div class="compose" role="form">`. `role="form"` — тот же ориентир для скринридера, что и элемент `<form>`, без вызывающих панель heuristics WebKit.
|
||||
- Кнопка отправки — `type="button"` с явным `click`, вместо `type="submit"` и события `submit` на форме.
|
||||
- `autocomplete="off"` на самом поле — на случай, если панель зависит ещё и от него, а не только от `<form>`.
|
||||
- `textarea`, `maxLength`, `field-sizing: content`, placeholder — без изменений.
|
||||
|
||||
Остальные формы (вход, `#/new`, участники, настройки) не тронуты: там несколько полей в форме, панель навигации между ними — по крайней мере, не чистый минус, и незачем менять то, что не жаловались.
|
||||
|
||||
## Следствия
|
||||
|
||||
- Проверить можно только на реальном устройстве — эмуляции панели WebKit нет; headless-Chromium её и не показывал никогда, так что автотест здесь не поставить.
|
||||
- Если панель не уйдёт (вдруг триггер — не `<form>`, а что-то ещё в эвристике Safari), следующий шаг — `contenteditable`, со всей его ценой из «Контекста».
|
||||
- `Enter` на десктопе и кнопка «>» на мобильном по-прежнему отправляют — обработчики `keydown` и `click` делают то же, что раньше `submit`.
|
||||
@@ -0,0 +1,28 @@
|
||||
# ADR-065: сообщения выравниваются по стороне — свои вправо, чужие влево
|
||||
|
||||
Пересматривает часть [ADR-024](024-identity-and-ui.md): десктопную сетку ленты «автор 132 px + текст» из `docs/identity/brief.md`, «Компоновка». Уточняет `docs/ui.md`, «Чат».
|
||||
|
||||
## Контекст
|
||||
|
||||
Тест с реальными пользователями: единый список с колонкой автора — десктоп сеткой `132px 1fr`, мобильный автором над группой — читается медленно. Чтобы понять, кто автор строки, нужно каждый раз смотреть в колонку слева; с чужого сообщения на своё и обратно глаз идёт через всю ширину.
|
||||
|
||||
Разделение по стороне, как в обычных мессенджерах, снимает это одним взглядом: своё — у своего края, чужое — у чужого. Айдентика «Скобы» этому не мешает и не помогает — про стороны сообщений там ничего нет, — но прямо запрещает пузыри, скругления и тени (`identity/brief.md`, «Цвет»). Значит выравнивание, а не bubble-чат: то же плоское сообщение, что и сейчас, просто у другого края.
|
||||
|
||||
Десктопная сетка `132px 1fr` для этого не годится: колонка автора у неё одна на весь список, слева, общая для всех строк. Разделить строки по сторонам в фиксированной сетке нечем — под это нужен один и тот же поток и на десктопе, и на мобильном, каким мобильный уже пользуется («автор над группой»). Решение — не расширять сетку, а убрать её: десктоп переходит на тот же поток, что мобильный.
|
||||
|
||||
## Решение
|
||||
|
||||
- Лента — везде (десктоп и мобильный) один поток блоков сверху вниз: автор и время строкой, текст под ними, без сетки.
|
||||
- Блок своего сообщения выравнивается по правому краю ленты, чужого — по левому. Свой ник в колонке автора остаётся цветом `mark` (ADR-024) — сторона и цвет вместе, не одно вместо другого.
|
||||
- Ширина блока ограничена (`min(640px, 85%)`), иначе выравнивать нечего: абзац во всю ширину ленты выглядит одинаково с любого края. Текст внутри блока остаётся выровнен по левому краю независимо от стороны — многострочное сообщение с рваным правым краем читается быстрее, чем с рваным левым.
|
||||
- Разделители дат и «новые» — во всю ширину ленты, не по ширине сообщения: они не принадлежат стороне.
|
||||
- Никаких фонов, рамок, скруглений и теней вокруг сообщения — это не бабл, а положение блока.
|
||||
- CSS-класс `feed-list` вместо `grid`: сетки в разметке больше нет, имя не должно об этом врать.
|
||||
|
||||
## Следствия
|
||||
|
||||
- `docs/identity/brief.md`, «Компоновка»: строка про сетку `132px 1fr` заменена на «поток, свои сообщения — у правого края, чужие — у левого, ширина блока ограничена».
|
||||
- `docs/ui.md`, «Чат»: абзац про ленту переписан под общий для обеих ширин экрана поток.
|
||||
- `docs/identity/screens.html` (эталон 2a/2b) обновлён: десктопный мок 2a больше не показывает сетку, оба мока показывают сообщения по сторонам.
|
||||
- Десктопная и мобильная лента визуально сближаются: раньше это были заметно разные раскладки, теперь — одна, с разной шириной блока и отступов. Разница экранов остаётся в сайдбаре, шапке и размере поля ввода (ADR-021, `identity/brief.md`).
|
||||
- Комната с тремя и более участниками: у чужих сообщений сторона всех, кроме себя, одна и та же (левая) — различает их по-прежнему только ник и цвет, сторона тут ничего не добавляет и не мешает.
|
||||
@@ -0,0 +1,25 @@
|
||||
# ADR-066: серверного «перца» для ключевого блоба нет
|
||||
|
||||
Закрывает последний открытый вопрос из `docs/open-questions.md`, поставленный при [ADR-006](006-e2ee-webcrypto.md).
|
||||
|
||||
## Контекст
|
||||
|
||||
Идея: шифровать ключевой блоб ещё раз серверным ключом, который лежит вне базы — например в `/etc/bare/env` рядом с VAPID. Тогда украденный дамп или бэкап сам по себе не даёт материала для оффлайн-перебора паролей. Против оператора это не помогает: у него есть и база, и файл с ключом.
|
||||
|
||||
Вопрос висел открытым с самого начала и мешает считать модель угроз закрытой: пока решения нет, непонятно, чего стоит ждать от следующей версии хранения.
|
||||
|
||||
## Решение
|
||||
|
||||
Перца нет. Блоб хранится так, как описано в [ADR-006](006-e2ee-webcrypto.md) и [ADR-013](013-password-policy-kdf.md): один слой шифрования, ключ выведен из пароля.
|
||||
|
||||
Аргументы:
|
||||
|
||||
- Рядом с базой появляется второй критичный артефакт. [ADR-003](003-sqlite.md) обещает «бэкап — копия одного файла»; перец это обещание ломает. Потеря файла с перцем — невозможность входа с новых устройств сразу для всех, а восстановления паролей в Bare нет by design. Для маленького самохостного инструмента риск потерять ключ при переезде выше риска, который перец закрывает.
|
||||
- Сценарий «утёк бэкап, но не сервер» уже закрыт [ADR-013](013-password-policy-kdf.md): PBKDF2-HMAC-SHA256 от 600 000 итераций и пароль от 12 символов делают перебор дорогим. Словарный пароль перец тоже не спасёт — при компрометации сервера он утекает вместе с базой.
|
||||
- Каждый дополнительный слой — код, который нужно аудировать, и оперативная процедура, которую нужно помнить. Простота важнее.
|
||||
|
||||
## Следствия
|
||||
|
||||
- Стойкость блоба в любом сценарии равна стойкости пароля, как и записано в `docs/threat-model.md`, «Слабый пароль». Новых оговорок в модели угроз не появляется.
|
||||
- Развёртывание остаётся «бинарь плюс файл базы»: ничего, что нельзя потерять, кроме самой базы, у оператора нет. `/etc/bare/env` восстанавливается по `docs/deploy.md`, VAPID-пара перевыпускается.
|
||||
- Решение обратимо: перец можно добавить позже отдельным ADR — он не меняет формат блоба, только оборачивает его.
|
||||
@@ -4,6 +4,8 @@
|
||||
|
||||
Уточнён [ADR-071](071-input-limit-cuts-what-arrives.md): предел держится до вставки и режет приходящее, а не хвост блока.
|
||||
|
||||
Пересматривает [ADR-064](064-composer-not-form.md): там ту же полосу пробовали убрать выносом поля из `<form>`, считая триггером форму. Не помогло — полоса бывает у `input` и `textarea` всегда. Контейнер `div` с `role="form"` и кнопка `type="button"` из ADR-064 сохраняются: событие `submit` в строке ввода больше не участвует.
|
||||
|
||||
## Контекст
|
||||
|
||||
На iPhone при фокусе в строке сообщения над клавиатурой висит системная полоса помощника форм: две стрелки перехода между полями и «готово». Стрелки неактивны — поле на экране одно, переходить некуда, — а полоса занимает место и ломает ощущение приложения, ради которого принят ADR-075.
|
||||
@@ -30,7 +32,7 @@
|
||||
|
||||
- Полоса помощника форм в чате исчезает. На экранах входа и «нового чата» она остаётся — там она и не мешает.
|
||||
- Проверить это можно только на iPhone: Chrome такой полосы не рисует вовсе, и никакой прогон её не увидит.
|
||||
- Строка ввода перестала быть элементом формы. Отправку это не меняет: Enter и раньше обрабатывал клиент, а кнопка «>» остаётся кнопкой отправки формы.
|
||||
- Строка ввода перестала быть элементом формы. Отправку это не меняет: Enter и раньше обрабатывал клиент, а кнопка «>» отправляет по `click` — `type="button"` и обработчик из [ADR-064](064-composer-not-form.md).
|
||||
- В запасном пути (браузер без `plaintext-only`) отмена набранного (cmd+z) не помнит нашей вставки: она делается руками, а не `execCommand` — тот в Chrome разбирает перенос строки в `<div>`, чего в блоке быть не должно. Там же держится `<br>`-заполнитель последней строки: перенос в самом конце браузер не рисует, и без заполнителя курсор оставался бы на прежней строке.
|
||||
- Автозаполнение и менеджеры паролей блока не касаются — в чате им нечего заполнять.
|
||||
- Записано в `docs/ui.md`, «Чат» и «Доступность».
|
||||
|
||||
Reference in New Issue
Block a user