To most Web developers, it sounds controversial until you hear the punchline: Last summer, the developers in charge of Google’s Chrome browser floated a proposal1 that went virtually unnoticed by the technology press, which was to remove support for an established W3C standard that every other browser vendor still supports. The standard in question? Extensible Stylesheet Language Transformations, otherwise known as XSLT.

In reaction to this news, most Web developers would likely shrug and say “So what?” That’s unfortunate.

Transformations are a simple yet powerful technique for separating content and presentation in Web applications. Yet, outside of enterprise and data-processing circles, transformations have failed to gain popularity through XSLT. As a result, Web developers are liable to think that transformations “don’t apply to me,” even though they work with HTML, a structured format ripe for transformation. Thankfully, new transformation frameworks are on the horizon, including work by the inventor of Sass, that hold the promise of a revival.

In this article, we will reintroduce transformations and explore their applications to mobile and responsive design. We will not only teach the old dog new tricks, but show that transformations are relevant to everyone who deals with HTML.

Separating Content And Presentation

A transformation is simply a system that transforms its input into an output according to a set of predefined rules.

The key thing about transformations isn’t the action they perform but the capability they enable. Transformations create an abstraction that decouples content and functionality from presentation. This separation is a design goal of many frameworks, but transformations facilitate it in powerful and unique ways.

A powerful example of this decoupling occurs in Enlive6, a transformation and templating system written in Clojure. Most templating engines use a customized markup language to mix HTML with programming constructs such as loops and variables. Take PHP, for example:

Completely understanding the code above is not important, but you’ll probably recognize the h1#output argument as a CSS selector. In this example, a template named helloworld is being defined, in which the h1#output element’s content is replaced by “Hello World!” When executed, this template would output the following:

<html>
<body>
<h1 id="output">Hello World</h1>
</body>
</html>

For more on Enlive, I recommend David Nolen’s excellent tutorial7. But the key point is that content and presentation have been decoupled. Website changes, A/B tests and even a redesign could be as easy as getting new HTML from your designer and dropping it in. In addition, the designer doesn’t need to know anything about the templating language and may use HTML classes and IDs, concepts that they already know.

While you don’t need to build a website in this way, the situation is analogous to building a Web page without a style sheet. True, you could design a page purely with inline styles (that is, using only the style attribute), and novice developers often code this way out of expediency. But experienced developers know that a style sheet improves workflow and productivity at scale.

Similarly, by separating content and presentation, you will unlock more productivity and agility for your team. In effect, transformations truly separate the front end from the back end and create a new workspace for the visual design team to operate independently of the rest of the system. In an industry where even simple things like the color of a button can affect conversion rates8, enabling your visual design team to iterate more quickly and continually could deliver tremendous value to the bottom line.

Responsive Retrofitting

Transformations are not just useful in a templating system. This decoupling of content and presentation can also be applied to an existing website, enabling developers to apply a new presentation regardless of how the original website was built. This combination of separating content and presentation and its applicability to existing websites is what makes transformations so powerful and useful to a broader audience than currently use them. I’ll illustrate this by responsively retrofitting an existing website using a transformation technology that’s in every browser today (at least for now), XSLT.

XSLT9 was introduced in the late 1990s as a language for transforming XML and XHTML documents. During the ascendency of XML, XSLT was seen as a solution for separating content and presentation in Web applications built on XML data formats. The W3C recommended XSLT as a standard, and almost every major browser incorporated support for some form of the language.

Now that Google’s Chrome and Blink team has proposed10 dropping support for XSLT, some might be concerned about using it long term. However, at the time of writing, XSLT is supported in all major browsers, including Chrome and the latest versions of the iPhone and Android browsers. In addition, XSLT may be used both server- and client-side. Server-side implementation works regardless of browser support, and open-source and commercial XSLT engines are available. Finally, JavaScript implementations of XSLT, such as Saxon-CE11, could also fill the gap client-side if Google does indeed decide to drop support for XSLT.

Responsive retrofitting is the process of grafting responsive Web design techniques onto an existing website that was not built to be responsive. Although a lot of resources and tutorials on building a responsive website from scratch are out there, retrofitting has curiously received far less attention, despite its enormous value. A lot more old websites exist than new ones, and significant capital and effort have been invested in them.

