On Friday, February 21, 2014 5:09:36 PM UTC+1, Thomas Broyer wrote:
>
>
>
> On Thursday, February 20, 2014 10:51:29 PM UTC+1, GWTter wrote:
>>
>> ----Before anything, sorry Thomas, I think I may have just replied to you
>> instead of just the topic (buttons bugged on me a bit), no-spam intended----
>>
>> You're right I guess I did misunderstand if the imported with prefix
>> doesn't in fact use a different obfuscation
>> for the original selectors in the final css. So using the imported with
>> prefix method isn't a viable workaround for avoid the
>> precedence override on injection after all.
>>
>> And definitely, anything that will help clear it up. I can try to clarify
>> my original example:
>>
>> You have the following,
>>
>> === Pseudocode ===
>>
>> CssResouces:
>>
>> SuperCssResource, is injected onModuleLoad (global css) and has the
>> following css as its source:
>> .genButton{
>> color: black;
>> }
>>
>> and
>>
>> LeafCssResource extends SuperCssResource
>> ....
>> css definitions here
>> ....
>>
>
> Why are you using an "extends" here? what do you expect from it? and more
> importantly what does your ClientBundle(s) looks like?
>
I'm just setting up viable example when working with Resources. In this
case specifically you would expect to be able to reference the styles
from SuperCssResource via LeafCssResource and be able to use the selectors
from SuperCssResource's css to qualify other selectors in LeafCssResource's
css.
The client bundle would simply look like:
interface LeafClientBundle extends ClientBundle{
@Source({"Leaf.css","Super.css"})
LeafCssResource leafCss();
}
>
>
>> ----------------------------------------
>>
>> Finally, we have the following 2 widgets:
>>
>> WidgetDisplayedFirst,
>> has the following css via uibinder:
>> MyCssResource:
>> .myButton{
>> color: red;
>> }
>>
>> And this button element:
>> <button class="genButton myButton" />
>>
>
> Using this, it means you have to ensure SuperCssResource is always
> injected *before* you createAndBindUi for the widget.
> Using .genButton.myButton (higher specificity) in the CSS would fix it.
>
Yes, and in this example I would make sure to inject LeafCssResource which
would thereby inject SuperCssResource.
And adding .genButton to further the specificity of .myButton would indeed
fix, however the point I'm trying to make is that I think it's
unreasonable to either overqualify every selector for fear of having your
styles be overridden because of precedence or that developers
need to be aware of all the other styles they would be affecting when
creating their own widget trying to qualify their selectors with a global
cssresource.
>
>> and WidgetDisplayedSecond which uses LeafCssResource
>>
>> ------------------------------------------
>>
>> Now if while my app is running I just display WidgetDisplayedFirst then
>> it will display its button
>> with the correct color: red because the .myButton was declared last and
>> thus overrides the .genButton which
>> has the same specificity.
>>
>> The issue comes into play if I then display WidgetDisplayedSecond. Since
>> WidgetDisplayedSecond uses LeafCssResource
>> this will cause SuperCssResource and its css to be injected when
>> LeafCssResource is injected.
>>
>
> No. Unless you have a @Shared annotation on SuperCssResource, the names
> from LeafCssResource will be different from those of SuperCssResource (so
> even if you referenced the same CSS file in @Source of your 2 ClientBundle
> methods, you'd have duplicated rules with different selectors, in no way
> would SuperCssResource be "reinjected").
> See http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html#Scope
>
Yes, and I should have actually put the @Shared in the example. I didn't
remember to add it because I was talking about reusing selectors in the
leaf css to qualify in which case you would need to have the same names or
else the qualifying would not work at all since the names would be
different. So in this case I am talking about using the @Shared on the
SuperCssResource and that you do see the selectors from SuperCssResource's
css reinjected when you inject LeafCssResource.
>
>
>> At this point because
>> SuperCssResource has now been reinjected and thus is now the last one
>> declared between it and MyCssResource, its
>> .genButton rule now wins and causes WidgetDisplayedFirst's button to now
>> have a color of black.
>>
>
> With the code above, it shouldn't (now there could be bugs).
>
So you're saying that SuperCssResource's css should not be included in with
the css generated for LeafCssResource to be injected? If that's the case
then I think there is a bug.
>
>
>> Now, granted, this is how Css is intended to work in terms of the
>> cascade. However, what I'm trying to say is that this
>> is an example of a case where that is not the desired outcome if you want
>> the button to keep the color of red as defined
>> in its MyCssResource.
>>
>> You really only have 3 options in order to prevent this currently as far
>> as I can see:
>> 1) You over-qualify all of your selectors to ensure that they always have
>> the most specifity and nothing
>> will override them
>> =>CON: over-qualifying is not great for performance and is not as
>> maintainable/cascadeable
>>
>> 2) You architect the app taking into account every single inheriting
>> resource that is injected dynamically/on-demand to make sure
>> that the injection of the extended resource does not cause an override in
>> widgets who are using its classes.
>> =>CON: extremely unrealistic for non-trivial apps much less a real web-app
>>
>
> Except that inheritance of CssResource interfaces does not work that way
> (and if it does in practice –I doubt it, there are unit tests–, then that's
> a bug).
>
I'm starting to think that a bug is the issue because you would see the css
from SuperCssResource in the css of LeafCssResource when the
LeafCssResource is injected which is why this precedence override is
happening.
>
>
>> 3)Do not extend CssResources, this way you can ensure that all resources
>> and their associated styles are ONLY injected
>> once in the lifetime of the app so there are no worries of unintended
>> precedence overrides.
>> =>CON: greatly restricts selector qualifying especially when trying to
>> localize css and reuse widgets
>>
>
> I don't get your CON here. If you need to use the class name from another
> CssResource in your CSS in a compound selector, then just @Import the other
> CssResource. As long as you're not changing the styles from the imported
> class names (same as if you had several CSS files without using
> ClientBundle), there's no need to worry.
>
>
My CON is assuming that if you do not extend the CssResource then you
cannot reference the selectors in the leaf css because I though that
@Import and extending worked together. However, I may be wrong about this
as I've never tried to use @Import without the accompanying extends on the
respective CssResources. Are you saying that using the @Import without the
extends would work in terms of being able to reference the super selectors
and that you wouldn't have this reinjecting issue too? Because that would
be a more reasonable workaround.
Thanks again for the response.
--
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.
