CSS3 support in CssResource: Closure Stylesheets?

[Thomas Broyer]

Hi all,

CssResource uses Flute to parse the CSS. Flute only supports CSS 2 (as do other CSS parsers in Java: CSSParser, Batik, etc.) and seems totally unmaintained (last version is 9 year old!). The version used in GWT has been patched to add support for the double-colon notation for pseudo-elements (from the css3-selectors spec). The most common complain is that you cannot use CSS3 gradients without wrapping them in literal(): http://code.google.com/p/google-web-toolkit/issues/detail?id=5771

Searching a bit, I only found 2 open source CSS parsers in Java that support CSS3 gradients: Closure Stylesheets and Aptana. Aptana is under GPL so it cannot be used.

So, what do you think about migrating from Flute to Closure Stylesheets as the CSS parser? (only the parser, not the processor)

I of course volunteer to propose the patch.

[John Lenz]

Personally, I would love to see that.  Let's see what others have to say.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Jeff Larsen]

Escaping css3 is a PITA. I'm 100% on board. 

[Ray Cromwell]

How could I refuse? :) SGTM. We will of course, still have to
maintain all of the GWT-isms. Actually, I've been wondering if we
shoudn't just adopt LESS or SASS extensions too.

-Ray

On Fri, Dec 9, 2011 at 6:40 AM, Thomas Broyer <t.br...@gmail.com> wrote:

> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Michael Vogt]

Hello.

> How could I refuse?  :) SGTM. We will of course, still have to
> maintain all of the GWT-isms. Actually, I've been wondering if we
> shoudn't just adopt LESS or SASS extensions too.
>

Yes, please.

Greetings,
Michael

[Daniel Kurka]

I would also volunteer to put some work into this, since I am hitting more and more bugs in the way GWT parses CSS files

-Daniel

2011/12/16 Michael Vogt <vme...@googlemail.com>

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Thomas Broyer]

Replacing Flute with Closure Stylesheets while retaining GWT's semantics is not easy. First, Flute is a SAC parser while Closure is DOM-like using visitors (much like GWT's own internal model).

Given Ray's earlier idea to even move to SASS or LESS, I'd rather introduce a new GssRessource (which can even be done as a third party lib), and possibly merge them later if possible.

[Daniel Kurka]

Thomas are you doing something about that?

I am actually getting really annoyed with all the bugs we have in the current ClientBundle implementations and all the workarounds needed to get some css3 working.

I would like to see some decent css3 support in the standard CssResource and would also devote some time for building it.

2011/12/19 Thomas Broyer <t.br...@gmail.com>

Replacing Flute with Closure Stylesheets while retaining GWT's semantics is not easy. First, Flute is a SAC parser while Closure is DOM-like using visitors (much like GWT's own internal model).

Given Ray's earlier idea to even move to SASS or LESS, I'd rather introduce a new GssRessource (which can even be done as a third party lib), and possibly merge them later if possible.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Thomas Broyer]

On Wed, Feb 1, 2012 at 1:16 PM, Daniel Kurka
<kurka....@googlemail.com> wrote:
> Thomas are you doing something about that?

No, I started looking at it, but quickly gave up, without writing any
line of code (I mean, I have no single commit in my
closure-stylesheets local git branch). I have no strong need for it,
so it was really low priority.

[Ray Cromwell]

Sorry to hear that. This is actually on our list of priorities for
GWT, so we will have to take this up internally.

> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors

[Thomas Broyer]

On Thu, Feb 2, 2012 at 7:05 AM, Ray Cromwell <cromw...@google.com> wrote:
> Sorry to hear that. This is actually on our list of priorities for
> GWT, so we will have to take this up internally.

Just a clarification: I was trying to replace Flute with the parser
from Closure Stylesheets, replacing the whole CssResource processing
(or creating a GssResource) with one based on Closure Stylesheets
should be relatively easy though. For now, my priorities are fixing
the remaining RF bugs and hope my half-a-dozen-or-so patches will land
in 2.5 (we're helping a company switch to web apps in GWT, and I'd
recommend them to use RF over RPC if there wasn't so many pitfalls
[1], having the fixes in 2.5 would help make the choice based on the
actual features and limitations due to their designs, rather than
ditch RF based only on its known bugs [2]). I had very little time
these past weeks so I couldn't even try fixing issue 6710 which, to
me, is higher priority.

So, when I'll have time and have fixed 6710 (the last remaining
"blocker" IMO), I'll see if I can help integrating Closure
Stylesheets, but I'm afraid not before. Does that sound good to you?

[1] That one in particular caught me when upgrading to a "recent
trunk" last fall, it's not documented and I can't say if it's a bug or
simply a limitation due to batching:
http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c1
[2] One such example:
http://code.google.com/p/google-web-toolkit/issues/detail?id=7120#c2

[Julien Dramaix]

Hi all,

Just to inform you that I would like to give a try to add support of CSS3 in GWT if nobody is working on.

After some research, I found another open source CSS parser in java supporting CSS3 : https://code.google.com/p/phloc-css If we need only a parser it could be a interesting alternative to Closure syle sheet.

What do you think ?

Julien

[Colin Alworth]

I'd be interested in helping with either approach. The phloc-css project looks interesting if we are only trying to add support for newer CSS features, while integration with Closure Stylesheets seems geared more toward extending the CssResource featureset. Much of the existing functionality in GWT's CssResource is also in closure in some capacity, though the implementation is likely different enough to cause interesting issues. There are advantages to making it through those differences - mixins for example.

Another thought would be to implement both - expand CssResource to support new properties with phloc-css, and create a new ResourcePrototype (StylesheetResource perhaps?) with its own resource generator to put code through closure's wringer.

-Colin

[Thomas Broyer]

On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote:

I'd be interested in helping with either approach. The phloc-css project looks interesting if we are only trying to add support for newer CSS features, while integration with Closure Stylesheets seems geared more toward extending the CssResource featureset. Much of the existing functionality in GWT's CssResource is also in closure in some capacity, though the implementation is likely different enough to cause interesting issues. There are advantages to making it through those differences - mixins for example.

Another thought would be to implement both - expand CssResource to support new properties with phloc-css, and create a new ResourcePrototype (StylesheetResource perhaps?) with its own resource generator to put code through closure's wringer.

+1 to that (obviously, as I think that's what I was proposing) 

[Goktug Gokdogan]

What we were planning was to add support for GSS, add the missing features and then migrate existing users and deprecate the older eventually. This would decrease the maintenance cost a lot in the long term.

We really want to see GSS support for GWT in the long term. On top of additional features, there are other benefits with moving to GSS; Google is committed to maintain GSS and support it in the long term, we can get direct support from the authors as they are close to us. One other major advantage more specific to us is, we can reuse tons of already available GSS resources. For that reason, we would love to see you moving in this route and will definitely help you along the way, and also provide you additional contact points from the team for support.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Julien Dramaix]

Thanks all,

I will focus on Closure stylesheets integration and the introduction of a new GssResource

Julien

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.

[Colin Alworth]

I spent an hour or two last night playing with phloc-css, and it doesn't seem to be quite as flexible as flute in terms of adding custom behavior for unknown @-rules (@def, @sprite, etc), or handling arbitrary (and unknown to both flute and phloc-css) functions like literal() and value(). I played briefly with modifying the jjt file, but realized that any gain made there comes at the cost of re-namespacing and trying to rebase such a change along as phloc-css changes. As a drop-in replacement, I'm not seeing a good strategy here, though I'm open to suggestions.

Closure doesn't quite seem a perfect fit either, though perhaps I am missing some details about it (I've only gone through the docs at http://code.google.com/p/closure-stylesheets/ and the wiki), specifically around the @sprite/gwt-image feature in CssResource, but also the other Java-specific pieces like @eval to get outside values into the css and @def to get inside values back out again. Can anyone comment on those aspects of how a GssResource could look?

On Tuesday, August 27, 2013 2:19:39 PM UTC-5, Julien Dramaix wrote:

Thanks all,

I will focus on Closure stylesheets integration and the introduction of a new GssResource

Julien

On Tue, Aug 27, 2013 at 5:25 PM, Goktug Gokdogan <gok...@google.com> wrote:

What we were planning was to add support for GSS, add the missing features and then migrate existing users and deprecate the older eventually. This would decrease the maintenance cost a lot in the long term.

We really want to see GSS support for GWT in the long term. On top of additional features, there are other benefits with moving to GSS; Google is committed to maintain GSS and support it in the long term, we can get direct support from the authors as they are close to us. One other major advantage more specific to us is, we can reuse tons of already available GSS resources. For that reason, we would love to see you moving in this route and will definitely help you along the way, and also provide you additional contact points from the team for support.

On Tue, Aug 27, 2013 at 3:24 AM, Thomas Broyer <t.br...@gmail.com> wrote:

