---
fonte: 01-canonicos/seed-componentes.md
versao_da_fonte: v1.43
secao: 92
titulo: "LISTA LONGA · **`estável`** (2026-08-24, F7.7-P5, uma decisão dele no gate) · LL1–LL6 · **fecha a BU-P1**"
sequencia: 98 de 98
bytes_do_corpo: 7617
md5_do_corpo: b1370c99c5e7a271892a1069daf31210
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-componentes.md
---
## 92. LISTA LONGA · **`estável`** (2026-08-24, F7.7-P5, uma decisão dele no gate) · LL1–LL6 · **fecha a BU-P1**

**O que esta seção é.** A regra de quando uma lista deixa de poder ser desenhada
do jeito simples. Fecha a terceira linha **❌ AUSENTE** do §6.1 e a pendência
**BU-P1**, aberta no §85.3 desde a F7.6.

### 92.1 Por que a regra nasceu de COBAIA, e não do acervo

A lista mais longa que existe aqui tem **38 itens** (`tela-quadro.html`). Nenhum
artefato nosso exercita o problema — o produto de referência medido no
`estudo-clickup-completo.md` §6.7 tem **~470 itens** num grupo. Logo a regra não
podia ser medida no acervo: foi medida em cobaia com carga estrutural igual à da
linha real do `tela-tabela.html` (9 campos, caixa de seleção, SVG de 9 formas,
chip ≈ 25 nós por linha), pelo instrumento
`06-validacao/ferramentas/mede-lista-longa.mjs`, mediana de 3 cargas frescas em
Chrome real, dado 100% sintético.

⭐ **Regra de método que fica: regra sem caso no acervo não se mede no acervo —
mede-se em cobaia, com a cobaia declarada.**

### 92.2 LL1 — a lista de TRABALHO é paginada (decisão dele: (a))

**O padrão da lista de trabalho é paginação**, não rolagem contínua. E o motivo
não é desempenho: é **achabilidade**.

A NN/g delimita o encaixe da rolagem infinita: itens **homogêneos, sem tarefa e
sem objetivo** — entretenimento, notícia, rede social. E nomeia o custo que
atinge trabalho: some o ponto de referência, e voltar a um item já visto fica
difícil (o "pogo sticking" devolve a pessoa ao topo). **Uma lista de ordem de
serviço é o oposto do caso de encaixe:** é heterogênea, com tarefa e com
objetivo.

A Deque enumera oito grupos prejudicados pela rolagem infinita — teclado (o foco
pula da última linha visível para o próximo nó na ordem do DOM), reconhecimento
de voz, comutador, tremor, baixa visão com ampliação, carga cognitiva, alcançar o
rodapé, e toque em tela pequena — e recomenda **"carregar mais" ou paginação**.

**Exceção declarada:** o **feed** (§87) é o único arquétipo homogêneo-sem-tarefa
da casa, e ali "carregar mais" com botão focável no fim é admitido — nunca
carregamento automático sem controle.

### 92.3 LL2 — o limiar medido é 2.000 linhas, e vale DENTRO da página

Orçamento de referência: **INP ≤ 200 ms** é a faixa "bom" das Core Web Vitals;
tarefa acima de **50 ms** já é tarefa longa.

| N | layout forçado (tabela) | layout (blocos) | clique→quadro (tabela) | clique→quadro (blocos) |
|---|---|---|---|---|
| 500 | 116,3 ms | 58,7 ms | 60,0 ms | 73,0 ms |
| 1.000 | 219,5 ms | 118,6 ms | 85,2 ms | 105,7 ms |
| **2.000** | **395,4 ms** | **222,8 ms** | **162,8 ms** | **166,9 ms** |
| 5.000 | 983,1 ms | 379,5 ms | 343,8 ms | 355,2 ms |
| 10.000 | 1.632,3 ms | 660,8 ms | 578,0 ms | 444,8 ms |

Em **2.000 linhas** um único layout forçado já custa **222–395 ms** — acima do
orçamento inteiro — e o clique consome **81–83%** dele. Em 5.000 a interação
passa de 340 ms, faixa "ruim".

**LL2-a** — abaixo de 2.000 linhas renderizadas, a lista é plana e simples.
Virtualizar aí é custo sem retorno.
**LL2-b** — acima de 2.000, vale a LL3.
**LL2-c** — 2.000 é **piso desta forma de linha**, não constante universal:
linha mais pesada baixa o limiar, e quem desenhar linha mais pesada **mede**.

### 92.4 LL3 — acima do limiar, contenção nativa — e o MATERIAL tem de ser bloco

