Re: Atom and accessibility - Atom vs RSS

Aristotle Pagaltzis wrote:
> Besides the content model, there is also the fact that
RSS has no
> summary/content dichotomy, which allows Atom to
transport non-
> human-readable data (as the content) along with a
human-readable
> alternative form (in the summary).

That sounds great in theory, but in practice you're usually
way better off 
with something like this:

<content type="html">
  &lt;img src="boat.jpg" alt="picture of
a boat" /&gt;
</content>

Than you are with something like this:

<summary>picture of a boat</summary>
<content type="image/jpeg"
src="boat.jpg"/>

That doesn't apply to all forms of content of course, but if
there's an 
accessible way to represent your data in HTML, then an HTML
content element 
is probably the most interoperable way to syndicate it.

> Furthermore, several RSS elements, such as title, may
not contain
> markup per the spec, and therefore cannot contain such
things as
> ruby annotations.

Out of curiosity, do you know of any Atom feed readers that
support ruby 
annotations in titles?

Regards
James

While the current limitations of existing readers is
important to 
consider, it's also important to note that the standard
supports 
capabilities that go well beyond what those current readers
have chosen 
to implement, especially given that most of those readers
began life as 
RSS readers.

- James

James Holderness wrote:
> 
> Aristotle Pagaltzis wrote:
>> Besides the content model, there is also the fact
that RSS has no
>> summary/content dichotomy, which allows Atom to
transport non-
>> human-readable data (as the content) along with a
human-readable
>> alternative form (in the summary).
> 
> That sounds great in theory, but in practice you're
usually way better 
> off with something like this:
> 
> <content type="html">
>  &lt;img src="boat.jpg" alt="picture
of a boat" /&gt;
> </content>
> 
> Than you are with something like this:
> 
> <summary>picture of a boat</summary>
> <content type="image/jpeg"
src="boat.jpg"/>
> 
> That doesn't apply to all forms of content of course,
but if there's an 
> accessible way to represent your data in HTML, then an
HTML content 
> element is probably the most interoperable way to
syndicate it.
> 
>> Furthermore, several RSS elements, such as title,
may not contain
>> markup per the spec, and therefore cannot contain
such things as
>> ruby annotations.
> 
> Out of curiosity, do you know of any Atom feed readers
that support ruby 
> annotations in titles?
> 
> Regards
> James
> 
> 

* James Holderness <j4_jameshotmail.com> [2008-06-06
21:35]:
> That sounds great in theory, but in practice you're
usually way
> better off with something like this:

As a publisher, yes. For authors of clients, particularly
clients
intended for a specific purpose, the extent to which other
existing clients fail to take advantage of the specified
features
of the format is of little relevance.

> That doesn't apply to all forms of content of course

Which is the point. In the cases where it doesn’t apply,
RSS
offers no way to do it at all. Atom does.

> Out of curiosity, do you know of any Atom feed readers
that
> support ruby annotations in titles?

No, but I would not be surprised if some web-based
aggregator or
other passes titles through with markup intact, or could
easily
do so by adding the ruby markup elements to a whitelist.

Also, as long as major clients do not misinterpret the
markup in
harmful ways and I had some content to publish that was
already
annotated, I would include the markup anyway – certainly
easier
for me than going to the effort of scrubbing them, and it
gives
serendipity a chance. Staying on the beaten path even when
the
risk of straying a little is minor is no way to make
progress…

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/&g
t;