On Tuesday, August 27, 2013 1:42:35 AM UTC+2, Colin Alworth wrote:

I'd be interested in helping with either approach. The phloc-css project looks interesting if we are only trying to add support for newer CSS features, while integration with Closure Stylesheets seems geared more toward extending the CssResource featureset. Much of the existing functionality in GWT's CssResource is also in closure in some capacity, though the implementation is likely different enough to cause interesting issues. There are advantages to making it through those differences - mixins for example.

Another thought would be to implement both - expand CssResource to support new properties with phloc-css, and create a new ResourcePrototype (StylesheetResource perhaps?) with its own resource generator to put code through closure's wringer.

+1 to that (obviously, as I think that's what I was proposing) 

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Samuel Schmid]

I'm a little bit late in this discoussion, i see there is a lot of work already on going.

But +1 for this.
SASS or LESS would be a big plus.
For me I think supporting OOCSS is more important than supporting CSS3 without workarounds.

Thank you guys!
Sam

[Colin Alworth]

Its never too late - I don't know how far Julien has gotten, but I've been distracted by other work, as well as trying to nail down conceptually where GSS meets ClientBundle.

For my part, SASS or LESS are a major step down from what we already have - the purpose of GWT in general is to let you write maintainable code that compiles to well-performing code, but not expose features that will perform badly (consider the lack of java.text, reflection support). The scoping feature that sass/less/compass has (allowing you to nest rules within other rules) makes for much longer selectors in the compiled out code, which equates pretty directly to worse performance (longer selectors take longer to find/track what they apply to). In contrast, Closure Stylesheets gives us the same sorts of variables, mixins, and @if syntax, but puts as much of this work on the compiler rather than adding more classes at runtime. It is a little more limited (and I'm not sure how we can even achieve things such as @def and @eval... which current CssResource has), but those limitations seem designed to provide better runtime performance.

On a different note, less/sass are implemented in Ruby, not Java, so either they must be made to work in JRuby or we'd need to require an existing Ruby installation.

OOCSS could be worth looking at - I don't know anything about it yet but would be interested in learning. At a glance, it *appears* to be more of a philosophy about writing html/css and a single set of starting structural css, rather than a more 'useful' css language - do I have it right?

Also, just as GssResource can be added as a new ResourcePrototype type, you could just as easily create a LessResource or OocssResource with its own generator to perform the required transformations.

I hang out in ##gwt on freenode, and would love to talk more about this whole task with anyone who is interested, otherwise i'd be open for a hangout to chat too.

[Julien Dramaix]

Hello,

First sorry for my late reply, I was on holidays in September.

I spent some evenings working on this subject and here is a summary of what I've done so far :

I first tried to replace the flute parser by the closure stylesheet parser for the CssResource. My idea was simple : traverse the tree returned by the closure stylesheet parser in order to build the internal css tree used by gwt. Unfortunately, I quickly stopped this because the parser used by the closure stylesheet project is not able to parse several at-rules used by gwt like :

- @if user.agent gecko {

- @external .className;

or even @sprite .className {

So without modify the closure stylesheet parser, we cannot use it for parsing css files used with the current CssResource.

So I started to implement the GssResource and its generator. At first, my goal is to be able to use any gss file with gwt by defining a GssResource, exactly as we do with the CssResource and a css file. The interface methods will give access to the class names and to the constants defined in the gss file (@def). I'm nearly done with this task and I should put my code online very soon (first at github for a "pre-review" and then I'll move the code on a project under the gwtproject account).

Then the next steps will be to add the support for missing features in google closure stylesheet that are existing in CssResource (like sprite...). The closure stylesheet parser uses a tree to represent the css file and has the concept of visitor to traverse the tree so it shouldn't be too hard to add the missing features. It offers also nice features like defining methods that you can use inside a gss file and produce css output. The implementation of these methods are done in java. I think that before to start this step we'll have to discuss how to implement the missing features. In order to ease the discussion, I will try to list what will be missing and the possible implementations.

I keep you inform,

Julien

--

http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/e0qUfkqBSog/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.

[Julien Dramaix]

I put online the first draft of the GssResource and its generator : https://github.com/jDramaix/gss.gwt/pull/1

Don't hesitate to review it, comment and give feedback. Once we'll agree that is the way to go, we can move the code in a project under gwtproject account.

This is a WIP and all is open to discussion. The pull request description contains what is done and what remains to be done.

My next task now is to create a document listing the missing features and their possible implementations.

To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.