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.
On Tuesday, October 1, 2013 3:18:06 PM UTC+2, Julien Dramaix wrote:
>
> 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.
