WYSIWYG Web Builder is a visual website authoring program that turns a project of pages and placed objects into HTML, style sheets, images, scripts, and other files for a web server. You build with text boxes, images, menus, galleries, forms, and layout containers on a canvas instead of writing every page by hand. The page names in Site Manager become the published HTML file names, so changing a project page called index affects the site’s main entry file. WYSIWYG Web Builder changes the site files it publishes; it does not become the hosting service or remove the need to test those files in a browser.
Canvas and layout
The canvas supports two different layout ideas. A fixed layout places objects at exact coordinates and preserves that arrangement at the width for which it was designed. It feels closest to arranging items in a desktop publishing program. A flexible layout places content inside layout grids, Flexbox containers, or Flex Grid, where columns and objects reflow as the browser width changes.
That choice affects the whole editing process. A fixed desktop page does not become phone-ready merely because every object fits on the canvas. WYSIWYG Web Builder needs breakpoints for alternate widths, or the author must rebuild the page with flexible containers. Browser preview remains necessary because font rendering, long menu labels, and embedded media can occupy more space than the editor suggests.
Breakpoint views
A breakpoint is another view of the same page at a selected width. WYSIWYG Web Builder lets each view change an object’s position, size, visibility, font, and other supported properties while keeping the underlying content connected. This makes it possible to move a menu, reduce a heading, or hide a decorative image on a small screen without creating a separate mobile site.
The shared-object rules require care. Deleting an object while a breakpoint is active removes it from every breakpoint, so the correct action for a mobile-only omission is Hide in Object Manager. An object created inside one breakpoint also starts hidden in the other views. Authors must unhide it where it belongs. Objects can belong to only one layer, form, carousel, tab set, accordion, or dialog across all breakpoints, so moving an object into a container can alter its relationship in the other views.
Shared page parts
Master pages hold elements that repeat across the site, normally a logo, navigation, header, and footer. A content page selects the master through Page Properties and displays those common objects behind its own content. The footer moves down when the content page grows, which avoids copying and repositioning the same footer on every page.
A master-page correction reaches every dependent page, but so does a mistake. Renaming a menu target, removing an object, or changing a shared header can affect the entire published site after the next upload. WYSIWYG Web Builder therefore keeps master-page work efficient only when the author previews several dependent pages before publishing.
Forms and publishing
Form objects collect typed values, choices, uploads, and button actions. Validation can reject missing or malformed input before submission, while the built-in processor can send or store submitted values when the server supports the required script. A successful local preview proves the layout and browser behavior, not the server-side form path. Mail settings, script support, folder permissions, and the published form action still need a real-server test.
Preview generates temporary output for the browser. Publish writes selected pages to a local folder, an FTP target, or another configured destination. Uploading only the changed HTML file can leave a new image or script behind, while publishing to the wrong remote folder can create a second copy of the site. The project remains the editable source, so keeping its project file and assets matters even after the generated pages are online.
