Subject: type=HTML

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 15:36:11 +0100

(<http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1>)

The spec currently says:

"If the value of "type" is "HTML", the content of the Text construct 
MUST NOT contain child elements, and SHOULD be suitable for handling by 
software that knows HTML. The HTML markup must be escaped; for example, 
"<br>" as "&lt;br>". The HTML markup SHOULD be such that it could 
validly appear directly within an HTML <DIV> element. Receiving software 
which displays the content MAY use the markup to aid in displaying it."

Is there anything that we can say about what recipients should do if 
they are not prepared to tag-soup-parse HTML content (such as something 
based on XSLT1 in Mozilla or running in a size-constrained environment 
(does MIDP come with an HTML parser)? Skip the entry? Do not display the 
content? Display the content including the escaped markup as plain text?

Shouldn't we at least give content producers the hint that producing 
XHTML content is preferred over HTML? (sorry if I'm opening a can of 
worms here)

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Sam Ruby <[email-masked]>
Date: Tue, 08 Feb 2005 10:43:06 -0500

> content? Display the content including the escaped markup as plain text?

I would suggest stripping the tags.  In Perl, something like this:

    s/<.*?>//g

> XHTML content is preferred over HTML? (sorry if I'm opening a can of 

Depending on the target environment, stripping the elements in XHTML may 
also be appropriate.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Tue, 08 Feb 2005 11:56:57 -0500

> Depending on the target environment, stripping the elements in XHTML may 

I would strip both unless the phone had an HTML component available. 
There are plenty RSS readers for phones and small devices, so this 
doesn't seem to be a problem.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Feb 2005 20:22:25 +0100

Sam Ruby wrote:
>> MUST NOT contain child elements, and SHOULD be suitable for handling 
>> by software that knows HTML. The HTML markup must be escaped; for 
>> example, "<br>" as "&lt;br>". The HTML markup SHOULD be such that it 
>> could validly appear directly within an HTML <DIV> element. Receiving 
>> software which displays the content MAY use the markup to aid in 
>> displaying it."
>>
>> they are not prepared to tag-soup-parse HTML content (such as 
>> something based on XSLT1 in Mozilla or running in a size-constrained 
>> environment (does MIDP come with an HTML parser)? Skip the entry? Do 
>> not display the content? Display the content including the escaped 
>> markup as plain text?
> 
> 

Thanks. Are we 100% confident that whatever results from that 
replacement can be safely embedded? For instance, what about <script> 
tags? Can they contain potentially dangerous code that would execute 
without being referenced from somewhere?

> Depending on the target environment, stripping the elements in XHTML may 

Sure, but for XHTML, the XML parser already contains the necessary 
machinery.

Anyway, the spec offers to alternatives (HTML and XHTML) that cover 
similar use cases. I think it would be good if it made a recommendation 
at least for those cases, where the producer already has XHTML content.

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Tue, 08 Feb 2005 15:50:52 -0500

> without being referenced from somewhere?

If one did the simplistic elimination of tags that I mention above, then 
scripts would show as content as opposed to being executed.  Another 
place where the results would be grossly suboptimal would be <table>s.

But in other cases, the results would largely display as intended.  Text 
would not be in bold/italics/whatever, super and subscripts would not be 
above or below, and lists would be flowed, but for most weblog posts the 
ideas would get through.

But in all cases, the results could be safely displayed as text.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Wed, 09 Feb 2005 12:33:58 +0900

>Shouldn't we at least give content producers the hint that producing 
XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here)

I'd be very much in favor of that. The first step is to order the sections
so that XHTML comes first. I have suggested this before. This is very close
to editorial, but can already give some hint.

The second is to add a sentence such as this: "Content producers that can produce
both XHTML content and HTML content SHOULD produce XHTML content."

Regards,    Martin.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Feb 2005 07:52:37 -0800

>not display the content? Display the content including the escaped 

I don't think adding such text helps with interoperability, and is 
thus not useful. If the person writing an Atom displayer that doesn't 
know HTML can't figure out what to do on their own, us making 
suggestions won't help.

>XHTML content is preferred over HTML? (sorry if I'm opening a can of 

Why would one be preferred over the other? They both have their 
strengths and weaknesses. We're not in the business of saying "this 
newer one is better".

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Feb 2005 17:34:02 +0100

Paul Hoffman wrote:
> ...

That's an interesting statement. Does type="HTML" have *any* strengths 
compared to type="XHMTL" (expect being easier to produce if you don't 
have XHMTL in the first place?).

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Feb 2005 09:07:42 -0800

At 5:34 PM +0100 2/9/05, Julian Reschke wrote:
>That's an interesting statement. Does type="HTML" have *any* 
>strengths compared to type="XHMTL" (expect being easier to produce 
>if you don't have XHMTL in the first place?).

That's certainly a big one. Also, many folks don't understand the 
requirements for XHTML that could cause them to create text that will 
be rejected as badly formed. In other words, HTML is just easier.

--Paul Hoffman, Director

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Feb 2005 19:06:33 +0100

Paul Hoffman wrote:
> requirements for XHTML that could cause them to create text that will be 
> rejected as badly formed. In other words, HTML is just easier.

I'll agree that it's easier to produce for those who don't understand 
XML. But shouldn't we recommend XHTML for those who *do* understand 
XML/XHTML (and actually read the spec)?

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Feb 2005 10:16:10 -0800

At 7:06 PM +0100 2/9/05, Julian Reschke wrote:
>I'll agree that it's easier to produce for those who don't 
>understand XML. But shouldn't we recommend XHTML for those who *do* 
>understand XML/XHTML (and actually read the spec)?

Unless that suggestion gains better interoperability for Atom, no.

--Paul Hoffman, Director

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 9 Feb 2005 20:56:54 +0200

> XML/XHTML (and actually read the spec)?

Don't you expect those people to use XHTML without being told so just 
out of an aesthetic dislike of "entity-encoded HTML"?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Feb 2005 20:04:16 +0100

> Unless that suggestion gains better interoperability for Atom, no.

I'll expect more clients to be able to handle XHTML than HTML tag soup. 
So yes, that would enhance interoperability.

Best regards, Julian

---

From: Robert Sayre <[email-masked]>
Date: Wed, 09 Feb 2005 14:41:09 -0500

> So yes, that would enhance interoperability.

I see no compelling reason to prefer one over the other. I think the 
draft should be organized the way it is now. This is not a 
gauntlet[0][1][2] Atom needs to run.

Robert Sayre

[0] http://weblogs.mozillazine.org/roadmap/archives/005632.html
[1] 
http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0004/2004jun02.html#topic24.2
[2] http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html

---

From: Graham <[email-masked]>
Date: Wed, 9 Feb 2005 23:00:48 +0000

> have XHMTL in the first place?).

That's an interesting statement. Does type="XHTML" have *any* strengths 
compared to type="HTML" (expect being easier to produce if you don't 
have HTML in the first place?).

Graham

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 10 Feb 2005 08:41:13 +0200

On Feb 10, 2005, at 01:00, Graham wrote:

> Does type="XHTML" have *any* strengths compared to type="HTML" (expect 
> being easier to produce if you don't have HTML in the first place?).

  * Mixing MathML for future Gecko-based aggregators
  * Mixing SVG for aggregators that use a future version of 
Gecko/WebCore/Presto
  * Less repulsive for people who really don't like "entity-encoded HTML"
  * Easier to produce with some tools (even if you have HTML in the 
first place)

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 09:58:54 +0100

> have HTML in the first place?).

Yes. It can be consumed (accepted without throwing away markup) by 
recipients that do not have access to a tag-soup parser.

Julian

---

From: Danny Ayers <[email-masked]>
Date: Thu, 10 Feb 2005 13:01:17 +0100

> XHTML content is preferred over HTML? (sorry if I'm opening a can of

Sounds reasonable, but as type="XHTML". 

Escaping XHMTL seems to be defeating the object somewhat (we should be
encouraging XML processing rather than tag soup microparsing).

-- 

http://dannyayers.com