What warnings do you heed?

The feed validator knows things that are errors, and things that are warnings. It knows that the RSS spec is silent about whether or not you can use dangerous markup like on* Javascript events and objects with nasty payloads, but that any sensible and conservative aggregator author will strip them out of your feed before sticking it into their user’s browser, and so it will tell you in /docs/warning/ContainsObject.html (in a little too strong of language, since in fact you only need to consider whether your use is safe, and whether your content will still work and make sense if the offending tags and attributes are stripped). However, since it currently only knows one way to get your attention, it will tell you that by saying “You, Sirrah, have an Invalid feed!

So, my question: what warnings, where a computer tells you “you’re good, but…” do you actually heed? If the feed validator told you “Congratulations! Your feed is valid $spec. However, here’s something you need to consider about whether it will work the way you expect.”, would you listen?


Comment by Mark #
2004-03-18 20:30:14

That’s long been a debate about the feed validator, and as you correctly point out, it is merely a UI issue (although an important one). Internally the validator knows which things are errors and which are warnings, it just reports both equally.

Constructive suggestions are always welcome. Criticism of the form ”that’s not explicitly mentioned in the spec in big red letters, so therefore YOU MUST BE STEALING RSS” are less likely to be taken seriously. Being a validator developer gives you a hair-trigger bozo bit.

Comment by Phil Ringnalda #
2004-03-18 20:51:07

Yup, I know it’s been around a while, because I think it was the first thing I complained about on the old mailing list. Unfortunately, this time when I complained, Sam said essentially (and correctly) ”where’s the patch?” And I just don’t know how to do it. The only similar thing I can think of is the ”requires human checking” messages while checking accessibility, and I just ignore those. Er, I mean I’m quite sure I’ve gotten all those things right.

Comment by Sam Ruby #
2004-03-19 06:11:36

If you can figure out what the human interface should look like, I’ll focus on the writing the backend code to enable it. That being said, I’ll only have intermittent internet access for the next few days.

Comment by Jacques Distler #
2004-03-18 20:35:27

I pretty much ignored that FeedValidator warning about on* attributes (which, in my case, generate those little MathML popups in my MathML-enabled posts).

It bugged me no end that these warnings were listed as ”errors”, but beggars can’t be choosers.

Once I figured out how to strip those babies out of my feeds, I was much happier.

But I confess that I was willing to ignore those (in this instance, pointless) warnings indefinitely.

As to whether validity has anything to do with whether your feed will work as expected, I submit to you the <content xml:base=""> element in the (current) MovableType Atom template.

<$MTBlogURL$> is a perfectly valid value for that attribute. But does it do what you expect?

Comment by Mark #
2004-03-18 21:43:52

Just out of curiosity, what did you expect the on* attributes to do in an aggregator, exactly, if you’re not including your script with your content? Are your on* methods self-contained?

Certainly I trust that you can figure this out, Jacques, but most people don’t think that far ahead. They complain when we flag onclick=”OpenPopupWindow()”. Um, hello? That link is BROKEN because you’re not understanding the fact that your entry content will be viewed in isolation.

Comment by Phil Ringnalda #
2004-03-18 22:37:39

But, we also flag <a href="example.com/images/1.jpg" onclick="window.open(this.href, '...');return false;"> which degrades just fine. And even if we can tell the difference, at least for the top few dozen sorts of nicely degrading dangerous content, we don’t much want to. So, we need to warn.

(Or, maybe I’m wrong: maybe there are enough aggregators doing stupid and evil sanitizing, nuking a whole link for an attribute, or stripping object tags and their content, so that it’s not possible to degrade gracefully. Bleah. I need a whole new aggregator test suite, mine’s gotten so old.)

Comment by Jacques Distler #
2004-03-18 22:21:12

I’m expecting it to be … ignored.

The XHTML source from which the feed is derived works just fine when javascript is turned off. I view the RSS Aggregator as just another client with javascript turned off.

