Existem muitas BOAS razões para usar o @import.
Uma razão poderosa para usar o @import é fazer o design entre navegadores. As folhas importadas, em geral, estão ocultas em muitos navegadores mais antigos, o que permite aplicar formatação específica a navegadores muito antigos, como o Netscape 4 ou mais antigo, o Internet Explorer 5.2 para Mac, Opera 6 e versões mais antigas e IE 3 e 4 para PC.
Para fazer isso, em seu arquivo base.css, você pode ter o seguinte:
@import 'newerbrowsers.css';
body {
font-size:13px;
}
Na planilha personalizada importada (newerbrowsers.css), basta aplicar o novo estilo em cascata:
html body {
font-size:1em;
}
O uso de unidades "em" é superior às unidades "px", pois permite que as fontes e o design se expandam com base nas configurações do usuário, onde navegadores mais antigos se saem melhor com base em pixel (que são rígidos e não podem ser alterados nas configurações do usuário do navegador) . A planilha importada não seria vista pela maioria dos navegadores mais antigos.
Você pode sim, quem se importa! Tente acessar alguns sistemas corporativos ou governamentais antigos e antigos e você ainda verá os navegadores mais antigos usados. Mas é realmente apenas um bom design, porque o navegador que você ama hoje também será um dia antiquado e desatualizado. E usar CSS de maneira limitada significa que agora você tem um grupo ainda maior e crescente de user-agents que não funcionam bem com seu site.
Usando @import, a compatibilidade de sites entre navegadores alcançará 99,9% de saturação, simplesmente porque muitos navegadores mais antigos não lêem as folhas importadas. Ele garante que você aplique um conjunto de fontes simples básico para seu html, mas CSS mais avançado é usado por agentes mais recentes. Isso permite que o conteúdo seja acessível para agentes mais antigos sem comprometer as exibições visuais necessárias em navegadores de desktop mais recentes.
Lembre-se de que navegadores modernos armazenam em cache estruturas HTML e CSS extremamente bem após a primeira chamada para um site. Várias chamadas para o servidor não são o gargalo de antes.
Megabytes e megabytes de API Javascript e JSON carregados em dispositivos inteligentes e marcação HTML mal projetada que não é consistente entre as páginas é o principal fator de renderização lenta hoje. Sua página de notícias média do Google tem mais de 6 megabytes de ECMAScript apenas para renderizar um pouquinho de texto! ri muito
Alguns kilobytes de CSS em cache e HTML limpo e consistente com pegadas javascript menores serão renderizados em um agente do usuário na velocidade da luz, simplesmente porque o navegador armazena em cache a marcação DOM e o CSS consistentes, a menos que você opte por manipular e alterar isso por meio de truques de circo javascript.