Which default table behaviour do you expect? Fixed Width or Automatic Width?

Hi, this is Henk. I'm a product manager on the Confluence Editor team and we've recently started working on making table columns resizable! See the JIRA ticket here: https://jira.atlassian.com/browse/CONF-3393 

We plan to introduce a new table "mode" with "Fixed Width Columns" and it will be possible to switch between the current, "Fluid Width Columns" mode and the new mode.

One question we've been wondering about: Would you prefer new tables to be created as:

  1. "Fluid" (like today, meaning the column resizes automatically as you add content), or as
  2. "Fixed" (meaning the table columns are a fixed width, but can be resized by clicking and dragging the cell borders) 

We'd greatly appreciate your feedback. 

Kind regards,

Henk Kleynhans | Senior PM - Confluence


39 answers

16 votes

I'd prefer a default of fluid, because it works fine for most of the stuff I write.  The ability to do fixed width would be very welcome for the times when fluid doesn't work for me, but that's maybe 20% of my tables at most.  I think the main reason for choosing fluid is that I don't want to have to think about column widths most of the time - I'd rather not default to having to adjust my columns for 80% of the tables I write.


  • I don't write huge amounts in tables, and I'd like to hear from heavier users.
  • My ideal implementation would be to have the default set in my profile, so I can set "fluid" and other people can choose "fixed" for themselves.

If fluid means that the column won't wrap until I tell it too, then that's fine.  I find that almost every new table currently creates the problem of wrapping things that I don't want wrapped, due to the page width.  I would prefer to choose which columns wrap and at what width.  This is especially true with the many small tables that I tend to create or maintain regarding contact information, financial figures, etc.

I would prefer the width to be fluid at time of creation, but stay fixed at time of edit.

Why not have a third option which is % so that the table remains responsive?


Fluid is the entire issue with tables right now - there seems to be no rhyme or reason as to how they auto-resize meaning I have columns in some of my tables that are 3 words wide and 20 rows long which is awful to read and makes the page unduly long. I'm shocked to see everyone saying "fluid" as this has been the issue on the JIRA ticket all along.

If "fluid" is the default, there must be the option to resize by clicking/dragging cell borders. 

Agree! All my tables look awful due to fluid re-sizing.

I understand where you are coming from but my thinking is that it would be best to have it fluid while you are adding info to the table and then be able to specify the widths once the table is populated. Having to specify fixed widths at the start when the table is created will just add an extra step as the widths are bound to need adjusting after you have populated the table.

That's a good point, Nick. As long as I have the option to manually redefine the widths, I'm happy with whatever the default is.

I agree - my personal preference is to default to fluid

I'd prefer a default of fluid too for the same reason as Nic.  I like his idea of being able to set a default in your profile.

Fluid as default would be preferable for most users, as usability will continue "as is" and extra format option is introduced for those who actually need it.

Resize feature is needed, but only in some cases. For most of the time current Confluence way to handle it is good enough.

2 votes
An Nguyen Atlassian Team Sep 14, 2015

I wonder whether it is necessary to have 2 modes and allows switching mode.

As I see, "Fluid" is what we have in MS Word. and "Fixed" is being in Google Drive (if I remember correctly). However, from developer's point of view, I think it would be better with "Fixed" mode and "wrap" or "pre-wrap" whitespace.  "Fluid" mode will give us more table's behaviors to take into account and make the UI a bit unstable and things will get more complicated when we have more features. One question should be "is it worth to do that?". 

Since customers like to have more control and so do I. I vote for "Fixed" mode, simple and sufficient.

Fluid as a default.  

It follows the principle of "least surprise" as that is what everyone is used to while "fixed" sizes are available to those who'll need the additional functionality.


  • However, it should never break in the middle of a word or a non-breaking space.

I also agree with previous posters that we should have a min/fixed/max width options.  %'s would be great, but the min/max/fixed options along with never breaking in the middle of non-whitespace would cover all my needs I would think.

I would prefer the functionality to match MS-Word's implementation of tables as closely as possible. i.e. "Fixed" (meaning the table columns are a fixed width and you need to manually resize the columns, by clicking and dragging the cell borders) 

I would also prefer the fluid mode as default.

