ENH: Remove the hardcoded border=1 in the to_html dataframe export.
State: closed

The border is impossible to overwrite at later stage, therefore using no
border gives the user the possibility to style the table, using CSS Classes.


Labels:
name: Output-Formatting
description: __repr__ of pandas objects, to_string
name: IO HTML
description: read_html, to_html, Styler.apply, Styler.applymap

Comments:
can you add a release notes entry? edit doc/source/releast.rst

is it possible to post a picture here of before/after?

Dataframe with border:
![dataframe_html_with_border](https://f.cloud.github.com/assets/96245/1001141/fc500544-0a61-11e3-9089-0df33dc10358.png)
Dataframe without border:
![dataframe_html_without_border](https://f.cloud.github.com/assets/96245/1001142/fc6bd29c-0a61-11e3-914c-25765db9aa4e.png)

thanks for the pic! ok....I actually like the border (my 2cents)...is that a way to do this such that you can do the css, while providing a default that has the border? (so existing behavior is maintained but you can override)?

@jreback I'm not sure if there is a quick way to achieve that. What we could do is to have `border` keyword on the .to_html() export.
If zero, no border will be used, otherwise the border's thickness will be used written (basically border=2 being the default.)

The problem is `write_result` https://github.com/mattions/pandas/blob/15af65239a964f71f410cab5bb28504fa1993d3b/pandas/core/format.py#L561
gets only a buffer as arguments, and I'm not sure from where we should insert the keyword, and propagate it all the way down to that function.

It may be possible, not too sure it's savvy.

I think the way to solve this is to add a display option to control this

see `pandas/core/config_init.py`

I think there is only 1 existing notebook option, so maybe add another (under the display name space)

`display.nb_border` with a default of 1, but could accept an integer, or `None`, whereby you could override
it (or even say interpret it as css?)

```
pc_nb_repr_h_doc = """
: boolean
    When True, IPython notebook will use html representation for
    pandas objects (if it is available).
"""
```

I think allowing `notebook.border` is ok too (e.g. create another category, even though its a display option, notebook is important enough to have its own)

cc @jtratner, @cpcloud, @y-p ?

that's it, after `eval` is merged i'm doing the template stuff. i think `notebook.border` is okay.

@jreback That makes sense, but preferable that outputted html doesn't have a border attribute at all if it's set to `None`.

I.e.

`border = 0` --> `<table border='0'..>`
`border = 1` --> `<table border='1'`..>`
`border = None` --&gt; &lt;table&gt;

as you guys are the CSS experts, I think @mattions wants to say set `notebook.border = None`, then pass a class? (to do something else)

@jreback that's a nice way to do it, because then you can just inject CSS into the notebook separately via IPython. Way easier to maintain for pandas too.

that might be a nice to way to have default formatters for the `to_*` methods that have formatting options, eg latex and html. would be sweet if you could also pass a formatting class (that maybe takes a template path, or maybe a `template` kwarg then construct the class inside the method) then farm it out to the templating engine 

@mattions can you update to use the option syntax to control this?

@jreback I'm sorry I don't understand the option you are referring to.
Could you point me to that?

I would like you to add an option, `notebook.style.border`, with a default of `1`, so the existing code is the same, then you are free to change it to `None`. The code that you changed should look at this option and use it to build the style. here's how to specify the options: https://github.com/pydata/pandas/blob/master/pandas/io/pytables.py#L201

The orig issue was concerned with control over the output of `to_html` for _export_
purposes, nothing intrinsicly to do with the notebook except that it too relies on `to_html`
to generate the markup.

Using the option mechanism to control exporting style breaks with the existing
convention which favor parameter hell (re #3190)

If you must add this option, I think it can comfortably join it's bretheren under the 
`display` catagory, and I generally favor keeping the option tree shallow. 

Again, keeping in mind the original issue this seems like the wrong thing to me. 2c.

so what's the right way forward @y-p?

I think templates are the goal ... maybe we can move the discussion there? in particular the API should be decided on and then I or someone else can start working on it

(#3190)

what did we decide for this?

option to control the border width?

templates in 0.14?

i'm a strong +1 on templates

agreed....should we do anything in 0.13 for this?

@mattions 

defering this to 0.14.

This very valid, thanks for the PR; the problem is adding this now could complicated the refactor for deal with a templated style system that is slated for 0.14. Feel free to contribute on that (and this will definitley be included, maybe via a slightly different mechanism).

I've commited to getting a more general solution for styling HTML output/generating output
using template which will absolutely cover this merged for 0.14. Thanks for the PR in any case.

#5763

closing.