You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chromium 51.0.2704.63 vs. Firefox Nightly 46.0.1 on Linux 64-bit (NixOS)
What steps will reproduce the problem?
Search in a multiple segmentation corpus
Compare the visualization of overlaps in Chromium and Firefox
What is the expected result?
Overlaps should be visually indicated by... well, overlaps of the HTML table cells :) Chromium handles this correctly:
What happens instead?
In Firefox, the overlaps are gone (at least visually):
The same happens on Firefox in Windows 10, and even Chrome / Chromium doesn't seem to get this consistently right. There seems to be a difference in default styling of colspans, which is unfortunate. Compare this stripped down example:
Here, it is clearer that Firefox actually does visualize the colspan but gives the middle column (which is never materialized as a separate cell in any of the rows) a minimal width. When I add a "most granular" row with no colspans, the rendering becomes fine:
...
<tr><td></td><td></td><td></td></tr>
...
Which made me wonder whether configuring the grid visualization to display the token layer (removing hide_tok: true) would fix things, but I'm currently struggling to get the tokens to display at all (they're empty in my case, which might be why). At any rate, I think displaying the purely technical token layer should not be a requirement for correct overlap layout, because it just adds visual clutter...
The text was updated successfully, but these errors were encountered:
OK, so displaying the most granular tokenization layer fixes the display in Firefox (but I still think it would be better if that line didn't have to be there at all, at least visually; with richly annotated corpora, screen real estate becomes a scarce resource):
I'm currently struggling to get the tokens to display at all (they're empty in my case, which might be why)
I was editing an older resolver_vis_map under the public schema instead of the one under the schema for my current version of ANNIS, that's why :)
I think this can be solved by actually outputting the token row, but setting the "visibility" to "collapse" in case the token shouldn’t be visible. Together with "min-width" for the td-cells this get's a kind of reliable result in both Firefox and Chrome:
Unfortunately in the example in Chrome there is still an issue with the border itself, I will check if this also occurs in the grid style used by ANNIS.
Good idea! ANNIS is setting border-collapse: collapse on the table, which seems to get rid of the "thick" border in Chrome (at least it did when I added it to the JSFiddle), so it should be fine.
thomaskrause
changed the title
Rendering overlaps in grid view, Chromium vs. Firefox
Rendering overlaps in grid view not always shown in Firefox
Oct 17, 2016
What is the used ANNIS version?
3.4.4 (rev. b53ef2e, built 2016-05-13 17:08:12)
What browser and operating system did you use?
Chromium 51.0.2704.63 vs. Firefox Nightly 46.0.1 on Linux 64-bit (NixOS)
What steps will reproduce the problem?
What is the expected result?
Overlaps should be visually indicated by... well, overlaps of the HTML table cells :) Chromium handles this correctly:
What happens instead?
In Firefox, the overlaps are gone (at least visually):
The same happens on Firefox in Windows 10, and even Chrome / Chromium doesn't seem to get this consistently right. There seems to be a difference in default styling of colspans, which is unfortunate. Compare this stripped down example:
Chromium:
Firefox:
Here, it is clearer that Firefox actually does visualize the colspan but gives the middle column (which is never materialized as a separate cell in any of the rows) a minimal width. When I add a "most granular" row with no colspans, the rendering becomes fine:
Which made me wonder whether configuring the grid visualization to display the token layer (removing
hide_tok: true
) would fix things, but I'm currently struggling to get the tokens to display at all (they're empty in my case, which might be why). At any rate, I think displaying the purely technical token layer should not be a requirement for correct overlap layout, because it just adds visual clutter...The text was updated successfully, but these errors were encountered: