If I understand correctly and you're concerned about (what essentially amounts too) conflicts with the CSS, then including your own custom stylesheets after the library ones is the best starting point; as @rthor has pointed out.
However this may not solve every issue, purely because it also depends on the specificity of the CSS selectors. There's a good article here on CSS specificity - which should also enable you to effectively combat any CSS conflicts that arise.
Now scope? That's a different subject, and one that's a little more confusing - purely because of (surprise surprise) browser implementations differ. You can just a polyfill for older browsers but that's not great. It's purely a HTML5 feature it seems Unless you're talking about the :scope psuedo-selector.. which is working draft for CSS Selectors 4
I'm sure some front-end wiz will be able to give you low down specifically regarding scope, as I expect my solution leaves a little bit to be desired. You could always make use of container elements (gasp.. I know, not ideal.) and ensure all styles specifically target children of the a container element.
Essentially..
<div id="widgetA" class="scope"> <!-- So this is our 'scope' -->
<div id="bla bla">.....</div>
</div>
By ensuring all your CSS selectors begin with the container element:
div#widgetA{ /* We essentially get a scoped namespace */ }
However that comes with nasties such as non-semantic mark-up and overly specific selectors which are bad for performance. However, it has legacy support and is quick'n'easy.. albeit a bit of a hack. If you use something like Sass/Less you could even quickly wrap the whole libraries CSS file in a div.widget{ }
rule and compile it; giving scope (albeit with the above drawbacks).
Alternatively, from a javascript view - if you target specific elements (and only those elements), I can't see too many issues arising from libraries applying their own styling - as the libraries shouldn't really be tampering with other elements.
Good luck