Empty span/div tags in RDFa pages

[Stephane Corlosquet]

Hi,

According to the examples of http://www.w3.org/TR/rdfa-syntax/#sec_6.1.1.5.1. it is allowed to use the shorthand notation for empty span/div tags in RDFa+XHTML:
  <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany" />

However, according to XHTML 1.0 specs [1]:
"Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />)."

There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is part of these. I looked in XHTML 1.1 and didn't find anything. The RDFa DTD [2] does not declare new EMPTY tags either. Can someone point me to some specs or a DTD which explains why the empty tag notation is allowed in RDFa?

On a side note, firebug does not render these well, and wraps the empty span around the next sibling tag [3]. That might be a firebug bug...

Stephane.

[1] http://www.w3.org/TR/xhtml1/#C_3
[2] http://www.w3..org/MarkUp/DTD/xhtml-rdfa-1.dtd
[3] http://skitch.com/scor/nrpat/empty-tags-firebug-bug

[Toby Inkster-4]

On Fri, 2009-10-23 at 14:12 -0400, Stephane Corlosquet wrote:
> There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is
> part of these. I looked in XHTML 1.1 and didn't find anything. The
> RDFa DTD [2] does not declare new EMPTY tags either. Can someone point
> me to some specs or a DTD which explains why the empty tag notation is
> allowed in RDFa?

If you read the XHTML 1.0 spec, you'll find that <div/> is perfectly
valid. Appendix C discourages it in favour of <div></div>, but Appendix
C is informative, not normative.

XHTML 1.1 was written as more of a "pure XML application" with
backwards-compatibility with non-X HTML less in mind, so takes the
they-parse-exactly-the-same-under-XML-rules approach. RDFa is built on
XHTML 1.1 rather than XHTML 1.0, thus inherits the "who cares whether
you use <div></div> or <div/>?" philosophy - in theory.

In practice, if you're serving RDFa using the text/html Content-Type,
you'll want to pay attention to the Appendix C guidelines of XHTML 1.0,
and avoid writing <div/>.

This is true for any XHTML-family language, not just RDFa - in theory
<div/> and <div></div> are identical, but in practise, served as
text/html, they're parsed very differently.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Julian Reschke]

Toby Inkster wrote:

> On Fri, 2009-10-23 at 14:12 -0400, Stephane Corlosquet wrote:
>> There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is
>> part of these. I looked in XHTML 1.1 and didn't find anything. The
>> RDFa DTD [2] does not declare new EMPTY tags either. Can someone point
>> me to some specs or a DTD which explains why the empty tag notation is
>> allowed in RDFa?
>
> If you read the XHTML 1.0 spec, you'll find that <div/> is perfectly
> valid. Appendix C discourages it in favour of <div></div>, but Appendix
> C is informative, not normative.
>
> XHTML 1.1 was written as more of a "pure XML application" with
> backwards-compatibility with non-X HTML less in mind, so takes the
> they-parse-exactly-the-same-under-XML-rules approach. RDFa is built on
> XHTML 1.1 rather than XHTML 1.0, thus inherits the "who cares whether
> you use <div></div> or <div/>?" philosophy - in theory.
>
> In practice, if you're serving RDFa using the text/html Content-Type,
> you'll want to pay attention to the Appendix C guidelines of XHTML 1.0,
> and avoid writing <div/>.
>
> This is true for any XHTML-family language, not just RDFa - in theory
> <div/> and <div></div> are identical, but in practise, served as
> text/html, they're parsed very differently.

Which of course is caused by the fact that you simply can't serve XHTML
as text/html. The media type is authoritative, so recipients will treat
it as HTML.

BR, Julian

[Toby Inkster-4]

On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote:
> Which of course is caused by the fact that you simply can't serve
> XHTML as text/html. The media type is authoritative, so recipients
> will treat it as HTML.

I think this is something that is often overstated.

RFC 2854 notes that "different versions [of HTML] are distinguishable by
the DOCTYPE declaration contained within them", so -- assuming that
XHTML is a "version" of HTML, whatever that means -- it is not incorrect
behaviour to detect an XHTML DOCTYPE and perform version-specific
parsing on the content.

I realise that many popular user agents (especially desktop browsers) do
not do this, but that doesn't make it wrong to do so.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Ian Hickson]

On Mon, 26 Oct 2009, Toby Inkster wrote:

> On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote:
> > Which of course is caused by the fact that you simply can't serve
> > XHTML as text/html. The media type is authoritative, so recipients
> > will treat it as HTML.
>
> I think this is something that is often overstated.
>
> RFC 2854 notes that "different versions [of HTML] are distinguishable by
> the DOCTYPE declaration contained within them", so -- assuming that
> XHTML is a "version" of HTML, whatever that means -- it is not incorrect
> behaviour to detect an XHTML DOCTYPE and perform version-specific
> parsing on the content.
>
> I realise that many popular user agents (especially desktop browsers) do
> not do this, but that doesn't make it wrong to do so.

This is one of the main things that HTML5 fixes in its updated text/html
registration:

  http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html#text/html

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Julian Reschke]

Toby Inkster wrote:

> On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote:
>> Which of course is caused by the fact that you simply can't serve
>> XHTML as text/html. The media type is authoritative, so recipients
>> will treat it as HTML.
>
> I think this is something that is often overstated.
>
> RFC 2854 notes that "different versions [of HTML] are distinguishable by
> the DOCTYPE declaration contained within them", so -- assuming that
> XHTML is a "version" of HTML, whatever that means -- it is not incorrect
> behaviour to detect an XHTML DOCTYPE and perform version-specific
> parsing on the content.

