Achei mais um conflito com os estilos do plugin, está acontecendo sobrescrita de estilos em componentes do Bootstrap (estou usando a v4.6).
Nos dropdowns do menu acontece isso, pois o Tainacan também utiliza as classes CSS .dropdown e .dropdown-menu.
Estilo conflitante (sem bordas, sem radius, padding menor):
Estilo padrão (com bordas, radius e padding):
Detectei esse problema também nos tooltips do Bootstrap, que ficam com o fundo da cor do Tainacan e não preto como o padrão.
De repente está acontecendo em mais locais, mas esses dois casos são os que detectei até o momento.
Acredito que a solução seja simples, porém trabalhosa: adicionar um “namespace” às classes CSS do plugin. Ex.: .tainacan-dropdown, .tainacan-tooltip, etc.
Ou usar estilos com escopo, caso eles estejam vindo do JS.
Tem algo que eu possa fazer no tema para mitigar ou somente alterando o código do plugin?
Então cara, essa é uma treta grande também… inclusive, descobrimos isso usando o Bootstrap no proprio Tainacan Interface. O que acontece é que o plugin do Tainacan usa uma biblioteca de componentes Vue .js chamada Buefy. Eles por sua vez usam a biblioteca de CSS chamada Bulma. Como muitos componentes da Buefy tratam de setar as classes da Bulma, não temos controle sobre o nome que as classes vão ter. Nem é possível colocar todas dentro de um escopo único, sem mexer no build dela.
Como você pode ver a discussão foi longe. Ela inclusive levou o mantenedor da Buefy à criar um outro projeto, muito interessante, o Oruga. Mas infelizmente o projeto ainda não está num ponto maduro para migrarmos pra ele, pelo que venho acompanhado.
No final das contas, é uma pratica ruim tanto do Bootstrap quanto da Bulma de ter estes nomes tão genéricos, mas que no início do nosso projeto, quando adotamos a biblioteca de componentes, nem nos passou pela cabeça. Hoje infelizmente a solução que eu vejo é tratar os casos de conflitos um por um.
Pois é, bem complicado mesmo. Realmente essas bibliotecas de estilos não costumam colocar prefixo nas classes. Daí gera esses conflitos quando se usa mais de uma, hehe.
Que pena que é um problema externo.
Vou acompanhar a issue para ver se algum dia se resolve.
Tentarei tratar os casos de conflito então, qualquer coisa reporto aqui.
Bom que fica a pressão aqui pra essa migração rolar um dia heheh. Eu tô otimista com a Oruga, só realmente ainda não tem os componentes que precisamos todos. Isso sem falar no TRAMPO que vai ser de reescrita e pensar como manter compatibilidade e tals… mas um dia sai
Só para reportar nesse tópico alguns testes que estou fazendo e entender como o plugin funciona. Estou tentando migrar meu tema para o Bulma. Pensei que fazer isso melhoraria a compatibilidade com o Tainacan.
Porém, percebi que mesmo assim o Tainacan adiciona estilos próprios que conflitam também com o Bulma. Como exemplo, estou tentando fazer um formulário inline com addons e os estilos do botão padrão estão sendo sobrescritos pelo plugin.
Segui o que está na documentação do Bulma, mas parece que a classe .button está com estilos próprios no Tainacan e não segue exatamente o .button do Bulma.
Estou gerando outro build pra você testar @ricardomoro. Em resumo, a questão não é simples porque não basta tratar de colocar todas as customizações em componentes dentro do escopo de divs relacionadas ao Tainacan… tem caras como os modais,diálogos e tooltips que tem o append feito direto na raiz do html. Mais recentemente, começamos a adicionar classes nestes elementos, quando permitido pela Buefy e pelo plugin V-Tooltip que utilizamos, mas preciso passar um pente fino ali.
O CSS vem de um bundle cujo enqueue é feito em todas as páginas do tema, já que ainda não há um modo de detectar em quais páginas existe um certo bloco gutenberg antes de fazer os enqueues. Na próxima versão teremos inclusive um filtro para des-registrar os blocos em algumas páginas, o que já ajuda pelo menos no carregamento. Então por enquanto, tentei mudar a maneira como estamos fazendo os @imports aqui pra ver se pelo menos em situações não relacionadas aos modais, díalogos e tooltips, as customizações ficassem retidas no contexto delas. Acho que deve resolver, só vai exigir alguns testes aqui com mais carinho pros diferentes temas.
Se quiser dar uma re-re-testada na coisa dos embed, fiz mais umas mudanças neles também. Acho que agora estamos pegando o jeito de como gerar as proporções certinhas pros diferentes tipos de aspect-ratios que os iframes geram
Enfim, o build tá no mesmo link que mandei o anterior, só atualizei o arquivo lá.
O que me confundiu foi que eu tinha entendido que o plugin usava o Bulma puramente. Então achei que esses estilos que são incluídos em todas as páginas vinham dele, não sabia que eram customizações.
Acredito que o Wordpress também tenha que amadurecer alguns aspectos dos blocos Gutenberg para facilitar essas detecções e personalizações por quem desenvolve plugins e temas.
Mas vamos testando, fico feliz em poder ajudar na melhoria do plugin para futuros desenvolvedores de temas próprios.
Muito obrigado, assim que testar dou um retorno aqui.
Ah sim, não mesmo! Apesar de ter a Buefy e Bulma de base, o projeto tinha uma equipe de designers no início que determinou uma identidade visual bem “opinated”, por isso tem customizações muito específicas pra cada elemento. E por mais que eu goste da Bulma como ferramenta, o ideal é que no futuro acabemos elaborando nossa própria framework CSS baseada na identidade visual do Tainacan justamente para podermos usar em algum sistema de componentes como o Oruga pra não termos estas tretas. Vale considerar também que no início era algo que ficava bontinho confinadinho lá no mundo do painel admin… daí um belo dia estes componentes viraram blocos e tudo começou a se misturar com os diversos temas WP
De qualquer modo, por enquanto evitar estes conflitos é algo que precisamos avançar mais e mais, com certeza.
Ah, seria excelente. Se for bem documentado para quem desenvolve temas vai ser ótimo. Daí eu migro meu tema para o design system do Tainacan.
Enfim, testei aqui e parece que não está aparecendo nenhum conflito até o momento. Durante o desenvolvimento estou percebendo que algumas classes estão se repetindo, sendo declaradas 2 vezes inline. Além disso o plugin está tentando carregar um arquivo que retorna 404: https://cdnjs.cloudflare.com/ajax/libs/bulma/x.y.z/css/bulma.css
É por causa da build de teste que você me enviou?
No mais, muito obrigado. Se eu achar mais alguma inconsistência eu reporto aqui.
Heheheh no fundo no fundo este é o Tainacan Interface, só lamento eternamente não termos começado ele com a mesma framework css de base.
E sobre isso, tô sabendo de onde vem… um do bloco de submissão de itens e outro do bloco de busca facetada… não estou muito seguro ainda de que vale tirar o import de algum deles por incerteza do outro existir. Por agora deve funcionar, mas a ideia é que no futuro vamos poder desabilitar quando um está registrado ou não, isoladamente.
