coverage html does not generate nice tables

Issue #491 wontfix
Benjamen Meyer created an issue

I primarily develop on a remote server accessible over SSH. So I use lynx to view coverage reports. When I view the index.html everything looks fine; however, when I look at any individual file I get a listing of all the line numbers then a listing of all the source lines.

Looking at the generated HTML, the index.html works because it builds each table row with all the information in it. However, the code pages seem to generate two blocks of data which I would not necessarily expect to line up properly.

I've noticed a few other Issues reporting alignment issues with the line numbers and code and this would seem to resolve those as well; I'm not sure this is a duplicate issue of any of those but the solution here would seem to address them - that is, make the code pages generate the same kind of data as the index page does - each line having all the data for that row.

FWIW, this makes the coverage reports very hard to follow in browsers like lynx.

Note: I did check the "links" console web-browser and things work there. I'm not sure what the difference is, but either way the above should make it more reliable across all browsers.

Comments (15)

  1. Matthew Boehm

    While coverage generates its own HTML, I've run into this same thing with pygments. Pygments allows you to choose whether or not you want a table. It defaults to not using a table so that you can copy source code without copying line numbers.

    A few possible resolutions:

    1. If tables are deemed definitively better, use them instead.
    2. If it's deemed worth the extra effort/complexity, add an option to generate file reports as tables
    3. Develop a custom css file that you can apply to reports that hides the numbers

    Since this bug seems specific to lynx. I'd recommend that we explore option #3 so that no changes to coverage are needed. You can read about how to include custom css to your html reports at .

  2. Benjamen Meyer reporter

    The solution, IMHO, is that the tables should be generated as: rowcolumncolumnend row instead of

    columnrow...end columncolumnrow...end column While the HTML is valid, it is an incorrect use of tables that will only ever lead to problems, including the many issues regarding alignment.By changing to doing what I suggest above, then the whole issue regarding alignment goes away as the tables will naturally solve that problem. Ben

  3. Benjamen Meyer reporter

    @mattboehm while Lynx may exhibit the behavior best, it is not specific to Lynx, but any browser that doesn't necessarily apply CSS. Per specific detail, my issue is with how poorly coverage generates the row data, choosing a rather obtuse manner to do so instead of a simpler format that would be guaranteed to render better on all browsers regardless of CSS support.

    There is also no reason why CSS support should be necessary to implement a simple table. CSS should augment the table to add styles, not make it correctly render at its most basic level - getting columns and rows aligned. If you do the simple:

    <tr> <td></td> ... <td></td> </tr>

    Then nearly all if not all html renderers will generate the correct page even if CSS is not applied.

    However, for some obtuse reason coverage is generating:

    <td> <tr> </tr> </td> ... <td> <tr> </tr> </td>

    And that will cause problems, and also lead to the various rendering bugs since CSS is now required to try to get the columns to line up properly.

  4. Loic Dachary

    @BenjamenMeyer could you please describe a way to reproduce the problem ? I tried and do not observe the obtuse <td><tr>...</tr></td> you're mentionning. By code page I assume you mean the page that displays the python code being covered. But maybe not ?

    part1.png part2.png

  5. Benjamen Meyer reporter

    I will try to find some time to reproduce again. It's been a while; but it was very reliable at the time. May be something changed since that fixed it.... Ben

  6. Ned Batchelder repo owner

    Ben is right about the structure of the file, but has mis-remembered the tags. As the code sample above shows, the source is a table with a single row and two cells. The first cell has all the line numbers (in <p> elements), the second cell has all the source lines (also in <p> elements).

  7. Ned Batchelder repo owner

    Ben, I've just looked at the HTML output with lynx, and I see what you mean about the line numbers, but I also wonder if this is worth pursuing: so much is wrong with the display, I don't understand what you will get from it? Because CSS isn't interpreted, there's no indication of lines covered vs uncovered, there's no syntax coloring, and even the indentation of the code is lost and the lines are double-spaced.

    What information are you getting from these pages?

  8. Ned Batchelder repo owner

    BTW, links and elinks both display the table properly, though both still have the larger issue that without CSS, there's no useful information on the page.

  9. Benjamen Meyer reporter

    I am not interested in pretty stuff; I'm interested in getting to the core functionality, and I think if you solve this you'll also solve other issues you have as a natural side effect. CSS shouldn't be necessary for loading the code coverage information. I checked one project - Falcon ( - that I have worked on. Viewing the file in "links" I found the line 132 in "falcon/util/" that had 16 branch misses; I was able to find the same text while looking at the data under "lynx"; however, the table structure kept the line information from coming up. If you want to reproduce - you can use my branch - - which I just used to check this with a fresh "pip install coverage". I modified the "tox.ini" to stop from moving the coverage data to another directory. $ source env/bin/activate   <- to activate the environment to run tox$ tox -e py27$ coverage html$ cd htmlcov$ lynx index.htmlSelect "falcon/util/"

  10. Benjamen Meyer reporter

    Okay...just looked at the HTML; I think it changed since I originally looked at it. Either way, each source line should match up to a single row in the table, with each column containing the various information - line number, source, comments, etc. This will solve formatting bugs - like text alignment, text sizes, etc.

  11. Ned Batchelder repo owner

    @BenjamenMeyer I don't understand how you are seeing which lines are covered and which are not? The HTML report only shows that by coloring the lines differently. Maybe I'm forgetting something about the information in the report, but I couldn't see the information when I checked a report in any of the character-mode browsers.

  12. Benjamen Meyer reporter

    You click on the file listing and see the source code. The first line where an issue occurs will have a notation. It might be a separate html paragraph (p element). If rendered correctly it is to the left of the source line IIRC. Ben

    Sent from Yahoo Mail on Android

  13. Ned Batchelder repo owner

    @BenjamenMeyer I see what you mean: partial branches show a paragraph with a notation about why the branch is partial. But there is no indication about completely uncovered lines. This report is unusable in a text-based browser, for more reasons than just the alignment of line numbers and lines.

    I recommend using one of the text-based reporting methods, either "coverage annotate" or "coverage report -m".

  14. Log in to comment