Skip to content

fix raw_input CSS #5331

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 20, 2014
Merged

fix raw_input CSS #5331

merged 3 commits into from
Mar 20, 2014

Conversation

minrk
Copy link
Member

@minrk minrk commented Mar 11, 2014

I had to express padding in px, not em for consistent appearance. I'm not sure why.

closes #5324
before:
screen shot 2014-03-10 at 3 16 05 pm

after:
screen shot 2014-03-11 at 16 08 31

I had to express padding in px, not em for consistent appearance.
I'm not sure why.
line-height: 1em;
font-family: @monoFontFamily;
// for some reason, em padding doesn't compute the same for raw_input
// that is not the first input, but px does
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true for both FF and Chrome? I remember experiencing some really weird padding behavior because the two browsers sometimes disagree on when padding should be collapsed between two padded elements.

@ellisonbg
Copy link
Member

The prompt in the input area is sticking outside the area itself:
screen shot 2014-03-13 at 4 21 12 pm

line-height: 1em;
font-family: @monoFontFamily;
// for some reason, em padding doesn't compute the same for raw_input
// that is not the first input, but px does
padding-top: 5px;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why this is needed. The div.output_subarea already has a top padding in em. This just overrides that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's needed because the value is wrong when computed in em. It only comes out right when using px explicitly.

@ellisonbg
Copy link
Member

I see why we have vertically compressed the input area here. It allows the textual representation to have the same height as when the user is typing into the field. If we want to keep that effect, then I think we need to work on the styling of the input area a bit more:

  • Need more than a 1px left padding.
  • Top and bottom paddings should be symmetric.
  • We might want to remove the border so it doesn't look so crammed vertically. But the border provides useful information to the user.

Other CSS related comments:

  • We are reusing the input_prompt CSS class to mean two separate things (here in raw input and another in the actual input prompts). It works because one is a div and one is a span, but we shouldn't rely on that.
  • We are also reusing the raw_input CSS class in two places here. Probably should use something different for one of these as well.

Here is an input area with more symmetric vertical paddings. The prompt would need fixing (along with a display of inline-block (so padding works).

screen shot 2014-03-13 at 4 41 20 pm

@minrk
Copy link
Member Author

minrk commented Mar 14, 2014

We are also reusing the raw_input CSS class in two places here. Probably should use something different for one of these as well.

I switched the div to raw_input_area and the span to raw_input_prompt

Here is an input area with more symmetric vertical paddings.

And a good example of why I didn't do it that way. The CSS shenanigans here ensure the baseline of the prompt text aligns with the input text, both when. Your example does not align.

minrk added 2 commits March 13, 2014 20:45
for once, vertical-align: baseline is the right choice
@minrk
Copy link
Member Author

minrk commented Mar 14, 2014

I just pushed some simplifications. For once, vertical-align: baseline is actually what I want, and that simplified things a lot. I backed off trying to tighten the layout. It moves more when you submit the input, but it's simpler and cleaner.

@minrk
Copy link
Member Author

minrk commented Mar 14, 2014

screenshot:
screen shot 2014-03-13 at 20 48 00

@ellisonbg
Copy link
Member

This looks great, merging!

ellisonbg added a commit that referenced this pull request Mar 20, 2014
@ellisonbg ellisonbg merged commit a4dd0cb into ipython:master Mar 20, 2014
@minrk minrk deleted the raw-input-css branch March 31, 2014 23:36
mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Style of raw_input UI is off in notebook
3 participants