Is it reasonable to ask for more? Should feedreaders distinguish between malicious elements and innocuous ones, stripping out the former but not the latter? The real question is: what should be the correct behaviour with respect to the SVG figure test? At a minimum, I would demand that feedreaders display the fallback GIF image. But it’s probably unreasonable to demand it as a general conformance requirement. Those whose platforms support MathML (Thunderbird, Windows-based feedreaders with the MathPlayer plugin installed) ought to support it. MathML support? Feedreader authors, generally, don’t write their rendering engine, so they are dependent on their platform for MathML support.(My testcase tests for just one of several instances where this departs from HTML parsing behaviour.) It’s also fairly clear what supporting type="xhtml" ought to mean: the content should be parsed using XHTML rules.It’s clear what xml:base support means.Well, the first question I have is: what ought to count as conformance? So how did your feedreader do? Did switching to Atom actually fix any of these issues for you? You should, at the very least, see the GIF image. But, either way, it is inexcusable to also strip out the fallback content of the element. I suppose I can forgive feedreader authors for stripping out all elements, rather than trying to distinguish between potentially hostile ones, like applets, and obviously benign ones, like SVG files. Now, many feedreaders quite properly sanitize their inputs to eliminate hostile applets (loaded via the element). Nested as the content of the element is a GIF image, to be used as a fallback alternative. No, I don’t include the SVG inline (thought that would make a nice torture-test). ( Thunderbird ought to fall into this class, as do, I am told, some Windows-based feedreaders when the MathPlayer Plugin is installed.) MathML: if your feedreader recognizes the content is XHTML, and the rendering engine it uses is MathML-aware, then you might just be able to see the equations. Does your feedreader pay attention, or does it just assume that everything anyone writes is tag-soup? Atom includes a type="xhtml" attribute which tells the feedreader that the content is actually XHTML. In fact, without explicit extensions, like, it doesn’t even have a mechanism for telling the feedreader that it contains markup at all (the feedreader has to guess). XHTML: RSS 2.0 has no mechanism for telling your feedreader that the markup in the posts is anything other than tag-soup.Does your feedreader actually implement it properly? Since such eventualities are not actually covered in the RSS 2.0 “Spec”, chances are those links were broken. Relative URLs: relative URLs in my posts (or in comments thereon) should have been interpreted as relative to the URL in the element of each.For the latter three, I wrote a little test feed of my own. For the first one, there are already tests in the suite of Atom conformance tests. Let’s see if its Atom support is any better. Here are 4 areas where your RSS feedreader fell on the floor.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |