-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
fix raw_input CSS #5331
Conversation
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 |
There was a problem hiding this comment.
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.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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:
Other CSS related comments:
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). |
I switched the div to raw_input_area and the span to raw_input_prompt
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. |
for once, vertical-align: baseline is the right choice
I just pushed some simplifications. For once, |
This looks great, merging! |
fix raw_input CSS
I had to express padding in px, not em for consistent appearance. I'm not sure why.
closes #5324

before:
after:
