Repository navigation
New jsviewer css [rebased] - #4174
Conversation
|
Hmm, the failing test is not related to this PR, it seems to be due to the use of an internal api of coverage, and coverage 4.0 has been released today, so this is probably related: |
|
For the appveyor failing test, it is due to the new test I have added and some windows path format, I will check. |
d243ef0 to
1ccbcf6
Compare
There was a problem hiding this comment.
The max_lines arg isn't being used anywhere and I was able to put a 10000 line table into the browser (which was really slow).
There was a problem hiding this comment.
Indeed, this seems to go back to d18364d when the use of pformat has been replaced with the HTML write. Fixed with table slicing.
|
I would echo the earlier comment that a sans-serif font would be cleaner. |
|
It seems like the table is forced to be 100% width, which looks awkward for a table that is just a few columns wide. |
|
I have added a default style using the default sans-serif font, and 80% width for the table wrapper. Without knowledge on the content of the table it is hard to set a good value for all cases, but at least with this value present in the docstring and signature it will be more visible. It seems from the code that the jsviewer table could be printed directly in an ipython notebook, , but I didn't found how, any hint ? I am trying somthing like this but it doesn't work: |
9e4fa59 to
616c0c3
Compare
|
And Appveyor is passing :) |
|
Sorry, haven't dug in to the details of this, but can't the default just be without an explicit width set? Is 100% hardwired into DataTables or something? I'm just thinking of a plain old |
|
It is possible, but then the header and footer (with the length selector, search field, pagination) will be aligned with the container's width and not the table, which doesn't look very nice. So setting the container size is a good compromise I think, we can maybe set a size smaller than 80% ? |
|
What about something that is functionally like this: |
|
These elements are added directly by DataTables, it must be possible to modify the HTML template but I'm not sure it is worth it:
And having a table which is only a few tens of pixels wide (when there is only 2 columns for example) is not especially beautiful imho, maybe a compromise could be to set a smaller width by defaut, in pixels to have the same for all screens, something like 600 or 800 px ? |
|
An example of a beaker notebook shows tables that I think are really beautiful: Note the second table which is just 4 columns and looks good. In most real-world tables the column names or data values are wide enough to make sure you never get a 30-pixel-wide output. My example was just intended to roughly illustrate the desired layout, but wasn't a suggestion for how to implement it. Anyway, I understand this PR was not intended to be a rewrite from scratch, and DataTables does seem to be quite powerful. I dug around a little in the docs, but I didn't see what I was looking for, naming some configuration to say "just act like a plain simple HTML table and make each column as wide as its widest element". Seems like not such an unusual desire, but all the examples I could see tended toward displaying a table where the number of columns is known in advance by the web page designer. |
|
I tried something inspired by your beaker notebook, it works if Show entries/Search/pagination are left-aligned: |
|
Rebased, now tests are all green :) |
|
Looks great! Does that screen shot reflect the current code? |
|
@taldcroft yes ! |
|
Ok, thanks for bringing this one home @saimn !! Merging. |
|
Great ! I will check if I can get something quickly to use this in the ipython notebook (#3937). |
|
Cool. I don't recall if there is an open issue, but it would also be great to be able to write out a table like this as an independent entity that can be copied into an existing HTML page. |
|
Yes there is #4058, that what brought me here, I wanted to embed a generated HTML table in a website. I have made something without this, but it would be easier if astropy support this directly. |
|
Nag: Most PRs, and in particular ones that add new features, should not be merged without assigning a milestone. |
|
@embray - copy, I'll work on burning this into my mental checklist. |
As astropy#4174 was based on an older PR, I didn't noticed that the changelog entry was in the 1.0 version.
Fix changelog entry for #4174 added to the wrong version.
As astropy#4174 was based on an older PR, I didn't noticed that the changelog entry was in the 1.0 version.
As astropy#4174 was based on an older PR, I didn't noticed that the changelog entry was in the 1.0 version.



This is a rebased version of #2982 with a few improvements:
Table.show_in_browser), and remove default style as it is now replaced by the DataTables css.cc @taldcroft