Daniel Aleksandersen wrote:
On 2008-01-30 23:32, you wrote:
Hi Daniel,
I am curious about the status of the required <div> container when
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.
That is a shame.
This is the wrong way to think about the div container. Think of it as
defensive markup. It's there to help prevent things that consume your
feed breaking or mangling your content. In itself, it's not flaw, or a
bug; it's not even a wart.
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.)
You can check the archives if you have time. I don't know if anyone that
worked on Atom likes it, but the div is considered necessary to robustly
transfer chunks of XHTML inside Atom.
[The problems the div solve aren't specific to Atom btw]
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>
Are there any downsides to defining the namespace in the atom:feed element
instead of repeating it troughout the document?
Probably yes. For example, that assumes downstream processors will
remember to copy over the namespace from the root element and not just
extract whatever is inside the content element. Or someone will paste in
prefixed XHTML fragment into a non-prefixed document, and something will
output garbage because it doesn't handle namespaces prefixing of XHTML
properly. Of course XML+XMLNS aware code isn't supposed to behave like
that, but if we had such things as the general case, we wouldn't need
the div workaround to encapsulate XHTML names to begin with.
Given that you've looked at this, considered it, and come up wanting -
a broken content-type workaround - it's probably better for you to
assume a lack of robustness in kind from your consumers, and emit what
the Atom spec says you must emit, irregardless of how you feel about it.
Like I said, it's defensive markup.
cheers
Bill
