W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14360] Count Unicode 'combining marks" together with "inter-element whitespace"

From: <bugzilla@jessica.w3.org>
Date: Tue, 04 Oct 2011 02:21:47 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RAudf-0001dW-RF@jessica.w3.org>

--- Comment #9 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-10-04 02:21:41 UTC ---
(In reply to comment #8)
> > > > 3)  Visually, such marks may look as if they combine with something outside the
> > > > element
> > > 
> > > They might well combine with something outside the element's border box. Why is
> > > this a problem?
> > 
> > The situation I described was one where it *looks* as if it it combines with
> > something (that is: with something unvisible) outside the element.  That is: A
> > situation where there is nothing to combine with. (For all I know, it combines
> > withe box - rather than a character - outside the element.)
> > 
> > If the combining character is inside an element with display:inline-block, and
> > combines with another character in a mathml element, then that is another
> > matter - and not a problem. 
> I have no idea what you're saying here. Could you elaborate? Maybe a concrete
> example?

W.r.t.  initial comment 3), then look here:
The demo shows tha combining marks, when "alone", move outside the left border
of the element, as if it combines with something that is outside the element.
It does perhaps not happen with every combining mark, but it seems to happen at
least with diacritica.

W.r.t. my subsequent reply to your comment, then look at the "inline-block"
examples at the bottom of the following demo: <http://tinyurl.com/5stsb7r>.
When I flesh it out a bit more, that demo has this code:
<p><span style="display:inline-block">&#x0020;&#x20DC;</span>
   Despite the space between the '' and the combining character, the combining
character combines with the ''.  This, I said is fine. Only if we removed the
"", would there be a problem as then there would be nothing to combine with:
<p><span style="display:inline-block">&#x0020;&#x20DC;</span>


NOTE 1: This bug is filed against the 'Flow content' section, where you give a
description of the  general rule of what """elements whose content model allows
any flow content""" as a minimum **should** contain. The spec says that the
minimum is not a strict rule: 'not a hard requirement'. And I simply would like
that this "not hard requirement" is stretched to include combining characters

      Btw, conformance checkers do not display a warning if e.g. the <body>
element is emtpy, and so it did not need to to actually warn in case the <body>
only contains a combining mark either ... It would be enough for me if the spec
explained that an element "whose content model allows any flow content", is
more than spaces and combining marks.

NOTE 2: Do you disagree with the advice of Unicode6, that  authors, when they
want to represent a combining character as if was an independent, spacing
character, should combine with no-break space?  If you don't, how  can one get
this authoring advice into the spec?

NOTE 3: It is not so that I that *my* proposal circumentvents all
implementation bugs. Far the from. So it is not a proposal that seeks to
circument implementation bugs. In fact, my proposal emphasizews that 

NOTE 3: Do I misunderstand "any flow content"? I read it as "every sort" but
perhaps it is meant "some sort"?

NOTE 4: This variant of my previous demo, has dd:first-letter{white-space:pre}.
And as you can see, this makes the line where there is a space plus a combining
mark identical with the line where there is no-break space and a combining
mark. However, the line where there is only a combining mark as first eltter,
is not affected - given that not every implementation has CSS enabled, one
can't rely on this:


Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 4 October 2011 02:21:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC