Enterprise: Soporte para configurar el elemento de nivel superior

Creo que necesitamos esto para otros casos, por lo que el truco sería simplemente agregar una clase de nivel superior ids-enterprise y dejarla en cascada solo después de eso. Sería un cambio radical que podemos mitigar fácilmente. También podría agregarlo a initialize () cuando llame a eso (si la gente lo usa).

¿Sería posible agregar soporte para soho para agregar soporte para ignorar elementos?
En nuestro caso de uso , queremos que la aplicación tenga un estilo de acuerdo con Soho, pero necesitamos una forma de decirle a Soho css que ignore ciertos elementos y sus descendientes.

por ejemplo, los elementos con clase serían ignorados

.soho-ignore

tal vez : no () selector sería de ayuda?

No estoy seguro de que sea fácil @Fruko Supongo que tendríamos que agregar una segunda hoja de estilo completa en la que: no () ¿TODAS las reglas de CSS? Por ejemplo, ¿qué pasa si usa una clase de árbol allí o un menú desplegable o cualquier otra cosa? Todavía podría causar problemas.

Creo que la otra forma de hacer esto es simplemente no poner la regla ids-enterprise en ese elemento de nivel superior y eso serviría como un no.

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

¡Gracias por investigarlo @tmcconechy ! Este y un par de otros problemas (que registraré) impiden que Infor Nexus migre a IDS (estamos en una versión bifurcada de Soho de hace años), por lo que esto sería de gran ayuda.

Genial, sí, suficientes casos de uso para agregar esto. Lo investigaremos pronto. Creo que solo requiere el elemento de nivel superior, pero puede significar una versión 5.0 solo para seguir el control de versiones semántico con una pequeña cantidad de cambios importantes.

@tmcconechy, pero ¿qué pasa con un escenario 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 el código anterior, ¿cómo podemos asegurarnos de que ids-enteprise css no se meta con "algún-componente-con-estilos-propios?

Desde mi punto de vista, agregar el elemento raíz al CSS en cascada desde es una buena idea para empezar, pero creo que para que entreprise css sea utilizable, tiene que haber una manera de hacer que no juegue con otras partes de las aplicaciones, si: not selector no es una opción, ¿qué pasa con el prefijo de todas las clases ids-enterprise con ids-enterprise?

sí, pensé en prefijar todas las opciones con ids- pero es un cambio mucho más importante. Tampoco estoy seguro de que resolvería este caso exacto si lo llamáramos ids-accordion-content .

Para este caso exacto, creo que podríamos encontrar algo que niegue cualquier estilo en el contenido del acordeón, pero creo que sería un tema aparte. Y tendría que hacerlo componente por componente.

Solo dudo que haya alguna buena manera de hacer una clase not-ids que funcione en cada componente completo, sin importar dónde lo coloque. Así que va a ser más una cuestión de caso por caso para eso.

¿Me pregunto si un reinicio más simple ayudaría aunque? Fx ... ids-reset

• ¿establecería la fuente, el relleno, el margen y tal vez algunas cosas más en la raíz del documento?

¿Una especie de reinicio inverso? ¿Podría ayudar en algunos casos, pero definitivamente no en todos?

eso podría hacer el truco

Ok echará un vistazo junto con esto. Eso no es tan malo como esperaba al principio.

Me gusta la idea del prefijo con ids. En realidad, se llama concepto de "marca". Definitivamente es un cambio radical, pero debería ser el camino a seguir para la estructura css de ids-enterprisd en el futuro.

Estoy de acuerdo en tener que ponderar el valor sobre el cambio de ruptura.

Comprobé esto más a fondo. No se puede hacer sin un prefijo agregado a la raíz. Esperaba poder encontrar una manera.
En el proyecto de próxima generación, todo tiene prefijos y es autónomo, por lo que esto no será un problema. Dejar de lado esto por ahora, pero no cerrar, ya que es posible que tengamos que hacerlo en una versión principal

Tenemos una solución en la próxima versión 5.0 donde cada componente es un componente web con CSS encapsulado y todo CSS tiene un espacio de nombres. Esto satisfaría este problema, así que cerrando

@tmcconechy ¡ eso es una gran noticia! ¿Existe una buena forma de realizar un seguimiento de cuándo está disponible de forma generalizada?

Puede estar atento a este proyecto https://github.com/infor-design/enterprise-wc -> está muy lejos, pero en algún momento del próximo año debería haber algo lanzado

¡Parece realmente prometedor!