Why we need access to body? First thing, it is programmatic access to setting and unsetting event handlers. It was extremely convenient to do it from the markup on a hash-routed website with a lot of views, especially if you want to map keyboard input for each route/view. Another indispensable use case was to handle setting properties and hints for different screen readers. Some screen readers or accessibility tools effectively have their own mark-up formats, and dom addons, so effectively you have to develop a website for a certain browser set, AND, a specific screen reader. Being able to programmatically set classes, lang, dir, and metadata properties (SEO meta, hints for ecommerce search engines) with router mounted on body was quite convenient too. Finally, having document.body DOM object being rewritten from Vue's DOM also worked well with routable sites where a view/route has a code that does something to the body DOM object that is specific to that route AND/OR a reactive data in it. I'd say, this is the most hard thing to implement when the upstream code from Vue and 3rd party Vue modules has no awareness of such possibility.

A follow up on my previous question that Phan answered, Phan, do you think I am not aware of the issue with too much code always competing for the document.body? Dan Abramov gives amateurish reasoning on the issue in the article you linked. Do not read his stuff. A lot of shoddy written third party code competes for document.body or the body sting content, and you always have to rewrite code that runs into conflict while doing so invariably of how you use Vue on the page. In our case we need to do that. We have complete control over 3rd party code, and we rewrite stuff that misbehaves. How to get in touch with you guys outside of AMA?

Hi, I'm checking again on using Vue in production for a client. The upstream Vue version deliberately fails mounting on the body element (el === document.body || el === document.documentElement && fail or something like that). Yes, Vue 2.0 does replace the element it is mounted on, but there is nothing DOM uncompliant in replacing the body, even while this will often fail due to browsers trying to close runaway tags, or 3rd party code doing the same. I insist on re-enabling mounting on the body element as a very useful thing. When trying to do SEO friendly SSR on our previous projects with vue 1.x, we were very pleased how well it worked with routing. On client-side, routed body element worked like magic to automate things like event listener attachment, setting ARIA attributes according to page content, lang or text direction properties, or changing contextmenu attribute when it was still a thing. I tried to remove the check and use vue 2 on our past projects, and so far, nothing breaks. The few 3rd party scripts that rewrite the body as a string have to be removed and rewritten for use with an SPA anyways.