I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion.
Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.) That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us. In the next release of GWT, when we remove the code for the existing generator, we will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax. Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases. Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the "extra" directory) if the -extra flag is set. Julien On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors < google-web-toolkit-contributors@googlegroups.com> wrote: > We worked on a migration plan a few weeks back. I don't think we need to > mix css and gss together inside the same app. > > At this point, the libraries have multiple reasonable options on > compatibility: > > 1- Provide both css and gss file for the resource (recommended). > The library will work fine regardless if the app enables gss or not as the > right file will be chosen for the app. That's what we will do for internal > resources in the SDK. > > 2- Keep providing the css file and make sure it works in strict mode. > The library will work fine in css mode and will work with gss only if the > legacy mode is enabled. > > 3- Keep the old css that requires lenient mode. > The library will work fine in css mode and *may* work with gss if lenient > legacy mode is enabled. > > More problematic part is the css inside uibinder. Like you said, simplest > option is to introduce a temporary attribute in <ui:style> tag that marks > the content as gss. In this case it is more tricky for the library to > support compatibility mode similar to the mode (1) above. Either the lib > should write the style that both compiles with css and gss or if it is not > feasible then it should extract the resource to a file and follow the two > file approach described above. > > > On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix <julien.dram...@gmail.com> > wrote: > >> > Hmm but still a bit of work if a library has lots of inline styles and >> wants to use GSS stuff. >> If you want to use GSS in all of your inline styles, you have first to >> convert them to GSS and it will take more time than simply adding an >> attribute that say that this inline style is using GSS. >> >> The problem with UiBinder is that we don't know if the developer is using >> CSS or GSS because the CssResource interface is generated and we cannot >> based our logic on the file extension as we do with normal CssResource. >> >> I have still to investigate but I'm pretty sure that adding an attribute >> will be the easiest way to support correctly GSS in uibinder inline style. >> >> >> >> >> -- >> 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+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6X1b-ZW21UjF3MPABTsofnqQ1G1BUH00fk8pR9KTh2yQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