A long responsive rebuild might not meet the budget or time-to-market requirements for many of these websites. Transformations provide an effective way to make a website responsive without the expense of rebuilding it.

The natural first step would be to retrofit the website purely in CSS. Ben Callahan’s bookmarklet12 for example, inserts a custom CSS file to make a given website more responsive. However, adding CSS gets you only so far. Eventually, the layout, nesting and order of elements in the original HTML will restrict your design options. John Shirrel describes this13 as an inherent flaw of CSS:

“You have discovered the weakness of using CSS… CSS does not allow you to transform your document. Elements must remain in the order they appear… There is no real decision-making power in CSS.”

Fundamentally, this process breaks down because CSS and HTML do not purely separate presentation and content. Whenever you’ve found yourself needing to wrap an element in an extra div or span to make the design work, you’ve encountered that breakdown. This is where transformations come in, restoring the abstraction (surprisingly) by enabling us to manipulate the document.

To demonstrate the technique, I’ve created an sample retrofit14 of Hacker News’ home page, by making the top navigation responsive, using ZURB’s Foundation15 framework. Naturally, additional design changes beyond these would be required, but it should serve to illustrate the process. Why Hacker News? First, using code from a real website helps to demonstrate the power of the technique. Secondly, the HTML on this website is Goldilocks-sized: not so small that it’s a toy, but not so big as to make our example complicated.

The most relevant file in this retrofit is the XSL style sheet transformer.xsl, which you can download directly16. In the paragraphs below, we’ll highlight some key points about the code in transformer.xsl. While a full explanation of XSLT is beyond the scope of this article, a quick crash course should make these explanations more understandable:

Syntax
The XSLT programming language is written in a form of XML. For example, an if statement in XSLT would be <xsl:if></xsl:if> element.

Parameters
Parameters to statements like <xsl:if> are specified in the attributes and child nodes of the element.

Matching elements
A common parameter is the match attribute, which selects a collection of nodes. For example, the template specified by the <xsl:template match="body/center"> rule would be applied when the XSLT engine encounters the <center> element that is the child of the <body>.

Embedding HTML
Finally, you can embed bare HTML in a style sheet.

The first thing we need to do is tell the browser to use the rules in transformer.xsl. To do this, we change the document’s Content-Type to text/xml (alternatively, in some browsers, you can simply change the file’s extension from .html to .xml) and add an <?xml-stylesheet> tag like the following to the top of the document:

<?xml-stylesheet type="text/xsl" href="transformer.xsl"?>

When the browser encounters this tag, it will transform the document according the XSLT rules specified in the style sheet before rendering it. This will execute the transformation in the browser (i.e. client-side). But transformations can also be performed server-side. Doing transformations server-side could result in better performance, but we’re doing transformations client-side to make our example accessible to anyone with a browser. For those interested in using this technique client-side, optimization techniques and tools17 are available for writing performant XSLT.

Another issue is how XSLT handles unspecified elements. By default, XSLT strips out any elements not specified in the transformation rules. This is a design decision that makes sense for XML documents, which typically represent data. However, when transforming a fully formed Web page, you will usually want to change only a relatively small part of the document, and specifying every single element we need to be preserved would be laborious. Thankfully, we can add a construct called the identity transform18 to the transformer.xsl style sheet:

The code above might appear cryptic, but in essence it tells the XSLT engine to copy (i.e. <xsl:copy>) every element node and attribute in the input to the output. Adding this to our style sheet will effectively change the default behavior from stripping out elements to passing them through.

The next step is to add Foundation to the document. For example, the following code would add Foundation’s CSS (foundation.css) and its dependencies (normalize.css and Modernizr) to the top of the <head>:

The chief difference between the two code samples above are the match attribute values (head versus body, indicating the element being targeted) and the placement of the <xsl:apply-templates> tag (which controls whether our new content will appear before or after the existing content).

Finally, to add the responsive header, we inline new HTML that matches the structure of Foundation’s top bar19, and we use the for-each and copy-of commands to populate it with the relevant links from the existing header.

