Re: SVGT 1.2: Appendix C3: SVG Error Processing

> Quoting David Woolley <david@djwhome.demon.co.uk>:
> > But the consequence of this policy is that there is no non-conformant
> > markup!
> 
> That is nonsense.

My text could have done with better proof reading, as parts of it didn't
quite make sense, but...
 
> # p { foobar:baz; background:lime }
> 
> ... is non conforming CSS. UAs do know _exactly_ what to extract from 
> the above

As I pointed out in another reply, my view is that CSS rules aren't about
the handling of invalid content, but rather about forward compatibility:  
the ignoring of valid future content forms.  (Specifically, one can only
say that it is not conforming CSS 2.1; it might be conforming CSS 5.0.)

The general commercial imperative for handling invalid content is to to
do what the author most likely intended, which is generally incompatible
with a policy of ignoring it, as used by CSS.

Incidentally, one of the biggest problems for HTML was, in my view, not
deliberate error recovery, but the use of simplified parsing strategies
(in that case, basically treating opening and closing tags as independent
rendering commands) that are unable to detect syntax errors, but easier
to implement (although I'm not convinced that these always produced a
valid result for valid input).  That's relevant for small platform SVG
in that it is precisely such sorts of parsing simplification that allows
code size to be reduced.

Received on Wednesday, 4 January 2006 07:47:39 UTC