At 03:24 2000-03-02 +0300, Nikolai Grigoriev wrote:
>Stephen Deach wrote:
>
>>Any property that is marked "Inherited: yes" in the summary header to the
>>property's definition may be placed on any fo in the flow hiererchy (below
>>the fo:flow node), and will inherit downward to all "children".
>
>I have a couple of questions to follow Stephen's reply:
>
>1) You say that I cannot specify inheritable features on fo:root (e.g.
>   define a common font for all fo:page-sequences). Where in
>   the spec is it written? I refer to [5.2 Inheritance] that poses
>   no limit on the collocation of inheritable features.
>
>   (As for me, I am glad to see an upper limit for inheritance at fo:flow
>   level - I suggested it in the RenderX DTD, half a year ago. I was sure
>   the idea was rejected by the WG).

Actually, I oversimplified my answer. You may specify an inherited property
on fo:root, and it will propogate downward until overridden. However, one
should note that it propogates down via the direct children of a node (at
each level), thus, since the objects in the flow or static-content that are
placed in a region are not children of the region (they are assigned to be
placed in that region via a property, not via a parent:child relationship),
they inherit their properties from the flow-containment hierarchy and not
from the region-containment.

>
>2) Many features are marked as "Inherited: no" but may assume the value
>   of "inherit". I have two choices about them:
>
>   A. These features cannot be specified but on elements to which they
>      are ascribed explicitly in the specs; therefore,
>      table-layout="inherit" only makes sense in a fo:table *nested
>      into another fo:table* (???), and size="inherit" is *meaningless*
>      (though permitted), as no two simple-page-masters may ever include
>      one another;
>
>   B. These features can be specified in the same places as the inheritable
>      ones; it means that, of the whole variety, only ~20 properties are not
>      inheritable, and the rest is permitted virtually anywhere in the tree.
>      Farewell to attribute validation.
>
>      Moreover, having size="inherit" or master-name="inherit" obliges us
>      to permit these features even above the fo:flow level. Mess increases.
>
>   I am afraid XSL could not swallow CSS2 inheritance model yet ;-). Which
>   of A and B is true? Or there's a third alternative that I have missed?

B is more accurate than A, but not completely correct.

Non-inherited properties (that are not "required") may also be specified
anywhere. They "inherit" from parent to child only if each level states:
property-name=inherit. Any level that does not make this statement (and
does not explicitly set a value for the property) is assumed to set the
property to the "initial" value.

(In alternate words, XSL does follow the CSS-2 inheritance rules.)

>
>Regards,
>
>Nikolai Grigoriev
>RenderX
>
>
>
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>

-----------------------------------------------------------------------------
This e-mail reflects the personal opinion of the author.
 -- Unless explicitly so stated in the text, it does not represent an
    official position of Adobe Systems, Inc.
 -- Unless explicitly so stated in the text, it does not represent an
    official opinion of the W3C XSL Working group.
-----------------------------------------------------------------------------
  Stephen Deach                            |  Sr Computer Scientist
  408-536-6521 (office)                    |  Adobe Systems Inc.
  408-537-4214 (fax)                       |  Mail Stop W15-424
  sdeach@xxxxxxxxx (no advertizing)        |  345 Park Ave
                                           |  San Jose, CA 95110-2704
                                           |  USA
----------------------------------------------------------------------------
-


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list