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

Min RK benjaminrk at gmail.com
Fri Jul 5 02:33:15 EDT 2013 

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

More information about the IPython-dev mailing list