Unprefixed classes causing issues with Box CSS

[adamgins]

Describe the solution you'd like Can we please get unminified CSS for all the UI elements https://github.com/box/box-ui-elements#css

Describe alternatives you've considered We've tried to edit the minified versions

Additional context We've go clashes with Box's CSS styles and ours

[DanDeMicco]

Hi @adamgins are you able to tell which selector is causing the clash? We try and prefix everything with .be

[adamgins]

@DanDeMicco thanks.
@dave-buzzy can you please let Dan know.

Dave's workaround was something like

           <div class="buzzy-box-picker  buzzy-box-explorer">
                 
            </div>
            <div class="box-container"></div>

We've also got some, what looks like z-index issues with the modal mode and for some reason the non-modal mode was not behaving with the addListeners did not seem to be picking up the change or cancel events as per https://community.box.com/t5/Platform-and-Development-Forum/Content-picker-event-choose-not-firing/m-p/60426

We tried with some the modal params but could not get it to work.Are there any examples on this pls? Without the params the modals were opening up behind out current modal. When we created our own modal we never received the events as above.

Below is without Dave's changes, it looks like standard Bootstrap button styles are clashing

With Dave's changes it contained the modal, albeit behind the other modal (z-index) but has not messed with our button styles.

boxFilePicker.show(folderId, accessToken, {
        container: '.box-container',
        modal: {
            buttonLabel:'Select/Upload from Box',
            modalClassName: 'buzzy-box-picker',
            // overlayClassName: 'overlay'
        }
    });

ps. was trying to get this ready for BoxWorld for IBM-ers at their ped :-)

[dave-buzzy]

@DanDeMicco @adamgins There's a whole bunch of very generic classnames in the Box css (as downloaded from eg https://cdn01.boxcdn.net/platform/elements/6.0.0/en-US/picker.css) that aren't prefixed - .btn-, .toggle, .menu-toggle, .radio-, .select-option and more which are causing headaches, since in our case this css is loaded after our main UI stuff and overwrites it.

My workaround was to dump the Box css wholesale (unminified via unminify.com - seemed to work) into our main .less imports, and wrap the whole lot in a more specific selector - eg:

.buzzy-box-picker {
    ... insert whole box-picker ui css here ...
}
.buzzy-box-explorer {
    ... insert whole box-explorer ui css here ...
}

Then when we use it we just make sure we're calling the Box stuff inside a container with the appropriate class.

<div class="buzzy-box-picker">
    ... insert boxpicker stuff here...
</div>

That way the Box css is quarantined from our other styles despite having common class names.

I haven't had a chance to look at the z-index issue, but assume that's gonna be simply a result of where and how the Box stuff is getting called in context of our UI, not anything to do with your css as such. If not, I should be able to hack the Box css now to suit since it's all exposed in our .less stuff now - won't be upgradable, but I will have more control :)

[dave-buzzy]

@DanDeMicco @adamgins

Ok, so the quarantining of the Box styles and unprefixed classes via css-specificity kinda works for the main UI.

However, the box UI uses a bunch of elements that are dynamically written into the dom - eg the dropdowns:

These are now outside the 'quarantined' container, and are now not rendering correctly since they are not receiving their css. Since the Box classnames need to work with the Box js, I can't simply go thru and prefix the css manually, hence the rough quarantine attempt. In the absence of Box providing prefixed styles (that work with their js), my only option would be to go through the css line by line and modify only the attributes of the unprefixed classes that specifically clash (ie comment out all visual styling stuff but leave any necessary z-index and layout attributes - but even then, these attributes will likely cause conflict).

[dave-buzzy]

~Actually, another hack would be if we could pass Box a 'parent' parameter which specifies where in the dom dynamic elements should be written - eg <body> appears to be the default, but if we could force the 'parent' to be <div class="buzzy-box-picker">, then the css specificity would still apply.~ [EDIT] Actually, forget this - likely to still not address everything. Would be a handy parameter to have tho.

[adamgins]

@DanDeMicco struggling a bit with the not getting events again...

The weird thing is it's working with Box.FilePicker() but not with Box.ContentUploader()

I actually copied my code from the picker to create the uploader files, changed params.

My files get uploaded, but I never get the 'upload' or complete events, I do get the 'close' event.

Any ideas what would prevent the ContentUpload from sending me these events?

here's my code

I am loading

        <script src="https://cdn01.boxcdn.net/platform/elements/6.0.0/en-US/picker.js"></script>
	<script src="https://cdn01.boxcdn.net/platform/preview/1.49.0/en-US/preview.js"></script>
	<script src="https://cdn01.boxcdn.net/platform/elements/6.0.0/en-US/uploader.js"></script>

then when the document is rendered...

var folderId = '0';

  	var boxContentUploader = new Box.ContentUploader();
  	boxContentUploader.show(folderId, accessToken, {

        container: '.box-uploader-container',

    });
    boxContentUploader.addListener('upload', function(file){
        console.log('upload',file, parentTemplateData);
		
    });
    boxContentUploader.addListener('complete', function(files){
        console.log('complete',files, parentTemplateData);
		
    });
    boxContentUploader.addListener('error', function(error){
        console.log('error',error);
 
    });
    boxContentUploader.addListener('close', function(){
        console.log('cancel');
     
    });

Any help appreciated

