- From: William F. Hammond <hammond@csc.albany.edu>
- Date: Wed, 25 Jul 2001 12:00:08 -0400 (EDT)
- To: www-html@w3.org
Masayasu Ishikawa <mimasa@w3.org> writes:
> Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>
> > I suggest to add a new item to section 3.2 of XHTML 1.0 that reads e.g.
[ . . . ]
> Like Terje, I disagree.
[ . . . ]
> If the directionality of an inline element's content is different, you
> might get a completely different rendering on visual user agents by
> moving white space.
[ Directionality? You are referring to a language characteristic, such
as German vs. Arabic, right? ]
Yes, but the whole thread arose over a complaint that a processor for
converting html to xhtml that formerly had W3C provenance(*) had
changed markup like
"<u>F</u>irst"
to
"<u>F</u>
irst"
(thereby incorrectly creating a word boundary after the inline element
"u").
I think it relevant to acknowledge here that such handling is indeed
erroneous and to say that the correct way for such a processor to gain
some control of line lengths (if indeed that was the intention) would
have been to write
"<u>F</u
>".
As I look around at various visual user agents, it seems that the
handling of (leading|trailing) white space in inline elements is
inconsistent among them. (There are also inconsistencies on the
issue between "u"(**) and "em" when, in the latter case, application
of the style in some agents to a blank space is invisible.)
My suggestion is that content providers should be told that writing
leading or trailing white space is deprecated inside these inline
elements.
-- Bill
(*) When I checked Dave Raggett's last tidy (4aug00) on this question,
I found no problem.
(**) The element "u" is excluded from "strict" html.
Received on Wednesday, 25 July 2001 12:00:20 UTC