I can see your point regarding test data. I'd prefer to see a less ad-hoc approach to coping with invalid documents than we are currently doing, and am slightly worried this is just adding extra code that might not be achieving the desired end result. 

For example, another approach here might be to isolate each individual rule creation step in it's own try-catch. This means ANY type of really bad document data can only crash the individual CSS rule at most.

I can see the possible crash you are preventing here, but am just unsure whether it improves the robustness of WebODF significantly. My main fear upon seeing something like this in a new code base is that it isn't clear when extra checks like this are expected/necessary (e.g., cargo cult-ing).

Oh well... we can probably debate principles until Bella returns from her fields... but you have a patch here that is complete. I'm ok for this to land in the patch.