Subject: Re: XS: Construction Rule Features From: James Clark <jjc@xxxxxxxxxx> Date: Sat, 24 May 1997 11:11:02 +0700 |
At 15:30 23/05/97 -0400, Paul Prescod wrote: >So I would prefer a more general way to have >attributes in the "query" for an element construction rule. >An element construction rule with an attribute specified could be more >specific than any without. Two rules with two different attributes >specified would be of the same level and would be an error. It would be nice if we could make the syntax for element construction rules the same as that for patterns in match-element? and select-elements. The issue (as you realize) is how to deal with specificity. In the following pairs, I think it's reasonably obvious that the second is more specific: (element FOO ...) (element (FOO (A1 V1)) ...) (element (FOO (A1 V1)) ...) (element (FOO (A1 V1 A2 V2)) ...) (element (FOO BAR) ...) (element (FOO BAR (A1 V1)) ...) But what about something like this: (element (FOO (A1 V1) BAR) ...) (element (FOO BAR (A1 V1)) ...) I think the easiest solution would be to say that element construction rule A is more specific that element construction rule B if (a) A has more element type names than B, or (b) A has the same number of element type names as B, but A has more attribute names than B. Then there's the issue of how to deal with rules with the same specificity. There are several different possible approaches: 1. Say that the first (in the stylesheet) wins. At the moment, within each part of a style sheet, the meaning of the style sheet is not affected by the order of the top level forms. I think this is a desirable property, and I wouldn't like to change it. 2. Say that it's an error if there is in fact an element that matches two rules with the same specificity. I think that's a workable solution, though it's rather a pain from an implementation poin of view. 3. Say that it's an error if an element *could* match two rules with the same specificity (even if there isn't any such element), ie it's an error to have (element (FOO (A1 V1)) ...) (element (FOO (A2 V2)) ...) even if there never is a FOO element with A1=V1 and A2=V2. I think (2) is probably the way to go. As a modification to any of 1, 2, 3, we could allow a priority to be attached explicitly to an element construction rule, but that makes it hard to allow multiple construct expressions within an element construction rule, so I would rather not. Is all this worth the complexity? >Also, there is a common idiom in CSS stylesheets where one construction >rule applies to many different GIs: > >H1, H2, H3, H4, H5{ > font-family: Times New Roman,serif; > font-weight: 500; > font-style: normal; > font-size: 10pt; > color: #000000; >} > >Could we do this too: > >(element H1 H2 H3 H4 H5 > (make paragraph > (font-size: (calculate-size (GI)) )) Not if we want to follow your earlier suggestion of allowing multiple construct expressions. Suppose that previously the stylesheet had (define H5 (empty-sosofo)) Is H5 an element type or a construct expression? Something like this would work: (element-group (H1 H2 H3 H4 H5) (make paragraph font-size: (calculate-size (gi)))) Is this worth the extra complexity? I'm not sure. James DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
XS: Construction Rule Features, Paul Prescod | Thread | Re: XS: Construction Rule Features, Paul Prescod |
Re: XS: Add element-with-id or map-, James Clark | Date | XS: out of line links, James Clark |
Month |