Textarea breaks layout easily

Textarea input has no resize: none CSS property set, so I’m able to resize it as much as I want.

It’s usually not what I want to because it will definitely break a website’s layout. Just try resizing “address” textarea on this demo page.

At least it should be locked horizontally and limited vertically.

[dgennetten]

@alansouzati I think an excellent companion post to follow the above would be to take this Textarea resize issue and make it into a well-written tutorial that all can learn from.

[alansouzati]

so, if there is resize={false}, why not transform it to resize=“false” and have a resize=“horizontal” and resize="vertical? Maybe just pass it straight up to CSS, that’s even simpler. And this is the point where I’m not sure whether we should be recreating the whole CSS as Grommet components’ props.

Yes. I think it is a great idea to have resize={true | false}, resize='horizontal', and resize='vertical'.

You are raising a very good question, that probably deserves a blog post or something. This is key to understanding grommet. So, let me explain here first and then later I will wrap this up in a post.

There are a few places in Grommet that touch styling one way or another.

1. The theme object

Properties inside the theme affect all instances. You also might be asking how we decide to put things in the theme or not. That decision is on a component-by-component basis. Take Anchor for example. A common CSS property used in anchors is textDecoration and, when used, you want to apply that in all your anchor instances, otherwise your app is going to look inconsistent. This feels a great property to live inside theme.anchor and not as a property to Anchor. As a result, you will not see <Anchor textDecoration='none' />. For customizing our components beyond the properties we added in the theme you can always rely on the extend functionality (e.g theme.anchor.extend, theme.anchor.hover.extend).

1. The component props

The properties in our components are defined also based on a need basis. Using the anchor again as an example, we found the need of icons and labels, and logic to have them reversed. Or using just the icon, or just the label. We started as small as we could, and we are open to adding more properties for as long as we see a good use case for it. Your resize example was a great one where it is totally possible for a given TextArea to allow resizing whiles others don’t. This does not make sense to live in the theme, since it can change for different instances. It is also common enough that deserves a dedicated prop to it.

Another great example of a prop that affects style is the truncate prop in Text. I often find people adding this boilerplate everywhere:

  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;

we find it easier to do as follows:

<Text truncate>...</Text>

Conclusion

The decision where to put things is done based on interpreting the needs of each component. We are open to the suggestions from the community when to add new props or not, and where to add them. It is strongly advised to stick to the properties, avoiding the use of style. This feels like going in your own route and forgetting about the component’s initial intentions. We are totally open to try and understand why you think Box and Grid properties are not clear. This would help us understand the changes we need to make in order to have you drop style. Of course this is your decision, if using style feels more natural to you, go for it. I just think it is harder to make things reusable that way, while still leveraging the theme entries.

Finally, in certain situations, I find the CSS syntax for grid and flexbox very complicated to interpret. Let me show you an example:

.my-grid {
    display: grid;
    grid-template-columns: repeat(12,minmax(auto,1fr));
    grid-column-gap: 24px;
}

Whenever I ask someone new to css grids to explain me what this piece of code is doing, they cannot explain it, especially repeat(12,minmax(auto,1fr)).

I’ve had more success asking them to explain and interpret this:

<Grid columns={{ count: 12, size: 'auto' }} gap='medium' />

This is almost self-explanatory: a grid with 12 columns that has a medium gap. Of course you can always do the pixel values:

  <Grid columns={{ count: 12, size: 'auto' }} style={{  gridColumnGap: '33px' }} />

But I see problems with this:

1. Using pixels values will lead to inconsistencies in your app
2. Using pixels values will make it harder to change things in the future
3. The code looks more verbose

I hope this helps you understand where we are coming from. And, of course, we are open for feedback.