New control for properly displaying HTML content

[ghost]

I think a solid control for displaying content doesn't exist at the moment. Sure, you can use a WebView control, build yourself a HTML template, add some CSS and all the things. But this makes it still complicated to use the WebView in a FlipViewItem for e.g. next/previous behaviors.

The HtmlBlock control from the Windows App Studio Libraries renders HTML into XAML. In my opinion this is a damn bad approach, as HTML can be really shitty and it could break the parser. Maybe there's another solution to fix the WebView problems.

[deltakosh]

I'm not sure to get why using the Webview is complicated. Can you picture it a little bit more?

[ScottIsAFool]

@deltakosh the webview might not be difficult as such, but it adds a significant memory overhead that would be preferred to be avoided.

[deltakosh]

But how do you want to render HTML without a webbrowser? :)

[ghost]

@ScottIsAFool For example. @deltakosh I'm missing a control (maybe based on the WebView) that is as easy to use as the rest of XAML. So I can put other controls on top of it (instead of building workarounds with WebViewBrush), put it in a FlipViewItem (like in the MSN news app, for example) and so on.

[Hanzalah-Adalan]

@jlnostr I have an unanswered issue for the HtmlBlock control.. I think the control has been deprecated since it's not brought into this new UWP Community Toolkit.. There must be a real reason why they ignore it.. https://github.com/wasteam/waslibs/issues/45

[javitosanchez]

In my experience the webview approach has 2 problems/limitations:

• Memory consumption
• The webview control handles it's own scroll, so it's not posible to include it into a scrollview. This limits any kind of layout composition

It's obvious that the best way to render html is using the webview control, but currently most of the content providers (rss, YouTube, Twitter...) uses the html as format. In order to apply a look & feel to your html content you will need to inject some amount of css, and this increase the complexity because you are mixing html/css and xaml. Here is were the HtmlBlock control makes sense.

[deltakosh]

@jlnostr and this control should be interactive I guess?

[ScottIsAFool]

@deltakosh if by that you mean things like clicking on hyperlinks, yes :)

[deltakosh]

So you need a browser which in turn needs memory. I do not see what we can do better here.

For webview integration in other control, I'm afraid this is beyond toolkit responsability and this is more an ask for XAML team. (you can use their uservoice for this: https://wpdev.uservoice.com/forums/110705-universal-windows-platform)

[hermitdave]

Folks,

I have needed this in past and i started with this control https://github.com/MyToolkit/MyToolkit/tree/master/src/MyToolkit.Extended/Controls/Html

However I couldn't style it and due to lack of time I eventually moved to using HTML to XAML transform

It would be great to implement at least a limited HTML to RichTextBlock transform

[Odonno]

@hermitdave Same, have used a HTML2XAML component but not really enjoy by it because it is very limited. Is there any solution to create an Embedded HTML view inside a XAML component ?

I mean, my current use case is to create a ListView where each item has a DataTemplate that contains some XAML stuff and an HTML block view.

[deltakosh]

I do not see how you can handle all the complexity of CSS + html + JS on a custom control without relying on an effective browsers. This control has to be perfect or you will spend ages dealing with support and maintenance.

[ScottIsAFool]

@deltakosh I would say most use cases don't require parsing complex html/css/javascript

[deltakosh]

"most" The risk could be reduced with a SOLID documentation perhaps

[deltakosh]

But once again, I do not want to block this control. Let's try and see how it could work

[hermitdave]

My thoughts.

1) No JS support. This is an HtmlView control. it renders Html and that's about it. 2) We start with basic html tags. I'd suggest a subset of HTML4 3) CSS again would be a no no.. we could look at inline style attribute as that isn't that bad an option.

[Dinchy87]

I also tried to make my own solution instead of the webview, parsing all the elements of a html document in a richtextblock or different xaml elements inside a scrollviewer but in the end it gets to the same as the webview. Handling JS and cookies and caching and so on there is the webview better and i thought if i do it further i will get to the point of a basic webview. So for me its the same. Maybe the webview is an memory hog, yes, but it also has a lot of options to display html. My own solution maybe has reduced the memory footprint but still lacks of polish, functions and usabilty. It was too narrowed down to my own case of a RSS source parsing to html.

Years ago this is why i found HtmlAgilityPack for parsing webpages and then switched (just display html instead of parsing/scraping) to a WebControl and now WebView. It gets better and better.

[deltakosh]

@hermitdave I still don't buy it as this is too restrictive to be used. I would prefer a MDView then. At least we can support everything for this one

[hermitdave]

@deltakosh i agree.. markdown would be easier to support than html

[Odonno]

Sounds good to me.

[deltakosh]

Ok closing this one and opening a new one for MDView (#300)

[Odonno]

Had an idea today. I don't know if it's feasible but why not a RuntimeDataTemplate, with a possible RuntimeDataTemplateSelector ?

I mean, imagining I have a ListView and each element inside of the list is pure HTML. I can't bind to a simple DataTemplate since the template is variable (based on the content of the HTML). So, a solution could be an HTML to DataTemplate renderer that will be created dynamically inside the DataTemplateSelector.

What do you think ?

EDIT : Of course, JavaScipt is banned and CSS is not really considered.

[hermitdave]

You'd still need templates to render specific html types. How would your handle nesting of html tags. It's a can of worms IMO unless you can define a strict behaviour

[Odonno]

In my opinion, I think it should be flexible. I mean, a <div> should be a Grid, or maybe the content that contains class="row" should be a Grid. That's entirely up to you to define the behaviour.

Maybe there could be a default behaviour and then you can extend or rewrite the entire generation.

[deltakosh]

I'm still convinced we should not try to parse HTML but instead concentrate on MD parsing

[Odonno]

Or maybe both. :)

You're right, we should try first with MD, and if it works, then try HTML.

[andrewleader]

+1 for both, I've needed something for HTML before (when I wrote a Craigslist app), and I ended up writing my own HTML -> RichTextBlock. There's definitely sometimes a need for lightweight simple HTML -> native controls translation.