Add a way to force an inline field onto a new row

[andyearnshaw]

Quite a few times I've wanted to have my inline fields be in 2 rows of 2 columns, or a row of 2 columns and a row of 3 columns, but there's no way to specify this in the API. For example (using discord.js):

const fields = [
  // Group 1
  { name: 'Solo Points', value: soloPoints, inline: true },
  { name: 'Solo Rank', value: soloRank, inline: true },

  // Group 2
  { name: 'Team Points', value: teamPoints, inline: true },
  { name: 'Team Rank', value: teamRank, inline: true },
];

Discord will render Solo Points, Solo Rank and Team Points on one line, with Team Rank on the next line. I generally try to find creative ways around this, for instance reordering fields or adding a blank 3rd column for each (though this squashes the content up a bit). However, there are times where I can't get such a workaround in.

Can we get some kind of implementation that allows us to specify where inline fields should break? Could be either a new property:

  { name: 'Team Points', value: teamPoints, inline: true, newInlineRow: true },

or a different kind of field:

  { inlineBreak: true },

[msciotti]

After messing around with this a bit, this is annoying 😁 Appreciate the note

[andyearnshaw]

Side question, out of interest: has any consideration been given to adopting an open standard to give devs more flexibility over the appearance of embeds? Adaptive Cards looks pretty interesting, especially the latest version which supports templates and, since it's supported by Skype and WebEx Teams, making a multi-platform chat bot would be much easier.

[ghost]

Why not just implement a 3-wide grid like bootstrap/skeleton.css does, but with less columns?

You can then add optional new fields to embeds that let you specify column span. That way you can just stack a list of fields like you would cols in the bootstrap/skeleton system, and it will still arrange itself.

All you'd need to supply is a new optional span, and to make field names and values able to be whitespace/empty, and you'd be able to arrange embeds how you like while keeping backwards compatibility for the most part and enabling embeds to remain mobile-friendly on thin devices.

[andyearnshaw]

I'm not sure span would solve the problem if the maximum number of columns is 3, because you'd have to support non-integer values to have 2 columns with equal width. At which point, you may as well just have a field for specifying the proportion of space the field takes up horizontally (e.g. 1fr, 2fr, etc. in CSS values).

[ghost]

I'm not sure span would solve the problem if the maximum number of columns is 3, because you'd have to support non-integer values to have 2 columns with equal width. At which point, you may as well just have a field for specifying the proportion of space the field takes up horizontally (e.g. 1fr, 2fr, etc. in CSS values).

That concept would also work, and was somewhat what I was trying to get at (albeit with poor CSS knowledge)

[Lachee]

I would really prefer the Adaptive Cards solution if they are going to rework the embeds. Developers have been wanting new ways to interactive for a while, like buttons that slack has for example.

If I remember correctly, reaction buttons are not a intended use case, so these cards would be a way better solution.

[ghost]

I would really prefer the Adaptive Cards solution

good time to make use of that type field :-)

[Lachee]

With the latest blog referring to new interaction features that maybe coming to bots, I would really like to drive home that Adaptive Cards would be an excellent solution. Their formatting options are bountiful with support of way more complex designs with fairly straight forward JSON, even collapsible cards.

They not only allow for more customisation in formatting, but allows for more interaction with actions. These actions would really bring Discord's bot support way up there and avoid having to use reactions for everything.

[noolaan]

You can do a hacky fix to do this by applying an "empty field" after the second and (optionally) the fourth entry (to align the four fields vertically).

{
   name: '\u200B',
   value: '\u200B',
   inline: true
}

Unfortunately the empty spaces might shrink stuff, but if you have small titles/values it shouldn't be much of an issue.

[MHooijberg]

So has this feature been implemented yet? its been a year

[Ryubal]

No news for this feature?

[Titouan-Legend]

Couldn't we change the way inline works by making it a line break instead. We could have all the fields default to inline, and then manually specify when the fields should be going to the next line.
So when you specify for example
line_break = True
The current field goes to the line.

[johnaqu1no]

instead of an array full of fields, maybe an array full of rows with fields within it.

Old:

[
  {
    name: "field1",
    value: "value1",
    inline: true
  }
]

New:

[
  // Row #1
  [
    {
      name: "field1",
      value: "value1",
    },
    {
      name: "field2",
      value: "value2",
    }
  ],
  // Row #2
  [
    {
      name: "field3",
      value: "value3",
    },
    {
      name: "field4",
      value: "value4",
    }
  ]
]

It may be messier but it gives a whole lot of flexibility on deciding which row gets which field.

[johnaqu1no]

Each field within a row is defaulted to have an inline, but you could add an inline parameter in the row but that wouldn't make total sense.

[NovaFox161]

I believe a more elegant solution to the above suggestion, would instead be an optional content object that contains the field's data with no content being essentially a "linebreak"

[
  // Row 1
  {
    content: {
      name: "name",
      value: "value"
    },
    inline: true
  },
  {
    content: {
      name: "name2",
      value: "value2"
    },
    inline: true
  },
  // line break
  {
    content: null,
    inline: false
  },
  // row 2
  {
    content: {
      name: "name3",
      value: "value3"
    },
    inline: true
  }
]

This allows the discord client to remain responsive and fit things on a single row if able to, while not massively complicating the structure of the json into n number of rows when the device it is rendered on does not allow fitting everything in a row array on a single rendered row. But also allows developers to style embeds by defining directly how they wish the embed to be formatted if enough room exists.

[InFiNiTy1234568]

That ends up looking terrible on mobile.

There are gains and losses

[InFiNiTy1234568]

Also uses up your 25 limit on fields

i don't understand why you need that much fields, but okay, whatever, I'm into changes to this way

[bsian03]

The point that is being made is that it would be great if it was possible to do that without the need of having blank embed fields

[InFiNiTy1234568]

The point that is being made is that it would be great if it was possible to do that without the need of having blank embed fields

But even without blank fields, this change would not fix mobile embed displaying problem

[bsian03]

Difference is there wouldn't be a massive gap in the embed on mobile

[0xAskar]

Is there still no fix? This seems simple enough to implement, adding a few new argument like newInlineRow or any of the other suggestions above would work.

here's my hacky solution:
so in discord embeds, the max num of cols is 3, so it forces a new row anyways, so you can just add a third embed with an empty field such as
embedResponse.add_field(name= "\u200B", value= "\u200B", inline=True)
which adds another field, but doesnt take too much space, and then make sure to add one as the third column in the second row or its going to make it look awkward

[meta-byte]

I would also like to contribute that It is difficult to format when I want three rows with two columns each since forcing inline to false means that the field is left by itself. A simple solution would be that inline false means that a particular field becomes column 1 on a new row. Then the following fields can still be columns on that row unless inline is set to false again in which case it will jump to a new row.

[Neoony]

Same issue here, first time doing embeds with bots :D

I guess I will have to settle with

{ name: ' ', value: ' ' },

Which creates a much smaller gap than

{ name: '\u200B', value: '\u200B' },

Comparison:

Would be nice to have some proper way of doing this with less space wasted. This "feels" like something is incomplete here.

EDIT: actually I rather found something I can put for the third field
(something useful, I dont really like the empty space on the right like the solution above)