XPost: alt.comp.os.windows-11, alt.comp.microsoft.windows   
   From: mariasophia@comprehension.com   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)