Almost Standard Compliant

Synonymous with 'not standard compliant'.

See Microsoft VisualC++. (90% ANSI compliance)

The problem there is the quantitative claim (what does it mean to be 90% compliant?), the implied suggestion that 90% is pretty good, and the implied policy that they're not going for 100%.

I'm reminded of a previous manager's definition of the only achievable claim of backwards compatibility "guaranteed to run none of your existing programs".

I think it is worse than 50% because there's the chance that someone might actually use it. And then you get people wanting bug-for-bug backward compatibility. Adoption of CascadingStyleSheets for Web pages has been delayed because of poor implementations, for example. -- MatthewTuck

On the other hand, if the 10% non-compliance refers to stuff that nobody wants to use, then an existing 90% compliant implementation might be better than a hypothetical 100% compliant implementation that does not yet exist. A good instance is the "export" keyword for C++, which will probably never be implemented on most compilers. Many standards contain a lot of stuff that is at best useless and at worst unimplementable. See CommitteesDontCode and CommitteesDontRead. Also WorseIsBetter.

The written standard is not always the "standard". But it's true that compliance with social standards is much more difficult to assess.

The real goal for most people is compatibility, not compliance. Naive people believe that if two systems are 100% compliant to the same set of standards, then they will be compatible, but that is often not the case. Few software standards have the required formality and completeness to guarantee compatibility. Many standards consist of little more than architectural guidelines or suggestions.

Examples?