[eclipse-incubator-e4-dev] Fw: CSS and UI model

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

(Tom and I decided we should move this discussion
to the mailing list since its of general interest.  We were discussing
the possible relationship between the UI model work and CSS.  I've
tried to reconstruct the thread of statements/replies as best I could,
though it makes it a bit long, sorry).

Hi Tom,

(Kevin said:)
>> Wrt. CSS interfacing with the UI
model, that's not clear to me.  One approach to CSS is we just style
the SWT widgets.
>> Another says we style the model
elements.  I suppose a third to is to allow either.  
>>
>> The issue for me in styling against
the model is that when I make styling decisions, I make them keeping in
mind a specific widget, 
>> its visual capabilities, and how
it looks on the glass.  Because the model hides the widget and could
via the factory create any widget,
>> the purpose of the visual attributes
in the model and the approach of styling against them becomes a bit abstract.
 How do I know
>> what visual attributes are there,
and how do I know how they will look on the glass, since the factory could
do anything?  I guess
>> this really brings into question
the value of the visual attributes in the model.  
>>
>> Still on the other hand its nice
being able to reach into the model and make changes like font, color, etc.,
just as I would in HTML. 
>> If we remove the visual elements
from the model, then we'd need another model which describes the SWT widgets.
>> Do we really need two models?  Seems
confusing.  Then again, the split between parts and widgets has always
been confusing.
>>
>> The difference between our DOM model
and the web DOM of course is that the HTML DOM is literal about the HTML
elements
>> its backing, while as we have this
indirection which hides the widgets.  So how can our model be neutral
regarding what widgets to create,
>> yet discuss visual elements which
ultimately must be expressed as widget calls/attributes?  As I keep
asking Eric, "What exactly is this a model OF?".

(Tom replied:)
> Well as I see when we talk about CSS
it's not clear to me how many 
> features of CSS we want to support. To fully support CSS the stylesheets
> need to have informations about the structure of the elements to support
>   things like.
> 
> .my-list-box option {
>     background-color: red;
> }
> 
> I don't know how much you know about CSS but the snippet from above
> redefines the background color for all Option-HTML elements how are
> children of an element which has assigned a style-class named my-list-box.

Right, so here are some selectors of interest
and how I think they relate:

1. CSS Class
2. Equivalent of HTML element type
3. hierarchical/containment selectors
4. ID
5. pseudo classes (we'll grow our own)

Plus there's a set of positional oriented
ones, like :first-letter, :first-line, '+' (adjacent sibling) which maybe
make more sense for publishing text than for an IDE, so I'm not so interested
in those.

Numbers 1, 2, and 3 have possible UI model
tie-ins.  

For (1), I could see the CSS class being
the workbench part type that the widget implements, or maybe even a specific
'visual type' field from the model (although what that'd be and how its
different than the model element type, I'm not sure).

For (2), lets say I want "all CTabFolders
have red backgrounds" so,

        CTabFolder
{
         
      background-color: red;
        }

OK straight forward enough.  But now
say I want "all editors have red backgrounds". Problem is that
editors and views are both CTabFolders.  That difference is a workbench
concept.  One approach is we use CSS classes for that, so,

        CTabFolder.editor
{
         
      background-color: red;
        }

or just

        .editor
{
         
      background-color: red;
        }

Since presumably the UI model expresses editors
v.s. views (because its a workbench concept), the CSS classes could come
from the model element types.

Another option is its based on the UI model
element type, not the SWT widget type. I actually like this solution.  So
just,

        Editor
{
         
      background-color: red;
        }

(as if "Editor" were equivalent
to an html element type).

My guess is that its a more natural way to
think about styling the desktop, since its in terms of the desktop concepts,
not in terms of the widgets that happen to implement them (e.g. what widget
implements the perspective switcher? Who knows? Who cares!). 

If on the other hand we only solve it with
widgets and CSS classes denoting the workbench concepts, then we end up
with an explosion of CSS classes, and in a sense we "use up the CSS
classes" where we otherwise might want to reserve them for some other
additional semantic tagging (although presumably the semantic tagging ought
to be expressed in the model somewhere, so not sure what it is if its not
the model element type).


For (3), it raises the question of which
hierarchy you're referring to, the widget one or the part one?  Again
maybe its more natural to think in terms of the UI model, especially since
we'll have a nice first class model that one can view and manipulate.
 
> I guess we won't go that deep into CSS but then I ask my self why
do we 
> use CSS to express the information? We need to invent new attributes
for 
> css-properties not available. Where's the real benefit of using a
CSS 
> syntax beside bringing in another parser technology.

To me there are a number of benefits:

1) Its a well understood, standardized separation
of visual from behaviour. Assuming we want that separation, building based
on a standard means there's a whole pile of decisions we don't need to
make, things we don't need to think about, there's no inventing from scratch.
 We also know that you can express a lot of interesting stylings with
it, that's it useful in practice. 

2) Since its well understood, anyone can
open a CSS book, get a feel for how it works, and apply that knowledge
to Eclipse.  Not verbatim because of course the property names will
be different etc. but I always need to learn the properties for any new
HTMl widget anyway and that's not the hard part.

3) There's already some technology out there
to reuse.  That's great, but I actually think the above benefits are
more important.  Its the well exercised conceptual framework that
I want.  Working code is of course a bonus :)
 
> I agree with you that no visual information should be part of the
> declartive ui model (though I'm not certain if this is true for images
> too :-). The interfaceing between the css and model happens exactly
when 
> it comes to scripting because a css-style is coupled with the UI element
> so in a scripting env I'd expect that I can write the following.
> 
> eclipse.workbench.getElementById('my-element').style.
> setAttribute("color","#FF00000")
> 
> So there's you have the interface between your declartive ui structure
> and the styles :-)

I agree that its nice being able to write
such expressions although the SWT-CSS only version would be:
eclipse.workbench.getElementById('my-element').widget.style.setAttribute("color","#FF00000")

That's only slightly more complicated.  That
part doesn't bother me.  What bothers me is, again, what do you think
you're styling, is it the widget or is it the workbench element?  If
the latter, then we must also define visual properties in the model, otherwise
you write the styles blind.

Kevin