[Standards] Questions about xhtml-im
stpeter at stpeter.im
Wed Jul 30 14:50:57 UTC 2008
> Peter Saint-Andre;1984 Wrote:
>> Please quote the entire section:
>> A user agent that implements this specification MUST conform to Section
>> 3.5 ("XHTML Family User Agent Conformance") of Modularization of XHTML.
>> Many of the requirements defined therein are already met by Jabber
>> clients simply because they already include XML parsers.
>> However, "ignore" has a special meaning in XHTML modularization
>> (different from its meaning in XMPP). Specifically, criteria 4 through
>> of Section 3.5 of Modularization of XHTML state:
>> W3C TEXT: If a user agent encounters an element it does not
>> recognize, it must continue to process the children of that element. If
>> the content is text, the text must be presented to the user.
>> XSF COMMENT: This behavior is different from that defined by
>> Core, and in the context of XHTML-IM implementations applies only to
>> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace as
>> defined herein. This criterion MUST be applied to all XHTML 1.0
>> except those explicitly included in XHTML-IM as described in the
>> XHTML-IM Integration Set and Recommended Profile sections of this
>> document. Therefore, an XHTML-IM implementation MUST process all XHTML
>> 1.0 child elements of the XHTML-IM <html/> element even if such child
>> elements are not included in the XHTML 1.0 Integration Set defined
>> herein, and MUST present to the recipient the XML character data
>> contained in such child elements.
>>> What I understand is
>>> that when I encounter a tag which I recognize as being xhtml, but
>>> is not in the xhtml-im subset, then I must display it "as is"?
>> Let's say you receive this:
>> <html><body><p>I like the Extensible Messaging and Presence Protocol
>> In this case you would display the XML character data of the <abbr/>
>> element even though it's not part of the XHTML-IM integration set.
>> That's just one example.
> Sorry I did not understand (or at least as much as the original).
Don't worry about that. XHTML modularization is a bit strange. :)
> So when you write to "display the XML character data", you mean that
> you just dump the tag element, and display its content ("XMPP") ?
> So you display this:
>> I like the Extensible Messaging and Presence Protocol (XMPP)
> This would look natural to me (and I think to have understood this is
> also how the W3C recommends it for the core xhtml .
> Anyway for the part about semantic/structure versus style/display,
> probably there can be discussions about this (and you already had
> apparently), but even though I am completely partisan of structure, I
> understood well the two points here which are that this XEP is for IM,
> and that normal users cannot be asked to think about structure when they
> just care about style.
> Yet just to answer shortly about this point:
>>> The style should come from the meaning of the tag, like in the web!
>> How so? Remember that we don't have external CSS here.
> In case where structure would have been chosen above style (even
> though, as I remind, I understand now why style is chosen in IM), there
> may be a small CSS just for the few available tags in xhtml-im on client
> side (then a user could even modify their personal CSS).
Well, I agree with you about structural markup and I don't remember the
discussions that led to a more stylistic focus in XEP-0071. I think
people argued that users really want to send (say) italicized text, not
emphasized text. I'm sure we could check out the list archives for
historical details, but the real question is: how do we want to proceed now?
I'd be willing to relax our usage of the Text Module so that we
encourage more structural markup. As far as I can see, the following
elements would be most useful:
In some applications I could also see an argument for:
h1 through h6
Those are not forbidden in XHTML-IM right now, just not encouraged. But
we could change that if we think it's a good idea.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards