[
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,
>
Q: Why Batik (vs. Flute vs. Steady State
vs....)?
To parse CSS styles, w3c recommand to use SAC parser. w3c provide SAC interface (sac.jar),
and Batik, Flute and Steady State have implement SAC parser.
Into TK-UI you can choose the implemtation SAC parser to use.
All SAC parser implementation support CSS2 but not CSS3. I have started to update Flute parser (update JavaCC)
to manage CSS3 namespace like this.
@namespace swt org.eclipse.swt.widgets;
@namespace ns2 org.akrogen.tkui.css.swing.engine.namespace.ns2;
swt|Text{color:red;}
ns2|Text{color:green;} "
This sample with namespace put red color to SWT org.eclipse.swt.widgets.Text widget and put
green color to org.akrogen.tkui.css.swing.engine.namespace.ns2.Text widget.
Regards Angelo
2008/7/9 Alex Fitzpatrick <
agfitzp@xxxxxxxxxx>:
My only knowledge of BIRT is as a victim^H^H^H^H^H^H
user.
From:
| Kevin McGuire/Ottawa/IBM@IBMCA
|
To:
| |
Date:
| 2008-07-09 03:45 PM |
Subject:
| Re: [eclipse-incubator-e4-dev] CSS flavor
used for theming in RAP |
Hey this is great!
Q: Why Batik (vs. Flute vs. Steady State vs....)?
Thanks,
Kevin
I'm doing too many things at once... I should have looked at this earlier.
In fact, the batik.css bundle is already available from Orbit.
http://download.eclipse.org/tools/orbit/downloads/drops/R20080611105805/
http://download.eclipse.org/tools/orbit/downloads/drops/R20080611105805/bundles/org.apache.batik.css_1.6.0.v200805290154.jar
So one would presume that Christian Damus would have done the IP check
when he added it to Orbit.
(Let me know off the mailing list if you need updated contact info for
Christian.)
--
Alex Fitzpatrick
agfitzp@xxxxxxxxxx
Software Developer - Rational UML Modeling
From:
| Alex Fitzpatrick/Ottawa/IBM
|
To:
| E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
|
Date:
| 2008-07-09 12:45 PM
|
Subject:
| Re: [eclipse-incubator-e4-dev] CSS flavor
used for theming in RAP |
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
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev