CSS anchor positioning: o que faz e porque a MDN ainda fala em disponibilidade limitada

O posicionamento por âncora em CSS permite prender um elemento posicionado em absoluto a outro elemento, de modo que um tooltip siga o seu botão sem uma linha de JavaScript. É genuinamente elegante. Também é, segundo o próprio banner da MDN, algo que ainda não pode publicar sem condições - e muito do que foi escrito em 2026 afirma o contrário.

As três peças

O modelo é pequeno. Dá um nome a um elemento como âncora, aponta outro elemento para esse nome e posiciona em relação a ele.

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(left);
}

anchor-name regista o elemento sob um identificador personalizado. position-anchor associa o elemento posicionado a esse identificador. A função anchor() resolve-se depois numa aresta da âncora: anchor(bottom) é a aresta inferior da âncora expressa no espaço de coordenadas do elemento posicionado.

O que o torna mais do que açúcar sintático é o comportamento junto ao limite da janela. Um tooltip preso por baixo do seu gatilho deveria virar para cima em vez de ficar cortado, e essa viragem é exatamente a lógica pela qual existem todas as bibliotecas de posicionamento. A ancoragem oferece-a de forma declarativa através de posições de recurso: enumera colocações alternativas e o navegador escolhe a primeira que cabe.

Porque o entusiasmo se adiantou ao suporte

O Chrome lançou a ancoragem em 2024, e seguiu-se uma vaga de artigos a anunciar que o CSS nativo tinha substituído as bibliotecas de tooltips. Procure o tema em 2026 e encontrará afirmações de estatuto Baseline e percentagens de cobertura acima dos noventa.

A página da MDN para position-anchor exibe atualmente outro banner: disponibilidade limitada, com a explicação de que esta funcionalidade não é Baseline porque não funciona em alguns dos navegadores mais usados. É a documentação de referência da própria propriedade, e é a linha em que confiar quando as fontes secundárias a contradizem.

Não é motivo para ignorar a funcionalidade. É motivo para verificar você mesmo o banner na MDN no dia em que pensa publicar, em vez de herdar uma afirmação de um artigo que era otimista quando foi escrito.

Como usá-lo sem apostar nele

Consulte-o com uma feature query. @supports é a diferença entre melhoria progressiva e um layout partido para quem está no motor errado:

.tooltip {
  /* colocação de recurso que funciona em todo o lado */
  position: absolute;
  top: 100%;
  left: 0;
}

@supports (anchor-name: --x) {
  .trigger { anchor-name: --my-trigger; }
  .tooltip {
    position-anchor: --my-trigger;
    top: anchor(bottom);
    left: anchor(left);
  }
}

Escreva primeiro o posicionamento comum e deixe a versão ancorada sobrepor-se dentro da consulta. Os navegadores que percebem a ancoragem recebem o bom comportamento; os outros recebem algo que continua a funcionar.

O resumo honesto: a ancoragem vai na direção certa e vale a pena aprendê-la já, mas um tooltip em produção em 2026 ainda precisa de um caminho para os motores que não a suportam. Apagar a biblioteca pura e simplesmente é uma decisão a tomar a partir da tabela de compatibilidade, não a partir de um título.

Onde encaixa no resto da plataforma

A ancoragem combina naturalmente com a API Popover, que trata de mostrar e dispensar enquanto a ancoragem trata da colocação, e com o elemento dialog para os casos que exigem um modal a sério. Esses dois estão mais avançados no suporte, o que é parte da razão para recorrer primeiro a eles.

Em resumo

anchor-name marca a âncora, position-anchor liga-se a ela, anchor() resolve as suas arestas e as posições de recurso tratam da viragem junto a um limite da janela. A MDN lista a propriedade como de disponibilidade limitada e explicitamente fora do Baseline. Use-a atrás de @supports, mantenha um fallback comum e consulte a tabela de compatibilidade no dia em que publicar, em vez de confiar numa percentagem de um blogue.