Fixed rows columns

[Marc-Andre-Rivet]

Fixed columns and fixed rows

Started restructuring styles and making them more efficient

• using a marker row to provide the expected width of columns
• using stylesheet to provide most styles for cells instead of inlining styles

[Marc-Andre-Rivet]

Running into some contradicting requirements between the fixed rows and the dropdown. Fixed rows require 'overflow-y: scroll', while the dropdown requires the overflow to be visible. Looking into what can be done..

[Marc-Andre-Rivet]

Update: So yeah.. this is a bit of a pickle.. the structure is as follow:

container -> spreadsheet -> rows -> cells -> Dropdown / Select -> menu

container: provides the relative positioning
spreadsheet: provides the overflow rules

Decoupling the positioning and overflow allow for this type of scenario, but we would need the menu to be created as a child of container for the spreadsheet overflow / clipping to be prevented. Not sure there's enough flexibility with the Dropdown package to do something like that.. reading through the Dropdown & Select repos to gather intel for a solution, we are not the first ones to encounter this issue.

[Marc-Andre-Rivet]

The dropdown gets clipped by the overflow: auto/hidden/scroll.. to move around that, we make it absolutely positioned, find the relative parent and calculate the absolute position needed for it to be placed directly beneath its parent. Since the relative parent is above the element with overflow set, it does not get clipped.

[chriddyp]

It looks like this isn't working for me in Firefox 61. Firefox on the left, chrome on the right

[chriddyp]

It looks like there is a slight 1px shift starting at column 3 (presumabley where the <input/> starts?)

I'm testing this with the demo data and n_fixed_rows: 3

[Marc-Andre-Rivet]

Answering to: #37 (comment)

Oh, nice! I did not test this on FF, only on Safari and Chrome.
Turns out stylesheets isn't standard across browsers.

Updating + I'll test against Edge tomorrow.

[chriddyp]

In FIrefox I also seem some odd scrolling in the headers with

            tableProps: {
                id: 'table',
                dataframe: clone(mockData.dataframe),
                columns: clone(mockData.columns),
                editable: true,
                // n_fixed_rows: 3,
                n_fixed_columns: 2,
                // row_deletable: true,
                // row_selectable: 'single',
                merge_column_headers: true
            },

[chriddyp]

I'm noticing this odd intermittent thing with horizontal scroll. If you look carefully in the input cell, it looks like the input is catching the horizontal scroll: the number inside the input moves left-to-right ever so slightly (like 1px?). If I move my mouse to the header, then it scrolls fine, and if I move my mouse to the border between the cells, it scrolls fine.

[Marc-Andre-Rivet]

Also experiencing weird stuff with the dropdowns (they cover the border/box-shadow)

[Marc-Andre-Rivet]

Answering to: #37 (comment)

@chriddyp Updated to fix the scrolling issue when the table/column is not editable; when editable the problem was present before the PR, this is not a regression, I'll open an independent issue based on your comment and prioritize.

#40

[Marc-Andre-Rivet]

Answering to: #37 (comment)

@chriddyp Overriding user agent defaults for table and input (Chrome -> 13px, FF -> 16px)
This will help a bit but is not a final fix. We need to rework the content of the headers further and move away from spans and probably go towards inline-block divs which will allow somewhat more predictable control over rendering.

[Marc-Andre-Rivet]

Just found that the fix for the clipped dropdowns introduces a new problem for the fixed columns (lack of clipping)

[Marc-Andre-Rivet]

Follow up to: #37 (comment)

Dropdown + fixed columns clipping fixed

[Marc-Andre-Rivet]

@chriddyp Please have another go at it! Thx. Haven't fixed the dropdown styling, will fix it after or as part of the merge with your changes, as they impacted dropdowns too.