issues around style and region.

In my continuing quest to understand the specification; I notice that style association for region has a special case not covered in 8.4. which is neither inline nor referential. Which to my mind complicates the specification, but which offers no additional functionality or notational convenience.

In general I think special cases should be avoided. And I'd like to propose removing <style> as an allowed child element of <region> unless someone knows of a good reason why they should be kept.

If we are to keep them, then I think this special case handling needs to be described, or at least referenced in section 8.4. Also apropos my earlier concern about chained referential styling; I think the problem may stem from the fact that we define a computed style specification set in <style> (and <region> although I think the latter should go) which contains the recursive algorithm; making 8.4.3 in fact redundant. But we don't explicitly reference the computed style specification anywhere in 8.4.

I think editorially it would make much more sense if the exposition of computed style specification set and style association were all combined into 8.4 to extend the concept of the computed style specification set to a content element and remove the concept of style association. This would then tie in with 9.3.2 and style inheritance both of which reference the computed style specification set of a content element; a concept which is rather ill defined at the moment.

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: 10 December 2008 10:35
To: Glenn A. Adams; Public TTWG List
Subject: RE: spec question - extent

Again, this is not a case where I have a problem with the underlying requirement, which I get; but the way it is expressed, which seems designed to confuse.

Having body set constraints on effectively its grandparent , which constrain its parent region, and thus its own layout seems at best odd, and at worst a circular definition.

I don't recall the time when extent was defined on tt, but that would seem a better option, and in fact . 9.3.2 is still defined as if that was where it was; so I support its move back there rather than change 9.3.2..

If I was one of those arguing for its move to body, then I clearly didn't understand the synchronic flow processing algorithm at the time,

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: 10 December 2008 00:47
To: Sean Hayes; Public TTWG List
Subject: Re: spec question - extent


I don't see as unusual or illogical at all. If I want to design a particular layout for regions, then I have to make certain assumptions about the coordinate space in which those regions are placed, which is precisely the intent of tts:extent on body. If you recall, we had earlier placed this property on <tt:tt/> rather than <tt:body/>, but some commenters felt strongly it should be on the latter, so we moved it. I was opposed to that change, however, so I would not mind moving it back to the way we had it.  For me, tts:extent on body is similar to specifying width and height properties on an <svg/> element in SVG. Similarly, it would be best to express this on <tt/>.


On 12/10/08 7:24 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
I'm confused by the definition of the extent property:

"The root container extent is determined either by a tts:extent specified on the body element, if present, or by the external authoring context, if not present. In the former case, if the width and height is expressed in terms of two <length> specifications, then these specifications must be expressed as non-percentage, definite lengths using pixel units."

I'm not sure we should even be considering shaping the external root container, but if we are, then since body elements are notionally re-parented inside regions, it seems illogical to me that the body would specify the extent of the root container in which regions are placed. It would make more sense to me in such a case if extent applied to apply to layout and region, the former setting the authoring context, and the latter setting the regions within that context.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

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