[
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,
Again, I have only comments to some of your points:
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".
I can't judge this for sure also. I'm looking forward to getting new
insights during this discussion.
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.
I just came across this statement in the CSS spec:
http://www.w3.org/TR/CSS2/selector.html#pseudo-elements
Some pseudo-classes are mutually exclusive, while others can be
applied simultaneously to the same element.
and below on the same page they give an example:
a:focus:hover { background: white }
The last selector matches A elements that are in pseudo-class
:focus and in pseudo-class :hover.
This means there is at least one use case even in HTML!
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.
I agree, attribute based selection could be an alternative if we'd need
to maintain compliance (attributes could still be lower case to separate
them from style flags). On the other hand, I wonder if full compliance
is possible at all, as CSS is rather document-centered and things like
:first-line, :first-letter, display="inline|block|list-item|..." etc.
obviously doesn't make much sense for a GUI.
> We use the CSS parser from Apache Batik
Cool. Can you provide some reasons why you chose Batik?
Actually, we went for the Batik parser because it was already in Orbit.
I read that Batik is "smaller and faster than Flute" which is good.
Yes, that's also stated on http://www.w3.org/Style/CSS/SAC/. This page
lists exactly these three Java SAC parsers, it seems these are the
candidates. I didn't have a look at Flute so far - it's W3C License, is
this compatible?
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.
This fact bothers me, too. org.apache.batik.css contains a lot of SVG
stuff, which goes far beyond CSS parsing. Moreover, the plug-in has
dependencies to org.w3c.dom.svg and to an org.apache.batik.util plug-in
which again depends on org.apache.batik.util.gui. That's why we just
took the parts that we really needed (the parser core) and wrote some
complementing code ourselves to make it work for us. It wasn't too much
work (a few days), so this could perhaps be an option.
The Steady State code looks small and tidy, but as you said, it's LGPL.
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).
That's what I meant with "higher level CSS" which I cannot really
imagine yet. For example, an alternative implementation of the
perspective switcher could show its items in a fancy colored header
ribbon at the top with the main coolbar below. Then the text of the
perspective items should have another color, size, alignment, hover
effect etc. than in the usual place. You'd need a different CSS for
this. Or am I off the track?
Maybe the "Cascading" comes in handy here as it allows to join different
style sheets. But then again, one might want to have some leading colors
that can be referred to in these CSS files. To my knowledge, this is not
possible in CSS.
Best Regards,
Ralf