Support other tags than div for ui.html

[kleynjan]

No description provided.

[falkoschindler]

Thanks for the pull request, Peter!
I just changed the demo to something that renders visually different than a div.

[ed2050]

Very glad this was caught and fixed. I just going to post a new issue about this.

You would expect these two lines to be equivalent, but they are not:

img = ui.element ('img').props (f'src={ src }')
img = ui.html (f'<img src="{ src }">')

Second line wraps <img> tag in a <div> which causes all sorts of trouble. When I add styles with img.style (...), they are put on <div> which gives wrong results. Got bit by this today and couldn't figure out where <div> was coming from.

[falkoschindler]

@ed2050 As the documentation for ui.html says:

Renders arbitrary HTML onto the page, wrapped in the specified tag.

So the HTML content "<img ...>" is always wrapped in a container element, usually a <div>. But you can change it, so that the following lines are equivalent:

ui.element('img').props(f'src={ src }')
ui.html(tag='img').props(f'src={ src }')

[ed2050]

Yes, with the Feb patch. Previously that wasn't possible. I'm using an older version.

I find it very strange that unrequested divs are dumped in my data structure. Why not just return what the user asked for? It's like a having sine function with docs that say note, actually returns 1 / sin (x). Docs are accurate, but why do it such a convoluted way?

Anyway all good now.

[falkoschindler]

@ed2050 I see your point, and I agree. When creating the ui.html element long time ago, I didn't know how to place HTML into the DOM without a container element. But when I think about it now, it should be possible with a custom Vue component. Even though it might break existing layouts and, therefore, needs to wait for the next major release, I would be interested in a pull request proposing such a new ui.html element.

[ed2050]

Thanks @falkoschindler. Actually I'm not sure I support changing this behavior. While it is misleading, I favor code stability over unnecessary breaking changes. Even in a major release, I prefer as few breaking changes as possible.

How about instead the tag parameter accepts a value of none to return the raw unaltered html? Otherwise it wraps with tag as current behavior. This could be made prominent in the docs by updating the first line:

Renders arbitrary HTML onto the page, wrapped in the specified tag (or none for raw unwrapped HTML).

[falkoschindler]

I like the idea of making the tag optional, @ed2050! This gives full control to the user, while not breaking anything. 👍🏻