That said, it’s better to strip out on* attributes from my RSS feeds, as I don’t expect them to actually do anything.

That’s what I do now.

Can’t we all just get along?

Comment by Sam Ruby #
2004-03-19 06:14:13

Think evil for a moment. In Radio Userland’s aggregator, for example, the page is served from a local file.

Comment by Jacques Distler #
2004-03-19 06:57:58

All the more reason that client should have javascript turned off.

Appealing to the users of the FeedValidator not to put javascript code in their feeds does nothing to deter the baddies (who aren’t exactly going to heed your advice, now are they?).

If Radio has javscript enabled, then Radio is broken.

Perhaps, one might argue that the presence of (inocuous, but non-functional) javascript in feeds will encourage Radio users to complain to their vendor. If only baddies put javascript in their feeds, the Radio user won’t notice the problem until it is too late.

Comment by sil #
2004-03-18 23:46:55

I’d read them. I am appallingly lax at checking feed validity (I should write a cron job or something, I know, I know), but once I’ve actually got as far as *doing* it I will read the warnings.
Thought (long, complicated, nightmarishly complex thought): chuck Javascript links at a JS engine and see if they throw an error, and report that as ”your JS link probably won’t work in a feed”. Ouch. Also: ”where’s the patch?”, I suspect. I’ll have a think about this…

Comment by Roger Benningfield #
2004-03-19 01:58:02

Phil: I would certainly *read* the advisory, but I wouldn’t necessarily make any changes as a result.

Perfect example: if I add a poll to an entry, my full-content feed will contain a form with an onSubmit attribute and an embedded script. The validator fires off its warnings, but they’re unnecessary… it’s designed to degrade acceptably even if Javascript is turned off or the onSubmit is stripped by the aggregator.

Comment by Phil Ringnalda #
2004-03-19 07:28:46

And that’s exactly the right reaction, and why it’s a warning: ”Warning: you used the sort of tags/attributes that are likely to be stripped by an aggregator, so you need to think about what will happen to the sense and function of your entry without them.”

Comment by Marcus #
2004-03-19 04:24:33

The W3C CSS validator warnings always work on me. I can’t bear to have code that’s only _almost_ perfect.

Comment by Ben Meadowcroft #
2004-03-19 05:00:15

If all the object tags are stripped out how could you include SVG images etc in a feed?

Comment by Phil Ringnalda #
2004-03-19 07:22:16

That’s what I meant somewhere up thread about wondering how viciously aggregator authors are stripping: just like the way a browser falls back on the contents if it doesn’t know how to render the outer element, they should be only stripping as little as they have to, so your <object type="whateverSVG" ...><img src="..." alt="screenshot of an SVG" type="image/jpg"/></object> will degrade.

Comment by Jacques Distler #
2004-03-19 07:33:08

I think Ben’s point, however, is that there’s nothing inherently bad about <object type="image/svg+xml">. If the Aggregator doesn’t know what to do with an SVG image, then it should fall back to the GIF image.

Just because we don’t want Aggregators running Java applets doesn’t mean all <object>s are bad.

Comment by Scott Johnson #
2004-03-19 14:06:39

If the feed validator told you ”Congratulations! Your feed is valid $spec. However, here’s something you need to consider about whether it will work the way you expect.”, would you listen?

I don’t develop or maintain any aggregator software. I do, however, maintain a few feeds on my website and the websites of others. Whenever I setup a new feed, I always run it by the validator before publishing the URL. I would definitely like to see advice like this if the feed is valid but not quite perfect. I believe that the W3C CSS validator does something similar, and this has been very helpful in the past.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <del datetime="" cite=""> <dd> <dl> <dt> <em> <i> <ins datetime="" cite=""> <kbd> <li> <ol> <p> <pre> <q cite=""> <samp> <strong> <sub> <sup> <ul> in your comment.