Custom field rendering in modern list views

Danny, what you are proposing is what we are planning on building.  Through a stable API, we plan on making available the DOM elements that contain list view fields, so you don’t have to search for specific elements via ID, attribute, etc.  Once you have the DOM element, you should be able to do anything you want to it.

The reason we talk about this work in terms of “scenarios” is because we plan on being pretty selective about which DOM elements on modern pages that we support being accessed and manipulated in this manner.  We will start with a small set and enable more and more as time goes on, based on feedback from the community about the customization scenarios that are necessary.  The reason we’re doing it this way is because we want to guarantee these customizations will work going forward as we evolve our UX. 

We are aware that once we give developers the ability to place custom code on pages in SharePoint, the developer has access to every DOM element on the page, not just elements that we provide through our stable API.  However, we don’t guarantee good results if you take advantage of this; these customizations tend to break when the product team makes changes to the out of the box pages and controls.  This is really nothing new – it has always been the plight of the SharePoint developer.  The difference is that today, we’re trying to give developers better options in the form of scoped APIs that allow you to create customizations that are robust against future product changes.  If the scoped APIs don’t do what you want right away, you can either give us feedback and we’ll try to build the right APIs in the right order to address most common needs, or you can try to do things the “old way” with all the known caveats.