Introduce width and height to Icon style

[KaiVolland]

This introduces the width and height property to the Icon style.

It includes an example.

The code is highlighy influenced by https://codesandbox.io/s/icon-forked-uof9by?file=/main.js so kudos to @mike-000

addresses #13508

[github-actions]

📦 Preview the website for this branch here: https://deploy-preview-14364--ol-site.netlify.app/.

[marcjansen]

Nice work, probably an often requested feature.

Should width, height and scale always be in sync, so that setting one will ensure that all getters return actual values?

We should have a test that ensures that the image is effectively scaled in the aspect ratio, when only one of width or height is being set.

I'd favor the opinion from @ahocevar or @tschaub in terms of potential API cluttering.

I am +1 on getting this in.

(edit: removed size)

[mike-000]

The size option defines the image.width and image.height when the image is obtained from a sprite. It need not prevent the width and height options being used to define the displayed size.

[KaiVolland]

Should width, height and scale always be in sync, so that setting one will ensure that all getters return actual values?

We should have a test that ensures that the image is effectively scaled in the aspect ratio, when only one of width or height is being set.

I tried to create tests for both of theses cases but unfortunately the used image has no dimensions (image.width is undefined) in the test suite (e.g. the basse64 src). The dimensions of the image are used to calculate the scale in updateScaleFromWidthAndHeight.

The size option defines the image.width and image.height when the image is obtained from a sprite. It need not prevent the width and height options being used to define the displayed size.

Ok. You're right. I'll see who it currently behaves and adapt the assertion.

[KaiVolland]

@mike-000 I adapted the assertion and checked how the example behaves when used with size (and offset) and it's all fine i would say.

[KaiVolland]

I couldn't manage to add a test for the scale. But I added the scale to the example to verify everthing works as expected.

But of course a test would be much better, as a broken example won't be detected by CI. If someone has an idea how to fix the issue with the undefined dimension I could add the regarding tests. I could imagine that the 'load' eventlistener in the constructor has some timing issues with the testsuite. But as stated I couldn't handle it.

[marcjansen]

@KaiVolland What do you think about marcjansen@24e3a53 which uses imgSize when testing. I am not sure whether this counts as cheating, though. npm run test-browser passes locally with these changes.

Feel free to cherry-pick if you want.

[mike-000]

The image will not load until required by the renderer unless you force a load as in https://github.com/openlayers/openlayers/blob/main/test/browser/spec/ol/style/icon.test.js#L29-L40

[marcjansen]

The image will not load until required by the renderer unless you force a load as in https://github.com/openlayers/openlayers/blob/main/test/browser/spec/ol/style/icon.test.js#L29-L40

This looks like a saner approach. Maybe @KaiVolland can pick and amend as suggested. That'd be great.

[KaiVolland]

I added some code and tests to ensure that scale and width/height are in sync.

[marcjansen]

On documentation comment, otherwise looks great to me.

[marcjansen]

Great. Thanks for the nice collaboration, everyone.

[gmerciel]

First of all, thanks all the developers for this excellent library!

I'm seeing a bug with this commit. You can not clone the Style or the Icon (needed to get clicked features), since it will try to set both height and width, and the scale, thus giving an AssertionError when creating the new Icon.

AssertionError: width or height cannot be provided together with scale
at assert (asserts.js:12:11)
at new Icon (Icon.js:169:5)
at Icon.clone (Icon.js:259:12)
at Style.clone (Style.js:236:48)
at createHitDetectionImageData (hitdetect.js:74:35)

IMHO it would be better if this assertion is removed, since the properties are in sync, so they shouldn't cause a conflict (or maybe the assert should check if you specify both, that they are in sync.

[tschaub]

Thanks for the report, @gmerciel. Can you open a dedicated issue describing the bug?

If we want to keep the assertion as is, one option would be to update the clone method to not include the scale of height and width are defined. Whatever the fix, tests should be added to cover the case.

[gmerciel]

Thanks @marcjansen!