Consider a Flex project with one main application file, a module including a Label with its styleName set to "myLabel", and two CSS files: Main.mxml, MyModule.mxml, main.css and module.css.

The CSS files are included (<mx:Style source=".."/>) in their respective MXML files and look like this:

/* main.css: */
.myLabel {
   color: red;
}

/* module.css: */
.myLabel {
   font-style: italic;
}

When you run this application and load in the module with the Label in it you'll notice that it is colored red, but its text is not italicized.

If you set the -keep-generated-actionscript argument to true in the compiler-settings* you can have a look under the hood of the Flex framework and see what actually happens here. Once the compiler has run you'll have a new folder called 'generated' in the 'src' folder of your project, this is where all the classes go that Flex auto-creates for stuff like data-binding and also embedded styles.

Somewhere in the generated folder there should be a class called MyModule-generated in which there's a method called _MyModule_StylesInit():

In the above code Flex starts by looking for an existing style-declaration for the stylename "myLabel" and if there is none it'll create a new one -- in our case there already is a style-declaration however (as we've made one in main.css).

Next, Flex examines the factory-property of the style-declaration (a CSSStyleDeclaration instance). The factory-property is a function that defines all style-values that were set at compile-time from the class associated with the generated class (in this case MyModule.mxml). The value of CSSStyleDeclaration.factory is usually generated by the compiler (as you can see on line 152-155).

This part of the method is where things go wrong; by only updating the factory if it is null, Flex assumes that a compile-time style-declaration can only be set at one location in your project -- whereas we set it at two (Main.mxml and MyModule.mxml).
Because the factory-property of our style-declaration has already been set when the styles from main.css were initialized (by similar auto-generated code for Main.mxml) the styles from module.css will be disregarded.

I at the very least hope this might save some other developers from hours of searching around their code, let me know. Also, this a good read if you want to familiarize yourself on the topic of modules and CSS in Flex:
viconflex.blogspot.com/2007/04/flex-modules-compile-and-run-time-css.html

* Configure the compiler by setting options in the 'additional compiler arguments' field of the project properties window (right-click your project, go to 'properties' and then 'Flex Compiler').

"Could not resolve <mx:ToolTip> to a component implementation."

So why does Flex (or rather MXMLC, the compiler) let you write <mx:Button> and <mx:Canvas> and all those other Flex components, but not <mx:ToolTip> -- it's a native Flex class and it's in the mx package just like all of the others, right?

Fact is, it's not the mx class-package that defines whether or not you can add a component by saying <mx:...>, but rather the Flex component manifest file -- it describes which of the native Flex classes fall under the mx xml-namespace (or actually any namespace you want to use). I might write a post about manifest-files in Flex somewhere in the near future, but for now you'll have to read up in the docs if you want to know more.

It so happens that the ToolTip class isn't included in the native Flex component manifest, and consequently the compiler won't be able to find it if you just write "<mx:ToolTip />". You can work around this by specifying a seperate xml-namespace for the mx.controls package:

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:controls="mx.controls.*">
    <controls:ToolTip />
</mx:Application>

Note that in the above example we can't change the value of the xmlns:mx attribute so that it would point to the mx.controls class-package, because if we would then the compiler wouldn't recognize the <mx:Application> tag anymore (since the Application class isn't in the mx.controls package).

Also, for the naysayers who completely miss the point and start talking about why on earth you would want to instantiate a ToolTip through mxml: To tell the truth I was wondering about this myself, but if you think about it, tooltips in Flex aren't restricted to just having whatever you put into UIComponent.toolTip automatically pop up when you mouse-over. In fact you may want to create a custom mxml-component subclass of ToolTip and manually add it to your application using the ToolTipManager class during runtime.

That having been said, ToolTip isn't the only Flex-class not included in the Flex component manifest, naturally what I wrote in this post also applies to any other class in the Flex framework that extends UIComponent but isn't included in the manifest.