[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