W3C home > Mailing lists > Public > public-tt@w3.org > December 2008

RE: spec question xml:space=preserve

From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Tue, 9 Dec 2008 16:09:48 +0000
To: "Glenn A. Adams" <gadams@xfsi.com>, Public TTWG List <public-tt@w3.org>
Message-ID: <90EEC9D914694641A8358AA190DACB3D2FCEA61E36@EA-EXMSG-C334.europe.corp.microsoft.com>
I'm happy with that solution. Just pointing out something needs to change, as it's wrong as it stands.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385

From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf Of Glenn A. Adams
Sent: 09 December 2008 15:39
To: Public TTWG List
Subject: Re: spec question xml:space=preserve

Or we could qualify 9.3.2 (7) to map anonymous spans to fo:inline only when their parent is p or span. I think this is the preferred way to resolve this issue.

G.

On 12/9/08 11:35 PM, "Glenn Adams" <gadams@xfsi.com> wrote:
Alternatively, we could specify that an anonymous span that is not a child of <p> or <span> is to be pruned from the tree for purpose of presentation processing.


On 12/9/08 10:21 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
So, based on this interpretation, test suite tt002.xml is misleading.

<?xml version="1.0" encoding="utf-8"?>
<tt xml:space='preserve'
  xmlns="http://www.w3.org/2006/10/ttaf1"
  xmlns:tts="http://www.w3.org/2006/10/ttaf1#style"
  xmlns:ttm="http://www.w3.org/2006/10/ttaf1#metadata">
 <head>
     <ttm:title>Content Test - tt - 002</ttm:title>
     <ttm:desc>Test the tt element with xml:space preserve.</ttm:desc>
     <ttm:copyright>Copyright (C) 2008 W3C (MIT, ERCIM, Keio).</ttm:copyright>
 </head>
 <body>
   <div>
     <p begin="0s" end="10s">This text
 must appear on two lines.</p>
   </div>
 </body>
</tt>

I believe the rendered text in this case should contain two leading newlines before the two lines of text and then two newlines following, it for a total of 6 lines. I suggest we move the xml:space='preserve' to the <p> element, or change the description.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385


From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf Of Sean Hayes
Sent: 09 December 2008 12:16
To: Glenn A. Adams; Public TTWG List
Subject: RE: spec question xml:space=preserve

That would do it. I think a note that region is not a content element in 9.3.2 would help though.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385


From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 09 December 2008 10:56
To: Sean Hayes; Public TTWG List
Subject: Re: spec question xml:space=preserve


I believe region is NOT a content element, but defines a layout specification, which, in XSL-FO terms, would be an fo:block-container (as you note).

I believe there is no problem with respect to preserved whitespace inside region, since, according to 9.3.2 (1), only text nodes in a content element are subject to being treated as anonymous spans.

I suppose your last question is whether we should modeify the phrase "that is not a child of a span element", yes?

In other words, I guess you are suggesting that the following:

span
  sequence of text nodes "ABC"
  span
    sequence of text nodes "DEF"
  sequence of text nodes "GHI"

should be rewritten by 9.3.2 (1) to:

span
  anonymous-span
    sequence of text nodes "ABC"
  span
    sequence of text nodes "DEF"
  anonymous-span
    sequence of text nodes "GHI"

So perhaps the language of 9.3.2 (1) should be modified and expanded to the following three rules:
a) for each significant text node in a content element, synthesize an anonymous span to enclose the text node, substituting the new anonymous span for the original text node child in its sibling and parent hierarchy;

b) for each contiguous sequence of anonymous spans, replace the sequence with a single anonymous span which contains a sequence of text nodes representing the individual text node children of the original sequence of anonymous spans;

c) for each span element whose child is a single anonymous span, replace the anonymous span with its sequence of child text nodes;
G.

On 12/9/08 6:24 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
Fair enough, but that leads to the question as to whether region is a content element? It's not in the content matter section so I perhaps not, but it has some content like behaviour defined in 9.3.2, so is whitespace significant in a region?

If region is considered a content element, then per 9.3.2, it maps to fo:block-container, which cannot take fo:inline as children so we would need more elaborate processing.

I also wonder, given we now allow nested spans, whether the first rule of 9.3.2 needs updating:

"for each significant text node in a content element that is not a child of a span element, synthesize an anonymous span to enclose the text node, substituting the new anonymous span for the original text node child in its sibling and parent hierarchy;"



Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385


From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 09 December 2008 04:09
To: Sean Hayes; Public TTWG List
Subject: Re: spec question xml:space=preserve


Since xml:space has semantics irrespective of presentation processing, and since xml:space is generally permitted by XML itself on any element, then it should not be an error to specify on any element in DFXP. Note the last paragraph in DFXP CR 7.2.3.


On 12/9/08 8:32 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
In DFXP should it be considered an error to use xml:space on elements other than span and p?

My thinking is that if text creates anonymous spans, surely these should only be allowed where spans are allowed?


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office:  +44 118 909 5867,
Mobile: +44 7875 091385
Received on Tuesday, 9 December 2008 16:11:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:39 GMT