Thanks @Jens, I understand what you mean. However, I still not see a could reason to force the gss file extension. I think we can assume that the developer knows what he is doing and it's his responsibility to feed the gss engine with the correct files, giving him the freedom to use any extension he wants.
I understand that it's a nice separation, and it's how other css generation tools work. But Gwt is a bit different and does more then just css generation, so in this case it has some blocking disadvantages. Advantages of allowing the css extension: shared code use, merging to gss step by step. Let me explain it through my use case: I have a gwt code base that exists of many widget having their own resource bundle and css files (empty mostly, following to the adapter pattern). New projects want to use css3 features, as such need the gss mechanism. However, these shared resource bundles can't be changed, as it results in breaking other projects using them. Neither do I want to change them as mostly they concern empty css files that aren't gss dependent, which they would look like it if they have the gss extension. To solve this I see 2 options: duplicating the shared css files and giving them the gss extension -> a lot of work, messy maintainable code. Patching the gwt gss engine to allow for css files with the css extension. I think I go for the last option as it seems an easy one looking at the gss code. I would suggest to allow for the css extension. Optional with a console warning that can be suppressed (like done in other parts of the gwt code). I understand that the css files might contain some gwt syntax like @def that might result in unwanted results when processed by gss. But isn't that the same as letting Spring eat some hibernate syntax that it understands and results in strange outcome.... It's the responsibility of the developer to overcome that.... So give him that freedom.... What do you think? Just my 50 cents. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