I like fluid as default as well. When a table is being quickly produced its just one less thing to think about. And in many cases, speed (for default options) is king.

That being said... we have a large Confluence implementation touched by thousands of users and its when a table is in a space open to all of our employees that the refinement of fixed width columns would be most welcomed. Looking forward to this being implemented.

Also, liked the idea of posting this question out on Answers as we're all not necessarily plugged in to feature requests that we have interest in. This new table feature will be most welcomed! 

An additional comment from one of my 'power' Confluence users, is a request to add a table property to suppress the table border display. This is helpful when one of the 'Page Layout' options does not quite fit a preferred layout requiring say 3 columns of differing widths or more than 3 columns. A table with defined widths could fill in, but having borders could get in the way.

My vote: default to fluid.

also, I hope that there can be a combination of fixed columns and fluid columns within a single table.

Fixed. My use-case is text-dominated tables where one column, typically, will contain very little text. That works well. But as soon as you have a single "text-heavy" cell in the "text-light" column, the whole table re-sizes and it looks dreadful. 

I would prefer the fluid mode as default. But this depends on how the fixed mode will be implemented. If the fixed mode will be implemented using absolute values then i definitely vote for the fluid mode. If the fixed mode values are relativ then i say, i don't care as long as it works.

Fluid because I am worried about the way the "fixed" mode will be handled by the PDF exportation...

I vote for "fluid" staying the default behavior. We definitely need option to set width (in some cases px, others %) for some of the columns, however, majority of tables don't need these explicit settings, so it would be great to have ability to set target width as an option but not as a rule.

Fluid as default. But please make sure to support relative AND absolute values for the cell width.

Great to see that this feature is eventually been worked on.

Default - fluid (as is) with option to manually overwrite.  As per previous posters, the larger % of times the auto-sizing does the trick, it's having the power to set min/fixed/max widths on the rarer (but super important) occasions


I would vote for fluid as the default.  I'd also vote for three options on the column: %, fixed, and none as options.

Story: As a table creator, I would like to be able to fix the width of one or more initial columns that I do not want to wrap, and reserve all remaining space for a final column so that I can create key-value style definition tables where the key(s) never wrap and the values column uses as much space as possible.


I vote for fluid by default. 

I think it would be great as a user preference, so I can set my pages to fixed but other users would be set to Fluid.

If I couldn't have the above option I would vote for Fluid and I would set the ones I needed to be set afterwards.

I also vote for "fluid" by default since this is what people are used to and it works for the majority of tables.

Regarding "fixed" mode, could you clarify if the resizing options mentioned (dragging column borders) are available in edit mode only or can people viewing the page also resize the columns to work for them?  Changes in view mode would not affect what others see, but could be stored for that person or for that browser session.

Another question about "fixed" - do you plan to provide some sort of page sizing options (sort of like page view in Word) or a ruler of some sort?  If you are trying to make a table that is formatted nicely for printing, this would be handy.

For me, a percentage mode (not typing in a percentage which is awkward, but dragging as described) would be quite handy in terms of having the table adapt to different screen sizes while still maintaining a nice ratio between column sizes.  So the table would work much like fluid mode, but the ratio between columns would be adjustable.  Presumably in fixed mode the table maintains a fixed size and side scrolling must be used to see all columns on smaller screens.

I do not like idea of 2 table types. It's too complicated for such simple thing as table. Maybe we can have one table type that behaves as fluid and fixed: - After adding all columns are fluid. - when I drag a border column at left becomes "Fixed" and all other are still fluid. googled and looks like it's supported by css: http://stackoverflow.com/questions/12641104/css-table-columns-width-fixed-dynamic30-dynamic70-fixed

@Volodymyr Krupach Speaking from a non-technical point of view, I was making the assumption when adding my own opinion below that default should be fluid (because it's the fastest option for informal, smaller tables), that changing it to fixed (perhaps better for more information-rich tables accessed by more users where more display refinement would be optimal) would be a relatively simple and seamless process. It must be easy and intuitive to be able to 'change states' between fluid and fixed in my view, perhaps via context-sensitive menu choices

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 12, 2019 in Confluence

Confluence Admin Certification now $150 for Community Members

More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...

1,485 views 4 13
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you