Să spunem acum de unde putem obţine mai multe seturi de piese de şah şi să vedem cum realizăm printr-un program, sprite-urile corespunzătoare. Apoi, cum am putea face pentru ca poziţionările câmpurilor şi imaginilor să nu depindă totuşi, de setul curent folosit (şi nici de orientarea tablei).

Avem o imagine în care am reunit piesele de şah de o aceeaşi dimensiune n şi pe de altă parte, un câmp de dimensiune nxn. Problema este de a selecta din sprite-ul nostru o piesă şi a o poziţiona pe câmpul dat, încât definiţiile CSS necesare pentru aceasta să nu depindă de n. Investigăm cum să determinăm pentru acest caz, procentele necesare pentru background-position.

Proporţionăm din ce în ce mai fin procente pozitive… dar până la urmă ajungem la o soluţie neaşteptat de simplă, folosind procente negative!

Montăm piesele de şah într-un sprite şi-l folosim apoi în widget-ul care mapează poziţii FEN pe tabla de şah.

Începe să fie clar ce înseamnă "dezvoltare inductivă: am ajuns tocmai la "partea a IV-a" şi încă n-am finalizat nimic!

Să "finalizăm" deocamdată ceea ce am început în (III): trebuie "citit" şi validat FEN-ul introdus de utilizator şi trebuie înscrisă poziţia respectivă pe tabla de şah.

Pentru exerciţiile din manualele uzuale, transmiterea (citirea) datelor sub forma unui tablou de valori este ceva aproape indiscutabil, de la sine înţeles… Dar dacă s-ar pune problema arhivării datelor, sau comunicării lor între programe - atunci reprezentarea ca text simplu este clar preferabilă.

Pentru chestiunea mediilor şcolare am putea imagina o reprezentare textuală simplă a datelor: "a95/b10/c775" ar putea reprezenta foarte bine tabloul {'a': 9.5, 'b': 10, 'c': 7.75}…

Analog se specifică o poziţie de şah: notaţia FEN. Crearea infrastructurii {Load FEN, tabla de şah}.