Subject: Status of the <xhtml:div> wrapper

From: Daniel Aleksandersen <[email-masked]>
Date: Wed, 30 Jan 2008 22:31:09 +0100

Hi emailing list, (message contains Unicode characters)

I am curious about the status of the required <div> container when 
including xhtml in text constructs. With it be changed to become optional 
instead? The below example never made much sense to me.

<feed … xmlns:xht="http://www.w3.org/1999/xhtml">
   …
    <summary type="xhtml">
      <xht:div>
        <xht:p>This is a <xht:em>summary</xht:em> paragraph.</xht:p>
      </xht:div>
    </summary>
  …
</feed>

Instead I am currently using a ‘hack’ which involves declaring the type as 
application/xhtml+xml instead of xhtml. It is not directly invalid, 
according to the Atom format specifications. However, it is not very well 
supported either. I always contain the XHTML in paragraphs or other XHTML 
element; so it stays valid XML all the time.

<feed … xmlns:xht="http://www.w3.org/1999/xhtml">
   …
    <summary type="application/xhtml+xml">
      <xht:p>This is a <xht:em>summary</xht:em> paragraph.</xht:p>
    </summary>
  …
</feed>

Is there a better way of doing this? —with ‘better’, I am ‘better 
supported and with a higher adoption rate’. My main concern is that some 
feed readers may not be able to support my undocumented 
implementation/interpretation. Anyone got any experiences in this field?

What about the <article> or <section> elements from the HTML 5 (+XML) 
working draft? They would both become much better containers than a 
meaningless <div> if it is absolutely required to have one.
-- 
Daniel Aleksandersen <[email-masked]>

---

From: James M Snell <[email-masked]>
Date: Wed, 30 Jan 2008 14:16:04 -0800

> instead? The below example never made much sense to me.

No. it is required.

>       <xht:p>This is a <xht:em>summary</xht:em> paragraph.</xht:p>

Don't do this. It's not valid either way.  When 
type="application/xhtml+xml", the content is expected to be processable 
as a complete XHTML document, which obviously is not the case.  Hacks 
like this are most likely just to lead to interoperability problems later.

> implementation/interpretation. Anyone got any experiences in this field?

The best approach is to stick to the standard and to not try to work 
around it.

- James

---

From: "Edward O'Connor" <[email-masked]>
Date: Wed, 30 Jan 2008 14:32:06 -0800

Hi Daniel,

> including xhtml in text constructs. Wi[ll] it be changed to become
> optional instead?

There's no ongoing effort to revise the Atom syntax format, so assume
this <div> will be required in the forseeable future.

> Instead I am currently using a ‘hack’ which involves declaring the
> type as application/xhtml+xml instead of xhtml.

Note that Atom's special-cased @type="html" and @type="xhtml" are
explicitly for HTML *fragments*; if you use
@type="application/xhtml+xml", it's reasonable for an Atom processor to
expect *an entire XHTML document*, <html> element and all, inside your
text construct.

> Is there a better way of doing this? [...] My main concern is that
> some feed readers may not be able to support my undocumented
> implementation/interpretation.

It's probably not a bad idea to use the HTML namespace as the default
within your text construct, like so:

<summary type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
    <p>
      This is a <em>summary</em> paragraph.
    </p>
  </div>
</summary>

-- 
Edward O'Connor
[email-masked]

Ense petit placidam sub libertate quietem.

---

From: Daniel Aleksandersen <[email-masked]>
Date: Thu, 31 Jan 2008 00:54:01 +0100

> this <div> will be required in the forseeable future.

That is a shame.

> expect *an entire XHTML document*, <html> element and all, inside your

Then maybe I should include an entire XHTML document structure. That would 
make more sense than including XHTML fragments contained in a div 
element. (That unnecessary div really bugs me, for some reason.)

>       This is a <em>summary</em> paragraph.

Are there any downsides to defining the namespace in the atom:feed element 
instead of repeating it troughout the document?
-- 
Daniel Aleksandersen <[email-masked]>

---

From: "David Nesting" <[email-masked]>
Date: Wed, 30 Jan 2008 16:01:46 -0800

> instead? The below example never made much sense to me.

Bear in mind that the div element used within "xhtml" content should not
actually appear within the resulting content.  When an Atom application
parses this feed, it's expected to drop the div element and only use the
content within it.  If your intent is to include only an XHTML paragraph
element, the first example is actually correct.  The div element shouldn't
persist.

David

---

From: Daniel Aleksandersen <[email-masked]>
Date: Thu, 31 Jan 2008 01:08:56 +0100

On 2008-01-31 01:01, you wrote:
> > including xhtml in text constructs. With it be changed to become
> > optional instead? The below example never made much sense to me.
>
> Bear in mind that the div element used within "xhtml" content should
> not actually appear within the resulting content.  When an Atom
> application parses this feed, it's expected to drop the div element and
> only use the content within it.  If your intent is to include only an
> XHTML paragraph element, the first example is actually correct.  The
> div element shouldn't persist.

Then what is wrong with the below?

<summary type="xhtml" xmlns:xht="http://www.w3.org/1999/xhtml">
  <xht:p>Is this such a <xht:strong>bold</xht:strong> thing to do?</xht:p>
</summary>

I am trying to understand why XHTML fragments must be contained within two 
containers (the atom:summary AND the xht:div elements).
-- 
Daniel Aleksandersen <[email-masked]>

---

From: "David Nesting" <[email-masked]>
Date: Wed, 30 Jan 2008 16:33:53 -0800

>   <xht:p>Is this such a <xht:strong>bold</xht:strong> thing to do?</xht:p>

