I think it is never trully possible to seperate design and logic

IMHO, you should take care to differentiate applicative-logic and GUI-logic, and consider 3 abstraction layers:

1. HTML-Template data, aka GUI elements, look-and-feel, skins, whatever you call it.
2. GUI-logic, tiny code elements, totally dedicated to data appearance. There you'll use HTML::Template modules or equivalent to handle HTML data from above layer. Taking an OO-approach, you may define here a "widgets" hierarchy of specialized objects.
3. Lastly, You'll have applicative-logic dedicated to manage applicative-datas and providing them to users through the help of above layer functionnalities.

                   +-------+
                   | Users |
                   +-------+
                       ^
                       |
                       v
+------------+   +-----------+
| HTML-Datas |-->| GUI-logic |
+------------+   +-----------+
                       ^
                       |
                       v
             +-------------------+
             | Applicative-logic |
             +-------------------+
                       ^
                       |
                       v
                   +-------+
                   | Datas |
                   +-------+
[download]

Pro: Design and logic are separated.

Cons: You'll have to stricly follow the rules of responsability separation when developping the differents layers. Anyway, you'll have a bit more code to produce and support all caveats involvde (more code => more bugs => more tests required => less time).

This kind of slicing gives you the basements to build applications decribed as 'Model-View-Controller' in Design-Pattern litteracy.

Updated:corrected some typos and added schematic.