[adamgins]

Ah one other bit of info... as you see above I should be catching errors too.. .when I upload a file that I have already uploaded... that listener does not fire either... but I see this in the browser console OPTIONS https://api.box.com/2.0/files/content 409 (Conflict)

So the error event is not firing either.

[DanDeMicco]

Hey @adamgins this thread is getting hard to read and there are multiple issues. Lets leave this issue for the css stuff, and you can open up additional issues.

I see the issue you are reporting. The imports are not being scoped correctly in some .scss files. For example, see base.scss

@import '~box-react-ui/lib/styles/common/buttons';
@import '~box-react-ui/lib/styles/common/inline-notifications';
@import '~box-react-ui/lib/styles/modifiers/accessibility';
@import '~box-react-ui/lib/styles/common/overlay';
@import '~box-react-ui/lib/styles/common/pills';
@import '~box-react-ui/lib/components/pill-selector-dropdown/PillSelector';
@import '~box-react-ui/lib/components/notification/Notification';

.be {

These imports should be inside .be so scss will scope them to .be. We will add this to our backlog, but we would welcome PR's as well!

I think even with this being scoped, there will be some amount of css issues from the collisions still, but hopefully it should be more manageable. Ideally, all components within brui are unique and prefixed, for example .brui-btn-primary should be done, but is a pretty large project and will take some time.

[dave-buzzy]

Cool, thanks @DanDeMicco - thought it was something like that; we were/are in a rush on this, so the quarantining hack above was my best option of a workaround without forking anything and having to maintain stuff ourselves (beyond cut&paste).

Re. the dropdowns and stuff dynamically written into the dom mentioned above (https://github.com/box/box-ui-elements/issues/522#issuecomment-416428707), we've disabled the 'add' button in the picker for now, and everything else seems to be kinda ok for now (pending the styles getting prefixed). The z-index stuff @adamgins mentioned was our context/where we were rendering things and has also been sorted.

[EmmanuelCarrara]

Any news about a fix on this issue? I was using an older version and after updating to the latest version of the content explorer all the styles on my page are broken, mainly the ones that use menu-item and tooltip classess.

[Salengo-com]

I second Emmanuel to get an update.. trying to make CSS elements working with BootStrap is a nightmare. Thanks for your help.

[jtdaugh]

Any update here? This is a real bummer on an otherwise great library

[sahiga]

Hey folks, thanks for reaching out to us about this issue. We recently created a new next dist tag with namespaced CSS class names, e.g., bdl-Button instead of btn. You can see the changes in this commit. If you're using npm, you can upgrade to 11.0.0-next.1 to try out the new class names.

Please note that this release is experimental and thus will not be available via our CDN. If you find any bugs, please report them to us in this thread.

[adolski]

Does this issue mean that the Box UI Elements and Bootstrap are basically incompatible with each other? Is there an ETA on when a fix might appear in a release?

[BRafols]

Same here, I found a collision with the .modal as well.

BoxUI CSS: 11.0.2 Boostrap: 4.3.1

Last comment is 6 months old, has anything been release since that date?

[morkov4o]

any update ?

[jameschheng]

Any updates or plans on issuing a fix where the CSS does not conflict with existing bootstrap css classes and default elements (input, buttons, etc)?

[noseworthy]

Any updates on this? I'm still seeing issues in version 13.

[fargs]

Any updates on this? Still seeing lots issues with version 14. Modal forms, buttons, labels, etc.

[alexkrolick]

Thank you for providing specific examples of components with conflicting classnames. We are incrementally migrating to a new Box Design Language namespace (bdl- prefix).

[fargs]

Is there a version available for use that has these incremental fixes? There was a comment above that mentioned a "next" version available on npm but it was targeting version 11. Currently this is a blocking issue for us as it impacts the css on the entire site.

[alexkrolick]

Since v11 went to stable, every standard release has included incremental changes to add the bdl prefix to more components.

[cadobrovic]

I came up with a work around for the dropdowns breaking quarantined CSS.

For context, I'm trying to incorporate Box CSS into a React app with bootstrap and am also experiencing style collisions. I went with the same quarantine approach as @dave-buzzy and also noticed the dropdown menu issue because dropdown menus are mounted to the DOM outside the div where my quarantine classname box-content-explorer is applied.

The workaround I came up for this is to use a MutationObserver and essentially listen for the dropdown div being mounted to the DOM, selecting it by its first classname, dropdown-menu-element

Here's my implementation:

// Mutation Observer
// Define a function to apply the box-content-explorer class to a mounted element
function applyBoxExplorerClass(element) {
  element.classList.add('box-content-explorer');
}
// Create a new MutationObserver instance and pass in a callback function
const observer = new MutationObserver((mutationsList) => {
  // Loop through each mutation in the list
  for (const mutation of mutationsList) {
    // Loop through each added node in the mutation
    for (const addedNode of mutation.addedNodes) {
      // Check if the added node is a .dropdown-menu-element div
      if (
        addedNode.classList &&
        addedNode.classList.contains(
          'dropdown-menu-element'
        )
      ) {
        // Apply the box-explorer class to the added node
        applyBoxExplorerClass(addedNode);
      }
    }
  }
});
// Start observing changes to the body element
observer.observe(document.body, {
  childList: true,
  subtree: true,
});