I completely agree with not using the css .class selector in this scenario; however, I'd like to suggest an alternative solution.

It's my understanding that the 'hideLoadingMessage' functionality is only used to hide the loading message in embedded mode. Instead of adding a 'data-id' attribute, I feel like it'd be more clear if we added an attribute such as 'data-hide-for-embedded' ( or a better name ) and use that attribute to determine what we hide in embedded mode.

That way we're marking the elements based on the intention of what we intend to happen to them.

Also, I don't think that we need to mark the parent of the element that we want removed, and instead we should be able to use element.parentNode.removeChild(element);

Curious, how does this help with the brittleness? If someone deleted .kibanaLoadingMessage but left the onload function as it was, wouldn't we get in the same crash situation? Or does data-id do something special?

@kobelb I think those are great ideas. I'll update the PR.
@stacey-gammon The brittleness mostly stems from the fact that we may want to change the name of the class, which is now possible to do without breaking the JS. In the case that we're removing the element altogether, I'm thinking that the attribute will ring an alarm bell in the dev's mind that the JS is doing something special with that element, and will know to dig deeper into the JS. When we're using a class, there's no indication that there's a relationship with the JS. I think Brandon's suggestion will do an even better job of ringing that alarm bell because the name of the attribute will convey a lot more information.