Enterprise: Prise en charge de la configuration de l'élément de niveau supérieur

Je pense que nous en avons besoin pour d'autres cas, donc l'astuce consisterait simplement à ajouter une classe de niveau supérieur ids-enterprise et à la laisser en cascade seulement après cela. Ce serait un changement radical que nous pouvons atténuer facilement. Pourrait également l'ajouter à initialize () lorsque vous appelez cela (si les gens l'utilisent).

Serait-il possible d'ajouter un support pour soho pour ajouter un support pour ignorer des éléments ?
Dans notre cas d'utilisation, nous voulons que l'application soit stylée selon Soho, mais nous avons besoin d'un moyen de dire à Soho css d'ignorer certains éléments et ses descendants

par exemple, les éléments avec la classe seraient ignorés

.soho-ignore

peut - être que le

Je ne suis pas sûr que ce serait facile @Fruko Je suppose que nous devrions ajouter une deuxième feuille de style entière où nous :not() CHAQUE règle css? Par exemple, que se passe-t-il si vous utilisez une classe d'arborescence ou une liste déroulante ou toute autre chose, cela pourrait toujours causer des problèmes.

Je pense que l'autre façon de procéder consiste simplement à ne pas appliquer la règle ids-enterprise sur cet élément de niveau supérieur et cela servirait de non.

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

Merci de vous y être penché @tmcconechy ! Ceci et quelques autres problèmes (que je vais enregistrer) empêchent Infor Nexus de migrer vers IDS (nous sommes sur une version fourchue de Soho vieille d'un an), donc ce serait d'une grande aide.

Cool oui assez de cas d'utilisation pour ajouter ceci. Je l'examinerai bientôt. Je pense qu'il suffit d'exiger l'élément de niveau supérieur, mais cela peut signifier une version 5.0 juste pour suivre le versionnage sémantique avec un petit nombre de changements de rupture.

@tmcconechy mais qu'en est-il d'un scénario comme celui-ci

    <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>

étant donné le code ci-dessus, comment pouvons-nous nous assurer que ids-enterprise css ne dérangera pas "certains-composants-avec-propres-styles?

De mon point de vue, ajouter un élément racine à cascade css à partir de est une bonne idée pour commencer, mais je pense que pour rendre l'entreprise css utilisable, il doit y avoir un moyen de ne pas jouer avec d'autres parties des applications, si : not selector n'est pas une option, qu'en est-il du préfixe de toutes les classes ids-enterprise avec ids-enterprise ?

oui, j'ai pensé à préfixer toutes les options avec ids- mais c'est un changement beaucoup plus décisif. Pas sûr non plus que cela résoudrait ce cas précis si nous l'appelions simplement ids-accordion-content .

Pour ce cas précis, je pense que nous pourrions trouver quelque chose qui annule tout style dans le contenu de l'accordéon, mais je pense que ce serait un problème distinct. Et aurait à faire ce composant par composant.

Je doute simplement qu'il existe un bon moyen de créer une classe not-ids qui fonctionne sur chaque composant entier, peu importe où vous le placez. Donc ça va être plus une affaire au cas par cas pour ça.

Je me demande si une réinitialisation plus simple aiderait tho? Fx... ids-reset

• définirait la police, le remplissage, la marge et peut-être quelques autres éléments à la racine du document ?

Une sorte de réinitialisation inversée ? Peut-être utile dans certains cas, mais certainement pas dans tous ?

ça pourrait faire l'affaire

Ok va jeter un oeil avec ça. Ce n'est pas aussi grave que ce à quoi je m'attendais au départ.

J'aime l'idée du préfixe avec les identifiants. En fait, cela s'appelle le concept de "branding". C'est certainement un changement décisif, mais cela devrait être la voie à suivre pour la structure css ids-enterprisd à l'avenir.

Je suis d'accord pour pondérer la valeur par rapport au changement de rupture.

Vérifié ceci plus loin. Cela ne peut pas être fait sans un préfixe ajouté à la racine. J'espérais pouvoir trouver un moyen.
Dans le projet de nouvelle génération, tout a des préfixes et est autonome, ce ne sera donc pas un problème. Mettre cela de côté pour le moment mais ne pas fermer car nous pourrions avoir besoin de le faire sur une version majeure

Nous avons une solution dans la prochaine version 5.0 où chaque composant est un composant Web avec un css encapsulé et tous les css sont dans un espace de noms. Cela satisferait à ce problème si la fermeture

@tmcconechy c'est une excellente nouvelle ! Existe-t-il un bon moyen de savoir quand cela est généralement disponible ?

Vous pouvez garder un œil sur ce projet https://github.com/infor-design/enterprise-wc -> c'est loin mais l'année prochaine devrait avoir quelque chose de publié

Ca a l'air vraiment prometteur !