fix raw_input CSS#5331
Conversation
I had to express padding in px, not em for consistent appearance. I'm not sure why.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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:
