One way to think of Ionic is as a library of components that are optimized to be consistently usable in a multitude of different environments: Android, iOS, Electron, browser. Part of that consistency and usability is predicated on you and me not messing with their internals.
Perhaps you’ve heard of the bromide about certain libraries or frameworks “making ordinary tasks easy and difficult ones possible”. I fundamentally think this doesn’t really apply for web applications, for several reasons, including the fact that the ecosystem is so complex and the language we are working in (JavaScript) scales so poorly. So, instead, I would suggest thinking about things this way: is there a clear, documented way to build the house I want to build, given the building blocks I have lying around? If not, then go find different building materials. Don’t try to make a doghouse out of matchsticks.
So,
Shadow DOM exists to facilitate protecting components from external interference. Work with it; respect it - don’t try to subvert it. CSS variables are designed to allow you to change things that can be changed without breaking the overall promise of “consistent usability”. If I don’t find one that gives me the customization I initially desire, the first thing I do is to have a serious discussion about whether that’s really customization I should be doing. Most of the time, frankly, the answer is “no”. The restrictive nature of shadow DOM protects the work of people who know what they’re doing about UX design from idiots like me.
No, but not entirely for security reasons. It’s simply too low-level of an object to be futzing with, especially if you’re unfamiliar with the framework. You will instantly lose the forest for the trees. Take the time to go through the Tour of Heroes, and look for features and idioms that seem similar to the app you have in mind. Emulate them.
For an alternative approach that avoids innerHTML in a safe and extensible idiomatic Angular fashion, you may want to check out skeletons and bones.