Hi Ralf,
Great discussion, this is really helpful.
A few comments below with some reply text dropped for compactness. In some
cases I combined your replies out of order to form one topic to respond
to.
> > 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
...
> > 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.
Thanks. In my original reply, I had only seen a very small reference to
this style, two pages, in the CSS book I use,
http://www.amazon.com/DHTML-Fourth-Visual-QuickStart-Guide/dp/032144325X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1215615814&sr=8-1
(which, btw, I find to be a pretty good book).
Since I'm not a seasoned web hacker, I can't distinguish common usage
strategies/best practice vs. cool mechanisms being exploited in new ways.
But your explanation makes sense. Just want to ensure we'd be using the
mechanisms "appropriately".
Its good that we can handle this style, it provides more expressiveness.
Once we agree on a technology which meets our needs, we then need to agree
on our best practice markup approach. At this time I just want to make
sure we *can* express our SWT/workbench usage cases (hence the Tab
Folder/CTabFolder discussion). If it turns out we have several workable
solutions then all the better, we can debate and agree on the right one
after. In the meantime the discussions are great in getting us all up to
speed on CSS approaches!
> > 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.
...
> 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?
It was last summer that I did this so I can't recall, I'd need to dig up
the code. You're probably right.
> 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.
Agree. There's some important points in here to be debated though.
On the one hand I'm glad the parsers handle multiple pseudo-classes. On
the other, clearly this never occurs in normal/html driven CSS since the
set of pseudo classes is relatively small and fixed (like a dozen), and
this case of two pseudo classes for an element never comes up. Plus as
you point out, the CSS spec does not provide for custom pseudo classes.
So do we think its the right approach to introducing our own pseudo
classes? I like the idea of using it for dynamic state selection since
that seems its intention. And the fact that the CSS spec doesn't provide
for new ones is likely more a reflection of its html context. That is, it
would only make sense in html if you could also add your own html element
types. Thus it seems we'd be following the intention of the feature but
not the specification, in our own SWT world where perhaps being legal CSS
isn't such a requirement. The alternative would be attribute based
selection but I like the syntax less and its mixing static and dynamic
inapprorpiately, as you point out.
> We use the CSS parser from Apache Batik
Cool. Can you provide some reasons why you chose Batik?
I read that Batik is "smaller and faster than Flute" which is good. Steady
State is LGPL which is somewhat of a problem for us. Batik is Apache
license v2 which I believe is good. But none of them are 1.0. Also one
thing that confuses me about Batik is that its a sub component of an SVG
toolkit.
Things I care about, in order:
License
Degree of completion/hardening of the code
Existance of community supporting the code
Footprint and performance
Ease of programming
> > What I've been pondering is whether the tie-in to workbench parts is
> > that the part names become the CSS class names.
> > ...
>
> 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"...
Yes, so in the end the widgets are the only "real things", and the extent
to which you can style the UI is exactly limited to the set of properties
and capabilities of the widgets. But I see four things that can be
happening in the workbench parts or the workbench model:
There's important semantic information captured in the workbench parts.
They express our usage of the widgets. On the surface that seems to match
the notion of a CSS class.
The parts encode state that can't be extracted from the widgets, but that
state is important in us making styling decisions. An example is active
state for folders, which is comes about through a combination of
presentation elements DefaultTabFolder+PaneFolder which dynamically modify
the styling of CTabFolder. What I'd like to see is four styles for
CTabFolder which get selected based on this combination of workbench and
widget state. We can either argue that the state should've been in the
widget (so say a modification of or subclass of CTabFolder), or we argue
that there's some higher level component in the workbench that could be
styled. Not sure yet.
Its possible that in some cases we have workbench parts that really should
be backed by a composite widget but instead manipulate the widget elements
itself (CTabFolder vs. DefaultTabFolder could be one, there may be others,
we should keep our eyes open for these cases).
I will briefly try to capture a hallway discussion with McQ and Eric
Moffat (btw, I actually don't agree with this approach so I might not be
presenting it well):
The workbench model captures our structural elements and via the factories
produce the widgets. In theory this allows different widgets to be
substituted for the same model element (e.g. what was once a table can
become a tree table). The model elements define a set of visual
properties which the factories pick up when creating the widgets. The
styling could be at the model level, since there's visual properties in
the model, and thus you get the same advantage of substitutability of the
widget (same style sheet gets reused).
This area of workbench and model tie-in is for me still the biggest
unknown. Its also critical because it hinges around what value we believe
the workbench parts provide over the widgets.
Best Regards,
Kevin_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
