Headings not aligning with data columns in Table Chart when height option is specified

[Greg Almond]

It looks like there are a few issues arising from the V41 release. As of yesterday I noticed that visualization table chart headings are misaligned with their corresponding columns of data when the 'height' option is specified. This does not occur when the height option is absent.

I'm assuming that this is related to the V41 changes made to the table chart header. Has this issue already been pointed out, and is it being considered in the set of fixes being prepared?

[Daniel LaLiberte]

Greg, there are a few issues with tables in the v41 release, but hardly anyone has given us enough details to reproduce the problems.  

It may be that specifying the height and width explicitly can resolve most of the problems.  We may rely on that, depending on the nature of the actual problems and possible solutions.   It is possible that we've basically gotten into a bind of conflicting requirements with no way out except to possibly break some uses, which can still be resolved by explicit sizing.

On Fri, Feb 20, 2015 at 8:33 AM, Greg Almond <gr...@gregalmond.ca> wrote:

It looks like there are a few issues arising from the V41 release. As of yesterday I noticed that visualization table chart headings are misaligned with their corresponding columns of data when the 'height' option is specified. This does not occur when the height option is absent.

I'm assuming that this is related to the V41 changes made to the table chart header. Has this issue already been pointed out, and is it being considered in the set of fixes being prepared?

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte  - 978-394-1058

dlaliberte@Google.com   5CC, Cambridge MA

daniel.laliberte@GMail.com 9 Juniper Ridge Road, Acton MA

[Greg Almond]

Hi Daniel, thanks for your reply.

I wanted to check if this was a known issue but now I'm trying to reproduce it in the simplest way possible. So far I haven't determined the exact conditions that cause the alignment to break.

The misalignment still exists in my implementation when the height and width is explicitly specified so that may not be the workaround in this case.

Greg

--
You received this message because you are subscribed to a topic in the Google Groups "Google Visualization API" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-visualization-api/yIYzGSgnIeE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-visualizati...@googlegroups.com.

[Greg Almond]

Hello again,

It appears the misalignment occurs when the table chart height is set and the table content height exceeds the chart height...in other words, when a vertical scrollbar is required. If the entire table is visible without a scrollbar, then the headings and columns are aligned.

It looks like the heading widths are not adjusted properly according to the width of cells that are not visible because of scrolling.

A work-around would be to set the pageSize for paging to a value that allows all rows to be visible (without scrolling) for a specified table height. However, there are situations where scrolling through a table is more effective than paging through it.

It would be useful to have the alignment behaviour that existing prior to V41.

Thanks,

Greg

[seth isernhagen]

Sorry if this is hijacking... 

I didn't think that tables could align (left, center, right) the header based upon the alignment of the cells in the column. 

Is that the alignment you are describing or something else?  I would like to know because I was looking for the specific feature.

[Greg Almond]

I guess that my terminology is misleading. By alignment I'm referring to the header cell width relative to the data cell width of the same column; if the two don't match then the header cell is offset from (or misaligned to) its corresponding column.

--

[seth isernhagen]

Is the header text aligned a little bit left of center? 

If so, I think this is because the sort indicator is treated as text even though it's hidden.   

On Friday, February 20, 2015 at 5:33:48 AM UTC-8, Greg Almond wrote:

[Greg Almond]

In this case the header offset isn't consistent as it depends on the variability of the width required for its corresponding data in the cells below. It appears that the width calculation of the header cell is based on the width of a subset of cells in the column when the column doesn't entirely fit within the specified height of the table.

--

[Dimitry Kudryavtsev]

I am seeing the same issue.  The scroll header width is calculated based on the text of the headers and not based on the width of the data cells.

On Friday, February 20, 2015 at 5:05:44 PM UTC-5, Greg Almond wrote:

In this case the header offset isn't consistent as it depends on the variability of the width required for its corresponding data in the cells below. It appears that the width calculation of the header cell is based on the width of a subset of cells in the column when the column doesn't entirely fit within the specified height of the table.

On Sat, Feb 21, 2015 at 7:50 AM, seth isernhagen <siser...@gmail.com> wrote:

Is the header text aligned a little bit left of center? 

If so, I think this is because the sort indicator is treated as text even though it's hidden.   

On Friday, February 20, 2015 at 5:33:48 AM UTC-8, Greg Almond wrote:

It looks like there are a few issues arising from the V41 release. As of yesterday I noticed that visualization table chart headings are misaligned with their corresponding columns of data when the 'height' option is specified. This does not occur when the height option is absent.

I'm assuming that this is related to the V41 changes made to the table chart header. Has this issue already been pointed out, and is it being considered in the set of fixes being prepared?

--
You received this message because you are subscribed to a topic in the Google Groups "Google Visualization API" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-visualization-api/yIYzGSgnIeE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to google-visualization-api+unsub...@googlegroups.com.

[Dimitry Kudryavtsev]

I did some more digging around and I think I found the issue.  This happens when there is enough data in the table where you need the scroll.  In this case, there are two tables created one that contains fixed header and the other one that contains the scroll header.  The scroll head is miss aligned with the width of the data cells.  What I noticed is that the scroll table has hidden property on tbody, if I remove this property the scroll headers become correctly aligned.  So definitely a issue with the new release.

[Daniel LaLiberte]

Dimitry, the duplicate tables created when there are enough rows, for the frozen header and body, should have the same cell contents, and the same width and height properties, so they should all end up aligned properly.   The way tbody is hidden, using visibility:invisible, means that the size of the cell contents should be the same but just not visible.  If it doesn't work for some cases, I would like to learn the details so I have a chance of making it work. Perhaps there is a browser difference.

There is a very large number of combinations of the dozen or so options that affect table chart layout, and I admit, we broke some common use cases with this release.  We are adding more test cases to be sure this doesn't happen again, but I'll need to find out what additional test cases should be covered.

--

You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.

To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

[Rick Brown]

I am also seeing issues with column headers not aligning with their respective data columns, but only in IE11.  Everything renders correctly in Firefox, but unfortunately, the corporate standard is IE.  I have not been able to isolate the specific set of conditions needed, but it is definitely related to sorting.

On Friday, February 20, 2015 at 8:33:48 AM UTC-5, Greg Almond wrote:

[Dimitry Kudryavtsev]

Hi Daniel,

Thanks for the feedback.  I might have found and solved the issue we are having.  It looks like .hidden class is also part of Bootstrap that was setting the display property to none with !important as such:

.hidden {

display: none !important;

visibility: hidden !important;

}

I added the following to my css and it fixed the miss alignment of the table headers.

.google-visualization-table .hidden {

display: table-row-group !important;

}

On Monday, February 23, 2015 at 12:01:48 PM UTC-5, Daniel LaLiberte wrote:

Dimitry, the duplicate tables created when there are enough rows, for the frozen header and body, should have the same cell contents, and the same width and height properties, so they should all end up aligned properly.   The way tbody is hidden, using visibility:invisible, means that the size of the cell contents should be the same but just not visible.  If it doesn't work for some cases, I would like to learn the details so I have a chance of making it work. Perhaps there is a browser difference.

There is a very large number of combinations of the dozen or so options that affect table chart layout, and I admit, we broke some common use cases with this release.  We are adding more test cases to be sure this doesn't happen again, but I'll need to find out what additional test cases should be covered.

On Mon, Feb 23, 2015 at 11:27 AM, Dimitry Kudryavtsev <dk8...@gmail.com> wrote:

I did some more digging around and I think I found the issue.  This happens when there is enough data in the table where you need the scroll.  In this case, there are two tables created one that contains fixed header and the other one that contains the scroll header.  The scroll head is miss aligned with the width of the data cells.  What I noticed is that the scroll table has hidden property on tbody, if I remove this property the scroll headers become correctly aligned.  So definitely a issue with the new release.

On Friday, February 20, 2015 at 8:33:48 AM UTC-5, Greg Almond wrote:

It looks like there are a few issues arising from the V41 release. As of yesterday I noticed that visualization table chart headings are misaligned with their corresponding columns of data when the 'height' option is specified. This does not occur when the height option is absent.

I'm assuming that this is related to the V41 changes made to the table chart header. Has this issue already been pointed out, and is it being considered in the set of fixes being prepared?

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-visualization-api+unsub...@googlegroups.com.

To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte  - 978-394-1058

dlali...@Google.com   5CC, Cambridge MA

daniel.l...@GMail.com 9 Juniper Ridge Road, Acton MA

[Daniel LaLiberte]

Dimitry, in the interest of defensive programming, I guess this is a case where we will have to prefix every css class name with our library-specific name, but I was hoping to move away from such verbosity. A short prefix like 'gviz-' would be better.   Alternatively, we could obfuscate all the css class names, though I would really rather not do that.

