Subject: text-only in atom:title?

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 15:36:27 -0700

I was reading the debate around PaceContentAsTextOrHtml, and (maybe 
this has beaten to death, but I don't think so) was wondering if there 
would be any support for limiting <atom:title> to text/plain content.  
It would sure make writing the UI of an aggregator easier.  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Aug 2004 13:22:08 +1000

> It would sure make writing the UI of an aggregator easier.  -Tim

with/without entities?

e.

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 20:57:45 -0700

On Aug 30, 2004, at 8:22 PM, Eric Scheid wrote:

>>  wondering if there

Non-issue.  If there's a < in the text it has to be encoded as &lt; per 
XML rules, and it's just a <, nothing special. -Tim

---

From: "Bill Kearney" <[email-masked]>
Date: Tue, 31 Aug 2004 01:03:55 -0400

From: "Tim Bray" <[email-masked]>
> It would sure make writing the UI of an aggregator easier.  -Tim

I've long supported the notion that titles should never contain anything
other than text; no markup whatsoever.  Character data only, in whatever XML
encoding the document is using.  Absolutlely no presentation markup a la
html <b>, <i> tags.

-Bill Kearney
Syndic8.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 08:46:25 +0200

On Tue, 31 Aug 2004 01:03:55 -0400, Bill Kearney <[email-masked]>  
wrote:

> other than text; no markup whatsoever.  Character data only, in whatever  
> XML encoding the document is using.  Absolutlely no presentation markup a
> la html <b>, <i> tags.

I'm +1 on this. Since title's main usage is to be displayed in lists, it  
would be terrible if it somewhat was required to parse the XHTML content  
of a title to get something useful out, and not to mention having to  
display all the wierd formatting people put into it.

If markup is allowed, how is an aggregator supposed to display the  
following titles:

   <title>
     <p xmlns="http://www.w3.org/1999/xhtml">First title paragraph</p>
     <p xmlns="http://www.w3.org/1999/xhtml">Second title paragraph</p>
   </title>

   <title>
     <p xmlns="http://www.w3.org/1999/xhtml">
       <em style="color: pink">This</em> is a
       <strong style="background-color: blue; color: green">crazy</strong>
       title.
     </p>
   </title>

   <title>
     <table xmlns="http://www.w3.org/1999/xhtml">
       <tr>
         <td>This</td><td>is</td>a</td><td>tabulated</td><td>title</td>
       </tr>
       <tr>
         <td>spanning</td><td>over</td><td>several</td><td>lines.</td>
       </tr>
     </table>
   </title>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Ian Davis <[email-masked]>
Date: Tue, 31 Aug 2004 09:44:23 +0100

On 30/08/2004 23:36, Tim Bray wrote:

> I was reading the debate around PaceContentAsTextOrHtml, and (maybe this 
> has beaten to death, but I don't think so) was wondering if there would 
> be any support for limiting <atom:title> to text/plain content.  It 
> would sure make writing the UI of an aggregator easier.  -Tim

+1

(But we've been telling people this for years and still there's a real 
desire by users to put markup in titles. It happens in the HTML world 
too: how many times have you seen <b>cool</b> in the title bar?)

Ian

---

From: Norman Walsh <[email-masked]>
Date: Tue, 31 Aug 2004 07:10:58 -0400

/ "Bill Kearney" <[email-masked]> was heard to say:
| From: "Tim Bray" <[email-masked]>
|> I was reading the debate around PaceContentAsTextOrHtml, and (maybe
|> this has beaten to death, but I don't think so) was wondering if there
|> would be any support for limiting <atom:title> to text/plain content.
|> It would sure make writing the UI of an aggregator easier.  -Tim
|
| I've long supported the notion that titles should never contain anything
| other than text; no markup whatsoever.  Character data only, in whatever XML
| encoding the document is using.  Absolutlely no presentation markup a la
| html <b>, <i> tags.

That might work fine for Atom, I won't argue against it, though it will
become FAQ why you can't put super/subscripts in them. Or images. Or MathML.
Or any of a host o fother things that require markup.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | I don't know the key to success, but
http://nwalsh.com/            | the key to failure is trying to please
                              | everybody.--Bill Cosby

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 07:16:38 -0400

> would sure make writing the UI of an aggregator easier.  -Tim

Depends on the aggregator.  Radio's aggregator, for example, will 
literally copy the title, byte for byte, from the feed to the HTML page 
that they produce.  This effectively means that titles will be treated 
has HTML.

Spec authors have *said* text only titles for years.

Content producers have *routinely* ignored this.  Even in newspapers, 
you will find italics in titles.

IMHO, the best that can be done is to (1) attempt to require content 
producers to explicitly declare whether or not markup is present, (2) 
inform producers that markup will be routinely stripped.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Tue, 31 Aug 2004 15:10:55 +0900

At 15:36 04/08/30 -0700, Tim Bray wrote:

>has beaten to death, but I don't think so) was wondering if there would be 
>any support for limiting <atom:title> to text/plain content.

It would result in limitations for internationalization, e.g. for
bidirectionality, for multilingual texts, for things such as ruby;
also e.g. for titles related to math and chemistry,...

I guess an Atom UI should have the necessary widgets for mixed content,
in which case it shouldn't be too difficult to use that for 'title',
too.

---

From: "Michael Stillwell" <[email-masked]>
Date: Tue, 31 Aug 2004 12:54:02 +0100 (BST)

> If markup is allowed, how is an aggregator supposed to display the

Do you expect aggregators to display pink text when it appears in
atom:content??  Maybe pink text they should, but there's surely a limit
to the number of CSS properties they should support.  I do think the
formatting requirements of atom:title are less than those of
atom:content, but plain text (plus entities) seems insufficient.  For
example, nytimes.com currently has one title containing italics on the
front page, and slate.msn.com has two:

  But Sweetie, You <i>Love</i> Lima Beans
  <i>The Captive Mind</i> Now
  <i>Et Tu</i>, Ed.?

--M.

-- 
http://beebo.org

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 07:55:36 -0400

> encoding the document is using.  Absolutlely no presentation markup a la

I was under the impression last year that this was an absolute
dealbreaker for Blogger, who wants users to be able to use <b> and <i>
tags in entry titles.  But perhaps someone from Google can clarify
their current position.

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 07:59:58 -0400

> Or any of a host o fother things that require markup.

I wish you hadn't included images in that list, and perhaps had included 
ruby annotations, or dir="rtl" instead.  In any case, we have been down 
this road before:

http://www.imc.org/atom-syntax/mail-archive/msg06493.html

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 31 Aug 2004 15:20:22 +0100

> inform producers that markup will be routinely stripped.

Could we not re-use for titles whatever constructs we settle on for 
content? That gives for people to innovate so long as the 
fallback/default behaviour is explained as you outlined.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 11:16:01 -0400

> fallback/default behaviour is explained as you outlined.

That is exactly how the current internet draft is worded.

    4.2.1  "atom:title" Element

    The "atom:title" element is a Content construct that conveys a
    human-readable title for the feed.  atom:head elements MUST contain
    exactly one atom:title element.

- Sam Ruby

---

From: [email-masked] (John Panzer)
Date: Tue, 31 Aug 2004 09:23:49 -0700

Sam Ruby wrote:

>> this has beaten to death, but I don't think so) was wondering if 
>> there would be any support for limiting <atom:title> to text/plain 
>> content.  It would sure make writing the UI of an aggregator easier.  
>> -Tim
>
>
> literally copy the title, byte for byte, from the feed to the HTML 
> page that they produce.  This effectively means that titles will be 
> treated has HTML.
>

There are good use cases for markup in real world headlines (e.g., book 
reviews).  Atom should support at least these cases.  I don't know how 
to distinguish these "good" cases from the "pathological" cases that 
people come up with, though.

> inform producers that markup will be routinely stripped.

+1. 

(How about "stripped and/or truncated?")

---

From: Walter Underwood <[email-masked]>
Date: Tue, 31 Aug 2004 10:42:49 -0700

--On Monday, August 30, 2004 03:36:27 PM -0700 Tim Bray <[email-masked]> 
wrote:
> be any support for limiting <atom:title> to text/plain content.  It would
> sure make writing the UI of an aggregator easier.  -Tim

I strongly favor text-only titles. Some points in favor:

* same as HTML <title>, MS Office titles, PDF title, etc.
* matches search engine practice
* much easier to sort (as easy as Locale-specific collation ever is)
* no room for malicious <script> tags and cross-site attacks

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 31 Aug 2004 18:36:21 +0100

> That is exactly how the current internet draft is worded.

LOL; I'd better go away and brush up on the spec.

cheers
Bill

---

From: "Jon Meyer" <[email-masked]>
Date: Tue, 31 Aug 2004 13:55:10 -0400

> inform producers that markup will be routinely stripped.

Is there any interest in an @alt attribute, so people who produce rich-text
titles can also be responsible for generating the plain-text version?  e.g.

<title alt="Ghost says *boo*!" type="application/xhtml+xml" mode="xml">
   <div xmlns="http://www.w3.org/1999/xhtml">
      Ghost says <em>boo</em><img src=".../exclamation.gif"/>
   </div>
</title>

Jon

---

From: Tim Bray <[email-masked]>
Date: Tue, 31 Aug 2004 10:57:55 -0700

On Aug 31, 2004, at 4:55 AM, Mark Pilgrim wrote:

>> other than text; no markup whatsoever.
>
> tags in entry titles.

And as Sam points out it'll be ignored.  And as Martin points out there 
are i18n issues.  OK, OK, I give up.  We should have language somewhere 
warning authors that such markup has a likelihood of being stripped & 
ignored.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 14:35:41 -0400

>       Ghost says <em>boo</em><img src=".../exclamation.gif"/>

I could live with that.

- Sam Ruby

---

From: Walter Underwood <[email-masked]>
Date: Tue, 31 Aug 2004 12:26:15 -0700

--On Tuesday, August 31, 2004 03:10:55 PM +0900 Martin Duerst 
<[email-masked]> wrote:

>> be  any support for limiting <atom:title> to text/plain content.

I'm not convinced.

Bidirectional text doesn't require markup, does it? That is standard
Unicode stuff.

Multilingual text can use Unicode langage tags. And I don't think
explicit language marking is essential for Atom. Didn't we discuss
that a few months ago?

Ruby is extra, not essential. Yes, it is very nice to have, but
is it common in card catalogs, etc? I've studied Japanese, and
ruby is good stuff, but it really is extra.

We should look at current practice in math and chemistry. I expect
that things are usually spelled out in titles. The notation is only
used after it is introduced in the body, right? I can ask about this
myself, I've got friends in the on-line science journal business.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 15:39:04 -0400

> Bidirectional text doesn't require markup, does it? That is standard

http://www.w3.org/International/questions/qa-bidi-controls.html

-- 
Cheers,
-Mark

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 15:42:07 -0400

> http://www.w3.org/International/questions/qa-bidi-controls.html

Sorry, I hit send before explaining this:

As this FAQ indicates, Unicode language tagging is acceptable in
places where markup is not allowed, but using (X)HTML's markup is
preferred in (X)HTML contexts.  In other words, bidirectional text can
be accomplished in either context and therefore should not impact our
decision to allow or disallow markup in titles.

-- 
Cheers,
-Mark

---

From: Norman Walsh <[email-masked]>
Date: Tue, 31 Aug 2004 15:45:44 -0400

/ Sam Ruby <[email-masked]> was heard to say:
| I wish you hadn't included images in that list, and perhaps had included ruby
| annotations, or dir="rtl" instead.

Yes, well, images always come to mind because DocBook has an "inline"
image object that can occur basically everywhere. It's purpose is
explicitly for glyphs that aren't available in a local alphabet, or
even in Unicode. I've never used one, but I'm sure it has been used.

| In any case, we have been down this road before:

I'm not surprised. :-)

| http://www.imc.org/atom-syntax/mail-archive/msg06493.html

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | And gentlemen in England now a-bed /
http://nwalsh.com/            | Shall think themselves accursed they
                              | were not here, / And hold their
                              | manhoods cheap whiles any speaks / That
                              | fought with us upon Saint Crispin's
                              | day.--William Shakespeare, Henry V

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 23:13:48 +0200

On Tue, 31 Aug 2004 12:54:02 +0100 (BST), Michael Stillwell  
<[email-masked]> wrote:

> atom:content??

They might. And they might not. Does it matter? atom:title is used for  
something different than atom:content. Thus does it make sense to treat it  
and serve it differently as well.

> Maybe pink text they should, but there's surely a limit to the
> number of CSS properties they should support.

Indeed. I wouldn't trust them to support anything. Atom clients should be  
able to parse Atom content. And there it stops. Although  
'application/xhtml+xml' is the preferred content type to inline, I don't  
think one can require or espect clients to support it. Perhaps they only  
have need for atom:title plus atom:link, for example. Then it doesn't  
matter what content type atom:content has inline.

> I do think the formatting requirements of atom:title are less than those
> of atom:content, but plain text (plus entities) seems insufficient.

Entities are plain text in practice. If we allow for plain text in  
atom:title, we allow for any means that can be used to express plain text  
in XML. That includes entities, CDATA sections and so on.

> For example, nytimes.com currently has one title containing italics on
> the front page, and slate.msn.com has two:
>

Then you're not talking about entities, but real markup. If real markup  
should be allowed, I would like to restrict it to inline elements, but I  
think that path is such a slippery slope that I'm not very eager to run  
down it.

---

From: Ian Davis <[email-masked]>
Date: Tue, 31 Aug 2004 13:33:47 +0100

> inform producers that markup will be routinely stripped.

Is there another way - specify a reduced set of XHTML elements that may 
be used. Some set drawn from one of the XHTML BASIC modules perhaps. I'm 
offline so I can't check details but the minimally useful set could be 
elements such as em, b, strong, i, sup, sub. The Atom spec could mandate 
that these elements are identical in behaviour to XHTML but (maybe) they 
are in the Atom namespace.

Ian

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 01 Sep 2004 00:21:42 +0200

On Tue, 31 Aug 2004 13:55:10 -0400, Jon Meyer <[email-masked]> wrote:

> Is there any interest in an @alt attribute, so people who produce  
> rich-text titles can also be responsible for generating the plain-
> text version?

I think rich-text titles is a really bad idea, but if the consensus is  
that those should be enabled, I don't think we should just use HTML's @alt  
attribute.

Alternative content is great, but the @alt attribute is so badly designed  
in HTML that I don't think we should inherit it directly. Let's use an  
element instead.

---

From: Michael Stillwell <[email-masked]>
Date: Tue, 31 Aug 2004 23:57:12 +0100

On Aug 31, 2004, at 22:13, Asbjørn Ulsberg wrote:
> Then you're not talking about entities, but real markup. If real 
> markup should be allowed, I would like to restrict it to inline 
> elements, but I think that path is such a slippery slope that I'm not 
> very eager to run down it.

Sorry, seems like my original email wasn't clear.  My variation on your 
"pink text" example was intended to show that the Atom spec will need 
to specify what parts of XHTML+CSS are supported in atom:content.  That 
is, the "slippery slope" discussion cannot be avoided because the spec 
will need to specify a point on this slope for atom:content.  So, we 
may as well have this discussion about atom:title too.

I don't know what markup atom:title should support, but I think it 
should support at least <i>, because without it, Atom feeds can't 
losslessly represent existing news feeds.

--M.

-- 
http://beebo.org
+44 78 21 18 90 49

---

From: Antone Roundy <[email-masked]>
Date: Tue, 31 Aug 2004 17:17:15 -0600

On Tuesday, August 31, 2004, at 04:57  PM, Michael Stillwell wrote:
> My variation on your "pink text" example was intended to show that the 
> Atom spec will need to specify what parts of XHTML+CSS are supported 
> in atom:content.  That is, the "slippery slope" discussion cannot be 
> avoided because the spec will need to specify a point on this slope 
> for atom:content.

Do we have/want to specify this?  We certainly need to mention 
something in the "Security Considerations" section about the potential 
for abuses via HTML, scripting, CSS, etc., and I'm sure articles will 
be written to help people figure out how to avoid the potential 
problems.  But I wouldn't think we'd want to go so far as to proscribe 
the use of any particular parts of those technologies, especially since 
doing so could cause more harm than good if it gives people a false 
sense of security.  "The spec says not to include JavaScript, so I 
don't need to write code to strip out JavaScript."

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 31 Aug 2004 16:34:00 -0700 (PDT)

--- Antone Roundy <[email-masked]> wrote:
> 
> But I wouldn't think we'd want to go so
> far as to proscribe 

Especially when simply banning or striping Javascript
tags doesn't remove security concerns. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 20:08:32 -0400

On Tue, 31 Aug 2004 17:17:15 -0600, Antone Roundy <[email-masked]> wrote:
> the use of any particular parts of those technologies

+1

It is a little-known fact that Internet Explorer will execute
Javascript within CSS (including inline style attributes), in at least
two different ways.

http://feedparser.org/docs/html-sanitization.html#advanced.sanitization.why

Furthermore, the definition of "dangerous" depends on whom you ask. 
Is this dangerous?

http://diveintomark.org/public/platypus.xml

-- 
Cheers,
-Mark

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 31 Aug 2004 17:09:36 -0700

>       Ghost says <em>boo</em><img src=".../exclamation.gif"/>

That seems pretty clean to me. The default type would be text/plain, 
but if someone wants to go crazy and knows that doing so might cause 
the title to not appear, have a blast.

--Paul Hoffman, Director
--Internet Mail Consortium