Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] CSS flavor used for theming in RAP 
Hi Kevin,
thanks for your positive feedback. See my comments inline, I only quoted what I could answer to keep it short. 

Kevin McGuire wrote:
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. 

Sure, I added a wiki subpage.


 > 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? 

Yes. See also http://www.w3.org/TR/CSS21/selector.html#matching-attrs
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?
Yes. The above selector matches Label and CLabel elements that have a "BORDER" attribute set, no matter what the value of the attribute is. 

I agree that a single style attribute like

  <Label style="BORDER CENTER WRAP"

would look better in the XML than for example

  <Text BORDER="1" CENTER="1" WRAP="1"

but would result in that ugly CSS:

  Label[style~=BORDER], CLabel[style~=BORDER] ...

or even

  Button[style~=PUSH][style~=BORDER], Button[style~=TOGGLE][ ...
My understanding is that it isn't typical to use attribute selection. Do you use it alot in RWT?
I guess attribute selection is not so popular because it is hardly useful in HTML styling. We use it only for style flags so far. I think it fits because it's a separate syntax that allows us not to mix (static) styles with (dynamic) states or (user defined) classes. 


 > 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).
From my point of view, this should be valid CSS except the fact that ":selected" is not defined and the CSS spec does not provide for custom pseudo classes.
We use the CSS parser from Apache Batik, which handles the above selector. I made a test again with the Steady State parser and it also does. The above selector results in a ConditionalSelector with this nested condition: 

  AndCondition(
     AndCondition(
        AttributeCondition( "TOGGLE" ),
        PseudoClassCondition( "selected" )
     ),
     PseudoClassCondition( "focused" )
  )
Could it be that the reason this did not work with Matthew's code is that this code only allows for a singe pseudo class per widget so far? 

  IPropertyHandler#public void handle( Widget widget,
                                       String property,
                                       CSSValue value,
                                       String pseudo ); <--
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
       }


Yes, exactly.
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.
For me this sounds reasonable, after all, styles are always applied to some SWT widget in the end. But I haven't really formed a view on the workbench tie-in yet. Maybe its preferable to provide some higher level styling for workbench parts that keeps the implementation exchangeable? On the other hand, I cannot imagine such a "higher level CSS"...
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
       }
Given that my assumption about the legality of combined pseudo classes is true I would prefer using a pseudo class for this. I'd somehow like to reserve those uppercase attributes for style flags which are always static, and use pseudo classes for changing states. 


 >     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.
Yes, I agree that we should not preclude this. It shouldn't be much of a problem to implement ids into RWT theming, too. 

Best Regards,
Ralf

Back to the top