To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.

To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte  - 978-394-1058

dlaliberte@Google.com   5CC, Cambridge MA

daniel.laliberte@GMail.com 9 Juniper Ridge Road, Acton MA

[Dimitry Kudryavtsev]

Hi Daniel,

It looks like whatever change was pushed in the last 12 hrs broke our tables again.  We are now seeing the headers misaligned and tables not filling the full width of the parent div. We seriously need a better versioning for this library, where the clients can lock in the version that works for them.  

Moreover, can you communicate the expectation for this library, is this production ready?  

On Monday, February 23, 2015 at 1:49:04 PM UTC-5, Daniel LaLiberte wrote:

Dimitry, in the interest of defensive programming, I guess this is a case where we will have to prefix every css class name with our library-specific name, but I was hoping to move away from such verbosity. A short prefix like 'gviz-' would be better.   Alternatively, we could obfuscate all the css class names, though I would really rather not do that.

On Mon, Feb 23, 2015 at 1:02 PM, Dimitry Kudryavtsev <dk8...@gmail.com> wrote:

Hi Daniel,

Thanks for the feedback.  I might have found and solved the issue we are having.  It looks like .hidden class is also part of Bootstrap that was setting the display property to none with !important as such:

.hidden {

display: none !important;

visibility: hidden !important;

}

I added the following to my css and it fixed the miss alignment of the table headers.

.google-visualization-table .hidden {

display: table-row-group !important;

}

On Monday, February 23, 2015 at 12:01:48 PM UTC-5, Daniel LaLiberte wrote:

Dimitry, the duplicate tables created when there are enough rows, for the frozen header and body, should have the same cell contents, and the same width and height properties, so they should all end up aligned properly.   The way tbody is hidden, using visibility:invisible, means that the size of the cell contents should be the same but just not visible.  If it doesn't work for some cases, I would like to learn the details so I have a chance of making it work. Perhaps there is a browser difference.

There is a very large number of combinations of the dozen or so options that affect table chart layout, and I admit, we broke some common use cases with this release.  We are adding more test cases to be sure this doesn't happen again, but I'll need to find out what additional test cases should be covered.

On Mon, Feb 23, 2015 at 11:27 AM, Dimitry Kudryavtsev <dk8...@gmail.com> wrote:

I did some more digging around and I think I found the issue.  This happens when there is enough data in the table where you need the scroll.  In this case, there are two tables created one that contains fixed header and the other one that contains the scroll header.  The scroll head is miss aligned with the width of the data cells.  What I noticed is that the scroll table has hidden property on tbody, if I remove this property the scroll headers become correctly aligned.  So definitely a issue with the new release.

On Friday, February 20, 2015 at 8:33:48 AM UTC-5, Greg Almond wrote:

It looks like there are a few issues arising from the V41 release. As of yesterday I noticed that visualization table chart headings are misaligned with their corresponding columns of data when the 'height' option is specified. This does not occur when the height option is absent.

I'm assuming that this is related to the V41 changes made to the table chart header. Has this issue already been pointed out, and is it being considered in the set of fixes being prepared?

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-visualization-api+unsubscr...@googlegroups.com.

To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte  - 978-394-1058

dlali...@Google.com   5CC, Cambridge MA

daniel.l...@GMail.com 9 Juniper Ridge Road, Acton MA

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualization-api+unsub...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

[Daniel LaLiberte]

Dimitry,

I strongly suspect the misalignment you are seeing now is due to workarounds for the previous version that are now incompatible with the current version.  Or perhaps there are other conflicting css classes, like the 'hidden' class.  Can you check whether you see any extra styles on the table chart elements.  If so, disable those and see how it looks.  

Again, if you can point me to a page, or reproduce the problem in jsfiddle, or provide enough code so I can reproduce the problem, I will have a chance of doing something about it.

The update that was pushed out late last evening should resolve most of the table related problem that I know about.  But very few people offered actual examples, so I had to guess about the rest.  All the tests I know about (which several hundred) work as intended.  There could be more cases that don't work as well as they should, but misalignment should not be one of those problems. 

We are now planning to provide frozen versions of the library, starting with the next release.

To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.

To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-visualization-api.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte  - 978-394-1058

dlaliberte@Google.com   5CC, Cambridge MA

daniel.laliberte@GMail.com 9 Juniper Ridge Road, Acton MA