92. LISTA LONGA

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.

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:

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.