Hi Daniel, >From what I know of XXE, your analysis of its non-compliance with the CSS >standard seems exactly right.
As Hussein has pointed out, however, once you understand XXE's simplified handling of margins, it's very easy to obtain the desired results in most cases. I prefer to think of XXE's styling engine as "CSS-like". It uses CSS syntax and cascading rules, and shares many properties with the CSS spec, but by no means was it designed to be a standards-compliant CSS implementation. In particular, I've been able to implement support for DocBook's spacing="compact" in my customization of the standard DocBook XML style sheet. The code required was relatively trivial - feel free to ask for help if you need it. -- Kevin Yank SitePoint Pty. Ltd. ----- Daniel Dekany <ddekany at freemail.hu> wrote: > Monday, May 21, 2007, 12:44:51 AM, Daniel Dekany wrote: > > > With an example: > > > > ... > > <foo> > > <bar> > > Blah > > </bar> > > </foo> > > ... > > > > If foo has a vertical margin A and bar has a vertical margin B, and > > neither elements have vertical padding or border, then the total > > vertical margin around the text should be max(A, B). But it seems > that > > with XXE it's A + B instead. > > Unfortunately, it seems the problem is not confined to vertical > margin > collapsing between elements that are in parent-child relationship. > Here is another case (working example attached): > > ... > <foo>X1</foo> > <div> > <foo>X2</foo> > </div> > <foo>X3</foo> > <foo>X4</foo> > ... > > Here, when both "foo" and "div" is "display: block", and "foo" has > vertical margin of size M, and div has no margin (and neither element > has border, nor padding) the visual vertical distance between all the > "X" texts should be M. With XXE, the distance between X3 and X4 will > be M as expected, but will be 2 * M between X1 and X2, and also > between X2 and X3. > > So, to recap, (CSS experts please correct me if I'm wrong) the CSS > rule is basically that if we have boxes in the normal-flow, then when > the vertical margin of them touches each-other (i.e. nothing > separates > them, like another box or even padding or a border), the smaller > vertical margin will be eaten by the bigger one. It's irrelevant what > is the relation between the XML nodes for which the boxes were > generated. It only matters if the two boxes touch each other > visually. > > And please don't go into fights about the importance of this bug... I > didn't wanted that ever, I just initially taken granted that I'm > satiating the obvious. Like, probably the reason why the DocBook > itemizedlist/listitem-s has, well, at best strange vertical spacing > with XXE (and also maybe that you didn't attempted to implement > spacing="compact") is that the author of the style sheet have find it > too hard make it better (too hard considering that it's just for > editing anyway). The good news is that real CSS is not that hard to > work with when it comes to vertical distances. If you don't have to > afraid of vertical spaces stacking up, it's as easy to solve a quite > decent itemizedlist/listitem vertical spacing as it was creating the > current one, even a bit easier [*]. (It's logical why. Simplified, > the > idea is that by saying "I want a vertical margin of 1.33ex", you just > say "I don't want anything visible to be closer to this thing > vertically than 1.33ex". And if it really just means that (but it > doesn't with XXE), then you can just drop the margins there like a > safety thing that can be only good. You don't have to wonder what can > possibly be next to the box visually that may already have a margin.) > > > * Like you don't have to explicitly erase the vertical margin of the > first child of the listitem. Nothing like that. Really, you just > had > to say that listitems has 1.33ex vertical marging, and itemizedlist > have no vertical margin. Pretty trivial, and the result looks > satisfying even for a bastard like me. > > -- > Best regards, > Daniel Dekany
