What is the difference between "strict schedule" and "cascadeless schedule"?

In database transactions theory, what is the difference between a strict schedule and a schedule that is merely secured against cascade aborts?

Could you give an example of a schedule that is secured against cascade aborts but is not strict?

I found these slides that give definitions but it's still not clear to me where is the difference (they just seem differently worded).

On a cascadeless schedule a transaction $T_2$ cannot read a value $a$ if a transaction $T_1$ wrote $a$ before that and didn't commit. On a strict schedule $T_2$ also wouldn't be able to write $a$ after $T_1$ wrote it (even if it read $a$ before $T_1$ wrote it).

If you read carefully, the definition of strict says "not read or overwritten". That's the difference.

I reproduce here an example of cascadeless but not strict schedule, from the Wikipedia page on the subject:

StackExchange Computer Science Q#42924, answer score: 7