Ganho da contenção (`content-visibility:auto` + `contain-intrinsic-size`) sobre o
plano, no custo de um layout forçado, medido:

| N | tabela `<tr>` | blocos `div` com papel ARIA |
|---|---|---|
| 500 | 1,04× | **5,87×** |
| 1.000 | 0,95× | **10,31×** |
| 2.000 | 0,93× | **15,37×** |
| 5.000 | 0,96× | **25,47×** |
| 10.000 | 0,91× | **17,44×** |

Mesmo CSS, mesma carga por linha, mesmos 9 campos, mesmo SVG. **O que muda é só a
caixa:** contenção de tamanho **não se aplica a caixa de tabela interna**
(`table-row`, `table-cell`), então `content-visibility` no `<tr>` é declaração
sem efeito.

**LL3-a** — lista que pode passar do limiar nasce em **blocos com papel ARIA**
(`grid`/`row`/`gridcell`), não em `<table>`.
**LL3-b** — a contenção mantém **todos os nós no DOM e na árvore de
acessibilidade**: focáveis, selecionáveis e **achaveis pelo Ctrl+F do
navegador**. É a razão de ela vir antes da virtualização.
**LL3-c** — `<table>` segue permitida abaixo do limiar, e as tabelas do acervo
hoje (≤ 15 linhas) ficam intactas.

### 92.5 LL4 — virtualização por JS só por MEDIÇÃO, e com compensação obrigatória

O que a janela por JS compra além da contenção é pouco — **1,11× · 1,22× · 1,24×
· 1,67× · 2,53× · 7,02×** — e cobra caro: **achabilidade = NÃO** em todo N ≥ 500
medido. O texto do item do meio **não está no DOM** e o Ctrl+F do navegador não
acha.

**LL4-a** — virtualizar exige **medição que mostre a contenção insuficiente**
naquele caso. Não se virtualiza por regra nem por hábito.
**LL4-b** — virtualizando, são obrigatórios: `aria-setsize` e `aria-posinset` em
cada item, com **`aria-setsize="-1"`** quando o total é desconhecido ou muda
(padrão da APG) · **substituto de busca dentro da lista**, porque o Ctrl+F deixou
de funcionar · **foco preservado** ao reciclar nó · **âncora de rolagem**, para a
volta não jogar a pessoa ao topo.
**LL4-c** — o contraexemplo está medido e é o vizinho: virtualizou ~470 itens e,
na mesma tela, o §8.4 do estudo mediu **0 `role="grid"`, 0 `role="row"`, 0
`role="gridcell"`, 0 `h1`/`h2`/`h3`, nenhum salto de conteúdo, 3 regiões
`aria-live` todas vazias, 249 focáveis, 90 alvos abaixo de 24×24**. *Virtualizar
sem pagar as compensações foi o que produziu uma lista impenetrável.*

### 92.6 LL5 — esta regra NÃO TEM conferência por declaração

⚠ `getComputedStyle(linha).contentVisibility` devolve **`auto` nas duas
estruturas** — em `<tr>`, onde não faz nada, e em bloco, onde faz. O estilo é
aceito, resolvido e reportado; só não tem efeito.

**Consequência normativa: nenhuma guarda pode aprovar esta regra lendo
declaração.** Uma guarda que perguntasse *"a lista longa declara contenção?"*
aprovaria uma tabela que não contém nada. **A única régua honesta é o tempo
medido.**

É a terceira ocorrência da mesma classe nesta casa — depois do
`document.fonts.check()` devolvendo `true` com a fonte falhando (§75) e do
resolvedor de fundo cego a gradiente. ⭐ **Regra que fica: quando o valor
computado e o efeito medido discordam, o computado não é evidência de nada.**

**Pendência `LL-P1`** — se um dia esta regra ganhar instrumento, ele mede TEMPO,
com orçamento impresso no placar, e é caro (classe do `contraste-composicao`, ver
CC-P1). Até lá, é gate humano com medição declarada.

### 92.7 LL6 — fronteiras

**Não** são desta seção: índice de busca, relevância e ranking (§85.3, produto) ·
estratégia de paginação no servidor (cursor × deslocamento) · agrupamento e
recolhimento de grupo, que são contratos do §40/DT8.

**Fronteiras da medição, declaradas antes de medir:** jank de rolagem
**[não conferido]** — tempo de quadro em navegador headless não representa o de
janela real · o FCP apareceu em 24 das 36 células, ausente exatamente nas páginas
mais leves, e serve de corroboração (blocos contidos pintam 1,4×–2,0× mais cedo),
nunca de número da regra.