On Thursday, February 20, 2014 12:08:28 AM UTC+1, GWTter wrote:
>
>
>
> On Wednesday, February 19, 2014 10:59:51 AM UTC+1, Thomas Broyer wrote:
>>
>>
>>
>> On Tuesday, February 18, 2014 6:38:36 PM UTC+1, GWTter wrote:
>>>
>>> Hi all,
>>>
>>> Let me just go with an example right off the bat.
>>>
>>> Let's say I have the following:
>>>
>>> === Pseudocode ===
>>>
>>> SuperCssResource: This is injected onModuleLoad before anything else
>>> .genButton{
>>> color: black;
>>> }
>>>
>>> Widget1 consists of:
>>> --- css ---
>>> MyCssResource:
>>> .myButton{
>>> color: red;
>>> }
>>>
>>> --- html ---
>>> <button class="genButton myButton" />
>>>
>>> Widget2 consists of:
>>> --- css ---
>>> XCssResource extends SuperCssResource:
>>> ... rules that use classes from SuperCssResource
>>>
>>> --- html ---
>>> ...elements
>>>
>>> My problem is that if I display Widget1 first and then display Widget2
>>> then the button in Widget1 will have a color of black instead of red.
>>>
>>> I know that this is expected behavior (GWT will merge the stylesheets
>>> together) since inheritance is basically the cssresource equivalent of CSS
>>> @import <http://www.w3.org/TR/css3-cascade/#at-import>
>>>
>>
>> Er, no.
>>
>> Inheritance of CssResource interfaces only deals with that: inheriting
>> methods. The actual CSS backing the resource is given by the @Source
>> annotation on your ClientBundle method, and if you use the same CSS file
>> for 2 different CssResource interfaces, the CSS will be duplicated, because
>> obfuscation of the class names is based on the interface fully-qualified
>> name:
>> http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html#Scope (the
>> order of the files in @Source will impact merging, just as they'd impact
>> precedence in CSS).
>>
>
> Hi Thomas,
>
> I guess I should have specified that it is inheritance along with
> specifying the source css that for all intents and purposes acts like CSS
> @import. I know that GWT will error if you extend the super resource and
> don't include it's source to match the classes, unless you're
> reimplementing them in the extending css resource which is not what I'm
> after and not the best idea IMHO.
>
>>
>>
>>> but I thought since this was GWT maybe there was a way to use
>>> inheritance in the sense that the inherited stylesheet would only be
>>> injected if
>>> not injected already. Is this currently possible? or could it be done
>>> with like a @Require annotation on the extending interface which would
>>> indicate
>>> that merging of the super stylesheet should not be done but rather a
>>> check would be made to see if it already exists and if not to inject it.
>>> This would easily resolve the specificity overriding issue in the
>>> example when it's not the desired behavior.
>>>
>>> I know I could also get around this by importing with a prefix, however
>>> I still don't like the idea of essentially reinjecting the same styles.
>>>
>>
>> If you don't want duplication, then you need a "shared scope" or
>> "imported scope". In any case, that means you should only use the
>> shared/imported class names in more complex selectors, you shouldn't change
>> the styles attached to the selector by itself.
>>
>> None of this applies if you use "@external" though, then it just works
>> like standard CSS.
>>
>
> I know, like you mentioned, that I could avoid the precedence override by
> importing with prefix for example. And my use case is only to increase
> specificity on the extending css resource, definitely not to change the
> super's rule def by redefining the super selector in the extending
> resource. But I'm not thrilled with essentially reinjecting all the same
> rules with just different prefixes and @external does really fit my need as
> I don't want to forgo the obfuscation.
>
I don't understand that "reinjecting all the same rules with just different
prefixes" bit; sounds like a misunderstanding of how @Import and
@ImportedWithPrefix work.
Obfuscation is based on the FQCN of the interface, so @Import()ing such an
interface is only about importing the *names*, not the source (which is not
defined in the interface anyway), and @ImportedWithPrefix is only there to
prevent conflicts (it also helps visually distinguishing those names that
have been imported and those that are "defined" in the stylesheet). The
gwt-CellTree-cellTreeItem you'd get by @Import(CellTree.Style.class) will
be replaced with the same obfuscated name as the cellTreeItem from the
CellTree stylesheet, so you can match something in a CellTree, but nothing
is "injected with just different prefixes", the prefixes are gone after
compilation.
Either that, or I'm not understanding your use-case, and a simple example
would really help! (in any case, if you could share a simple example, I
think everyone could benefit from a discussion around it, or maybe just
using it as a basis for their own work, maybe even a "best practice")
--
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 google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
