Closed
Bug 246514
Opened 20 years ago
Closed 15 years ago
Errors in SVG content don't cause SVG rendering to abort
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ian, Unassigned)
References
Details
(Whiteboard: [Hixie-P1])
According to: http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing ..., when an element or attribute is encountered in the document which is not part of the SVG DTD and which is not properly identified as being part of another namespace, and when an element has an attribute or property value which is not permissible according to the specification, the document shall be rendered up to, but not including, the first element which has an error, and a highly perceivable indication of error shall occur. We don't do this: http://www.hixie.ch/tests/adhoc/svg/error/001.xml http://www.hixie.ch/tests/adhoc/svg/error/003.xml http://www.hixie.ch/tests/adhoc/svg/error/007.xml http://www.hixie.ch/tests/adhoc/svg/error/008.xml http://www.hixie.ch/tests/adhoc/svg/error/009.xml For the purposes of this bug, I propose that "document" be interpreted as "SVG document fragment". That is, we should skip to the end of the <svg> element, but further processing should continue (since SVG can't give error handling rules for non-SVG content).
Comment 1•20 years ago
|
||
Mass reassign of SVG bugs that aren't currently being worked on by Alex to general@svg.bugs. If you think someone should be assigned to your bug you can join the #svg channel on mozilla.org's IRC server ( irc://irc.mozilla.org/svg ) where you can try to convince one of the SVG hackers to work on it. We aren't always there, so if you don't get a response straight away please try again later.
Assignee: alex → general
Reporter | ||
Comment 2•20 years ago
|
||
IMHO this should be a blocker for turning SVG on by default.
Comment 3•20 years ago
|
||
We're not a validating parser... so I don't think we can reasonably implement this.
Reporter | ||
Comment 4•20 years ago
|
||
You wouldn't have to be validating (indeed in SVG 1.2, since it doesn't have a DTD, being a validating parser wouldn't help anyway; even in SVG 1.1, the fact that documents can pass in and out of error by DOM changes would mean that a validating parser wouldn't help). The SVG code just needs to keep track of when constraints are violated, and abort rendering while it is.
Would the SVG version to check against be keyed off the <svg> "version" attribute?
Reporter | ||
Comment 6•20 years ago
|
||
My understanding is that you would check against the version that the UA implements.
That is a very crappy backward compatibility story.
Reporter | ||
Comment 8•20 years ago
|
||
Tell the SVG working group.
I guess I will.
Reporter | ||
Updated•20 years ago
|
Whiteboard: [Hixie-P1]
Updated•19 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 11•15 years ago
|
||
WONTFIX
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Comment 12•15 years ago
|
||
(In reply to comment #11) > WONTFIX Just to clear up my understanding of this: does not fixing this means that an effort to render the document as much as possible will always be made? (Even if/when portions of the document are in error.)
Comment 13•15 years ago
|
||
Pretty much. It means that we will not be following the error handling model linked to in comment 0. We'll be looking to SVG Tiny 1.2 (which defines much saner error handling) on a case by case basis. Where it defines behavior we'll do what it defines. When it does not, I'll bring it up in the working group and we'll try to get consensus.
You need to log in
before you can comment on or make changes to this bug.
Description
•