Hi all, Earlier this year I had asked a number of questions on the XSL-editors mailing list. Most of those had not yet been answered. I just received detailed responses from the working group at the W3C. Thought you might be interested in seeing them so here they are. Perhaps we'll be seeing a PR soon. Regards, Karen -------- Original Message -------- Subject: Your comments on the XSL Candidate Recommendation Date: Thu, 14 Jun 2001 14:23:21 -0400 From: "Anders Berglund" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Thank you for your thoughtful and constructive comments on the XSL formatting objects Candidate Recommendation. We have structured the attached response as follows: 1. Broken down the comments into individual items. 2. Included copies of relevant mail discussions that took place on the xsl-editors list regarding your comments. 3. The written response of the XSL WG. The XSL WG appreciates the time and effort you made in constructing your comments. If there are any questions or concerns please send mail to the xsl-editors list at [EMAIL PROTECTED] by July 2, 2001. If we have not heard from you by that date we will assume that our response satisfies your comments. Sharon C. Adler Senior Manager, Extensible Technologies IBM Research PO Box 704, Yorktown Heights, NY 10598 tel: 914-784-6411 t/l 863 fax: 914-784-6324 (See attached file: klease.htm)Title: Disposition of Comments on XSL Candidate Recommendation
Disposition of Comments on XSL Candidate RecommendationComment 17 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0008.htmlMessage-ID: <[EMAIL PROTECTED]> Date: Thu, 04 Jan 2001 23:18:10 +0100 From: Karen Lease <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: fo:block-container, padding and borders- request for clarification Hello, Item 1I'd like to make sure I have the correct understanding of how to handle padding and border on block-container formatting objects. In section 6.5.3 I read: "The fo:block-container formatting object generates one or more viewport/reference pairs. ... The following properties apply to this formatting object: [7.4 Common Absolute Position Properties] [7.6 Common Border, Padding, and Background Properties] " In the general explanation of the area model (Chapter 4.9.4), it says that the border is not rendered for areas which are children of viewport-areas. Since border and padding can be specified on block-container, should they be applied to the viewport-area? For example, suppose I have an absolutely positioned block-container. The values for left,top etc. position its content rectangle. Assuming no scrolling, the content rectangle for the reference area and its parent viewport area should be the same (at least their start and before edges are the same). If non-zero padding and border were specified for the block container, are they to be rendered outside the content rectangle of the viewport area? Disposition: Explanation of XSL spec The answer to both your questions is yes. The border and padding should be applied to the viewport-area and rendered outside its content rectangle. Thanks in advance, Karen Lease, FOP'er Comment 18 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0009.htmlMessage-ID: <[EMAIL PROTECTED]> Date: Thu, 04 Jan 2001 23:53:58 +0100 From: Karen Lease <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Inherited values where percent is legal Hello, Item 1In working on FOP's FO property handling, I've run across a few issues involving lengths which can be specified as percentages, especially when the property can be inherited. My list of such properties and their reference dimensions is as follows: start-indent, end-indent width of containing reference area text-indent, last-line-text-indent width of containing block line-height font-size of the FO (inherits specified?) font-size font-size of parent (inherits computed) leader-length width of content-rectangle of parent area leader-pattern-width width of containing box provisional-distance-between-starts width of containing box provisional-label-separation width of containing box I know that the general rule is that computed values are inherited. This is explicitly stated for font-size. On the other hand, for line-height, when it is specified as a number the specification says that the specified value is inherited. In this case, I'm inclined to treat a percentage in the same way as a number (and a relative length too for that matter). For the other properties above, there is no specific mention of the inherited value, implying that the computed value is inherited. This bothers me a bit, especially for a property like leader-length where the default value for leader-length.maximum is "100%". I would feel more comfortable if the specified percentage value were inherited and recalculated on each flow object. I'd appreciate any explanations or justifications you can offer for this. Disposition: Explanation of XSL spec For compatibility with CSS2 the general rule, even for percentages, is that the computed value is inherited. We have added a section specifying in detail which area is used as reference when the "general rule" is not sufficient, e.g. a percentage specified on fo:root. Added text in the XSL recommendation: 7.3 Reference Rectangle for Percentage ComputationsAllowed conversions for percentages, specified on the property definition, is typically in terms of the content-rectangle of some area. That area is determined as follows:
Item 2A related question: in the list above, there are several different ways of designating the base length for a percentage. My interpretation is : a) the dimension in question is always the content-rectangle, unless explicitly stated otherwise, b) "containing block" means the nearest block-area ancestor c) "containing box" and "parent area" are basically equivalent and could be either an inline-area or block-area. Is this correct? Or is there some distinction I'm missing? Disposition: Accepted (bug in spec) A section has been added to specify in detail which rectangle (which in almost all cases is the content-rectangle) is used as reference for the calculation of the computed value of a percentage. The different ways it was designated in the text has been rationalized. See added text above. Thanks in advance for any information, Karen Lease, FOP'er Comment 31 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0096.htmlMessage-ID: <[EMAIL PROTECTED]> Date: Fri, 16 Feb 2001 00:14:06 +0100 From: Karen Lease <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Interaction of shorthand and corresponding properties Dear editors, Item 1Could you one of you please comment on the following cases assuming the block progression direction is top to bottom : A <fo:block padding="3pt" padding-top="4pt">.... According to 5.2 and 5.3.1, I see the following property values being set for padding-top and padding-before. padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-top=4pt (set explicitly) padding-before=4pt (set from the corresponding padding-top property) Now supposing we have this: B <fo:block padding="3pt" padding-before="4pt">.... This seems to imply the following values being set padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-before=3pt (set from the corresponding padding-top property, so the explicit setting of 4pt is ignored!) What I (as a user) expect to happen is this: padding-before=4pt (set explicitly) padding-top=4pt (set from the corresponding padding-before property ???) In 5.3.1, the CR says: "If the corresponding absolute variant of the property is specified on the formatting object, its computed value is used to set the computed value of the corresponding relative property. If the corresponding absolute property is not explicitly specified, then the computed value of the absolute property is set to the computed value of the corresponding relative property." This rule works fine for case A. In case B, it seems that I can only get padding-before (and padding-top) set to 4pt if I consider that the shorthand is not equivalent to setting the absolute property explicitly, so that the explicit value of the relative property is used (for both). But then what about this? C <fo:block padding="3pt">.... This seems to imply the following values should be set: padding-before=0pt, padding-top=0pt (initial values) padding-top=3pt (from the shorthand) padding-before=3pt (set from the corresponding padding-top property) But here, I want to use the value set by the shorthand to set the relative property. In other words, the behavior that seems natural is that the shorthand setting of the absolute property is "weaker" than the explicit setting of the corresponding relative property. If that's what you meant, perhaps you could make it clearer in the next (final?) version. Disposition: Accepted (clarification) Text to clarify that your last paragraph is indeed the intended meaning has been added. Added text in the XSL recommendation: For this class, the computed values of the corresponding properties are determined as follows. If the corresponding absolute variant of the property is specified on the formatting object, its computed value is used to set the computed value of the corresponding relative property. If the corresponding absolute property is not explicitly specified, then the computed value of the absolute property is set to the computed value of the corresponding relative property. If the corresponding relative property is specified on the formatting object and the absolute property only specified by the expansion of a shorthand, then the computed value of the absolute property is set to the computed value of the corresponding relative property. Thanks in advance for your feedback, Karen Lease (FOP contributer) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Comment 32 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0097.htmlDate: Thu, 15 Feb 2001 18:18:33 -0500 (EST) Message-ID: <[EMAIL PROTECTED]> From: Karen Lease <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Meaning of keyword "inherit" for non-inheritable properties Hello again, Item 1I suppose this has been mentioned before, but it still bothers me to be able to specify xxx="inherit" when xxx isn't inheritable. (Of course, if it is inheritable, there's no reason to say so, since if xxx isn't specified, it will get the value from its parent.) The meaning seems to be identical to xxx="from-parent(xxx)", including the case of shorthand properties. So is this just to simplify life for users? Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0099.html Message-Id: <[EMAIL PROTECTED]> Date: Sun, 18 Feb 2001 17:18:35 +0900 To: Karen Lease <[EMAIL PROTECTED]>, [EMAIL PROTECTED] From: Martin Duerst <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Meaning of keyword "inherit" for non-inheritable properties At 18:18 01/02/15 -0500, Karen Lease wrote: >Hello again, > >I suppose this has been mentioned before, but it still bothers me to be >able to specify xxx="inherit" when xxx isn't inheritable. Please change 'inheritable' to 'inherited', and everything looks much more reasonable (I'm not sure where you got the word 'inheritable' from, I hope it's not in the spec itself.) Either a property is (by default) inherited, or it can be inherited by specifying 'inherit' as a property value. Regards, Martin. >(Of course, if >it is inheritable, there's no reason to say so, since if xxx isn't >specified, it will get the value from its parent.) > >The meaning seems to be identical to xxx="from-parent(xxx)", including >the case of shorthand properties. > >So is this just to simplify life for users? > >Karen Lease (FOP contributor) Discussion message: lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0107.html To: Karen Lease <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], FO subgroup <[EMAIL PROTECTED]> From: Max Froumentin <[EMAIL PROTECTED]> Date: 20 Feb 2001 13:37:21 +0100 Message-ID: <[EMAIL PROTECTED]> Subject: Re: Meaning of keyword "inherit" for non-inheritable properties Karen Lease <[EMAIL PROTECTED]> writes: > I suppose this has been mentioned before, but it still bothers me to be > able to specify xxx="inherit" when xxx isn't inheritable. I guess one should read 'Inherited by default: none' where the spec says 'Inherited: no'. > (Of course, if it is inheritable, there's no reason to say so, since > if xxx isn't specified, it will get the value from its parent.) In CSS, it makes sense to specify 'inherit' as a value even though the property is inheritable because the value may have been set to something else in the cascading process and you want to override it. In XSL it also makes sense, but for shorthand properties. For example you might have (probably as the result of the expansion of a use-attribute-set): font="bold 12pt helvetica" font-size="inherited". font-size is inherited by default but you still have to specify it to override the shorthand property. Does this answer your question? Max. Disposition: Explanation of why no change will be made The "inherit" keyword, as well as the term "inheritable", are both used in CSS2 and for compatibility reasons are used in XSL as well (even if "copy from parent" would have been more natural). Karen Lease (FOP contributor) |
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
