[IPython-dev] Just looking for feedback before PR

Matthias Bussonnier bussonniermatthias at gmail.com
Thu Nov 15 14:01:34 EST 2012

Short from my phone. Longer answer later.

Heading cell are used in conversion to latex/other to give
section/subsection... Etc. Which is much harder otherwise as you could mix
and match markdown and html hx tag. Could also help doing a notebook TOC
Le 15 nov. 2012 19:37, "Carl Smith" <carl.input at gmail.com> a écrit :

> Cheers for the detailed feedback Brian
> >  I see that you have just applied these styles to text cells, rather than
> > the rendered_html class.  Right now the tour version you are dealing with
> > puts the heading cells in the markdown rather than using actual heading
> > cells.  I have a PR open that updates all example notebooks to use actual
> > heading cells:
> >
> > I think we want to have these styles applied to the heading cells, as
> well
> > as HTML output, so I would use the rendered_html class.
> That's an easy edit. No problem.
> Can I just ask why we have header cells at all? It may be a daft
> question, but I always used Markdown to create headers, so I never
> knew what the header cells were for. Is there a good reason to have
> more than just code and Markdown cells?
> > But there are a few bigger issues here - I think I missed the earlier
> > discussion - so I feel like I am playing catch up.  Some general
> thoughts on
> > this.
> It was discussed while the ML was very quiet. I think John Hunter was
> ill at the time. I remember the list being really quiet for a couple
> of weeks.
> > * There is a very specific look I have been trying to create with the
> > notebook, namely that of a clean, empty piece of white paper.  This means
> > have a very simple, uncluttered look with an absolute minimum number of
> > visual distractions and minimal styling.  Even adding the subtle shading
> to
> > the code cell's input area was a difficult decision, but one that I think
> > does make sense.  I think this is really important and is a key part of
> the
> > notebook's user experience.  In light of this, I think the style you have
> > created, while very good looking, doesn't match these overall design
> goals.
> > Because of this, I don't think it makes sense to have it as the default.
> I understand your point here. I really like the Notebook's super clean
> look, and know minimalism is more difficult to get right than it seems
> like it would be until you've tried it. I'll come back to this point.
> > * I regularly use custom styles in markdown cells to customize the look
> of
> > individual notebooks.  This is such a simple and elegant solution for
> > customization.  We should create a place on the github wiki that points
> to
> > css files on gists that have nice styles such as this, that users can
> plug
> > into notebooks.  If this turns out to be a nice way of working, we could
> > think about including this customization point in the notebook's (yet to
> be
> > written) configuration UI.
> Maybe we could explore adding a simple stylesheet to each new Notebook
> profile. When the profile is used, the Notebook could check for that
> stylesheet file. If the file is empty or absent, then no style is
> applied, else it'll use whatever's in the stylesheet.
> This means users with a few profiles and no incentive to edit the
> styles would have a few copies of the same file on disc, but these are
> small files and are not using any RAM. The benefits would be that
> there'd be no need for a new config option, just delete the file to
> disable the styles, the user would have a readily accessible file to
> hack at, the file serves as a template, which is handy for those of us
> who know very little CSS, and it allows profile based configuration.
> > * I am willing to consider changing the notebook styling, but there has
> to
> > be a clearly identified problem each change is solving.  One change that
> I
> > have thought about is that the current heading styles take up a bit too
> much
> > vertical space.  That makes it difficult to view notebooks on screens
> with
> > small vertical real estate.  This is a very specific problem that has a
> > specific, focused solution.
> As it stands, I don't personally see any reason to change the Notebook
> styling at all, but I haven't used the header cells, so I can't
> comment on that issue. I really like the look of the Notebook, and I'm
> naturally a merciless critic when it comes to art and design. It's my
> background.
> > * In general, we are using a small amount of border radius on all of our
> > rectangles with borders.  The sharp corners of the heading divs look
> > inconsistent with the rest of the UI look.
> An easy edit.
> > * I think the fill colors of the different heading levels need to have a
> > more consistent color scheme.  For example, right now the h1 color is
> grey,
> > but the h2 level is the same as the code cells.  Could you try to just
> > lighten or darken the code cell's fill color for the different heading
> > levels?
> Is that a typo, or are you asking me to change the *code cell* fill
> colour? I'm thinking to lighten up the headers. I've no reason to edit
> the code cell CSS. It looks spot on already.
> > * I am finding that font size used in notebooks is very specific to the
> > purpose of the notebook.  For example, in presentations I up the
> font-size
> > dramatically.  I see you are using a larger font size (16pt for text)
> that
> > may or may not make sense for users.
> That's probably just my personal taste coming through. I love
> anti-aliasing, so I tend to give every character plenty of pixels to
> play with. It probably looks a bit too big to most people.
> > * It would be wonderful if we could start to use less for all of our css
> -
> > even cooler if users could enter css using less in markdown cells.  That
> > would make it *much* easier to tune the look with a few lines of
> css/less.
> This sounds like a good idea, but I've not actually used less to know
> how well it works. I'll look it up tonight.
> I'm glad you like the general idea, and it's really valuable to hear
> the thoughts of such an experienced user. You can foresee cases that
> I'm not envisioning, where my approach might not be a good fit.
> Thanks again for your time Brian.
> Cheers
> Carl
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121115/ca9c90c1/attachment.html>

More information about the IPython-dev mailing list