While Opera Mobile supports web fonts and is like a mobile version of full desktop Opera, the Opera Mini application doesn't currently support web fonts and also follows a different versioning system separate from the main Opera version. Thus, we should treat Opera Mini as a separate browser for the purposes of web font support, and make sure that we don't return false positives for support as well.
This is a less onerous way to avoid DOM construction caused by the DomHelper constructor. We make a method to check if a feature is supported and memoize the value the first time it's called.
UserAgent was required to construct a DomHelper, but the only thing it was used for is in setStyle to determine if we're in an old IE and need to use a different approach. I was using DomHelper in some code and finding it cumbersome to have a UserAgent instance around as well. This goal is better accomplished with a feature-detection approach anyway. I've replaced the UserAgent arg with feature detection for getting/setting the style attribute. This is a very similar approach to the one that jQuery uses to detect the same feature. This has the added side-effect of allowing many of the modules to no longer construct a UserAgent instance using the parser, since they only used it for the DomHelper, which simplifies things.
… has been removed. Since we were using the default marker anyway removing this flag is not an issue.