[whatwg] Separating Interface and Content

[Greg Houston]

Ten years ago we separated style from content. Pretty soon I think we
may need to start thinking more about separating the interface from
the content as well. We are still treating the web as a web of
documents when it is gradually becoming something more akin to a web
of applications. As an application developer the ratio of user
interface markup (divs within divs within divs) to content markup
(text and images and such) in each of my pages is gradually increasing
on the side of the interface. Just as removing style from HTML vastly
cleaned it up and gave an incredible boost to what we could do with
style, I imagine the same thing would be true if we separated the
interface from the content. The HTML would be cleaner and web
interface technology might be able to fully develop like CSS is doing.

Right now we tend to think of having a plain document that we then
warp into the shape of a user interface with CSS and a little
Javascript magic. But on the backend, for web applications at least,
that is not really what we are doing. We are making an interface and
then injecting content into its various parts and with AJAX updating
that content in those various parts individually. Seeing such a web
"page" as a single document rather than as an application with many
documents open within it is starting to make less and less sense.

I am aware of XUL, but am not very familiar with it, and I imagine not
a lot of developers are yet. My open question is, given the direction
the web seems to be going in, in developing HTML5 are we giving much
thought to eventually separating the interface from the content? Like
right now we are adding such elements as meter, progress, menu,
context menu and so forth to the specification when it seems they
might be better suited to a separate file. Five years from now are we
going to be giving people a hard time for sticking context menus right
into their HTML file the same way we now hassle people for using
tables to structure their document? "That guy is still putting
progress bars in his HTML markup." The progress element hasn't been
implemented yet, but I can already foresee it's demise.

Right now we load a document and then apply CSS to it. It might make
more sense to load the UI file first, then the UI's CSS, then the
document(s) and their CSS. Again, I am not familiar with how XUL
works. It may do something similar or do something a lot smarter.

Another way to think about this is the differences between your screen
CSS and print CSS. What do you hide in your print CSS? With each new
project it seems like I am setting increasingly longer lists of
elements to display: none in the print.css. It is all interface stuff
that does not specifically relate to what the viewer wants to print.
Generally almost all of my menus are hidden from print. Once context
menus are implemented they will certainly go on that list. So if I
feel that I need to hide something from being printed, should that
something be in the content file in the first place or would it be
better suited in an interface file? Should there be a way to print
only specific sections of an HTML file rather than the whole thing? If
so, how would you go about defining the different sections in the
markup? Maybe someone wants to print the help text in this div
container but is not interested in printing all the other widgets on
the page.

The CSS for my content (paragraphs, blockquotes, ...) is generally
rather small and has not really increased much in size over the years,
but the CSS for all the interface divs and unordered lists twisted
into crazy menuing systems grows month by month, from project to
project. I think this is a good indicator of the direction things are
going in.

- Greg Houston