Edit the template block of a .vue file from the browser

Only the template blocks. The scanner walks the file, finds each template element, and marks its interior as the one region that may contain markup. A script or script setup block is JavaScript and a style block is CSS, and neither is ever scanned for elements or written to. That is why a class name that also appears inside a style rule cannot be confused for a class attribute, and why nothing PortBay does can reach your component logic.

Yes, and this is the concrete advantage of an SFC over a JSX file. In markup, a capitalised or dotted tag is a component and nothing else, so the scanner can stamp the usage site safely. That means an element rendered by a child component still traces back to the line where you used it. In a .jsx or .tsx file the same tag shape can be a TypeScript generic parameter list, so that tier is dropped rather than guessed at — a real difference between the two lanes, and the reason a Vue project maps essentially everything you can click.

Bound attributes are refused by name, not silently skipped. If you drag a new image onto an img whose src is written as :src, v-bind:src or a shorthand from another framework, PortBay tells you the src is bound dynamically and that the URL in the source is not the URL the browser will request. Writing a literal over the binding would break the binding; writing to the bound expression would need to know where its value came from. Saying so is the finished answer, and the change belongs in the data.

No, and it says which rule it hit: a text run holding braces is a template expression, so PortBay refuses it and points you at the source rather than rewriting bytes that hold a binding. Static copy in the same template edits normally. There is a related detail worth knowing in the other direction — when PortBay has to write a literal pair of braces into a Vue template, it writes them as HTML character references, because Vue's tokenizer scans the raw source bytes for its delimiter and never decodes an entity first. The browser decodes it and the visitor sees the braces.

Not into your style scoped block. A style change becomes a Tailwind class rewrite when the project uses Tailwind and the utility would genuinely win the property — the editor checks that first, because adding a class that a more specific rule in your own CSS already outranks would change nothing on screen. When it would not win, the change goes to a PortBay override sheet and you get a notice saying so. The one thing that never happens is a change reported as saved that renders no differently. Design tokens are a separate and stronger lane: renaming a Tailwind token in your v3 config or a v4 @theme block rewrites every class reference to it across your markup in one save, spliced byte-for-byte so the rest of the file's formatting is untouched.

Nothing to install for Vue on Vite. The stamping plugin lives inside the PortBay binary, is written out to PortBay's own data directory, and reaches your dev server through a config generated outside your repository — uninstall PortBay and your package.json, lockfile and node_modules are byte-for-byte what they were. Nuxt is supported through its own injection path rather than this one, because nuxt dev takes no config flag, so PortBay extends it as a layer instead. Same plugin, same stamps, different seam.

PortBay's Vue visual editor is not a CMS. It edits the .vue files in your repository, which is the opposite end of the problem from the visual-editing products built around a content backend — those are good at letting an editor change words inside a slot and explicit that they do not open the components themselves. On price: the editor is a Pro feature, in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build. It attaches only to local .test hosts and refuses while a project is shared over a public tunnel. Everything else on this page — the hostname, the HTTPS, the dev server, the task board — is in the free app.