- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 31 Mar 2009 11:00:33 +1100
- To: Doug Schepers <schepers@w3.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-html@w3.org, Sam Ruby <rubys@intertwingly.net>, www-svg <www-svg@w3.org>
Doug Schepers: > The SVG WG, including me, doesn't have a real problem with this error > correction (or at least, we don't have a better solution); what I have a > problem with is the implicit notion that because something *can* be > error-corrected, that the non-well-formed code is of equal value. I think there’s a real difference of opinion here about whether using the unquoted or minimized forms of attributes is actually an error that needs correction. Some people come from the perspective of these attribute forms being perfectly fine in HTML elements, so why then would certain elements within an HTML document (the SVG elements) have a different notion of what is an error? On the other hand, others come from the perspective of taking the XML syntax of SVG and integrating it with the text/html syntax, where there is a desire to try to keep as close to the original syntax as possible and to encourage authors to do so, hence wanting the parse errors. If performance issues are indeed a major argument against making using these attribute forms a parse error, then I agree with Doug that it would be good to see some concrete evidence of this. IMO, this isn’t the main argument, however. I think the consistency one is. (Feel free to correct(!) me if any of you think I’m wrong here.) So we need to weigh up the advantages of self-consistency within the text/html syntax against the desire of allowing copy/paste out of text/html into image/svg+xml. Jonas Sicking: > > From my understanding the main remaining disagreements centered > > around what should be considered parse errors in a validating > > implementation, and what isn't. For example if casing different from > > what SVG-in-XML uses, or unquoted attribute values, is a parse error > > or not. Doug Schepers: > That's part of it. The bone of contention is how to come back from > those parse errors. I disagree, and think the bone of contention is indeed whether they should be errors at all. (Whether or not they are errors, it seems there is agreement that a particular DOM will be produced.) -- Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 31 March 2009 00:01:23 UTC