Errors in SVG content don't cause SVG rendering to abort

RESOLVED WONTFIX

Status

()

Core
SVG
RESOLVED WONTFIX
14 years ago
9 years ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P1])

(Reporter)

Description

14 years ago
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).
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

13 years ago
IMHO this should be a blocker for turning SVG on by default.
We're not a validating parser... so I don't think we can reasonably implement this.
(Reporter)

Comment 4

13 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

13 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

13 years ago
Tell the SVG working group.
(Reporter)

Updated

13 years ago
Whiteboard: [Hixie-P1]

Updated

13 years ago
OS: Linux → All
Hardware: PC → All
Duplicate of this bug: 377479
WONTFIX
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
(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.)
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.