This entry is part 1 of 4 in the series Getting to Know xstyle

xstyle_transparentxstyle is a framework for enhancing or building applications by extending CSS. xstyle is intended to be simple and unobtrusive enough to provide transparent shimming for standard CSS, yet powerful and expressive enough to provide an entirely new and elegant approach to building web applications. xstyle is both a set of small CSS tools, as well as a framework for building entire applications using declarative syntax and reactive constructs, allowing you to define UI components, sub-components, bindings, styling, and layout all within encapsulated UI definitions, while leveraging cascading layers to intelligently create separation of concerns.

I wanted to introduce xstyle by looking at the some key design philosophies and goals that have driven this project. Perhaps the first and most overarching design goal is to facilitate a single, consistent specification of a user interface presentation and its UI components by providing the tools to build, extend, and compose complex UI elements within the browser’s native UI presentation format, CSS, leveraging and working in harmony with a browser’s increasing focus on presentational features in CSS. xstyle achieves this with a few simple constructs that pave the way for powerful application building blocks like data bindings and component definition and reuse.

While we are familiar with many of the warts and annoyances with CSS, some of which xstyle helps to overcome, CSS also has some very important and desirable characteristics as a language. CSS is a declarative language. In imperative languages, the state of the application can be the result of complex and difficult to discern steps of operation, but with a declarative language, there is a direct, easy to follow relationship between the file’s structure and the application’s run-time state that it represents.

CSS is also a functionally reactive language, describing a continuous relationship between inputs and outputs. For example, there is no need for imperative instructions for how CSS should respond to document or element resizing, one can simply define an element’s width or height as a percentage and the browser automatically updates one element’s size when its relative element changes. By taking this concept even further, and applying it to bindings between data sources and input and presentation elements, we can succinctly define relationships without the noise and ceremony of describing how to keep the source and target in sync. xstyle provides powerful data binding capabilities, and used in conjunction with the element generation capabilities, xstyle provides an elegant reactive templating solution for presentation.

To provide a brief example of what this looks like, here is how we might create elements in a form, that are data-bound:

#my-form {
    =>
      h1 (username) /* make an h1 element, bound to the username variable */
      label 'A field:'
      input[type=number] (some-numeric-variable)
}

This is just a quick look at the syntax, but we won’t go into details here, this will be discussed in later posts, and within the xstyle documentation.

While xstyle encourages the use of reactive declaration/programming, it is certainly not expecting to eliminate the need for imperative programming. xstyle includes an interface into JavaScript modules, allowing it to leverage all the capabilities that JavaScript provides. And this approach provides a more rational separation of concerns, we separate our declarative and reactive definition of our user interface from our imperative explanations of how certain custom components implement the relationships.

Another goal in extending CSS is to provide more compositional power for presentation. This enables UI definitions in a single language, and a single place, so we can better encapsulate our UI elements. This means we do not have to be as dependent on synchronizing code between multiple formats. Modern web development is often an exercise in synchronizing identifiers like class names between HTML, CSS, and JavaScript. We create an element, give it a class name, and then repeat that same class name in CSS to style it, and repeat it again to add event handlers. This repetition of the identifier is a disappointing violation of the principles of Don’t Repeat Yourself (DRY), and simply an unnecessarily inefficient and error-prone process.

xstyle includes the ability to define the creation of DOM elements as part of the presentation definition. This enables virtually unlimited forms of UI expressions, all within a single file. This provides a form of templating within xstyle. xstyle uses CSS syntax to describe the elements to be created and whitespace to denote hierarchy. This is somewhat similar to Jade‘s syntax, but provides live, reusable, reactive templates that can be used by client-side components. This not only gives us better encapsulation, it helps to prevent the abuse of HTML. HTML is intended to define semantically descriptive content. However, HTML is also often used to create the essential build blocks for the presentation of the user interface. This represents an abuse of the purpose of HTML, going well beyond the intended purpose. While xstyle can perform DOM element generation, it is not intended to eliminate well-structured HTML. By permitting the creation of presentation elements in the presentation language and layer, HTML can be kept “clean”, focused on semantic documents, while the extended CSS layer defines how the user sees it.

