Document that OL with CSS is expected to be a two-tag library

I found out that the problem is due to the theme css not being completely loaded when wComp and hComp are calculated. This new patch removes the firstRun logic, and does a setTimeout loop instead until values for wComp and hComp are returned. I do not know if using setTimeout is an appropriate way according to OpenLayers design, but it works.

Hm. This is definitely an interesting issue. I'd like Tim to offer an opinion, since this 'CSS loading slowly' issue is something that he has the most knowledge on.

I think a workaround is to manually specify the theme CSS in the page, which will mean it is loaded before the overviewmap.

I think we should resolve the two competing goals of pulling style declarations from the code and having OL be a single tag library. I'd be pleased if I were wrong, but I think we'll continue to find problems like this and get forced into awkward solutions (setting a bunch of timers to wait for the dynamically loaded style).

Browsers are designed so that CSS works with ordered tags. I can't think of a clean way to have every other method wait for that dynamically added stylesheet to load.

In case it's not clear, the conflict is that the code needs to know information about calculated styles. If style declarations are not in the code (which is certainly not where they should be), those declarations need to be made before any style checking code executes. This happens naturally with style declarations made in <style> tags or in external stylesheets loaded with <link> tags.

Finally, I wouldn't approve the above patch because it will endlessly set timers to call that calculateBorderCompensation method in the case where the extent rectangle actually has a zero width border - think of an opaque box with no border.

crschmidt, specifying the CSS in the head of the HTML document before specifying the OpenLayers.js script tag fixes the issue indeed.

tschaub: I agree with you. The patch only works if a border with at least 1px width is specified. In my application I can live with the extra CSS definition in the HTML document head. For integration in Mapbuilder, we have to do a little more thinking. Maybe it would be best to copy the content of the OpenLayers style.css into the Mapbuilder css file.

Replying to ahocevar:

tschaub: I agree with you. The patch only works if a border with at least 1px width is specified. In my application I can live with the extra CSS definition in the HTML document head. For integration in Mapbuilder, we have to do a little more thinking. Maybe it would be best to copy the content of the OpenLayers style.css into the Mapbuilder css file.

Yeah, if you really only want one stylesheet, you could surely paste it in. In terms of upgrades, it certainly seems easier to me to have two separate stylesheets - or if you have something on the server side that concatenates them, that would make for easy management as well (as in src="somescript?style=OpenLayers,MapBuilder). With regard to concatenating (or cascading) styles. If a MapBuilder (or any other app) user wants to customize a single style declaration - you can't use OL's dynamic theme thing anyway, because you never know which declaration is going to be made last.

So, if nothing changes on the OL side, I would encourage you (or anybody that wants to customize an application) to start using theme: null as a map option in OL. Then you add the stylesheet in a <link> tag per ususal, and you're ready to start customizing.

PS - setting this.hComp and this.wComp to null instead of 0 (and checking for null before setting the timer) takes care of the endless timers thing in the case of a zero border - but the point about having to hack in these types of things is the bigger issue.

I think it makes sense to me that the 'default' behavior in single-tag mode is not neccesarily going to be the 'right' behavior with things that require CSS. I think that it probably just makes sense to make anything which uses Controls include the script tag in the page and set 'theme' to null.

I think that what this means is that the current patch is not going to be applied, and in the 2.6 timeframe, we will look towards documenting and demonstrating that OpenLayers with visual elements controlled by CSS is expected to be used as a two-tag library.

Does that sound like a sane course of action?

Replying to crschmidt:

I think it makes sense to me that the 'default' behavior in single-tag mode is not neccesarily going to be the 'right' behavior with things that require CSS. I think that it probably just makes sense to make anything which uses Controls include the script tag in the page and set 'theme' to null.

Done so in Mapbuilder: http://jira.codehaus.org/browse/MAP-418

Because Mapbuilder starts widget painting not before the body onload event, we can load stylesheets on widget initialization (ie. before the Mapbuilder "init" event). By doing so, we should have all stylesheets loaded before OpenLayers.Map is created. So I set "theme: null" in the map options, and Mapbuilder dynamically loads the OpenLayers style.css theme on widget initialization of MapPaneOL.

I think that what this means is that the current patch is not going to be applied, and in the 2.6 timeframe, we will look towards documenting and demonstrating that OpenLayers with visual elements controlled by CSS is expected to be used as a two-tag library. Does that sound like a sane course of action?

For me, this sounds perfectly sane.

Bumping to 2.6 as a reminder

(In [6145]) In order to make it more clear that users are required to have the theme/ directory to deploy when depending on features which use CSS, and make it clear how to override the CSS in OpenLayers, include <link rel> ags in all examples. (Closes #884)