In issue #2 you note some submission guidelines for improving caniuse.com feature coverage, and as I have been missing higher-fidelity detailed data about what parts of SVG are supported where (similar to the good support coverage data CSS has) I figured I'd bring it up in a separate ticket.
At the moment, I make do with some prior work in the field done by Jeff Schiller (@codedread), where he has somewhat manually run the SVG test suite a couple of times over the years and across a swath of browsers (and plugin configurations). The data is a little unwieldy to access, find and read, though – here's a JSON gist I made of it today: https://gist.github.com/2803171
I believe "P" = pass, "F" = fail, "FU" = also fail and "H" = partial support (with aggregated notes in tests.json). The ones with crash: true crashed the testing browser.
The more interesting parts would of course be translating the SVG test suite format to your automatic tester, which it should be somewhat well suited to, as each of the listed tests have isolated test file, rendered look and test notes, as per your test suite requests (since browser makers use them for their own compliance and regression testing as well).
If there is anything else I can do to help make this reality, do tell.
Unfortunately, while I'm a big SVG fan myself, I don't feel there's enough interest in SVG in the developer community (compared to interest in CSS, etc) to warrant including extensive SVG feature support on caniuse.com. Maybe a few more subsections (like SVG SMIL) but not anything too detailed. The site is geared toward basic feature support, where detailed information on other sites is occasionally linked to.
So I certainly applaud and encourage your work in this area, but at this point I feel it's out of scope for caniuse.
Just a clarification request: When you say "to warrant including extensive SVG feature support", do you mean it wouldn't be worth the effort, or that most users would be overwhelmed with the extra info?
If it's the latter, I must point out that I tend to use the site almost exclusively through the filter box, and assume most people do so as well, so I don't see how it would be such a hassle for users.
Otherwise, if you're talking about the work it would take to implement and maintain the detailed SVG support tables, maybe now with github-based updating we can help you keep it up to date. There are several people who constantly monitor and update the article Comparison of layout engines (Scalable Vector Graphics) at Wikipedia, many of whom could potentially be interested in helping out. Also, there are many comprehensive resources listed in the references section of that article (the Presto support pages are quite good, for instance!), which could be used for the initial seeding.
I believe I meant it wouldn't be worth the effort on my part, considering how other features are often valued higher by average devs. So yes, you're right in that the new system should provide a way to do so regardless of that.
So absolutely, I encourage the addition of such features. :) I would suggest the focus be on features that have differing support among browsers, rather than anything already covered by all SVG-enabled browsers. (since the "basic support" table largely covers that).
#2 Clarification for Pointer Device Adaptation, #3 more info on Point…
…er Events API
Note #3 (used by Firefox) was curiously missing, so I reconstructed it, based on https://developer.mozilla.org/en-US/docs/Web/API/Element/insertAdjacentHTML