Attribute clash is a display artifact seen on some 8-bit home computers (such as the MSX and sometimes the Commodore 64), mainly the ZX Spectrum, but is also noticeable on some 8-bit consoles, such as the Nintendo Entertainment System and Game Boy Color (even though that issue was less common on these systems due to more advanced hardware allowing four colors per block and up to 40 three color movable sprites), showing the limitations of these systems.
The limitations of the graphics circuitry was the main cause of this issue. As an example, the ZX Spectrum was able to use only two colors in every tile, while the NES could use four colors in every tile due to the PPU's limitations. The Thomson MO5 and TO7 microcomputers, the Oric 1, the MSX 1 architecture and other systems based on the Texas Instruments TMS9918 Video Display Controller, show a very similar constraint. For each group of eight pixels horizontally, only two colors out of 16 were available, thus giving a similar, but less noticeable effect than the one of the Spectrum.
To avoid attribute clash, static graphic displays had to be constructed with care. Careful design could achieve impressive results, as could synchronising color changes to the refresh rate of the display, usually a television set. Unfortunately, animated displays were more difficult, if just one pixel in an 8×8 block was recolored because a moving part of the display touched it, the entire block would change color, thus detailed moving graphics producing large ugly fringes of rapidly changing colors to follow them around.
Early ZX Spectrum software simply ignored the problem, while 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 games on the ZX Spectrum simply ignored the issue, such as Knight Tyme, while others were rendered in monochrome in order to avoid this issue, such as Knight Lore. Detailed color backgrounds were almost impossible, since color would only apply to 8x8 pixel tiles. Late ZX Spectrum software, like Faster Than Light'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.
As for the MSX1, it didn't had just one single color attribute byte available for a whole 8x8 pixel area, as this was the case with the ZX Spectrum, but eight, one attribute byte for each 8×1 pixel area. Thus, while the Spectrum was limited to one color pair for a square area of 8x8 pixels, the MSX 1 was only limited to one color pair for a "line" of eight adjacent pixels. In addition, the MSX1 could use sprites which were not bound to any attribute clash problems, even though MSX1 sprites did have their own limitations. Unfortunately, this didn't help the MSX1 to produce better pictures, since several European software companies ignored the advantages of the MSX1 over the ZX Spectrum, thus resulting in many MSX1 games having a similar amount of attribute clash as the ones on the ZX Spectrum, as well as ignoring the sprite capabilities of the MSX1, and because the video display capabilities were otherwise quite similar (256×192 resolution, 16 colors), both systems produced virtually identical displays for the same game. In contrast, most Japanese MSX1 games were better looking at graphics, due to fair use of the MSX1's capabilities.