Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-incubator-e4-dev] Fw: CSS and UI model

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

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.


Back to the top