[
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