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

Re: spec question xml:space=preserve

From: Glenn A. Adams <gadams@xfsi.com>
Date: Tue, 09 Dec 2008 23:38:57 +0800
To: Public TTWG List <public-tt@w3.org>
Message-ID: <C564B212.6D9B%gadams@xfsi.com>
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 15:39:46 GMT

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