(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_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
