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
[EMAIL PROTECTED] 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! :)
>
> Best regards,
>
> Ralf
>
>
> [1] http://www.eclipse.org/rap
> [2]
> http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.rap.
> help/help/html/advanced/theming.html
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
