[IPython-dev] nbconvert: trouble with the new style sheet

Fri Jul 5 02:38:54 EDT 2013

OK, great.

On Thu, Jul 4, 2013 at 11:33 PM, Min RK <benjaminrk at gmail.com> wrote:
> I'm not sure that's actually true. I will experiment with generating subset CSS files tomorrow.
>
> -MinRK
>
> On Jul 4, 2013, at 22:19, Brian Granger <ellisonbg at gmail.com> wrote:
>
>> That bring up another issue.  We are currently using both the
>> boilerplate style reset as well as bootstrap which does its own reset.
>> We can probably get rid of the non-bootstrap reset stuff.
>>
>> I think it will be very difficult to split up style.min.css because
>> our own CSS uses bootstrap variables.  That is one of the downsides of
>> using less - it sort of all has to be built at the same time...
>>
>>
>>
>> On Thu, Jul 4, 2013 at 3:47 PM, MinRK <benjaminrk at gmail.com> wrote:
>>> One problem is probably the 'reset' styles.  While it makes sense for the
>>> webapp to have just one `style.min.css`, we should probably generate at
>>> least one or two more css files, so that others can use just the IPython
>>> style without inheriting reset and (maybe) bootstrap.
>>>
>>>
>>> On Thu, Jul 4, 2013 at 2:23 PM, Jacob Vanderplas <jakevdp at cs.washington.edu>
>>> wrote:
>>>>
>>>> On Thu, Jul 4, 2013 at 1:42 PM, Min RK <benjaminrk at gmail.com> wrote:
>>>>>
>>>>> We are going to have to explore a few options, it's not obvious what's
>>>>> the best choice for various contexts.  It will help to have the various
>>>>> sticky points affecting Jake as data points.
>>>>
>>>>
>>>> I like the idea of wrapping everything so it's self-contained. My "sticky
>>>> points" are basically all due to this: either places where the blog theme
>>>> overrides the notebook and makes it look ugly, or places where the notebook
>>>> css overrides the blog theme and makes it look ugly.  Most of my hacks to
>>>> the CSS have involved getting the template to the point of being essentially
>>>> what you're describing here.  Because it's not designed that way from the
>>>> ground up, however, some of the styles aren't carrying down to multiply
>>>> nested elements.
>>>>
>>>> I think the best solution would have the following:
>>>>
>>>> - use non-generic CSS class names (e.g. "ipynb-cell" rather than "cell",
>>>> and "ipynb-highlight" rather than "highlight"),
>>>> or nest any such generic names within an "ipynb" namespace.
>>>> - make no global CSS modifications (e.g. global-level header formatting,
>>>> page formatting, body formatting)
>>>> - design the CSS so that notebook sections in a div, such as <div
>>>> class="ipynb"></div>, so that multiple notebook snippets can easily be
>>>> included in a page which otherwise has arbitrary html/css styling.
>>>>
>>>> I don't have a great deal of experience with CSS, but from my
>>>> understanding, this sort of approach should be possible.
>>>>   Jake
>>>>
>>>>>
>>>>>
>>>>> -MinRK
>>>>>
>>>>> On Jul 4, 2013, at 13:37, Brian Granger <ellisonbg at gmail.com> wrote:
>>>>>
>>>>>> One other usage case - if someone wants to integrate ipython assets
>>>>>> into their web page at a finer grained scale - imagine someone wanting
>>>>>> to put a single cell at various locations on their non-ipython using
>>>>>> page.  In that case, each IPython containing div would have to have
>>>>>> the .ipython class?  I don't think that is a problem, but I just want
>>>>>> to make sure we are covering the different usage cases...
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Thu, Jul 4, 2013 at 12:38 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>>>> There are two ways of applying style to descendants - immediate (with
>>>>>>> `>`)
>>>>>>> and any level (with space, or as you posted).
>>>>>>>
>>>>>>> So if we just put all of our style in a `.ipython {...}` block, then
>>>>>>> our
>>>>>>> classes in a single `.ipython` div, our style would not apply outside
>>>>>>> that
>>>>>>> context.
>>>>>>>
>>>>>>> Illustration: http://nbviewer.ipython.org/5929801
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 4, 2013 at 12:25 PM, Brian Granger <ellisonbg at gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Does the less syntax for nesting:
>>>>>>>>
>>>>>>>> .ipython {
>>>>>>>>
>>>>>>>> .cell {}
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>> map to only the immediate children or all descendents?  If it only
>>>>>>>> works for immediate children, our css stylesheets would have to
>>>>>>>> become
>>>>>>>> horribly nested.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> On Thu, Jul 4, 2013 at 12:11 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>>>>>> Matthias is right - we don't actually have to prefix every name, we
>>>>>>>>> can
>>>>>>>>> just
>>>>>>>>> scope our CSS based on the outer ipython container.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jul 4, 2013 at 12:04 PM, Matthias Bussonnier
>>>>>>>>> <bussonniermatthias at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Short from my phone:
>>>>>>>>>>
>>>>>>>>>> Could we add an .ipython class to body,
>>>>>>>>>> And wrap the all less import in a .ipython{}
>>>>>>>>>>
>>>>>>>>>> CSS will then only apply to elements that are included in a
>>>>>>>>>> div.ipython
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> Le jeudi 4 juillet 2013, Brian Granger a écrit :
>>>>>>>>>>
>>>>>>>>>>> There are a couple of factors going on:
>>>>>>>>>>>
>>>>>>>>>>> * We are now minimizing the stylesheet which obscures everything.
>>>>>>>>>>> * We are transitioning to using bootstrap.  You may have direct
>>>>>>>>>>> conflicts with bootstrap classes as well as ours
>>>>>>>>>>> * Our css classes are horribly named - generic names like "cell"
>>>>>>>>>>> or
>>>>>>>>>>> "selected".  To address this we are planning on renaming our css
>>>>>>>>>>> classes using the following convention:
>>>>>>>>>>>
>>>>>>>>>>> ipy-cell-selected
>>>>>>>>>>> ipy-notebook-foo
>>>>>>>>>>>
>>>>>>>>>>> We probably won't have time to do all of our classes before 1.0,
>>>>>>>>>>> but
>>>>>>>>>>> we can prioritize the ones you are having problems with.  Can you
>>>>>>>>>>> open
>>>>>>>>>>> an issue for this and provide us with a list of the ones you are
>>>>>>>>>>> running into?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 4, 2013 at 9:10 AM, Jacob Vanderplas
>>>>>>>>>>> <jakevdp at cs.washington.edu> wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I've been working on adapting the recently-merged nbconvert
>>>>>>>>>>>> refactor
>>>>>>>>>>>> to
>>>>>>>>>>>> work
>>>>>>>>>>>> with my Pelican blogging plugin, and am having a really difficult
>>>>>>>>>>>> time.
>>>>>>>>>>>> In
>>>>>>>>>>>> particular, the header content produced by the new nbconvert (via
>>>>>>>>>>>> CSSHTMLHeaderTransformer) contains a lot of extra stuff compared
>>>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>> old
>>>>>>>>>>>> version.  This is conflicting with the default blog theme, and
>>>>>>>>>>>> leading
>>>>>>>>>>>> to
>>>>>>>>>>>> some results which are not very pretty.
>>>>>>>>>>>>
>>>>>>>>>>>> In the old iteration of the notebook plugin, I used about half a
>>>>>>>>>>>> dozen
>>>>>>>>>>>> regular expression replace statements to modify the stylesheet &
>>>>>>>>>>>> content and
>>>>>>>>>>>> make it play well with the blog style.  My hope was that the new
>>>>>>>>>>>> nbconvert
>>>>>>>>>>>> would be flexible enough to obviate the need for this sort of
>>>>>>>>>>>> text-mangling;
>>>>>>>>>>>> in reality the required text-mangling in the new version is much
>>>>>>>>>>>> more
>>>>>>>>>>>> extensive.  I've been working at it for several hours, and still
>>>>>>>>>>>> don't
>>>>>>>>>>>> have
>>>>>>>>>>>> a suitable solution that leads to nicely-formatted notebooks
>>>>>>>>>>>> within
>>>>>>>>>>>> blog
>>>>>>>>>>>> posts.
>>>>>>>>>>>>
>>>>>>>>>>>> For those of you familiar with the new nbconvert: what is the
>>>>>>>>>>>> reason
>>>>>>>>>>>> for the
>>>>>>>>>>>> changes in the default CSS styles between nbconvert 1 and 2?  Is
>>>>>>>>>>>> there
>>>>>>>>>>>> a
>>>>>>>>>>>> good way to recover the old style sheet within the new codebase?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>  Jake
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> IPython-dev mailing list
>>>>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Brian E. Granger
>>>>>>>>>>> Cal Poly State University, San Luis Obispo
>>>>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> IPython-dev mailing list
>>>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> IPython-dev mailing list
>>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> IPython-dev mailing list
>>>>>>>>> IPython-dev at scipy.org
>>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian E. Granger
>>>>>>>> Cal Poly State University, San Luis Obispo
>>>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>>>> _______________________________________________
>>>>>>>> IPython-dev mailing list
>>>>>>>> IPython-dev at scipy.org
>>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> IPython-dev mailing list
>>>>>>> IPython-dev at scipy.org
>>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian E. Granger
>>>>>> Cal Poly State University, San Luis Obispo
>>>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com