This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Inheritance Model (was: XSL-fo)
- To: xsl-list at mulberrytech dot com, "XSL List" <xsl-list at mulberrytech dot com>
- Subject: Re: Inheritance Model (was: XSL-fo)
- From: Stephen Deach <sdeach at Adobe dot COM>
- Date: Wed, 01 Mar 2000 19:59:32 -0800
- Reply-To: xsl-list at mulberrytech dot com
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@adobe.com (no advertizing) | 345 Park Ave
| San Jose, CA 95110-2704
| USA
----------------------------------------------------------------------------
-
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list