I'm confused how to get HTML to render correctly when being loaded from a KML file. I have a KML file with Placemarks, and they have descriptions with links, line breaks, etc. When the data is loaded using
var kml_layer = Cesium.KmlDataSource.load(url);
viewer.dataSources.add(kml_layer);
All of the HTML is stripped out in the description, leaving the infobox unable to render any of it. I have tried just overwriting the description with some HTML, and that renders correctly in the infobox, so it isn't a problem with infobox. The only thing that seems to work is to wrap the description in <![CDATA]>, but since I'll be loading the files externally, I don't want/can't do that.
How do I get the KML data loader to not strip out html?
Rachel is correct, HTML inside of XML needs to be properly escaped. I am curious if your existing KML works as expected in Google Earth (it might because GE likes to allow “bad” files, but we might not have that option since we need to rely on the browser for parsing).
I’ll check out the samples you posted and let you know.
I am the same! Thanks for your help. Also, is it possible to have HTML in the title of the info box? The names of the data have links in them, and I would like to keep them
Now for the big picture: Allowing KML (or any other external data source) to inject arbitrary HTML into a web application is actually a major security hole. This is why Cesium uses iframe sandboxing and text bindings instead of html. Our goal is “secure by default” so the infobox does not allow any HTML or JavaScript out of the box. For developers that need this functionality and understand the risk (or will be in total control of any data that gets loaded), the iframe sandboxing can be disabled and HTML and JavaScript descriptions will work as-expected. However. you are the first person to ever request the ability to we allow HTML for the entity.name and title itself. Since I already mentioned above that this is an easy change, I wrote up https://github.com/AnalyticalGraphicsInc/cesium/issues/5446 so that we address this in the future. If you are interested in contributing the change, we’d be happy to look at a pull request.
That does make sense, and I do understand your logic for most use cases, but since this will be an internal application, we aren't really concerned with these sorts of security flaws.
Changing that line did work, thank you! I feel that this could be changed through a simple property in the viewer, or some 1 line of code that changes this.