# Dev Diary Ep36 - Powerful New Scroll Effects

**URL:** <https://forums.realmacsoftware.com/t/dev-diary-ep36-powerful-new-scroll-effects/44659>\
**Category:** Elements\
**Created:** [September 17, 2024, 10:32am UTC](https://forums.realmacsoftware.com/t/dev-diary-ep36-powerful-new-scroll-effects/44659 "2024-09-17T10:32:24Z")\
**Posts on this page:** 1\
**Showing post:** 49

<div class="post-metadata">

**Author:** ![anon68150607](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@anon68150607](https://forums.realmacsoftware.com/u/anon68150607)\
**Post date:** [September 17, 2024, 3:24pm UTC](https://forums.realmacsoftware.com/t/dev-diary-ep36-powerful-new-scroll-effects/44659/49 "2024-09-17T15:24:19Z")

</div>

> [@anon68150607](#):
>
> The way you’ve implemented many of these effects and features is baked into certain Elements (ie: grid items, flex items, etc ) and not available on others. This means that users have to remember which Elements/components they can access these properties on, and which they cannot. You’ve essentially created a frustrating puzzle where users try to fit random Elements together to achieve their goals. I’m also struggling to see how 3rd party components will fit into this jigsaw in any meaningful way.
> 
> The whole inspector is still just a never-ending game of whack-a-mole and “Where’s Waldo?”, and the constant refrain of “it’s so powerful and intuitive“ is getting old, especially as it doesn’t represent my experience using Elements at all.

I know I’m responding to my own post, but something that’s been driving me nuts with Elements is how it uses [TailwindCSS](https://tailwindcss.com/) but completely misses the fact that [Tailwind is built on a utility-first concept](https://tailwindcss.com/docs/utility-first), which enables you to add pre-defined utility classes and modifiers to _ **any element** _ in order to create custom designs without writing CSS. However, in Elements we have no way of applying these utility classes unless they have been included/exposed in the specific element/component you’re using, or you enter them into the Advanced → Custom CSS Classes text field, (ie. `py-8 px-8 max-w-sm mx-auto bg-white`).

This approach either requires the **duplication** of all common properties _for **every** element_ (_including_ custom elements), or (what we’re seeing) where every element implements only a few properties, and often in different and confusing ways (different labels, location, widget, etc).

I keep coming back to that the base elements, the _core building blocks_ of Elements, [should have an inspector similar](https://forums.realmacsoftware.com/t/elements-ui-ux-ideas/43943/9) to that of [Sketch](https://www.sketch.com), [Pages](https://www.apple.com/ca/pages/), etc. (if you’re going to be Apple/Mac only, then _lean_ into it) that enable users to add and remove utilities classes and modifiers in much the way we edit, add and remove background colours, strokes, fonts, etc in other applications. All of the base elements share a vast number of properties (margin, padding, colour, background, border, radius, etc - keeping in mind that they often have AND relationships, not OR, ie. multiple backgrounds, borders, etc.) with each other, and other elements such as Grid, Flex, Images, and Video have a few additional properties that are bespoke to them (columns, rows, gap, src, alt, etc).

Taking an approach like this would create a more intuitive, consistent, and useable interface, and allow custom elements to only focus on the things that make them unique.

---

_[View the full topic](https://forums.realmacsoftware.com/t/dev-diary-ep36-powerful-new-scroll-effects/44659)._