[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense

[Achim Schneider]

"John A. De Goes" <john at n-brain.net> wrote:

> 
> Perhaps I should have been more precise:
> 
> How do you define "layout" and "interaction semantics" in such a way  
> that the former has a *necessarily* direct, enormous impact on the  
> latter?
> 
> HTML/CSS is a perfect example of how one can decouple a model of  
> content from the presentation of that content. The developer writes  
> the content model and the controller, while UX guys or designers get  
> to decide how it looks.
> 
HTML, or rather XML, would be layout to me. GUI's usually don't serve
static content, and allowing a CSS layer to position eg. a filter GUI
that supports chaining up any amount of filters by slicing them apart
and positioning them on top of each other (maybe because someone didn't
notice that you can use more than one filter) wrecks havoc on both
usability and the semantics.

"Wrecks havoc on the semantics" in the sense of that if a thing is
editable, the semantics should guarantee that it is, indeed, editable.
Likewise, if something is marked as visible (and such things are
explicit in the model, not defined by an outer layer), the semantics
should guarantee that it is visible.

That, and I don't intend to write a browser.

There will be, of course, a separation between what is displayed and
how things are displayed, because that's the very sense of a widget
toolkit.

-- 
(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.