- markup (52)
- xml (7)
- xslt (21)
- atom (8)
- overlapping markup (2)
- schema (9)
- creole (4)
- xforms (1)
- pipelines (7)
- coding (2)
- dtll (1)
- genealogy (3)
- gtd (1)
- hardware (1)
- legislation (1)
- ontologies (2)
- unicode (1)
- web (24)
- google (3)
- rdf (6)
- rest (3)
- wikis (1)
- work (1)
- xpath (1)
- xquery (1)
- xtech2008 (3)
- life (26)
- children (5)
- equality (6)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (7)
- xtech (6)
- blog (7)
- drupal (3)
Processing CSS and pipelines with XSLT.
Sounds interesting, I'll have to have a closer read, but I have had some similar experiences myself:
1) I have done some XSLT work recently parsing CSS and applying it to an Atom feed as 'style' attributes so that subsequent templates can convert those styles into actual styles for the destination user agent but I was using XSLT 2. It too dealt with inheritance.
Are you actually parsing CSS files or picking up style attributes?
2) About a year ago I embarked upon an experiment to build a graphics renderer, X-Reyes, using XSLT 2 (it produces a Base64 encode TIFF image) and one of the first things I had to do to break-up the problem was to implement a pipeline processor in XSLT. This is expensive as I was recursively descending the pipeline feeding the result of the previous step into the next but it helps wonderfully in isolating each phase of the rendering process. You can also add stop conditions to catch the output of intermediate steps. As you can see from the blog link above, I had some success but the project remains dormant for now...
...or maybe not, ho hmmm.