Just to summarize: - GSS will be available in GWT 2.7 - GSS will use the CssResource interface and your file needs to end with the .gss extension - GSS will not be enabled by default. To enable it: add <set-configuration-property name="CssResource.enableGss" value="true" /> in your module file. - Once enabled, all the CssResource interfaces will be generated by the new GssResourceGenerator - If your app uses still old css file compatible with the GWT-CSS syntax you will need to enable the automatic conversion of these files to GSS. To do that: add <set-configuration-property name="CssResource.legacy" value="true" /> in your module file. - The GSS parser and compiler is more strict than the old one. If you meet some issue in this automatic conversion, you can also enable the lenient mode: <set-configuration-property name="CssResource.conversionMode" value="lenient" /> - When GSS is enabled, we have to use an attribute gss="true" in your uibinder inline style (<ui:style>) in order to enable GSS
We decide to go with the memory conversion because it is the way to move forward. The goal is to enable GSS (with the automatic conversion not enabled by default) and remove the CssResourceGenerator in the next release. So we want people test this strategy in order to fix possible issue and ensure that the automatic conversion is stable. On Wednesday, October 8, 2014 1:49:37 AM UTC+2, Goktug Gokdogan wrote: > > Can you also summarize why we need in memory conversion as opposed to > simpler alternative? > So it is documented for the next time when we will have similar discussion > :) > > On Tue, Oct 7, 2014 at 4:00 PM, Daniel Kurka <dank...@google.com > <javascript:>> wrote: > >> Hi all, >> >> summarizing the discussion I just had with Julien: We want to have the in >> memory conversion in GWT 2.7 (even if it is not battle tested yet), since >> this is the way to move foward. We can even do a followup release (2.8) as >> soon as google is using it in production and we sorted all issues out. >> >> If GSS is turned on we will: >> >> - We will make a decision which generator to use based on file extension >> - You can not mix gss / css on the same interface >> - In UiBinder we will add a new attribute to tell that this interface >> needs gss (default css) >> - If lib has gss in it the app using that lib needs to have it enabled. >> >> I think there is good value in including this in GWT 2.7 since we can ask >> for external feedback as well, while at the same time making sure its >> mature within google. >> >> -Daniel >> >> >> >> On Tuesday, October 7, 2014 8:55:27 AM UTC-7, Goktug Gokdogan wrote: >>> >>> I didn't take notes in the meetup so I cannot recall all the reasons >>> (perhaps someone else did?) but I think one of the reasons to introduce in >>> memory conversion was to get rid of the CSS generator code with the GSS >>> release and another one was the possible complications of coexisting css >>> and gss in the same page (e.g. name collisions). >>> >>> Given that we cannot get rid of the CSS generator in 2.7 and if you >>> think everything would be fine with css/gss mixed together (e.g. with >>> prefixes), I'm totally fine with kicking in-memory conversion out and it is >>> definitely not required for 2.7 even if we decide to keep it. >>> >>> However, arguably there might be still value in having an experimental >>> flag to enable GSS as it is not well tested yet. >>> >>> On Tue, Oct 7, 2014 at 1:37 AM, Julien Dramaix <julien....@gmail.com> >>> wrote: >>> >>>> 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....@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+unsubscribe@ >>>>>> 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+unsubscribe@ >>>>> 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+unsubscribe@ >>>> 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 >>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6X1b-ZW21UjF3MPABTsofnqQ1G1BUH00fk8pR9KTh2yQ%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 >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7187f2b7-024e-4c5a-94d4-71e6f5f58456%40googlegroups.com >> >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/7187f2b7-024e-4c5a-94d4-71e6f5f58456%40googlegroups.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/eaeec36f-faca-4f93-9138-a8be90c5a949%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
