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

Brian Granger ellisonbg at gmail.com
Fri Jul 5 01:22:26 EDT 2013


> 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.

The nesting will prevent ipython's styles from affecting your own.
But it would still be possible for your own styles to affect ipython
managed elements.  css has a notion of priority.  If you define
styling for a cell class that has higher priority than our nested
rules, it will win out.  The only way to avoid that is to use truly
different names for css classes.

> - make no global CSS modifications (e.g. global-level header formatting,
> page formatting, body formatting)

Well, except for the fact that we use bootstrap, which does these
things...I don't see any way around that.

> - 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.

Yes, this should definitely work.

> 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
>



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



More information about the IPython-dev mailing list