[lxml-dev] Targeted XSL transformations

[Stefan Behnel]

Emanuele D'Arrigo wrote:
> Hmmm. I might be starting to grasp what you are suggesting. You are
> suggesting to load the xml/xul content separately from the css information
> and associate the two together only as needed, inside the application, as I
> build the actual objects that are described by the xul content and are
> eventually displayed to screen. This effectively means that the css doesn't
> act on the xml/xul content file nor the generated ElementTree, but instead
> it acts directly on the display objects that are created out of it. It acts
> on the objects that are eventually displayed rather than the xml objects
> generated by etree or objectify.

Sort of, yes.


> Hmmm. That means I'd have to create my own
> css selectors that act on the display objects rather than the elements in an
> ElementTree object.

What? Why? I thought you used the Mozilla engine for displaying the XUL
pages? They are perfectly capable of handling CSS. Actually, CSS is the
only way to map style information onto a XUL document. I'm only suggesting
to put it into a separate file rather than into the XUL document itself.

Asking Google for "xul css" immediately brought up this, for example,
although there may well be some better tutorials out there:

https://developer.mozilla.org/en/introduction_to_xul


> Programmatically what I need is to be able to add composite GUI elements to
> an interface. I.e. a composite GUI element might have text labels, text
> input fields and buttons. The description of the element in terms of its
> sub-components is in a XUL file but the style is dependent on 1) some
> default style information 2) any overriding style information that has been
> added or modified at runtime, i.e. by the user.
>
> When I add a composite GUI element to an interface (i.e. a new record in a
> table) it's easy enough to add it to the tree of objects in the GUI, but in
> terms of style I'd need to find out which style information applies to it
> given the nature of the added element and its location in the tree. In a
> sense, rather than selecting the element given a (css) rule, I'd need to
> select the applicable rules from the element and its position.

And that needs to be decided at runtime? Aren't there any general rules
like "when element X appears within the panel named Y, give it style Z"?

What you can generate with XSLT (or using whatever type of tree
manipulation) is the element X, which now appears in the panel Y and thus
picks up the style that was predefined in the CSS file for exactly this
case: "Y > X { ... }".

I doubt that you really have requirements that you cannot express
statically (i.e. in advance) using CSS selectors. If you really need to
distinguish identical elements depending on some logic in the XSLT driven
document generation process, just give them different IDs and use those in
the CSS file.


> Furthermore I'd need to find a way to apply any rule that the addition,
> removal or modification of an element has made applicable to other elements.
> I.e. the rule E F {color:red} does not apply until the element E has an
> element F as a child. When I add that child I must somehow retrieve that
> rule and apply it to E. Right now I don't quite know how to do that.

That's exactly what the CSS engine is there for. Keep moving, nothing to do
here.


> But I realise I am digressing into non-lxml related issues. I apologize if
> I'm abusing of your and other's patience. Admittedly there are various parts
> of the problem statement that remain unclear even to me. Attempting to
> explain it to you and the list does help a little, hence my potentially
> unwelcome verbosity.

What I think you need to understand is the difference between the document
status of an element (e.g. descendant of Z, child of X, @id="Y",
@enabled="true") and the visual representation (visible, green, large,
...). The mapping between those two is what CSS is designed for. And the
CSS engine that sits right inside your XUL layout engine will do that
mapping for you whenever either the document or the style information changes.

Stefan