Hi Andreas, Andreas L Delmelle a écrit : <snip/> > I'm wondering if your confusion is not caused by the fact that > space-properties can also be specified as conditional, and there is a > very subtle difference between conditionality in the cases of: > 1) a space-specifier: "a compound datatype whose components are minimum, > optimum, maximum, conditionality, and precedence" (space-* properties) > 2) a plain and simple length-conditional: which is the possible datatype > for the border-* and padding-* properties (no .minimum, .optimum, > .maximum or .precedence components)
I'm telling you I'm not making the confusion ;-) Yes I have those points in mind. But more below. <snip/> > Reading a bit closer: > "The padding of a block-area does not interact with any space-specifier > (except that by definition, the presence of padding at the before- or > after-edge prevents areas on either side of it from having a stacking > constraint.)" > > Now, if I interpret correctly, this means that the border/padding itself > acts as a fence in the space-resolution. Yes. > "The border or padding at the before-edge or after-edge of a block-area > B may be specified as conditional. If so, then it is set to zero if its > associated edge is a leading edge in a reference-area, and the is-first > trait of B is false, or if its associated edge is a trailing edge in a > reference-area, and the is-last trait of B is false. In either of these > cases, the border or padding is taken to be zero ***for purposes of the > stacking constraint definitions***" > > A matter of interpretation, maybe, but I would say that if an area B' is > the first child area of the described block area B and B is leading in a > reference-area, then the associated edge on B', ***for the purposes of > resolving border and padding conditionalities***, can be considered to > be a leading edge in that same reference-area. Hmmm, I see your point. You mean that for space-resolution (where the border/padding conditionality is used to determine fences), border and padding should be seen as leading /edges/. Whereas for border/padding conditionality itself (actual value of border/padding width for the area), they should be seen as before-edges of leading /areas/ (and same for border/padding after and trailing edge/area). That makes sense, but this is really an interpretation I think. The "then it is set to zero if its associated edge is a leading edge in a reference-area" above makes me seriously doubt of it. That said, that seems pretty logical and would probably match most expectations. > If not, then there would be no way whatsoever to keep border and padding > on nested blocks from being retained at page-breaks. :/ Well in most cases that would work as expected I think. Again here I'm thinking of power-users having studied every detail of the spec and counting on it to achieve special effects... and also of how that impacts the implementation of that stuff. Cheers, Vincent
