top | item 11999218

(no title)

FuturePromise | 9 years ago

I spent a long time learning XSL/XSLT. The theory was we'd represent the data on a web page with XML, and then determine how it's to be displayed with XSL/XSLT. I think browsers still support it, but it never caught on.

discuss

order

Mikhail_Edoshin|9 years ago

Which is very sad, because it's a totally sane way. Have a set of different low-level languages to describe a screen layout, a paper layout, a audio layout for the blind, a single high-level language that describes content, and three transformations written in a very powerful yet pretty much declarative language. What not to like?

For example, sometimes we may need to enumerate certain things, e.g. headings. Normally this is a part of the final typesetting package (LaTeX or MS Word, whatever). But with XSLT and XSL/FO we have a different share of responsibilities: XSLT computes the numbers and XSL/FO typesets what it's given, so it has one less thing to worry about. This is great, because typesetting is complex enough already.

Besides, XSLT way of creating styles (xsl:attribute-set) is one of most elegant I've seen. It's very simple (one element and one attribute) and very powerful at the same time: you can easily inherit styles and/or use mixins or combine these approaches and there's no ambiguity. Besides, it's generic.

Semiapies|9 years ago

Did a little of that, myself.

A lot of the fundamental premise there did actually happen, just with different technologies. Today, there's a lot of sending structured data (in forms like JSON) to server- or client-side templates and components that render in a declarative way.