Native Elements in a Visual Page Builder
There are two ways to put a beautiful page into a website builder. One is to paste a large block of finished code into a single custom element. It looks perfect on day one. The other is to build the page from the builder's own elements: sections, columns, headings, text, images and buttons that the builder understands and can edit.
On our platform, VoVo, we choose the second way, for our own sites and for imported sites. Here is why it matters and how we make it practical.
Pasted code is a trap
A page made from one block of pasted code cannot really be edited in a visual builder. Changing a heading means finding it in a wall of markup. Swapping an image means editing an attribute by hand. Moving a section means cutting and pasting code. The organization that owns the page becomes dependent on whoever wrote it.
Pasted code also escapes the builder's protections: responsive settings, theme colors, accessibility checks and revision history all work best when the builder understands what it is looking at.
Native elements stay editable
When a page is built from native elements, every heading, paragraph, image and button can be selected and edited in place. Styles can be changed with the builder's controls. Sections can be reordered by dragging. The page responds to the site's theme, so a brand color change flows through. And every save records a revision.
That is true whether a person built the page by hand, a script published it or an importer converted it from another platform. Our importers target native builder elements rather than dropping whole pages in as code.
Reusable blocks
Building from native elements also makes reuse easy. A section that works well, such as a hero with a headline and image or a grid of features, can be saved as a reusable block and inserted on other pages. Our platform provides a catalog of supplied blocks for every organization, and organizations can create their own.
When we rebuilt this website, we saved our signature sections as reusable blocks with names that start with "Jag," such as Jag Hero, Jag Feature Grid and Jag Contact Panel, so future pages can use the same design without starting over. Supplied blocks are protected from accidental edits and deletion, while organizations can duplicate them and customize their own copies.
Live content elements
Some parts of a page should not be fixed at all. A list of the latest blog posts should update every time a post is published. A contact form should be the real form, connected to submissions and notifications. For those, the builder offers live elements: a blog posts element that renders the newest articles when the page is viewed, a form element that embeds a real form and others.
Using live elements means pages stay current without anyone remembering to update them. The home page of this site uses the blog posts element, so it always shows the newest articles.
Styles that belong to the page
Each page keeps its own styles alongside its content, so the builder's editing canvas and the live page look the same. Site-wide pieces that the builder does not render, such as the header and footer, use the site's theme and custom code settings. Keeping those layers clear avoids the frustrating situation where a page looks one way while editing and another when published, which we describe in CSS cascade layers and our page builder.
Animations without custom scripts
Motion is available as a native option too. Elements can be given entrance animations from the builder's own set, with delays, and the platform loads the animation helper only on pages that use it. Owners do not need custom scripts to make a page feel alive, and on this site those animations switch off when a visitor asks for reduced motion.
Frequently asked questions
Why not paste custom HTML into a page builder?
Pasted code is hard to edit visually, escapes the builder's theme and responsive controls and makes the page dependent on whoever wrote it.
Can I reuse sections across pages?
Yes. Sections can be saved as reusable blocks and inserted on other pages, and supplied blocks are available to every organization.
Will my blog post list update automatically?
When you use the builder's blog posts element, the list renders the newest published articles each time the page is viewed.
Related Posts
Writing Error Messages People Can Act On
An error message is often the moment someone decides whether to keep trusting software. Here is how we write messages that explain what happened and what to do next.
Brand Colors as Tokens: Keeping Every Customer's Brand Intact
Every organization on our platform has its own look. Here is how theme tokens let each site keep its brand while sharing the same building blocks underneath.
Consent First: How We Handle Email and Text Message Permissions
Sending messages people did not ask for damages trust and breaks rules. Here is how our platform treats consent, unsubscribes and suppression as features, not fine print.
CSS Cascade Layers and Why Our Page Builder Depends on Them
A heading that is white in the editor and dark on the live page is a cascade problem. Here is how CSS cascade layers keep our page builder's styles in charge.
Designing AI Features That Refuse to Invent Facts
AI models are confident even when they are wrong. Here is how we design AI features to work from approved sources, admit gaps and hand off to people instead of improvising.
Comments (0)
No comments yet. Be the first to share your thoughts!