Hey this is great! Q: Why Batik (vs. Flute vs. Steady State vs....)?
Thanks, Kevin Alex Fitzpatrick/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 07/09/2008 03:05 PM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] CSS flavor used for theming in RAP 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 [EMAIL PROTECTED] Software Developer - Rational UML Modeling From: Alex Fitzpatrick/Ottawa/IBM To: E4 developer list <[email protected]> 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 [EMAIL PROTECTED] Software Developer - Rational UML Modeling From: Kevin McGuire/Ottawa/[EMAIL PROTECTED] To: E4 developer list <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