By giving better encapsulation support, xstyle does not eschew the separation of concerns. Rather it enables separation to be more intelligently and carefully constructed around logical divisions in an application, rather than being driven by the arbitrary technical limitations of the languages.

Another key goal of xstyle is to facilitate high performance, responsive applications. One of the challenges that we often face with a JavaScript-centric widget system is that in the process of seeking a consistent widget interface to all the components in application, the number of widgets can easily grow to a very large number. Widgets typically consume a non-trivial amount of memory and processing, and with a large number of widgets, this quickly can lead to sluggish applications.

In xstyle, rather than forcing a widget instance for every element that we wish to model or extend, we use the CSS principle of categorical definitions. We can declare a set of properties, a description of our elements, and apply it categorically (determined by the selector), to a whole set of elements, rather than dealing with each on an individual basis. If a component can be described purely with regular CSS, one shouldn’t have to create objects for each element to access the component in a consistent manner. Custom properties may be implemented by utilize existing CSS rules, they may utilize event-delegation to respond to events, and even if and when elements do need to accessed or modified, it may not be necessary to maintain separate objects for each one. All of these tools are available as optimized ways of working with custom components when using an interface that defines components collectively rather than individually.

xstyle is designed for performance as well, and includes build time tools to create applications that can be loaded as efficiently as possible. xstyle’s syntax is designed to easily be analyzed and isolated statically, and therefore it can be preprocessed during builds, making the extensions available without any extra requests or unnecessary parsing. And because xstyle integrates with Dojo builds, this can be seamlessly done as part of the normal Dojo build process.

As browsers continue to unveil exciting new features that are available in new releases, there will always be eagerness to use these features. Certainly one of the most valuable features that a library can provide is to shim or polyfill new browser features. Nothing is more performant than using native features, and by being able to use these for modern browsers (which are more heavily used in mobile) while smoothly falling back to a polyfill, we can leverage and make the most of the modern technology.

Finally, xstyle is designed to enable reuse of code/declarations. Of course this a goal of many languages, DRY is an essential principle of good coding, and this one of the primary motivations behind CSS preprocessors. xstyle provides similar functionality for reusing, parameterization, and mixing in rules to reuse properties, variables, and nesting rules to repeat selector duplication (albeit with more of a focus on simple build blocks than brevity). xstyle achieves this with a simple set of constructs, with a runtime module (that doesn’t require a server process, but works in conjunction with the build tool) that can be used to eliminate duplication and fits within the broader set of functionality provided by this framework.

A benefit of the property-driven approach of CSS and xstyle is that it facilitates and encourages easy use of combining orthogonal functionality in elements. In typical class/component style design, strong linear hierarchies often appear, forcing component users to pick single components to use or extend. With xstyle UI design, various properties that provide different functionality (a visual effect, a data binding, etc.) can be combined in elements’ definitions/rules. This pushes presentation design towards better reuse and composition of additional and existing functionality.

By extending CSS, we can build on these foundational principles, fix and give greater power to CSS, and enjoy the benefits of CSS for a more primary role in our application. CSS has great tooling support in browsers, we can directly manipulate rules and instantly see changes. There is also an incredibly broad range of people that are capable of using it. There are countless web designers that have good, or at least decent, proficiency in CSS, certainly more than authoring high quality JavaScript. xstyle focuses on just a few simple constructs that can easily be learned in a short time, making it possible for designers to have a greater role in building and managing applications, and helping developers to focus on the specific customizations that really require imperative JavaScript programming.

Any of these goals alone may not be that intriguing. However, these ideas combined: extensible CSS, declarative/reactive data bindings, simple constructs, categorical definitions, high performance built applications, DRY CSS, and shimming provide a consistent, comprehensive, and powerful way to build web applications.

xstyle is one of several great projects being developed through the SitePen Labs.