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

style MIME type omitted

Better simplified example, rendered as https://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/bd/20140616211051%21Test.svg/500px-Test.svg.png (near the same as https://bugzilla.wikimedia.org/attachment.cgi?id=15666 from bug 66551)

Attached:

https://bugzilla.gnome.org/show_bug.cgi?id=695162#c5

Looks like this was fixed upstream 5 months ago? https://gitlab.gnome.org/GNOME/librsvg/issues/74 and https://bugzilla.gnome.org/show_bug.cgi?id=786372#c7 got closed as fixed.

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:

• https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FWorld_Reserves_to_Production_Crude_Oil.svg&ss=1#result
• https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FUS_Proved_Crude_Oil_Reserves.svg&ss=1#result

In T68672#4396191, @JoKalliauer wrote:

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. https://commons.wikimedia.org/wiki/User_talk:Perhelion#DTD (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 https://commons.wikimedia.org/wiki/Help:SVG#cite_note-3). So I mean the W3C-Validator is not really usable for SVG anymore: https://www.w3.org/Bugs/Public/show_bug.cgi?id=30257

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:

https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FMap_Tenerife_Disaster_EN.svg&doctype=SVG+1.1&ss=1#source

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

https://validator.w3.org/nu/?doctype=SVG%201.1%20%2B%20URL%20%2B%20XHTML%20%2B%20MathML%203.0&parser=xml&doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F0d%2FMap_Tenerife_Disaster_EN.svg

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:
https://validator.w3.org/nu/?doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F0d%2FMap_Tenerife_Disaster_EN.svg

@Aklapper Was there an recent (this week) update or something?

I can test
https://commons.wikimedia.org/wiki/File:Mldotnet.svg
or
https://commons.wikimedia.org/wiki/File:Cityfone_logo.svg
or others,
and all of them seem to work?

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