Enterprise: Suporte para configuração de elemento de nível superior

Acho que precisamos disso para outros casos, então o truque seria apenas adicionar uma classe de nível superior ids-enterprise e deixá-la em cascata somente depois disso. Seria uma mudança significativa que podemos mitigar facilmente. Também poderia adicioná-lo a initialize () quando você chamar isso (se as pessoas usarem).

Seria possível adicionar suporte para soho para adicionar suporte para ignorar elementos?
Em nosso caso de uso , queremos app estilizado de acordo com Soho, mas precisamos de uma maneira de dizer ao Soho css para ignorar certos elementos e seus descendentes

por exemplo, elementos com classe seriam ignorados

.soho-ignore

talvez : não () seletor ajudaria?

Não tenho certeza se seria fácil @Fruko . Acho que teríamos que adicionar uma segunda folha de estilo inteira onde: não () CADA regra de css única? Por exemplo, e se você usar uma classe de árvore lá ou um menu suspenso ou qualquer outra coisa, isso ainda pode causar problemas.

Acho que a outra maneira de fazer isso é simplesmente não colocar a regra ids-enterprise naquele elemento de nível superior e isso serviria como um não.

<div class='ids-enterprise'>
   <!-- Soho / IDS stuff -->
</div>
<div class='anything-else-but-ids-enterprise'>
   <!-- Not Soho / IDS stuff -->
</div>

Obrigado por olhar para isso @tmcconechy ! Este e alguns outros problemas (que irei registrar) estão impedindo o Infor Nexus de migrar para o IDS (estamos em uma versão bifurcada de anos do Soho), então isso seria uma grande ajuda.

Legal, sim, casos de uso suficientes para adicionar isso. Analisarei isso em breve. Acho que exigir apenas o elemento de nível superior, mas pode significar uma versão 5.0 apenas para seguir o versionamento semântico com um pequeno número de mudanças significativas.

@tmcconechy mas e um cenário como este

    <div class="accordion ids-enterprise" data-demo-set-links="true" data-options="{'allowOnePane': false}">
      <div class="accordion-header">
        <a href="#"><span>Warehouse Location</span></a>
      </div>
      <div class="accordion-pane">
        <div class="accordion-content">
          <some-component-with-own-styles></some-component-with-own-styles>
        </div>
      </div>

dado o código acima, como podemos ter certeza de que ids-enteprise css não mexa com "some-component-with-own-styles?

Do meu ponto de vista, adicionar o elemento raiz ao CSS em cascata é uma boa ideia para começar, mas acredito que para tornar o css do enteprise utilizável, deve haver uma maneira de evitar que ele mexa com outras partes dos aplicativos, se: não o seletor não é uma opção, que tal prefixar todas as classes ids-enterprise com ids-enterprise?

sim, eu pensei em prefixar todas as opções com ids- mas é uma alteração muito mais inovadora. Também não tenho certeza de que resolveria esse caso exato se simplesmente o fizéssemos chamado ids-accordion-content .

Para este caso exato, acho que poderíamos chegar a algo que negue qualquer estilo no conteúdo do acordeão, mas acho que seria um problema separado. E teria que fazer esse componente por componente.

Só estou duvidando que exista alguma boa maneira de fazer uma classe not-ids que funcione em todos os componentes, não importa onde você os coloque. Portanto, será mais uma questão de caso a caso para isso.

Gostaria de saber se uma reinicialização mais simples ajudaria tho? Fx ... ids-reset

• definiria fonte, preenchimento, margem e talvez mais algumas coisas de volta para a raiz do documento?

Uma espécie de reinicialização reversa? Pode ajudar em alguns casos, mas definitivamente não em todos?

isso pode funcionar

Ok, vou dar uma olhada junto com isso. Isso não é tão ruim quanto eu esperava inicialmente.

Gosto da ideia de prefixo com ids. Na verdade, é chamado de conceito de "marca". Definitivamente, é uma alteração importante, mas deve ser o caminho a seguir para a estrutura css ids-enterprisd no futuro.

Eu concordo que devo ponderar o valor sobre a alteração de interrupção.

Verifiquei isso mais detalhadamente. Isso não pode ser feito sem um prefixo adicionado à raiz. Estava esperando que eu pudesse encontrar uma maneira.
No projeto da próxima geração, tudo tem prefixos e é independente, então isso não será um problema. Arquivando isso por enquanto, mas não fechando, pois podemos precisar fazer isso em uma versão principal

Temos uma solução na próxima versão 5.0, onde cada componente é um componente da web com css encapsulado e todos os css têm namespaces. Isso iria satisfazer este problema, então fechar

@tmcconechy, isso é uma ótima notícia! Existe uma boa maneira de rastrear quando isso está geralmente disponível?

Você pode ficar de olho neste projeto https://github.com/infor-design/enterprise-wc -> está longe, mas no próximo ano deve ter algo lançado

Parece realmente promissor!