Skip to main content
[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

Back to the top