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
On Wed, Sep 25, 2013 at 6:50 PM, Colin Alworth <[email protected]> wrote:
> 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.
>
>
> On Wednesday, September 25, 2013 2:24:06 AM UTC-5, Samuel Schmid wrote:
>>
>> 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
>>
>>
>> On Friday, December 16, 2011 11:51:43 PM UTC+1, Michael Vogt wrote:
>>>
>>> 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
>>>
>>> --
> 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
> [email protected].
> 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 the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
