Re: [eclipse-incubator-e4-dev] CSS flavor used for theming in RAP

[Alex Fitzpatrick <agfitzp@xxxxxxxxxx>]

FYI.. BIRT is already using batik for
PDF generation and CSS parsing.

-- 
Alex Fitzpatrick
agfitzp@xxxxxxxxxx
Software Developer - Rational UML Modeling

From:	Kevin McGuire/Ottawa/IBM@IBMCA
To:	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Date:	2008-07-09 12:23 PM
Subject:	Re: [eclipse-incubator-e4-dev] CSS flavor used for theming in RAP

---

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: 
1.        License

2.        Degree
of completion/hardening of the code 
3.        Existance
of community supporting the code 
4.        Footprint
and performance 
5.        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:

1.        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. 
2.        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.
3.        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).
4.        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
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev