But why would you expect to use WebKit to render rich text? If using an HTML/CSS/JS renderer to render text is "completely appropriate", what isn't appropriate for it? Why would you not render everything with it?

I don't understand how you go from "rendering text is completely appropriate" but then "rendering everything is ridiculous".

▲

mrbombastic 4 hours ago | parent | next [-]

a bit of a roundabout way to answer this, but i think most native devs are okay with a self contained app element using webkit, that is what it is there for and generally stuff like rendering html, markdown, a one off static page, it is just a view from UI perspective. When things get more interactive, have a navigation hierarchy, animations etc are when things start to diverge from native feel and performance and you have gone too far.

▲

p-e-w 5 hours ago | parent | prev | next [-]

> But why would you expect to use WebKit to render rich text?

Because rendering rich text correctly and consistently is one of the hardest problems in software. Bidirectional text, a million glyph shaping complexities, mixed content such as inline images and different text sizes, reflow that should take milliseconds, natural-feeling selection, etc etc.

No implementation comes even close to browser rendering engines in covering all of these.

▲

Wowfunhappy 5 hours ago | parent | prev | next [-]

I mean, this is why I think PDFKit is a good comparison. Could you render your app's entire UI as a series of PDFs? Absolutely! Should you do that? Uh, probably not. You should use the native controls Apple gives you for buttons and dialogs and input fields and so on.

But WebKit is the native UI for HTML, and Markdown is intended to be transpiled to HTML.

▲

stavros 5 hours ago | parent | next [-]

It's irrelevant what Markdown was meant to be transpiled to. When people say "Markdown support" these days, they mean "rich text support", since Markdown is actually just ASCII. It is ridiculous to need a Web renderer to render rich text, on any platform. Even terminal emulators can do it.

	▲	4 hours ago \| parent \| next [-]
		[deleted]
	▲	Wowfunhappy 5 hours ago \| parent \| prev [-]
		HTML is basically analogous to RTF, no?

▲

carlosjobim 4 hours ago | parent | prev [-]

If think that the MacOS GUI is actually entirely rendered as a series of PDFs, if I have understood things correctly.

▲

jonhohle 4 hours ago | parent | next [-]

That’s how it originally worked, but Apple has moved away from PDF to other native GPU frameworks for drawing. Now window content is stored as bitmaps instead of redrawing vector instructions.

▲

mpweiher 3 hours ago | parent [-]

That's not how it ever worked.

Quartz is a vector drawing engine whose output can be captured as a PDF and which is closely aligned with the PDF imaging model.

Window content was always stored as bitmaps.

	▲	jonhohle 2 hours ago \| parent [-]
		You’re correct. I meant to say textures, but even that isn’t completely accurate. AppKit used to generate the bitmap directly through CoreGraphics (PDF model). Now it uses Core Animation and Metal and no longer draws the bitmap directly.

▲

mpweiher 3 hours ago | parent | prev [-]

You have understood things incorrectly.

▲

joenot443 5 hours ago | parent | prev [-]

> what isn't appropriate for it?

It'd be very silly to render a shader pipeline in WebKit. You could, but with Metal sitting right there, it would be silly.

	▲	stavros 5 hours ago \| parent [-]
		If we're all agreeing that all the native elements are useless, I can see how the question is "do I use Metal or do I use WebKit", but my question wasn't about WebKit vs metal, it was WebKit vs native elements.