Workarounds
Early software simply ignored the problem. Later, the standard workaround was to use color for static display elements — such as a decorative border around the edges of the screen, which might include score displays and so on, or some form of instrumentation — with a smaller central monochrome area containing all the animated graphics. This also made graphics faster, as less of the screen had to be updated — both a smaller region, plus only changing pixel information and leaving the color area untouched.
Some late Spectrum software, such as FTL's Light Force, used extremely careful graphics design to achieve full-color moving graphics, essentially by limiting both the design of the onscreen elements and their paths of motion to 8×8 color resolution boundaries. The moving elements were thus relatively large and rather blocky or squarish, and their movement was constrained, but this was not visually obvious and the sight of moving full-color graphics was hugely impressive to Spectrum owners.
No mainstream developers were able to find a suitable all-round fix for the attribute clash problem, instead preferring to use the monochrome graphics method when fast, clear graphics were needed, and full-color graphics when the situation permitted.
It was possible by paying careful attention to timing to modify the attribute area of RAM at certain specific times as the display was drawn - let the display hardware draw one line of the display, then change the attribute RAM before the next line is drawn to give the effect of different attributes for each individual line. These changes had to be done in software and were time-consuming to program, meaning that this technique was usually limited to special effects. This technique was also very popular in the demoscene.
Read more about this topic: Attribute Clash