Less css #2708
Less css #2708
Conversation
|
fantastic stuff. as a plugin writer, i would love to be able to use LESS when building new widgets. what relationship does this have to the larger JS/HTML refactor? In that vein, it seems like picking up an existing LESS-ful framework like bootstrap could be beneficial. I have found that my code has gotten much cleaner on the JS side after dropping bootstrap jquery-ui for page basics... and the theming is much, much cleaner. of course, the jqui stuff would all still work. |
|
Are you saying it's much better after dropping jquery-ui, or after dropping bootstrap? |
|
Yes, we want to move to bootstrap. |
|
From what I've seen of less (we have someone that is moving the Sage notebook to it), +1 to the idea. |
|
using more bootstrap than jqui. I have found that I think more clearly base bootstrap doesn't create magic temporary/hidden/intermediate/wrapping
|
|
Matthias, do you think we should start to use prefixed css class names like On Thu, Dec 20, 2012 at 5:04 AM, bollwyvl notifications@github.com wrote:
Brian E. Granger |
Is it to prevent conflict with bootstrap ? If it is for embedding/nbviewer...etc you just "namespace" the css with a nesting rule Which will effectively apply the css only to the element that are inside the `#ipython' div... |
|
But if the parent page has the same classnames, some of its styles could be erroneously applied to the IPython part. |
|
And if the embedding page use a bootstrap theme that conflict with our, we are also screwed, the same with jQuery UI. The other risk of embedding will be that boilerplate might not be applied and you will have some inheritances you dont want. We can be careful while creating new css-classes, but I'm not sure it is worth it for now, we will encounter collision elsewhere. I also would really like if jQuery UI classes where not manipulated with javascript. |
|
Yes, both to prevent conflicts with Bootstrap but also to enable better I think we really do need to do more than simple elements nesting, to On Thu, Dec 20, 2012 at 9:03 AM, Bussonnier Matthias <
Brian E. Granger |
|
Matthias, What prefix should we use? ip? ipynb? ipy? I completely agree that it would be wonderful to get rid of the jquery ui On Thu, Dec 20, 2012 at 9:25 AM, Bussonnier Matthias <
Brian E. Granger |
|
Short from my phone. I can do this as part of this pr. I'm leaving in a few hours, so my availlability will vary a lot durring the Also i will be stuck with windows I hope i'll be able to install a VM.
|
|
If we go this way.
I'm + 1 on staying on browser side compilation, |
|
I see no disadvantages to client-side css compilation, as your performance haven't checked the code, so I don't know whether you have the compiled If you are talking compilation at runtime, it seems like adding node.js re: runtime, server side compilation. webassets, the python module, which
|
|
The python compiler have no commits in 2 years. Advantage of compiling browser side is that user can override 1 less file Also for now we don't have any build step for the notebook, It will greatly On Sat, Dec 22, 2012 at 10:26 PM, bollwyvl notifications@github.com wrote:
|
|
new Either use |
|
Need to be rebased. |
ghost
assigned
|
Ok, should merge cleanly again. |
|
Bootstrap css added (not the Js plugins/ images) There are a few glitches here and there, but nothing serious, just ugly. I replace the "project folder" in dashboard with a breadcrumb not clickable yet, but it might be a way to "Navigate" the folder structure. |
|
rebased on top of master to avoid the few conflict. |
|
OK I will try to review this soon. On Sun, Jan 20, 2013 at 11:55 AM, Bussonnier Matthias <
Brian E. Granger |
|
Css still need some tweaks with the current merge of celltoolbar. |
|
Just hacked up an inventory of existing notebook elements that could (not saying should, as it means more work!) use bootstrap javascript components, with some notes on where future components could use these. further, the dev community seems to be picking up speed on building stuff "the bootstrap way," but the jquery ui ecosystem still strictly dominates in terms of available components. actually, one of the items from that post includes a less-ful theme of jq.ui to make it more bootstrap-like... this could be great for getting consistent visuals, while keeping the goodness that is jq.ui, and would tie in nicely to the effort on this ticket Legend👍 useful Transitions: 🎱
Modal: 👍
Dropdown: 👍 👍
Scrollspy: 🎱
Tab: 🎱
Tooltip: 👍
Popover: 👍
Alert: 👍
Button: 👍 👍
Collapse: 👍
Carousel: 🎱
Typeahead: 🎱
Affix: 🎱
|
|
Thanks for the comprehensive review ! With some comment though. Tooltip are written fully from scratch. I didn't found anything even close from what we have now. Scrollspy could be use to keep current focused cell in focus when new output arrives above. I would like for the "celltoolbar" a kind of affix, where it stick up the screen when the cell bleed above See what I mean ? |
|
great stuff. first off: will this become another line in the
does the message format already account for this? haven't sniffed much of I have found BS tabs a bit easier and more semantically-sound than jq.ui
we used d3/svg for this... is there a targeted browser that supports I could envision a notebook add-on which, in exchange for 20px of
|
we'll need it for the ipynb > * converter.
We'll see.
Not supported yet on master, but it is on Emacs client.
This is purely frontend specific.kernel is agnostic that it runs from a notebook.
look in "closed PR" someone had a draft.
It shouldn't be 'that' much entangled.
I do not get everything, but you could try. |
Yes, jinja2 will be a dependency of the notebook from 0.14. It is a |
|
The notebook page is also much closer. A few more things:
Later tonight i will try to finish looking through your css sample notebook, but this is getting closer. |
Quick note to myself, does it apply to other pages like dashboard ? |
|
Not sure if you are asking me a question - I do think we should have On Tue, Jan 29, 2013 at 10:06 PM, Bussonnier Matthias <
Brian E. Granger |
No, I just need to check that the use_less flag also have an effect on other pages, I might have forgot some templates modifications. |
Done
Not changed.
Will make sens when you'll have to make them clickable to browse folders... A few more things:
Should be fixed
Also fixed... this one was hard.
I can't differentiate myself...
Hum, strage, font-type is set to monospace still..
moved in examples/tests |
Now it does. |
|
Ok, I guess I fixed everything. |
|
Things are really looking good.
|
|
While the printnotebook view is disabled, I see that all of its files, its its tornado handler are still there. Do you mean to remove them? Any reason to keep them around? |
|
So the only things I see are:
|
it seem to have been for quite a while commit 0c51946afcf388c6f7515846d9bb85cff12c90a8
Author: Brian E. Granger <ellisonbg@gmail.com>
Date: Fri Jul 22 17:07:35 2011 -0700
Updating font-sizing to use the YUI protocol.
diff --git a/IPython/frontend/html/notebook/static/js/pager.js b/IPython/frontend/html/notebook/static/js/pager.js
index a6ce743..707e666 100644
--- a/IPython/frontend/html/notebook/static/js/pager.js
+++ b/IPython/frontend/html/notebook/static/js/pager.js
@@ -81,9 +81,8 @@ var IPython = (function (IPython) {
Pager.prototype.append_text = function (text) {
- var toinsert = $("<div/>").addClass("output_area output_stream monospace-font");
- toinsert.append($("<pre/>").addClass("monospace-font").
- html(utils.fixConsole(text)));
+ var toinsert = $("<div/>").addClass("output_area output_stream");
+ toinsert.append($('<pre/>').html(utils.fixConsole(text)));
this.pager_element.append(toinsert);
};but indeed, removing it bring back monospace font.
Do you mean background ? I always have #ababab for border ... the background was different still
It will probably be easier to reenable the print view. and I would prefer to remove in a separate PR to undo more easily if needed. Also one can still access it by adding /print manually |
|
I do mean the border. Let me try to describe a bit more. When you are editing a markdown/text cell, it shades in the input area and adds a border to it. The fill color looks fine to the eye, but the border is darker than the border around the code cell input area. It is most noticeable when you have the celltoolbar open, as the ctb has the correct lighter border compared to the input area.. Let's worry about the pager formatting in a later PR. I am fine with you plan for the printview, I just wanted to make sure it wasn't a mistake to leave that stuff there for now. |
|
Matthias, Not sure if you are still up, but do you want to IRC about this PR? I am On Thu, Jan 31, 2013 at 4:37 AM, Bussonnier Matthias <
Brian E. Granger |
|
I think this is ready, great work! |
Edit : TODO
[ ] prepare nbviewer for transitionStart to replace css by less.
For now, in browser compilation, kind of much better to develop and test as you don't have to restart.
Start replacing hardcoded value with variable.
(try setting
@notebook_backgroundinvaraibles.lessto a nice light pink, and the rest follows)Start removing jquery-ui-class references in javascript.
Eg, instead of toggling
ui-widget-content ui-corner-allon cell selection/unselection, replace by a 'selected' class and put the correct css inBrowser side parsing should allow things like user only defining css variable in their
.profile/static...and it should work.(parsing time is ~+80 ms on my laptop according to less)
Just for your eyes, what you can do with variables...
Current style is unchanged of course.