<http://tools.ietf.org/html/rfc2854#section-2> states:

    Published specification:
       The text/html media type is now defined by W3C Recommendations;
       the latest published version is [HTML401].  In addition, [XHTML1]
       defines a profile of use of XHTML which is compatible with HTML
       4.01 and which may also be labeled as text/html.

So there's really nothing in there that would allow to use a different
parser than then one for text/html.

> I realise that many popular user agents (especially desktop browsers) do
> not do this, but that doesn't make it wrong to do so.

I believe it is wrong to do so, and that all desktop browsers get *this*
one right.

BR, Julian

[Julian Reschke]

Ian Hickson wrote:

> On Mon, 26 Oct 2009, Toby Inkster wrote:
>> On Mon, 2009-10-26 at 18:40 +0100, Julian Reschke wrote:
>>> Which of course is caused by the fact that you simply can't serve
>>> XHTML as text/html. The media type is authoritative, so recipients
>>> will treat it as HTML.
>> I think this is something that is often overstated.
>>
>> RFC 2854 notes that "different versions [of HTML] are distinguishable by
>> the DOCTYPE declaration contained within them", so -- assuming that
>> XHTML is a "version" of HTML, whatever that means -- it is not incorrect
>> behaviour to detect an XHTML DOCTYPE and perform version-specific
>> parsing on the content.
>>
>> I realise that many popular user agents (especially desktop browsers) do
>> not do this, but that doesn't make it wrong to do so.
>
> This is one of the main things that HTML5 fixes in its updated text/html
> registration:
>
>   http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html#text/html

I don't think this is a "fix", in that RFC 2854 never said you can
deliver XHTML as text/html and expect it to be treated as XHTML.

BR, Julian

[Toby Inkster-4]

On Tue, 2009-10-27 at 15:11 +0100, Julian Reschke wrote:
> I don't think this is a "fix", in that RFC 2854 never said you can
> deliver XHTML as text/html and expect it to be treated as XHTML.

Nor does RFC 2854 place any particular limits on how documents served as
text/html may be treated. Parsing some such documents with an XML parser
is not forbidden.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Julian Reschke]

Toby Inkster wrote:
> On Tue, 2009-10-27 at 15:11 +0100, Julian Reschke wrote:
>> I don't think this is a "fix", in that RFC 2854 never said you can
>> deliver XHTML as text/html and expect it to be treated as XHTML.
>
> Nor does RFC 2854 place any particular limits on how documents served as
> text/html may be treated. Parsing some such documents with an XML parser
> is not forbidden.

Again, <http://tools.ietf.org/html/rfc2854#section-2>:

    Published specification:
       The text/html media type is now defined by W3C Recommendations;
       the latest published version is [HTML401].  In addition, [XHTML1]
       defines a profile of use of XHTML which is compatible with HTML
       4.01 and which may also be labeled as text/html.

Of course a recipient can do whatever it wants. But by serving the
content with

  Content-Type: text/html

the sender indicates that the content should be treated as text/html
(remember: authoritative metadata), and the mime type registration for
text/html says that the HTML 4.01 spec applies.

If the recipient does something else it essentially does content type
sniffing.

BR, Julian

[Stephane Corlosquet]

Thanks! That makes sense. Firebug was right, if the same page is served as application/xhtml+xml  it's rendered well. So now I wonder what's the best thing to do. Keep the old text/html and not use the shorthand notation, or switch to Content-Type: application/xhtml+xml .. I think we're too late in the development process of Drupal 7 to change the Content-Type, as I'm not sure what the side effects are.

Steph.

On Mon, Oct 26, 2009 at 1:40 PM, Julian Reschke <julian.reschke@...> wrote:

Toby Inkster wrote:

On Fri, 2009-10-23 at 14:12 -0400, Stephane Corlosquet wrote:

There are only 10 EMPTY tags in HTML 1.0, and neither div nor span is
part of these. I looked in XHTML 1.1 and didn't find anything. The
RDFa DTD [2] does not declare new EMPTY tags either. Can someone point
me to some specs or a DTD which explains why the empty tag notation is
allowed in RDFa?

If you read the XHTML 1.0 spec, you'll find that <div/> is perfectly
valid. Appendix C discourages it in favour of <div></div>, but Appendix
C is informative, not normative.

XHTML 1.1 was written as more of a "pure XML application" with
backwards-compatibility with non-X HTML less in mind, so takes the
they-parse-exactly-the-same-under-XML-rules approach. RDFa is built on
XHTML 1.1 rather than XHTML 1.0, thus inherits the "who cares whether
you use <div></div> or <div/>?" philosophy - in theory.

In practice, if you're serving RDFa using the text/html Content-Type,
you'll want to pay attention to the Appendix C guidelines of XHTML 1.0,
and avoid writing <div/>.

This is true for any XHTML-family language, not just RDFa - in theory
<div/> and <div></div> are identical, but in practise, served as
text/html, they're parsed very differently.

Which of course is caused by the fact that you simply can't serve XHTML as text/html. The media type is authoritative, so recipients will treat it as HTML.

BR, Julian

[Julian Reschke]

Stephane Corlosquet wrote:
> Thanks! That makes sense. Firebug was right, if the same page is served
> as application/xhtml+xml  it's rendered well. So now I wonder what's the
> best thing to do. Keep the old text/html and not use the shorthand
> notation, or switch to Content-Type: application/xhtml+xml .. I think
> we're too late in the development process of Drupal 7 to change the
> Content-Type, as I'm not sure what the side effects are.
> ...

If you switch the content type to application/xhtml+xml, IE will not be
able to deal with it (I think unless you make the extension .html, in
which case IE appears to do content-sniffing).

BR, Julian