16 posts tagged with "Naming"

The question: The extension that turns Unyson+ elements into Elementor widgets is listed as "Elementor Widgets". Would it be better to name it just "Elementor", since more Elementor features may be added to it later?

The question: The product-name rule is about site conversion. Can the docs simply name AI products, tools, agents and WordPress plugins?

The question: we had a runbook for training the converter on a site and a separate one for fixing a converted site. Should they stay separate — different audiences, different permissions — or is that split the reason neither job ever gets finished properly?

The question: the gallery element launched under the name "3D Gallery". But is that the right name? Only some of its designs are actually 3D — and the roadmap makes that gap worse, not better. Should we rename it before launch, and if so, how far does the rename go — just the label, or the folder / tag / CSS / block underneath too?

The question: the Model Viewer's Scroll Choreography — pin the element in a fixed, transparent, z-indexed layer and drive its position, scale, rotation and opacity from the page scroll via keyframes, with an opt-in authoring guide — turned out to be the exact "kage-style" foreground effect people wanted for flat images, not just 3D models. So we ported the engine to a new image element. That raised three placement/shape decisions: (1) it's self-contained (its own runtime, no hard Animation-Engine dependency) and its closest structural sibling (Parallax Scene) lives in the shortcodes extension — so does it go there, or in the Animation Engine next to Model Viewer, its closest conceptual sibling? (2) Is "Scroll Choreography" the right element name, or should it be qualified? (3) The standard builder adds Styling / Animation / Advanced tabs only when a shortcode opts in — which of them make sense here?

The question: Is it better to make a design-decision permalink https://docs.unysonplus.com/block-enrichment-which-types-stay-core — flattened to the site root — instead of https://docs.unysonplus.com/decisions/block-enrichment-which-types-stay-core?

The question: The modern Div renders through utility classes like d-flex, flex-row, justify-content-center, align-items-center and fw-col-6. The unprefixed ones are literally Bootstrap's class names, and fw-col-6 apes Bootstrap's col-6 — so the output reads as Bootstrap and .d-flex even collides with real Bootstrap if a theme loads it. Do we rebrand the utilities (e.g. a new upw- prefix, or Tailwind-style names), and what do we call the column/grid utility?

The question: I want the "product reveal" effect — a visual that comes apart to show its internals on scroll / hover / drag. It shows up as several techniques (frame scrubbing, layered separation, true 3D). Do we build one clever element that switches between them, or separate elements? And what do we call the new one, given "explode" is only one of its motions?

The question: A typography overhaul this large can't safely be edited in place on the live control. How do we build and prove it without risking every site, and without leaving a messy v1 / v2 / v3 option-type namespace behind?

The question: qTip2 has been unmaintained since 2016, and we replaced it with Floating UI. The old implementation put its vendor everywhere — .qtip-fw class names, a 'qtip' script handle, $.fn.qtip(). Do we carry that naming over to the new library and call things floating-ui, or name them something else?

The question: The [newsletter] element already renders a form, validates a signup and emails the site admin — but nothing stores it. Building that storage layer means choosing a shape now that still works when campaigns, automations, contact timelines and Mailchimp/MailerLite/Brevo sync arrive. So: custom post type or custom tables? And once that is settled, how are lists, tags and segments modelled — because that is the decision that is expensive to reverse.

The question: As the AI Dev Kit grew, its root filled with a mix of hand-authored files and machine-fetched folders. Should the fetched/assembled folders be collected into one directory — and if so, what should it be called?

The question: The new Card Rows designer lives on a Card tab, but the reusable border/corners/shadow/fill preset you apply to that card is called Box Style (from Box Presets). That looked inconsistent — should we rename everything to one word ("Box tab / Box Rows", or "Card Box Style / Card Box Presets")?

The question: the compact rounded-label shortcode — sub-tag, message, leading/trailing icons, optional link — was called announcement_pill. It renders status badges, "what's new" hero chips, eyebrow labels and announcement bars. Is "announcement pill" the right name for it, or should it be badge — and if we rename, do we need a migration?

The question: every new content library (page-builder templates, then component presets, then icon packs) was about to get its own GitHub data repo. That felt messy. Can we put all library content in one repo — and if so, what actually has to stay split?

The question: UnysonPlus is a fresh restart of Unyson. The rich typography control shipped as typography-v2 while the original typography was a weaker, older implementation. Do we upgrade typography-v2 in place, or promote it to the clean typography name and scrap the -v2 suffix?