GNOME Bugzilla – Bug 765737
Order of adding style providers affects priority
Last modified: 2016-04-28 23:16:40 UTC
Created attachment 326959 [details] testcase showing the problem When adding two style providers with the same priority, the provider added last always gets a higher priority even if it has less specific selectors. Example: One provider changes the background of all "window" elements to red and another provider changes the background of all widgets with the ".blue-window" class to blue. Expected result: All windows with the ".blue-window" class should have a blue background since class based selectors are more specific than element based ones. What actually happens depends on the order in which the providers get added. If the red provider gets added last, the window is red, if the blue provider gets added last, the window is blue. This is currently causing a bug in nautilus when using desktop icons and switching themes: https://bugzilla.gnome.org/show_bug.cgi?id=765687
I've so far considered the behavior of 2 style providers with the same priority undefined. And I don't think we want to change that - in particular because giving any ordering guarantees there would imply that we'd also have to give guarantees for GTK-provided providers. The correct fix for bug 765687 should be to use higher/lower priority for the provider you care about more. Just like with main loop sources, use PRIORITY_APPLICATION + 1 (or - 1). Long term, we might wanna think about supporting the cascade as per the CSS spec, but that would get rid of priorities, so I don't think we want to tackle that unless we have to.
I think we'd need at least '!important' before going to proper cascade as per CSS specs.