Re: FO. Is XSL FO realy XML? Re: attributes ordering

Dear Stephen,

Thank you very much for providing this information. 

Do I understand right that in the situation 
'border' + 'border-style'  + 'border-top' 

'border-style'  overrides 'border'  and  then
'border-top' overrides 'border-style' ?

Thank you.

Rgds.Paul.

PS. It appears that there could be at least 2 new sections 
in the WD. One section is 'inheritance' and another is 
'priority'.


> This refers to the order the sub-properties are specified within the
> border="..." property itself. The entire border="..." argument string is
> treated as a single property by XSL.
> 
> If one sets 'border' and 'border-start' and 'border-start-style' on the
> same FO, they should be processed from least-qualified to most-qualified
> (which happens to be the order that they are shown -- thus border sets up
> tenative values for all sides, then border-start replaces the settings for
> the start edge, finally border-start-style overrides the individual style
> setting on the start-edge.)
> 
> There are other "order-of-interpretation" issues which we are attempting to
> identify. For example, font-size must be evaluated first, since EM-based
> sizes depend on it.
> 
> We need to add a section to the specification describing this.
> 
> 
> 
> At 22:11 1999-09-22 -0700, Paul Tchistopolskii wrote:
> >
> ><WD>
> >
> >5.4 Common Border, Padding, and Background Properties
> >....
> >
> >5.4.31 border
> >5.4.31.1 Allowed Values
> ><'border-top-width'> || <'border-style'>> || <color> 
> >
> >5.4.31.2 Description
> >A shorthand property for setting border the properties of a block-area or
> inline-area.
> >
> >The "border" property is a shorthand property for setting the same width,
> color, 
> >and style for all four borders, top, bottom, left, and right, of a box. 
> >Unlike the shorthand "margin" and "padding" properties, the "border" 
> >property cannot set different values on the four borders. To do so, 
> >one or more of the other border properties must be used. 
> >Since, to some extent, the properties have overlapping functionality, 
> >the order in which the rules are specified is important. 
> ></WD>
> >
> >The last line requires processing to rely on the attribute order.
> >( 'border'  is actualy attribute ).
> >
> >Rgds.Paul.
> >
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > paul@xxxxxxxxx   www.renderx.com   www.pault.com
> > XMLTube * Perl/JavaConnector * PerlApplicationServer
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> >
> >> On Wed, 22 Sep 1999 16:14:41 -0400, you wrote:
> >> 
> >> >if the order is important, how can I keep the attribute order instead
> >> >of using @*?
> >> 
> >> Attributes are intrinsically unordered. If you are doing some
> >> processing that relies on the attributes being in some particular
> >> order, you are going to have to rethink what you're doing.
> >> 
> >> -Steve
> >> 
> >> 
> >>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> > 
> >
> >
> >
> > XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
> >
> 
> --------------------------------------------------------------------------
> This e-mail reflects the opinion of the Editor of the XSL (formatting
>    objects) Specification. This is my interpretation of the
>    current (majority) opinion of the portion of the XSL-WG that
>    is working on formatting objects. It may not reflect the opinions
>    of all members of the XSL-WG or even of all members of the portion
>    of the WG that is working on the formatting objects. It is subject
>    to change.
> --------------------------------------------------------------------------
> Unless explicitly so stated in the text, it does not represent an
> official position of Adobe Systems, Inc.
> --------------------------------------------------------------------------
>   Stephen Deach                       |  Sr Computer Scientist
>   408-536-6521 (office)               |  Adobe Systems Inc.
>   408-537-4214 (fax)                  |  Mail Stop E15-420
>   sdeach@xxxxxxxxx                    |  345 Park Ave
>   xsl-editors@xxxxxx                  |  San Jose, CA 95110-2704
>                                       |  USA
> -------------------------------------------------------------------------------
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


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