Bug in repeaters when using "fit to content in html": Height of row to does not adjust in rendered html, only inside Axure


#1

I’m creating af pretty standard table using a repeater. Some of my rows have fairly long titles, causing them to wrap onto more than one line. I then check “fit to content in html”. Inside Axure the result is then exactly as I want. Long titles causes a higher row.

However, once I go and build the prototype, this doesn’t work ind the actual html:


#2

This is one of those things that is effectively a bug, in that it doesn’t behave as most users (of Axure RP) expect and want, but is technically a “misunderstood feature,” in that it works as documented. :roll_eyes:

…Or then again, maybe it is a real bug… :bug: As I set out to demonstrate this I discovered I didn’t really understand what was going on, and after a long trip down a dark rabbit hole, I managed to come out the other side with a hacked solution to your problem (skip to Page 2 to see it.) …But I still don’t understand what’s going on. :thinking: On the positive side, it’s Friday and I just solved a problem that has plagued
us since the dawn of the repeater. :partying_face:

https://rhpccl.axshare.com/#id=j3gkoc&p=page_1&g=1

fit to text in a repeater.rp (203.6 KB)

There are two different "Fit to … " features that affect this issue. Here is my understanding of how this works. Each widget capable of containing text has a size property, which can be set to Default/Fixed; or “Fit to Text Height”; or “Fit to Text Width”. The latter two are dynamic such that the dimensions of the widget will change based on text content. In the editor, this is shown dynamically as you enter or paste text content. If the text content of a widget changes with one of the “Fit to …” settings, the dimensions of the widget change accordingly in the editor. Normally, this works fine and is not an issue in the browser (although fonts are rendered differently in each browser than they are in the editor so the dimensions of a widget can vary a little from the editor to the HTML in the browser.) However, in the prototype’s HTML–in the browser–this is only dynamic “once” --when the widget/page is loaded. If you change a widget’s text content dynamically in the HTML–via interaction code–the dimensions of the widget do not change again. Personally, I would love this feature, and it has been requested by users for Axure RP9 as well as in previous versions. For now, just realize this is how it works: if you set a widget to “Fit to Height” that height will only get set once, in the editor.

The repeater widget itself has a “Fit to Content in HTML” setting, which means that as the height of the content in the repeater cell changes, so does the height of the cell/row. Likewise, as the width changes so does the cell/column. Believe it or not, this is actually working correctly in your repeater (as evidenced by your “editor view” screenshot.) However, the size of the widget does not get changed in the browser, presumably because the text is getting set dynamically in the HTML via the repeater’s Item Loaded event. But, I did discover the row’s height gets set to fit the overflow text if the widget in the repeater is set to “Fit to Text Height”, and if you get the .height property of that text widget, it is reported as the height of the row–even though visually the height of the widget does not change–or more accurately, the height of the widget can decrease but not increase beyond the widget’s original height. This lead me to realize the repeater does know how tall to make each row, so if that height can be retrieved, the text widget in each row could be set based on that value. The way to find the height of the row (when the text widget is the only or at least tallest widget in the repeater) is kind of stupid, and it really shouldn’t work–but it does. In the Item Loaded event, after setting the text, get the height of that widget with the text–the value returned by [[LVAR1.height]] (where LVAR1 points to the widget) is the height of the row. So, it’s like the widget height does get changed–which makes sense, because it does get changed on the page in the editor–but that change doesn’t get shown in the browser HTML. Weirder yet, the widget height does get changed in the browser if it shrinks, but not if it grows taller than the original widget in the repeater cell. I have no idea why.

At any rate, you can read through the descriptions on Page 1, see my solution on Page 2, some shortcomings to this on Page 2b, another hack solution on Page 3, and proof this can work for “Fit to Width” as well on Page 4.


Expandable Rows
Repeater rows do not dynamically change height in shared/published project - but does so in Axure itself
#3

Hi!

I’d love to see a solution where adding/deleting/applying-filters to a repeater still respects text wrapping in its rows. As you point out on page 2, the repeater respects text wrapping when it first loads, but then shits the bed when any modification to the repeater is applied.

I don’t see a working example of this in your file. Am I looking in the wrong place?


#4

Well, I show how it doesn’t work with updating a repeater on Page 2b. No magic solution for this, though. I was just happy it could work at all.


#5

Hi again!

Yes, it’s super frustrating. This bug has existed since Axure 8 and has been reported over and over. AND, the bug is terrible! “Fit to Content in HTML” is essentially a useless feature, because why use a repeater at all if you’re not going to manipulate it?


#6

The HTML seems to render exactly the same regardless if “Fit to Content in HTML” is selected.

In the HTML the problem is that the text and the text background (same style in Axure) are separated in sibling <div> tags. This doesn’t make sense for the “Fit to Content in HTML” feature because you’d either format the entire Axure style in a single <div> tag, or as parent and child <div> tags.

So while it displays as intended in Axure, the HTML output is incorrect.


#7

@mbc66
Thanks for your RP file, this lead me to piggyback off your solution to create a fully adaptable table.
This one is currently configured with 10 columns: adjustable_table_rows.rp (74.4 KB)

I tried a couple alternate ways of doing this (repeater data, dynamic panel) but was unsuccessful. @mbc66’s way of doing it is the simplest.


#8

Try to use a “ruler”

adjustable_table_rows_Jorkin.rp (63.1 KB)

Preview: https://6l1j6z.axshare.com/