Page MenuHomePhabricator

SVG style element ignored if no type attribute is specified
Closed, ResolvedPublic


The <style> element is ignored if you omit the default value type="text/css"

This bug seems new as upstream on (as in v. 2.36.4)

Example are here in the first revisions:
File:World Reserves to Production Crude Oil.svg
File:US Proved Crude Oil Reserves.svg

Version: unspecified
Severity: normal
See Also:
T68551: CSS class are not inherited to child text/tspan elements in SVG (not general)
The W3C specification:



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:14 AM
bzimport set Reference to bz66672.
bzimport added a subscriber: Unknown Object (MLST).

Ok the examples could be much better, you can recognize this only there in the font-family.

Perhelion renamed this task from Style element ignored if no type attribute is specified to SVG style element ignored if no type attribute is specified.Dec 23 2014, 3:16 PM
Perhelion updated the task description. (Show Details)
Perhelion set Security to None.

Indeed, thanks! Fixed in b2cc9ce which is included in the 2.40.20 tarball. 2.40.20 is in Debian testing (buster) but Debian stable (stretch) ships 2.40.16.

According to W3C-Validator with DTD 1.1 <style> needs "type" see:

The W3C-Validator is gone somehow buggy and inconsistent these days, as @Glrx mentioned on my Commons talk-page, the DTD is static strict. (compared also to the Nu-Validator)
Before this year the W3C-Validator accepted SVG 1.1 without DTD as valid, which should be true this days too (DTD is not really required and in practice not recommended for SVG So I mean the W3C-Validator is not really usable for SVG anymore:

Anyway, in HTML4 the type attrib was required in HTML5 it is optional (as it was fully against practice).

The W3C Validator isn't bad; it just isn't as clever as it once was.

The SVG 1.1 DTD has #REQUIRED the style element to carry a type attribute. That was probably an OK thing when librsvg was also requiring the type attribute. In other words, it had been a useful bug. If librsvg is now fixed, then the bug is annoying. But the fault is not with the W3C Validator but rather the W3C SVG 1.1 DTD.

If a file is validated against the SVG 1.1 DTD, then RDF and Inkscape elements are reported as errors. They do not exist in the SVG 1.1 DTD, so they are "invalid".

In previous years, if the W3C Validator was given an XML file without a DTD, then it would just check that the XML was well-formed. It would not (and could not) notice structure issues like elements or attributes that don't belong in the document. The Validator would report those SVG files without a DOCTYPE as valid XML rather than valid SVG.

Then the W3C Validator got a little smarter. If it retrieved a file with Content-Type SVG but without a DTD, then it checked the file as SVG 1.1 and tolerated the RDF, Inkscape, and Sodipodi namespaces. That made the Valid SVG template give the right answer. Interestingly, one could not select that validation option on the Validator's web interface.

At some point, the W3C Validator got even more clever. For the SVG file without a DTD, it would forward the file to the nu validator and report the results as its own. A few months ago, this feature stopped working for the URL generated by the Commons template. W3C would try to forward the request, but the forwarding would fail, and W3C would report the "External Checker" (nu) as unavailable.

Today, the W3C Validator cannot be clever with Commons files. The Commons template inserts a doctype instruction to produce a URL such as:

That tells W3C to ignore any existing doctype and use the SVG+1.1. DTD (The file Map_Tenerife_Disaster_EN.svg has no doctype.) Consequently, the W3C Validator is not being given a chance to be smart. That means RDF and Sodipodi namespaces will produce errors.

If the &doctype= arg is removed, then the W3C Validator reports:

External Checker not available
Checking the Document Type of this document requires the help of an external tool which was either not enabled in this validator, or is currently unavailable. Check in the validator's system configuration that HTML5 Validator is enabled and functional.
The error encountered was: 403 Forbidden

That's the behavior that appeared a few months ago.

The following URL with a different doctype argument

validates the file without incident and does not issue errors for RDF or Inkscape extensions.

So I take the current situation as (1) Commons currently insists on SVG 1.1 DTD verification and (2) the W3C Validator is no longer trying to be smart.

If the Commons template used the encodeURIComponent("SVG 1.1 + URL + XHTML + MathML 3.0") doctype, the result would be better.

Even simpler with no doctype:

@JoKalliauer Since last week all servers are using librsvg 2.40.20-3 which fixes some svg rendering issues (and possibly introduces others).