Enabling Structural Markup and Design

One of the key goals behind Atlas was to enable designers who know and love HTML and CSS and developers who know about adding behavior and logic to an otherwise static design to turn it into something interactive to work together in a complementary fashion.

This is all very abstract by itself, but if you take a closer look at some of the Atlas controls, such as ListView, you'll see a complete separation of UI and behavior. For example, the HTML markup defines a regular table, and the xml-script markup defines a template whose layout is defined as the table element. The ListView can now repeat rows as it iterates over its associated data. Essentially the designer can now design a fancy table using standard HTML and CSS, and the developer can specify the behavioral aspects of the desired end result. This separation of UI exists down to the level of simple controls like labels, textboxes, buttons etc.

Anyway, I thought I’d highlight this aspect of Atlas now, because I have the perfect example to point at - Bertrand’s accordion control. Check it out (I know Bertrand will delve into more details on implementation in future posts), and then come back here.

Here is what you see in the page:

<div id="accordion1">
  <a href="javascript:;">Pane 1</a>
  <div id="Pane 1">
    This is Pane 1 in the accordion control.
  </div>

  <a href="javascript:;">Pane 2</a>
  <div id="Pane 2">
    This is Pane 2 in the accordion control.
  </div>

  <a href="javascript:;">Pane 3</a>
  <div id="Pane 3">
    This is Pane 3 in the accordion control.
  </div>
</div>

Simple vanilla HTML, that any designer can tweak to hearts content, in any HTML editor. This HTML doesn't indicate any of the behavioral aspects, such as which pane is visible, the animation used when one pane is slided over another, which panes are enabled/disabled etc. This is where xml-script comes into the picture. For instance (in your xml-script):

<accordion id="accordion1" />

This tag binds together an instance of the "Accordion" script object with the "accordion1" <div> element. The script object can now inspect contents to figure out the headers, and the corresponding panes, attach event listeners to add interactivity, attach animation effects to provide the actual sliding behavior and provide an object model that developers can use to programmatically manage panes etc.

Beyond achieving a split between content and behavior, what you also have is structural markup that makes logical sense when you look at the markup, and a mechanism to associate script behavior in an unobtrusive manner using Atlas and xml-script.

One of the reasons behind xml-script is to provide a designable mechanism to specify behavior. So in that sense, you could look at the designer/developer split as one wherein the developer puts together components like the Accordion, and the designer designs the page, and also add a set of these components from a toolbox of objects, and customize them in a declarative manner (for example, what type or how fast of an animation the accordion control should use).

Hopefully this provides more insight into some of the design choices of what you see in today's Atlas bits. What are your thoughts? Clearly this is an area that would benefit immensely with the appropriate tool support that is part of the overall vision.