There are some caveats to this approach the reader should be aware of. First, in this retrofitting example the transformations were performed by the browser but executing the transformations server-side has a couple of advantages. Server-side transformation reduces the burden on mobile devices, which have less processing, power, and memory capabilities than the server.

The server is also the appropriate place to segment your content to avoid sending unnecessary data over the network and to improve performance. Lastly, you can update the server transformation engine and keep it consistent, instead of dealing with potentially different quirks and levels of XSLT support among browsers. (For example, while XSLT 1.0 is supported in most browsers, XSLT 2.0 is not supported in any, although Saxon-CE is one attempt to add it via JavaScript.)

Second, XSLT’s roots in functional programming make it inaccessible to the average Web developer. It isn’t simply a matter of learning a new syntax. The recursive processing model of XSLT requires a new way of thinking that is unfamiliar to developers of imperative languages, especially developers from a design background who do not have formal training in computer science.

Finally, a larger challenge is that this technique works only for Web pages that are in XHTML (a flavor of HTML that is XML-compliant), because XSLT can transform only XML, not HTML. According to W3Techs, 55% of websites are in XHTML20. While this is a majority, it still leaves out a large number of websites. In fact, for this retrofitting example, I worked around this limitation by running Hacker News’ HTML code through an HTML to XHTML converter21.

In the next section, we’ll explore how the Tritium transformation language was built to address these issues.

Responsive Delivery

In the example above, we’ve used transformations in the browser to create a responsive experience for an existing website, but conceptually the two approaches overlap. Because responsive Web design is itself about changing presentation across multiple screen sizes, transformations can help in that process as well. Instead of simply pairing different CSS styles to the same fixed HTML as in typical responsive design, we can leverage transformations to change the HTML across devices.

As we explored earlier, the ability to manipulate the HTML (which is missing from CSS alone) not only creates flexibility but actually improves the separation between presentation and content. As a result, maintainability becomes easier because the content is more semantic and less tied to layout. In essence, think of this as moving the breakpoints in responsive design to the transformation layer.

At Moovweb22, we’ve leveraged these insights about transformations to implement a technique called responsive delivery, which draws inspiration from responsive Web design, RESS and adaptive design. With responsive delivery, transformations are used to adapt an existing website to different touch points, such as smartphones and tablets.

Because the transformed website inherits directly from the desktop, responsive delivery provides the unified content and functionality across touch points that you get with responsive Web design, while the majority of the processing is done server-side. And because transformations can be used to manipulate the HTML, we get the benefits that we saw earlier: independent and precise control over the look and feel for each touch point, thanks to an abstraction that separates content from layout.

Also worth noting is that responsive delivery can power desktop websites. In the ideal scenario, the back end would produce semantic but unstyled HTML (affectionately called “wireframe HTML”), and the responsive delivery layer would transform the output for all user touch points.

27The data flow in this responsive delivery configuration uses wireframe HTML as the source data for transformations that output to mobile, tablet, app and desktop end points. (Large view28)

Especially in large organizations, this makes for a powerful decoupling of teams. Back-end engineers can focus purely on functionality (i.e. producing the “wireframe HTML”), and front-end designers can focus on the experience (i.e. transforming the wireframe HTML into a styled Web page). Because the channel between both teams is simply HTML, both teams understand it, and passing through implementation details that are inherited by the front end (such as styles and JavaScript) becomes easy.

Consider a simple autocomplete widget. With a responsive delivery approach, the back-end engineer would write the server code to support an autocomplete API and embed the corresponding JavaScript that powers the widget in the wireframe HTML. The designer could then style the widget using CSS and transformations and, if necessary, add JavaScript beyond the stub provided by the back-end engineer. The key point is that HTML is used as a flexible carrier of both content and functionality, as opposed to XML or JSON, which represent only data.

One way of applying this approach is to use a software-as-a-service platform to process transformations in the cloud. This is the service that we built at Moovweb to power mobile websites and apps for Macy’s and 1-800-Flowers, among others, using our own open-source transformation language, called Tritium. Tritium was designed by Hampton Catlin, inventor of the CSS preprocessor Sass34. He used his experience to create a transformation language that’s accessible to Web designers and developers. Some features that we felt would be important to the language are the following:

Familiar syntax
The syntax should be similar to CSS and jQuery so that it’s more familiar and readable than XSLT’s XML syntax.

Imperative style
We wanted to use an imperative programming style, instead of the function and recursive processing model of XSLT.

Input transparency
The input is passed directly to the output, so there is no need for a construct like the identity transformation (as is the case with XSLT). Stated differently, the identity transformation is an empty document.

HTML-compatible
Tritium was designed to process regular HTML, so it can be used on any website, not just XHTML websites (as with XSLT).

For a simple “Hello world” example, the following Tritium script will select all of the HTML table elements with an ID of foo and change their width attributes to 100%:

The Tritium language has its own official website35, and Moovweb has scheduled to open-source the language in 2014. Developers interested in contributing are encouraged to check out the public GitHub repository36 for the core Tritium parser library.

To compare an example, the analogous Tritium code for adding Foundation to an HTML document, as we did earlier with XSLT, would be this:

Recall that, in the case of XSLT, the relative placement of new content in the document relies on the judicious placement of the <xsl:apply-templates> tag. However, in the Tritium code just above, the straightforwardly named functions inject_top and inject_bottom are used to insert the boilerplate HTML that installs Foundation.

In practice, the Moovweb SDK offers a Foundation scaffold37 that installs the Foundation boilerplate for you. The scaffold also offers convenience functions to use other components in the Foundation framework. For example, we would use the following functions to create the responsive top bar for Hacker News:

As in the XSLT example, the XPath selector "//span[@class='pagetop']//a" is used to select the links for the menu, but the foundation.tbar*() convenience functions make it easier and spare us from having to know the details of the top bar’s HTML format.

As a final example, a full project implementing the responsive retrofit of Hacker News with Tritium is available on GitHub38 for you to run and play with using the Moovweb SDK. Unlike the XSLT version, which uses HTML downloaded from Hacker News (due to the need to run it through an XHTML converter), you can run this project with the live version of the website.

Transform Your Thinking

Closures once sat obscurely in functional languages until languages such as JavaScript and Ruby brought them into the mainstream. Likewise, transformations have been buried in frameworks that are alien to the average developer, and the popularity of the transformation approach has been married to the fate of XSLT.

This is unfortunate because transformations are more about a new way of thinking than about any particular technology. They enable a powerful separation of content and logic from presentation, and the usefulness of this separation is important in a number of ways. As we move into the post-PC era, transformations provide one part of the answer to serving websites across a wide array of form factors.

Furthermore, the separation enabled by transformations enhances productivity and accelerates the iteration cycle for visual design teams. Meanwhile, for developers who rearrange DOM objects via JavaScript or jQuery, transformations are a new lens on their current workflow, and they open up new doors to optimizing tasks, such as server-side transformation.

In an industry that has no shortage of new ideas, sometimes the most useful thing is to connect new concepts with old ones to make them more digestible. That is what this article has tried to do with transformations. Hopefully, we’ve demonstrated the power of thinking in transformations, showing its relevance to anyone who works with HTML.

Ishan is Director of New Products at Moovweb. He has been launching mobile products for the iPhone since the day it was released, and his work has been featured on TechCrunch, ReadWriteWeb and LifeHacker. Prior to Moovweb, Ishan worked at Digidesign and his expertise was in multi-threaded real-time systems programming for the computer music industry. Ishan holds dual-degrees in electrical engineering and mathematics from MIT.

Related Articles

Luke L