This has been discussed on the list a few times.  If you haven't already,
consider going through the archives if you're interested in seeing the
rationale behind this decision.  The chief benefit in my eyes is allowing
for the ability to change the default namespace to improve the readability
of your content's markup.  It also underscores the fact that you're working
with an XHTML document fragment, not an entire document.  You should only
feel comfortable putting content within the div element that you'd be
comfortable putting within a div element inside of a real XHTML document.

But does any of this really matter at this point?  Even if there were good
reasons to change this aspect of the standard, you'd introduce
interoperability problems, because Atom implementations expect a div element
to be there.  If you make it optional, how would you unambiguously use a div
element as a container for your content without some implementations trying
to strip it out?  You'd have to create some new mechanism to make the
decision to strip it out explicit (and probably the default behavior), which
means you're trading one oddity (div) for another
(@strip-first-element="false")..

David

---

From: Joe Cheng <[email-masked]>
Date: Wed, 30 Jan 2008 16:38:12 -0800

> Then maybe I should include an entire XHTML document structure.
> That would make more sense than including XHTML fragments
> contained in a div element. (That unnecessary div really bugs
> me, for some reason.)

The question is, does it bug you enough to sacrifice interop
with pretty much any AtomPub client or server out there? Cause
we're all expecting type="xhtml" and the div; I don't think
anyone is going to do anything nearly as sensible with
application/xhtml+xml as they would with type="xhtml".

There are a few little details about the AtomPub spec that bug
me too, but don't forget that interop is the main reason for
all this stuff. Interop first, reuse second, personal hang-ups
about inelegant packaging a (very) distant third... :)

---

From: "James Holderness" <[email-masked]>
Date: Thu, 31 Jan 2008 03:20:08 -0000

> implementation/interpretation. Anyone got any experiences in this field?

First off, summary elements can't have a type of "application/xhtml+xml" - 
MIME media types are only permitted on content elements.

However, if you're happy to use a content element, then 
"application/xhtml+xml" works almost as well as "xhtml" in my experience. 
The catch is that you must use an xhtml fragment. If you include a full 
xhtml document (as recommended by the spec), your results will tend to be a 
lot worse.

Whatever you do, though, don't use namespace prefixes - aggregators don't 
deal at all well with that.

And in case it's not obvious, your best bet is actually to avoid xhtml 
altogether and use escaped html - but I suspect you won't want to do that.

Regards
James

---

From: Eric Scheid <[email-masked]>
Date: Thu, 31 Jan 2008 15:51:37 +1100

> instead of repeating it troughout the document?

the downside is that you have to repeat the xht:ns prefix on all the child
elements:

<feed Š xmlns:xht="http://www.w3.org/1999/xhtml">
   Š
    <summary type="xhtml">
      <xht:div>    
        <xht:p>This is a <xht:em>summary</xht:em> paragraph.</xht:p>
      </xht:div>   
    </summary>
  Š
</feed>

Any content not much more complicated than that very simple example and it
would actually be more bytes than repeating the declaration inside each
summary.

That, plus the hassle of you adding the prefix, and the receiver removing
the prefix .. much simpler all round to repeat the ns declaration on the
<div /> wrapper each time.

e.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Jan 2008 10:38:55 +0100

James Holderness wrote:
> ...
> Whatever you do, though, don't use namespace prefixes - aggregators 
> don't deal at all well with that.
> ...

I'd take that as a good reason to use them, unless interop with broken 
clients is really required.

 > ...

BR, Julian

---

From: Daniel Aleksandersen <[email-masked]>
Date: Thu, 31 Jan 2008 11:43:53 +0100

On 2008-01-31 05:51, you wrote:
> > Are there any downsides to defining the namespace in the atom:feed
> > element instead of repeating it troughout the document?
>
> the downside is that you have to repeat the xht:ns prefix on all the
> child elements:
>
> <feed  xmlns:xht="http://www.w3.org/1999/xhtml">
>    
>     <summary type="xhtml">
>       <xht:div>
> Any content not much more complicated than that very simple example and
> it would actually be more bytes than repeating the declaration inside
> each summary.
>
> That, plus the hassle of you adding the prefix, and the receiver
> removing the prefix .. much simpler all round to repeat the ns
> declaration on the <div /> wrapper each time.

One can easily add and remove the prefixes using any XML parser. (Which is 
required to work with Atom feeds anyways.)

I m really left with no choice but to use both <summary> and <div>, and 
with no predeclared namespace. I wonder why the specification even 
mentions other approaches then.

Regarding application/xhtml+xml in <content>.… Must I include a full 
document type and all? Or is it only the full <html> tree construct (from 
that element) that is required?

I think I will stick with representing a simple text‐type and a link!! :-P
-- 
Daniel Aleksandersen <[email-masked]>

---

From: Daniel Aleksandersen <[email-masked]>
Date: Fri, 1 Feb 2008 03:44:16 +0100

On 2008-01-31 11:43, Daniel wrote:
> document type and all? Or is it only the full <html> tree construct
> (from that element) that is required?

I have not been able to find an answer to this elsewhere, so I am asking 
the question again. From the html element, or the full thing with doctype 
declaration?
-- 
Daniel Aleksandersen <[email-masked]>

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 31 Jan 2008 18:55:37 -0800

Daniel Aleksandersen wrote:
> I have not been able to find an answer to this elsewhere, so 
> I am asking the question again. From the html element, or the 
> full thing with doctype declaration?

You cannot embed a doctype declaration into an XML document. It is illegal syntactically.

- Brian