Isn't CSS about giving a "style" to the "views" in the model-view-controller paradigm? So basically it is a way to change the look of a user interface, without having to change the user interface definition itself. But isn't this just an environment monad that has functions to convert a model into a view (= geometry = render function + picking function)? Plugin a different environment and voila, the widgets are painted and maybe even layed differently, but you don't have to change any code or data.... Of course what a "model" really is, is not fully clear: http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx On Tue, Feb 3, 2009 at 8:50 PM, Jeff Heard wrote:

Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. Similarly, there are more ways to interact with a computer than ever before, from simple keyboard up through multitouch interfaces like the iPhone. It would be cool to me to see a semantic model that captures this.

2009/2/3 Conal Elliott :

...

[Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits]

I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational).

- Conal

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jeff Heard wrote:

Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way.

I would go with Bret Victor's argument (http://worrydream.com/ MagicInk/) that the concept of user interface as primarily _interaction_ is misguided. What GUIs are really about is visual _presentation_ of information. The semantic questions are about what it means graphically to compose information sources. We spend more time reading, viewing, and absorbing that information, than rearranging it, or adding to it. Interaction changes the sources, or the way they compose, but is (or should be) fundamentally an infrequent activity. The better the visual presentation, the less you need to interact with it. Regards, Malcolm

Malcolm Wallace wrote:

I would go with Bret Victor's argument (http://worrydream.com/ MagicInk/) that the concept of user interface as primarily _interaction_ is misguided.

I tend to disagree. But then I'm a game developer, not an HTML monk... what definitely makes sense, though, is to divide the gui visually along presentation of the world vs. presentation of your interface to the world. "presentation of your interface to the world" subsumes such things as the marker on the minimap that shows which part you are looking at, and what tool you selected to interact with it (say zoom, smudge, paintbrush) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

On Tue, Feb 3, 2009 at 2:06 PM, Thomas Davie wrote:

On 3 Feb 2009, at 20:39, Conal Elliott wrote:

[Spin-off from the haskell-cafe discussion on functional/denotational GUI

...

toolkits]

I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational).

Can I start by replacing html please :)

I'd like to separate the document in roughly the same way as html and css attempt to, meaning I'd like a document description language, and a styling description language.

I can imagine the styling language having the meaning "function from documents onto geometry", but the document description language is harder. Ideally what I'd like to do with it is to make it describe *only* the logical structure of the information being conveyed – sections, text, figures, tables (no, not for layout, for tabular data) etc.

This is easy to me. Everything is content. Sections, text, figures, tables -- these are all static content. Functions are interactive content. Numbers are content, as are lists of content, maybe content ... The interesting part is how you display it. In the simplest sense, a "style" is just a function Style a = a -> Geometry. But work has been done, eg. with TVs, that have composition of content and composition of the display mirror each other. I'm not totally satisfied with TVs. For example, I think it's worth exploration describing *how* the content was composed, such that styling language maps compositions of content to compositions of geometry. Content is not interesting. The *mapping* from content to presentation is the important part. Luke

wren ng thornton wrote:

I can see LaTeX as demonstrating that there is no such (single) language. It seems to me that the elementary units (chapters, sections, paragraphs,...) depend almost entirely on the domain of the document (a book, an article,...).

This is what I had in mind while I tried to write the plumbing to agar objects: Defining your own widgets. A library to do this, it seems would consist of things like ActionProducers instead of Buttons, and TextInput instead of TextBoxen and ListBoxen... that is, of Event ()'s and Behaviour/Event String's, alongside with high-level renderers, coupled with a feedback mechanism, that'll then be called Button and TextBox. A Listbox is already made out of such primitives, but this should be transparent to the developer. Another most important thing that I really want to have, is to enable the end-user to edit presentation, in a sensible way, like re-specifying the width of textboxen, add additional hiding panes etc. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

amen & amen! thanks, achim. On Tue, Feb 3, 2009 at 4:50 PM, Achim Schneider wrote:

Conal Elliott wrote:

...

[Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits]

I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational).

I think a very important thing to keep in mind while investigating web-technologies for pointers is that Haskell already comes with XML and XSLT (in the disguise of ADT's and functions), and that CSS is often abused for operations that are in the domain of XSLT.

I don't believe that it's possible to draw a clear destinction between "concerns the programmer" and "concerns the designer". In fact, I get offended by the notion that I'm inherently incapable of distinguishing readable from unreadable text, and think that the notion of designers being unable to do anything but assembling a colourful collage of the data they're given is more of a self-fulfilling prophecy than a truth.

-- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe