Hi Ralf,
Thanks for the note, this is cool. It would be great if you could
put together a little wiki page at http://wiki.eclipse.org/E4/DeclarativeUI
so that we can include this in the discussion meeting (TBA). The
page doesn't need much more than you have below, see the very light template.
Some comments below.
Best Regards,
Kevin
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote
on 07/05/2008 07:56:49 AM:
> Hi all,
>
> let me first introduce myself: I'm a member of the RAP [1] team and
> developed the theming subsystem. I guess most of you already know
about
> RAP, it is a platform that lets you run RCP applications on a web
server
> and access them with a browser. RAP uses an implemenation of a (growing)
> subset of SWT for the web environment, called RWT, that renders widgets
> in a browser. The RWT theming allows to define the default look of
these
> widgets (comparable to the theming capabilities of a desktop
> environment). A few month ago we decided to switch from theme
> definitions in simple property files to the more flexible and popular
> CSS format.
>
> I'd like to present our theme file CSS flavor here and line out a
couple
> of design choices we made. Of course, we would love to see a convergence
> between the RWT theming and the CSS support in e4. Our design is very
> similar to Matthew Hatem's work. For more details, see [2].
>
>
> 1. Element names are plain widget names without any namespace prefixes
> for the sake of readability. There are no name collisions
in SWT,
> custom RWT widgets can declare a different name/prefix
(every
> themeable widget provides an xml file that declares
its widget name
> and its themeable properties). Example:
>
> List, Table {
> background-color: white:
> }
I agree that
Widget name =
HTML element name
is a good approach.
> 2. We represent every style flag as a single attribute:
>
> Label[BORDER], CLabel[BORDER] {
> border: 1px solid #ff0000;
> }
I'm only a little familiar with use of attribute selectors.
Would the equivalent HTML elements have these attributes to be selected?
If I'm reading the example above correctly, the style
will apply if the attributes exist, so "apply the style if Label has
a BORDER attribute, apply if CLabel has a BORDER attribute". Is this
right?
My understanding is that it isn't typical to use attribute
selection. Do you use it alot in RWT?
> An alternative had been to have a list of style flags
in a single
> "style" attribute, but this would result in
more complicated CSS
> declarations such as:
>
> Label[style~="BORDER"], CLabel[style~="BORDER"]
{
> ...
> }
Right yes.
> Some style flags are used to select a certain widget
subtype (e.g.
> SEPARATOR, RADIO). We decided to use attributes for
all style flags
> for consistency instead of inventing new names like
PushButton or
> Separator. CSS attributes can also be combined like
this:
>
> Button[PUSH][BORDER] {
> ...
> }
Yes agree this seems reasonable, generating artificial
element types would just seem to clutter.
> 3. We use pseudo-classes for dynamic states like hover, selected,
> focused, etc.
>
> Button[PUSH]:hover {
> background-color: white
> }
Agree yes. This is what Matt did too as I recall.
I wonder though how we handle something that has more
than one state variable. For example, our part tab folders have both focus
(active) and selected states (CTabFolder only has selected though), which
gives us four cases to style. Yet I believe the following isn't legal
syntax:
TabFolder:active:selected
{
}
(or at least it didn't work way back when I tried
it with Matt's EclipseCon code, the Steady State parser wouldn't handle).
and the following isn't right either since it catches
too many cases (since the comma is 'or'):
TabFolder:active,
TabFolder:selected {
background-color: blue
}
Thoughts?
Note also this fact that we track more tab folder
state than CTabFolder is a good example of why we need some tie-in to parts
(see below).
> 4. CSS class syntax for "widget variants". This is a way
to style
> certain widget instances separately, comparable to classes
in HTML.
> Example:
>
> Button.shopping-cart {
> padding: 10 px;
> background-image: url( "images/shopping-cart-bg.png"
);
> }
>
> button.setData( WidgetUtil.CUSTOM_VARIANT, "shopping-cart"
);
>
> We think that the .class notation is a natural fit even
though the
> spec reserves this construct for HTML.
I agree CSS class is very important and we should
support.
What I've been pondering is whether the tie-in to
workbench parts is that the part names become the CSS class names. This
allows us to differentiate uses of same widget in very different uses (e.g.
same widget is used for both perspective switcher and fast view control).
Thinking further, I believe that the workbench model work previously discussed
(Eric, Ed, Tom, etc.) could be the true source of CSS class names, since
the model describes the semantic structural elements which then happen
to be mapped to some set of widgets. Its *our use* of the widgets.
But that doesn't cover the TabFolder problem above.
To solve it suggests either we push our active state into CTabFolder
so it can be selected, or we style against the workbench model. One
then questions whether you can style against both SWT and the workbench
model, or only the workbench model. This is too long discussion to
be inserted into your write up and deserves its own thread.
Q: Using attribute selection, is it possible to inject new state (e.g.
via some kind of tagging mechanism) into existing elements so that we can
select against it? In this case, we inject an "active"
flag into the CTabFolder so we can write:
CTabFolder[ACTIVE]:selected
{
background-color: blue
}
> In addition, we could also support
widget ids, but this would
> restrict the style definition to one single widget instance.
> We didn't see any advantage in this so far.
I'd like to support widget IDs for completeness although
I suspect that most often we only need HTML class, element type, and pseudo
class. But I could see for example the Help view having a specific
ID and then styling it.
> 5. Reuse existing CSS property names whereever possible (such as font,
> border, color, background-color, background-image, etc.)
> We only invented a few new properties where no suitable
CSS property
> existed, for example "background-gradient-color".
Agree although I think its worth debating because
I can see arguments both ways.
> Although both e4 CSS and RWT theme file CSS define
styles for SWT
> widgets, there are some differences:
>
> * RWT theming defines the *default* look of widgets, i.e. the styles
> that apply when no custom color, font, etc. has been
set. These values
> are also restored when calling setColor( null ), setFont(
null ) etc.
> In SWT, the default style is defined by the windowing
system. As an
> effect, setColor( null ) would always re-install the
system default no
> matter what is defined in the CSS, right?
I think I agree. What I assume will happen is that
the styles will be applied just after widget creation, before control is
returned to the calling code creating the widget. I'm not sure about
setColor(null) in SWT, we'd need to discuss with Steve (seems reasonable
though).
> * RAP can potentially provide more flexible styling than a widget
> toolkit on the desktop as it is not bound to the operating
system's
> restrictions. For example, developers will be able to
define hover
> colors, radius of rounded corners, or register their
own images for
> check boxes.
Only in so far as we do or don't support more flexible
owner-drawing of widgets but I agree in general, web widgets are more flexible.
> * RWT theming is limited to widgets, it cannot (yet) be used to style
> workbench parts.
(see above, this is an important area that we need
to understand).
> What do you think about how this could relate to CSS styling in e4?
It looks pretty good! :)
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
