1370464 - [DateTimeInput] Baseline of input box is different from other inputs (e.g. text)

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, enhancement)

Description

[Jessica Jong [:jessica] (inactive)]

Follow-up to bug 1311857. While adding reftests in bug 13118157, we noticed some tests failed because the baseline of <input type=time> is different from <input>. We used `vertical-align: top` to workaround the issue.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a testcase.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of misalignment

Comment 3

[Daniel Holbert [:dholbert]]

This misalignment *might* just be due to us using a different font inside of datetime inputs vs. other inputs, perhaps...?  [if we do use a different font -- I'm not sure]

If so, then maybe this isn't unreasonable after all as long as it's only ever an off-by-one-pixel sort of issue.  That would mean we're dutifully baseline-aligning the text inside the inputs with the line that they participate in, and that just happens to position the edges of the field at slightly different positions.

It would be worth checking (locally) whether this issue goes away if you use a consistent font in the internal styling of the two types of inputs.

Comment 4

[Jessica Jong [:jessica] (inactive)]

You are right again. :)

The misalignment is due to different font inside of datetime inputs vs. text input.
We use a monospace font inside of datetime inputs, since we don't want the input box width to be changing every time user changes the value (and we need to use inline span elements so that bidi algorithm works correctly).

Comment 5

[Jessica Jong [:jessica] (inactive)]

Attachment: screenshot of baseline w/o font

removing the font property in .datetime-input-box-wrapper

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jessica Jong [:jessica] from comment #4)
> We use a monospace font inside of datetime inputs, since we don't want the
> input box width to be changing every time user changes the value

If that's the only reason we use monospace, I believe you can also achieve the same effect (specifically for numerals 0-9), *without* needing a monospace font, by using:
  font-feature-settings: "tnum"

More info at:
  https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature-settings
  https://www.sitepoint.com/cross-browser-web-fonts-part-3/#numerals-fractions-and-ordinals

This feature's availability does vary from font to font, though (I think), so maybe it's fine/best to stick with a monospace font.

Anyway: as long as we're using a special different font in these inputs, I think the observed behavior here is us behaving as expected (aligning inputs so that their text is baseline-aligned), so this is INVALID in that the described behavior is not actually a bug after all.  Sorry for leading you astray. :)