A. Pagaltzis wrote:
So what is your intent? What do you expect aggregators to do
with that content?
Really, what I expect them to do with that content is to not fail
to display a full document if a full document is what I provide.
That aggregators attempt to render such full documents inline
(and unsurprisingly fail to produce a reasonable facsimile of the
original) is in error.
I think I provide a reasonable facsimle of the document when I display it
inline (although no CSS). I know of maybe 4 other aggregators that handle
inline xhtml documents to some extent. Maybe 8 handle inline html documents.
That's not exactly great support considering I've tested 15, but nothing
about Atom content rendering is well supported.
I would further expect that full document to be rendered as is,
unadorned by any decorations the aggregator applies to its
rendering of inline content and unaffected by any aggregator
stylesheets. In other words, I shipped a full webpage in my feed,
and I expect it to render as a full webpage in a standalone
browser would.
Well to be fair your browser probably includes a title, a url bar,
navigation buttons, a status bar, etc. I don't think it's unreasonable for a
feed reader to display the title, author, date, related links and whatever
other metadata you've associated with that document. I agree that applying
other styles to your document is probably pushing it.
To show a fragmentary document inline, I suppose, cannot be
argued to be in error. It is still in violation of the spirit of
the spec on the producer’s side to provide such, though.
Agreed.
As I said before, most likely, it would be shown in an IFRAME.
(This would also provide a local scope for any CSS, thereby
greatly reducing the need to cripple any included stylesheet for
anti-spoofing reasons.)
The real problem with CSS is javascript, and I don't think an IFRAME is
going to help that. I'd happily leave all CSS and javascript in the HTML
(whether you're using a MIME type or not) if I thought it was safe. But
everything I've read on the subject has lead me to believe that is a bad,
bad idea.
Yes, sure, but the whole point is moot because no such thing as a
fragmentary PDF or JPEG documemt exists. Either you have a full
PDF or JPEG document or you have corrupt, undecodable data. This
is markedly distinct from the situation we’re dealing with.
Well I thought we were disagreeing about whether content with a MIME type
should be shown inline or not. I was just saying that I'd ideally render all
MIME type documents inline if I could. If we can agree that that's
acceptable, then I think our only difference of opinion is whether it's
acceptable to preprocess a document prior to displaying it.
I can understand why you wouldn't want your beautiful CSS being mucked up by
a feed reader for no good reason, but security is a fairly good reason IMO.
Ideally if I had the time to write a full CSS parser that could safely
remove the bad bits and leave the good bits I would, but I don't think it's
reasonable to expect all (or any) feed readers to do that.
Your line of reasoning did not go wrong. I just did not mean “in
error” formally as in “producing invalid Atom”. What they’re
doing is technically permissible, because it’s not technically
disallowable. Replace “in error” by “abusing/misinterpreting the
format”, if you want.
Ok, sorry for the misunderstanding. I can agree with that.
Regards
James
