GNOME Bugzilla – Bug 514268
style[not(@type="text/css")] elements are not ignored
Last modified: 2012-11-16 11:21:28 UTC
According http://www.w3.org/TR/SVG/styling.html#StyleElement a style element requires attribute type with value "text/css". Therefore not conforming elements should be ignored. Current (2.20.0) librsvg doesn't respect the specification.
Created attachment 104375 [details] test case The rectangle (spreaded across whole cavnas) should be black because style element has no @type="text/css".
The relevant text from the linked-to section of the (v1.1) spec is “Authors must supply a value for this attribute; there is no default value.” Thus, I believe that the correct behaviour when encountering a <style> element with no type attribute is as specified at <http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing>: don't render anything after the first error (so don't render the rectangle at all, in this example), and instead render an obvious error indication such as “a translucent colored pattern such as a checkerboard”, and possibly also some text that mentions “a line number and character number at which the error was encountered”. For a command-line tool like rsvg-convert, I suggest that reasonable behaviour would be to write an error message to stderr and exit with non-zero status. The importance of strict error handling is so that authors (of the SVG or the tool that generated the SVG) are as likely as possible to fix things so that SVG files render the same everywhere rather than different viewers handling the error differently. Permissive error handling should be left for ‘tidy’-like tools that produce correct (and hence more portable) SVG as output.
Fixed on master.
Created attachment 229114 [details] [review] lookup the mimetype from 'type' and 'contentStyleType' Hi, https://bugzilla.novell.com/show_bug.cgi?id=789728. I did some investigations and found it was related to this bug. According to http://www.w3.org/TR/SVG/styling.html#StyleElement, 'type' in 'style' --> ‘contentStyleType’ in 'svg' should be looked up to determine the mime type, if both were not found, 'text/css' would be the default mime type. A proper patch is attached.
If anyone else is interested in how “Authors must supply a value for this attribute; there is no default value” turned into the current spec text, it turns out that this is a change in the SVG spec introduced with erratum http://www.w3.org/2003/01/REC-SVG11-20030114-errata#clarify-content-style-type-behavior . [The word "clarify" in the erratum entry is wrong: the 2003 versions of http://www.w3.org/TR/2003/REC-SVG11-20030114/styling.html#StyleElement with #DefaultStyleSheetLanguage is very clear in specifying a different behaviour from that introduced for this erratum. Perhaps there should be an erratum for the erratum...]