32 posts tagged with "Conversion"

The questions: the opt-in --share flow sanitizes each conversion into a structural-only JSON and POSTs it to a Google Form. (1) Will an external developer's AI agent send us something we can actually use to improve the converter? (2) What's the right consent cadence — does it send cumulatively or per bug; does one "yes" cover the rest of the site; and is it OK to keep asking after a "no"?

The question: the Site Converter is deterministic, so an outside AI agent will hit cases it can't map. Will that make the agent ship a half-baked site? And to fully convert, should the agent fork the converter (or keep a custom converter folder/hook) and report its changes?

The question: when an agent creates a new shortcode, how does it choose where the shortcode lives — and should it ask the user how they want to install / distribute it (child theme vs an uploadable zip they can hand out), or just decide?

The question: the spacing scale (unysonplus_default_spacing_scale()) has no 32px or 40px step — the range 24→48px is one gap — so the Site Converter, which snaps a source's captured padding to the nearest slug, rendered e.g. a 40px bottom padding as 48px (up to 12px error). Should we renumber the whole scale to Tailwind numbering (pt-8=32px, pt-10=40px…) to fill the gap, or keep the scale and add arbitrary values (pt-[40px])?

The question: a decomposed element carries styling a shortcode has no option for (a heading's font-extrabold leading-[1.1], a paragraph's md:text-xl text-foreground/70). The Special Heading shortcode — and every shortcode's Advanced tab — has a CSS Class field. Rather than synthesizing Custom CSS for each effect, why not just put the source's own utility classes in that field and let the section's carried CSS render them? Isn't that cleaner and more editable?

The question: the wc_products (Products) element controlled a product card three overlapping ways — a Classic/Slot "Card Layout" dropdown, a column of per-element show/hide switches (Price, Rating, Rating Number, Short Description, Quick View, Add to Cart, Wishlist, Stock), and an editable Card Rows slot designer. Do we keep all three, or is one model enough? And with the fixed "Classic" markup gone, where should a card's visual skin (border, corners, shadow, hover) come from?

The question: the converter kept producing sections with the wrong spacing, a missing overline color, a dropped background. One proposed fix: extract all of Tailwind's official utility classes (a finite, canonical set) and selectively pre-map each to a shortcode option, so coverage is "complete" and we stop missing things. Is that the right primary mechanism, or a regression to brittle class-name parsing?

The question: while reproducing a source site, the converted output had many small misses (a button missing its shadow-lg, a pill rendered as a plain <span>, borders and paddings off). The fast instinct is to hand-fix that one site — nudge misc_custom_css, tweak a preset value — until it matches. But should the AI hand-patch the output, or should every fix go into the deterministic Site Converter so it produces the correct result on its own?

The question: we already decided the converter's job is to fix the algorithm, not the output. But in practice, when a build hits a section the converter can't map yet (e.g. a WooCommerce product grid), what is the exact, repeatable iteration — and when do you actually write a recognizer versus just hand-build it?

The question: to make a demo's animation flow match a heavily scroll-animated reference site, do we bake the continuous "camera ride" into one pre-rendered video / frame sequence that scrubs with scroll (the way the reference site itself does it), or do we keep every card, device screen, image and line of copy as a live page-builder element and drive the camera moves with scroll animation over an optional decorative backdrop?