As someone who made a few websites using the Symphony CMS [http://www.getsymphony.com/] which uses XSLT for all templates I can tell you why they’re not in favour; XSLT is a horrible technology.

You end up with horrible hacks and unintelligeble selectors to do even the simplest things. Couple that with the awful performance (because they never took off in the first place) and you have a recipe for disaster.

Sataa Daghir

Ishan Anand

The article is really about the power of “thinking in transforms” than about XSLT. In fact, the problem I’m trying to correct is that transforms as a technique have been tied to the fate of XSLT. Imagine if we never had closures/lambdas in Ruby and JavaScript because folks said “none the languages that used them are popular anymore”.

My goal isn’t to get you to write XSLT. My goal is to encourage folks to explore, apply, and even create the new transform languages and frameworks — like enlive, tritium and kioo — that fix the shortcomings of the past.

Alex P

I respectfully disagree. I’ve done almost 40 projects in Symphony and once you get by the harder learning curve you can do almost anything, even a full fledged online store. Pjax is so easy to implement using a comparable solution to the one described above and if you cache your data-sources it’s as fast as a static site. Of course XSLT is harder than other templating languages because it’s more powerfull. If you think of your HTML as multiple components and use XSLT more like you would use CSS it would be easier to use and understand.

Jon Mifsud

XSLT is not a horrible technology. It is a “Transformation” step, so you are NOT supposed to do anything but wrap HTML around your data. And quite frankly XSLT does exactly that, it is much better then other systems where you can plug in your PHP at the templating layer which I’m sure developers who complain that you can’t do “Simple” things with XSLT actually do. What you’d have to do is find what’s providing your data and amend there in most cases, it’s much simpler and far more organised.

I’ve been working with Symphony CMS which uses XSLT exclusively to generate the XHTML outputs for over 3 years. It only took me around a week to get the idea of XSLT, however I admit some of the tricks I learnt on the way were by coincidence, and trial and error well after I started.

The only problem I have with XSLT is that there is no single place where you can find all the tips and tricks to get it to work. If there was a complete resource I’m sure it would be much easier for those starting out.

Sidd Maini

XSLT may not be a horrible technology but the design and the way you are supposed to implement it IS! Everybody has to agree to that. I have used XSLT in a few web development projects especially when it involved using a content management system. The problem was its ease of use and lack of online support or good documentation. It is not object oriented enough.
I do agree that presentation needs to be separate but the time burden to implement such an under utilized technology is not worth the time and effort. I do not really want to spend my precious time on a technology that is not sustainable. I hope you understand my point of view.

Starbeamrainbowlabs

Steve

Brendan Abbott

False. JSON is a data format, like XML. XSLT is a W3C standard as transform language (templating language).AFAIK, JSON doesn’t have an standard transform language, although there are options such as Mustache or Handlebars.

Paul d'Aoust

@Steve: perhaps you were thinking of JSON replacing XML as a data interchange format? XSLT is for transforms only. To an extent, the new CSS Regions spec will replace XSLT’s ability to shuffle parts of the page around, which is nice, but of course if you want to support both old browsers and new ones, you’ll have to support XSLT for the old ones and CSS Regions for the new ones. Sounds like a bloody mess; better to just go with one future-friendly solution.

Aaron Linkous

In actuality it doesn’t matter. I’ve been using moov for about 18 months now. One of our clients has some of the worst code I have ever seen in any website. Im talking, code after ajax loading ajax as html even though it’s json, 3 versions of 1.4.X jquery on every page, font tags, and even non closing p tags. Tritium can handle it.

Jason

Great writeup Ishan. One that is sure to stir up some controversy as well. Most people, especially designers, who have spent a decent amount of time working with XSLT may quickly shoot down the idea of using it. I can’t say that I blame them, it’s a tough language to work with. XSLT is extremely sensitive and has some logical gaps (like “variables” that don’t vary) that make it an entirely different experience from HTML and CSS. This is why you aren’t wrong when you say this technology has a high learning curve for some designers.

Other limitations include being stuck to XSLT 1.0 for global support, which limits your functional capacity even more. Understanding XSLT templates and logic statements is a step separate from what you see in Javascript or any object oriented languages. And using javascript at the DOM execution level becomes near impossible since anything that isn’t driven by a user interaction on the page or a timing event will fail to fire against your HTML. The transformation layer disrupts the normal flow of JS driven behavior on top of HTML.

With all of that said it’s important to understand no one here is saying XSLT is the new way to create responsive websites. It is simply presented as a potential option and a new angle to approach the process of developing flexible websites. For that reason this article is a productive one that provides a well researched approach.

Daniel

I worked with XSLT since early betas in 2000/2001. It is an “ok” DSL for XML Dom correction and mild transformation, but it sucks big time for anything that is a bit more complex. There are fast implementations, debuggers and visualizers indeed.

But the standards generation of XSLT, XML Schema, XML Databases, XQuery, RDF, SOAP, WSDL, WS-*, and UDDI are more or less dead for *new* projects or special uses.

There is a reason that *simple* technologies like JSON, REST APIs, NoSQL (KVS/Document) etc. won the war. We have our preprocessors (HAML, SASS, CoffeeScript) which are also not perfect but all about applying as much DRY and friction from developing web apps.

Douglas Bonneville

XSLT quickly becomes an unmanageable, unreadable hot mess of nested XML + stuff that is impossible to scan with the eye quickly. It’s powerful, but so is machine code. Goodbye XSLT!

It’s also noteworthy that MS Sharepoint 2013 dropped XSLT as the main means of giving developers custom output control on templates which developers relied on for Sharepoint 2010. The writing is on the wall if both Google and MS have given it the back seat in two of it’s major applications. Enough said.

Austin

Jon Hartmann

XSLT is bloated and insane… it made sense in a world that thought that XML was going to solve all of the world’s programming problems like a fabled Rosetta Stone, but it couldn’t and it didn’t and XSLT can now rest in peace.

Ryan Boone

I’m a big fan of decoupling when possible, and the Tritium language is very interesting, but I am trying to figure out why dropping browser support for transformations would be a big deal if these operations can happen server side. And if we’re already moving transformations server-side, couldn’t these same things be done with current, more widely-used languages? It seems there could be a way to further abstract HTML content from presentation with Ruby on Rails or PHP. Please forgive me if I’m missing something you said in the article. It’s quite compelling. I’m also a print designer by trade, so it takes me a while to wrap my head around things.

Ishan Anand

You are correct dropping browser support isn’t a big deal if you are doing the transformations server-side. I open with that because it’s a signal that few folks today know or care about transformations in general.

For languages like PHP or Ruby on Rails, the templates are typically rendered server-side although that’s been changing with the rise of JavaScript based templating frameworks.

Philip Damra

This seems like a horrible idea. HTML5 is not valid xml. CSS and JavaScript are far more than sufficient to handle the task of responsive design. How would you handle, for example, switching from portrait to landscape mode when reading on a tablet? Based on this article, you’d have to, at the very least, re-process against the XSLT.

It sounds like the XSLT suggestions here are just a Trojan Horse to promote Tritium. IMO, it’s better to work on improving existing approaches than to reinvent the wheel. Javascript for DOM manipulation and @media and display for responsive styling in CSS.

Simon

Exactly my thoughts. CSS just re-factors the layout as you change the size of the viewport. The benefit of that is even on a desktop, if you shrink your browser to half your screen, or even a small sliver like a mobile phone at 400px, the site is optimized for that viewport scale and can change as the user scales it. Using XSLT to change things for different screen sizes limits the end user to the viewport size they initially loaded that page at. Any change in viewport size would require the XSLT to reload. This is far from optimal and really not true to Responsive Design.

Ryan Boone

“It sounds like the XSLT suggestions here are just a Trojan Horse to promote Tritium.”

I kind of feel the same way, Philip, although JavaScript for DOM manipulation, while certainly the preferred method, can spell doom for websites if JS is turned off. I welcome alternative server side suggestions, but it escapes me as to why we need yet another language to achieve this.

Asbjørn

XSLT sounds great until you actually try using it. It is horribly verbose to do even the simplest things and it suffers greatly from being XML-based. It tries to take normal things from a programming language like loops and conditional statements and force them on an XML-based language. The results are a disaster.

Brendan Abbott

As a developer of Symphony CMS, and someone who has used XSLT for several years, I can understand why people hate it, but it also saddens me that it will be removed.

Arguments that it should be removed purely because it’s verbose are short sighted. You can create great things with XSLT, just like any other language, just because it’s not as terse doesn’t make it any less valid.

Marco

I mean, I’ve had my share of working with XSLT in terms of print design but using it to develop websites feels a bit off. Sure enough, it is possible to do things with XSLT web-wise and the approach mentioned here is not bad (actually a really clever idea) but… I have to go with Douglas (#comment-682579) and Jason (#comment-682568). Not my cup of tea.

Carl

As in-depth and well-written as this article is, it just feels so… …odd.

I’ve used XML a fair bit, and XSLT a little in the past. I can honestly say that in two years of designing and developing responsive websites I have never felt the need to use XML or XSLT to solve any problem. I still use and parse XML server-side where I need to, but otherwise use JSON wherever possible.

This is an odd article in Smashing Magazine of 2014, and it comes across like a way of shoehorning “responsive” into anything to try and get published.

Paul d'Aoust

I’m quite puzzled by the negative comments on your article. I think people think you were supporting XSLT itself, whereas as you read on it’s evident that what you’re writing about is transforms. I’ve been attracted to transforms for a while, because I think they can do some nifty things — taking all the “ elements in each of the blog posts on your ‘Archive’ page and dropping them down a level so they’re smaller? Sure, it can do that. Creating your own custom elements (e.g., “) that are replaced with real HTML, à la Web Components or ASP WebForms? That’s easy too.

I’m curious about your Tritium project; when I get the chance I’m going to read more. I’ve always been of the mind that if you want clean content/data, you need to have your own internal data format that gets transformed into HTML markup, but you have a very good point — HTML is a pretty decent format already.

Megan Brown

As a designer/front-end dev who works in .NET and a whole lot of server-side XSLT, I’d agree that the learning curve is steep. However, after implementing many sites for many different applications, the logic and templating behind XSLT are clearly powerful. Making a site responsive with XSLT requires far less code and after seeing many solutions, is a viable one, and one that should be considered. It just requires a bit of time to learn the logic.

Ishan Anand

– I realize XSLT has left a bad taste for a people so I’m not surprised by the polarizing reactions. My intention is to elevate the discussion on the transformation approach beyond the reaction XSLT has created and inspire developers to experiment transformations in general. (e.g. https://twitter.com/matths/status/431698730979704832 )

– This also isn’t an argument in favor of XML, W3C 2.0, and a lot of the other stuff typically associated with XSLT. Those are distractions in the discussion.

– Transforms and media queries are not mutually exclusive. In fact the responsive retrofitting example is using both together.

– Yes you can do DOM manipulation in JavaScript. And depending on how you go about it, that can also be a transformation based approach. See for example Kioo (https://github.com/ckirkendall/kioo) which brings Enlive style templating to Facebook’s React JavaScript library. I’d consider the IntentionJS framework (http://intentionjs.com/) to also border on the transformation approach. That being said, client-side based transform approaches don’t have the benefit of operating before the browser’s render and in some cases this can lead to “artifacts” where the user will briefly glimpse the page before the transform has been applied.

Ishan Anand

– I realize XSLT has left a bad taste for a people so I’m not surprised by the polarizing reactions. My intention is to elevate the discussion on the transformation approach beyond the reaction XSLT has created and inspire developers to experiment transformations in general. (e.g. https://twitter.com/matths/status/431698730979704832 )

– This also isn’t an argument in favor of XML, W3C 2.0, and a lot of the other stuff typically associated with XSLT. Those are distractions in the discussion.

– Transforms and media queries are not mutually exclusive. In fact the responsive retrofitting example is using both together.

– Yes you can do DOM manipulation in JavaScript. And depending on how you go about it, that can also be a transformation based approach. See for example Kioo (https://github.com/ckirkendall/kioo) which brings enlive style templating to Facebook’s React JavaScript library. I’d consider the IntentionJS framework (http://intentionjs.com/) to also border on the transformation approach. That being said, client-side based transform approaches don’t have the benefit of operating before the browser’s render and in some cases this can lead to “artifacts” where the user will briefly glimpse the page before the transform has been applied.

Ian Young

Thanks for a very interesting article Ishan. I’m glad others think the same way about the benefit of transforms in bridging the server to client divide.

From some of the comments I think one or two are missing the benefit of generating on the server-side and transforming to only serve up the required information to the client based on context, need, constraints (available screen space, bandwidth, device limitations, etc), or requirements. It’s not just about DOM manipulation, hiding and revealing, or changing the style of certain sections on the page.

The “wireframe HTML” concept you mentioned is an interesting one but wouldn’t it be a step further to instead output as a data interchange format, XML for instance (as it is W3C standard, already has a default transformation language and is the most expressive option)? So content is generated on the server-side and is fed to the client-side via a RESTful design pattern. Client-side developers could then apply templates to the data output to “transform” it to (X)HTML5 or whatever other format was required. Importantly the RESS-based approach would allow for responsive support to transform to Mobile app, Tablet, Desktop (as you have depicted in your diagrams). The generated HTML (or other required format) would only contain the information needed by way of the transform.

The advantage of this approach would be that instead of a wireframe HTML you have a data model ready to be consumed by any other application or site and in a format which has tools and standards supporting consumption, transformation, and processing (XSLT as the standard but every other server-side lanuguage has good XML processing tools). XML also has the advantage of being semantic already meaning that your data is described and in line with RDFa (http://rdfa.info/) giving it meaning when processed. Applications, search engines, and custom scripts will no what data they’re dealing with be it a person, an address, an event, a location, etc—much the future for the web. Everything is a resource but to create a truly connected (and useful) web the resources need to be described.

So, we’d have a clean separation of content and presentation, a modern RESS-based approach to transform a document and not just style it, a portable medium (XML) which is both a web standard and well supported with tools in almost any language (not to mention a standards based transformation language), the coupling of a modern RESTful URI design, descriptive data for semantic meaning, RDFa support for future friendliness, and the ability to generate once and use several times saving a lot of work. Then there wouldn’t be a need to create a new transformation language but to get behind the existing standards.

Pete

Very interesting to read about something that previously I hadn’t encountered in the area of responsive design. I had an idea around the use of media-aware transform logic for a possible responsive images solution concept a while ago: https://github.com/petelock/Responsive-Image-Mapping

Ferdy

The only thing I’d like to add is that I don’t see the mixing of HTML and template placeholders as a problem. If done properly, I’ve never had any issues with it, also in large projects with a mix of designers and programmers.

Before you have a solution, you must first have a problem. I understand the theoretical pros of the transformation approach but in practice it often means just moving the problem elsewhere, it doesn’t actually go away. The Clojure code you’re starting with shows exactly that: it’s a tight coupling between template and content, you have only moved the problem. The HTML itself cannot be changed without you changing that code, thus you are in the exact same spot.

gotofritz

XSLT in the browser may have been the hipster technology in 2003 or thereabout for a few months, but nowadays nobody uses it. And with HTML 5 dropping the requirement for XML compliant, it ain’t coming back. We are asking already a lot of browser manufacturers – SVG, WebGL, Flexbox, all the HTML 5 APIs, CSS Regions. responsive images, the list is very, very long. I think it’s ok for them to drop XSLT support.

Juan

Milind R

I am really sad to see so much hate for XSLT. And the way the W3C bowed to the majority opinion shows where their priorities lay – paving the cowpaths.

XSLT, is pretty much web application templating done right. Whenever you feel its verbosity is too high, is a good time to go back and see whether that transformation you’re trying to do isn’t flawed in some way.

What I can see clearly these days is a reinvention of all the good work the W3C was doing, under different enough names and syntax that people won’t recognize them. And then these folks mindlessly applaud.

Tavis Reddick

I think that procedural programmers coming to XSLT (or other declarative languages) often struggle because of having to unlearn a specific mindset. If you work with documents and databases and XML and the web, then XSLT is a natural fit for SQL-to-XML-transform-to-HTML.

Basically, you schedule an output of XML in a validatable format from your relational database (which also contains chunks of descriptive XHTML). If it passes validation, you overwrite the file on the webserver. This is transformed via a small number of XSLT stylesheets to different pages: Course Search, Course A to Z, Courses by Category, and Course Detail pages. Using ASP.NET compiled transforms, the pages render faster than any database connections I’ve tested. In fact, if you code the web pages right, these dynamic pages render faster than static HTML.

Normally, I guess XSLT should be used server-side and never be seen by the client, although I have suggested some exceptions when:
1. the web application is packaged in a transferrable object, independent of host server environments (like a widget or learning materials object);
2. the web application is offline and cached (the XSLT stylesheet can be downloaded to the device);
3. sharing rapid prototypes of a web application, where the browser does the work.

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at SmashingConf Oxford on March 16–19 or meet us at the shores of Santa Monica for SmashingConf LA on April 27–30. You won't be disappointed.