Re: PSA: HTML fragment mode interaction between Chromium, Clipboard & Notepad++

Doing my part to ignore insults from those who can never add value,
but who feel desperate to post something (anything!) for some odd reason,
the summary below explains (to the best of my knowledge) what happened.

The problem has been solved (see the recent detailed Notepad++ macro)
but this article below attempts to explain why Firefox doesn't cause this.

Only Chromium.

Hmmm.... 

I wondered why this problem of pasting into Notepad++ (which I've fixed
using a macro that adds a space & then removes it) doesn't happen with my
Firefox pastes. It only seems to happen with my Chromium pastes.

As Carlos, Andy & Paul astutely and helpfully noted, apparently Microsoft
systems place HTML fragments into the clipboard simply because the Windows
clipboard architecture is designed to support multiple parallel
data formats for a single copy operation. Hence, modern applications such
as Chromium use this capability to provide rich content to any target
program that can consume it (Notepad++ not being one of them, I guess).

It was known to Paul, Andy & Carlos, but not to me, that when Chromium
copies a selection, it generates both a plain text stream and an HTML
Fragment block that follows the Microsoft HTML Clipboard Format
specification. 

This specification requires StartHTML, EndHTML, StartFragment, and
EndFragment offsets so that applications can extract only the visible
portion of the Document Object Model (DOM).

What's a DOM? I don't/didn't know, but I looked it up and it seems to be
the word they use for the internal tree structure that a browser builds
after it parses an HTML page. So why Chromium and not Firefox then?

It turns out that Chromium and Firefox handle clipboard HTML in different
ways apparently because they were built on different internal models for
selection, rendering and data transfer. The relevant point here is that
Chromium always generates an HTML Fragment block when copying from a web
page because its editing and selection subsystem is based on the WebKit and
Blink design, which treats every selection as a range of DOM nodes that can
be serialized into both plain text and HTML.

This behavior was inherited from the original WebKit clipboard code and
was kept for compatibility with Windows applications that expect rich
HTML on the clipboard. 

On the other hand, Firefox uses a different clipboard pipeline that
was originally built around XUL and the Gecko editor and it only emits
HTML Format when the selection contains markup that Firefox considers
meaningful. Hence, as this problem only happens when I copy from
Chromium-based browsers, in most cases Firefox emits only plain text
because its selection serializer is more conservative and does not always
generate a full HTML Fragment block. 

On the other hand, Chromium always emits HTML Format because its design
goal is to maximize fidelity when pasting into applications like Word or
Outlook, while Firefox focuses on correctness and minimal output. 

Who knew?
Not me.
Now I do.

As a result, Chromium produces these problematic HTML fragments far more
often than Firefox does, even when the user sees no visible formatting.
-- 
On Usenet, people help others out of their kindness and generosity.