Follow up of bug 943966. We would like to adjust height of input[type=color] to match other input types, to be more consistent. Also, I noticed input type color doesn't have the same vertically alignment as input type text or input type button. I think we would like to fix this, but as they are supposed to share the same CSS rules, I'm not sure why we end up with discrepancy. Looks like removing the "display: block;" fixes the alignment issue, but breaks the rendering... dholbert suggested adding a text node might fix the issue, as different alignment rules will apply.

(In reply to Arnaud Bienner from comment #0) > Looks like > removing the "display: block;" fixes the alignment issue, but breaks the > rendering... (from the color-swatch, correct?) > dholbert suggested adding a text node might fix the issue, as different > alignment rules will apply. Yeah... Since (IIRC) other buttons & form controls derive their height from shrinkwrapping some text (and derive their baseline-alignment position from getting the baseline of that text), we might need to do that here as well.

(In reply to Daniel Holbert [:dholbert] from comment #1) > (from the color-swatch, correct?) Yes. I tried to add a new Text node (something similar to what nsGfxButtonControlFrame does) but it didn't fix the alignment issue. Anyway, setting "vertical-align: bottom;" to input[type=color] fixes the issue for me here. It's a shame I didn't noticed this before. And I also set the height to 25px to match other input types. But then I noticed the height of input type color changes while zooming int/out. I'm not sure why it happens, but I don't think this the behavior we would like to have.

Anyway, here is a patch which makes things better. I think it's harmless to integrate if it looks fine for you, but I'm still worried about the "height changing when zooming" issue (but this can probably be part of another bug or at least another patch).

Comment on attachment 8346888 [details] [diff] [review] align_input_color.patch (In reply to Arnaud Bienner from comment #2) > Anyway, setting "vertical-align: bottom;" to input[type=color] fixes the > issue for me here. It fixes the issue for me, too, at normal font-sizes; but if I add some larger font-size text, it throws us out of alignment pretty badly. e.g.: data:text/html,<input type="color" style="vertical-align: bottom"><input><i style="font: 100px serif">abc</i> So I don't think vertical-align:bottom actually fixes things for us here. > And I also set > the height to 25px to match other input types. I don't see any mention of 25px for other input types in forms.css, so while this may happen to be the height of other form controls on your platform, I don't think we can hardcode this and call it good. :) I believe the heights of other form controls are determined by shrinkwrapping a line of text or using em units or something like that (more complex than just a hardcoded pixel size). Note that, for example, these are much taller than 25px: data:text/html,<input style="font: 50px serif"> data:text/html,<input type="submit" style="font: 50px serif"> > But then I noticed the height of input type color changes while zooming > int/out. I think I see what you're seeing, but I don't think the <input type="color"> is actually changing its height (at least, its computed style remains the same). If you have it next to another form control and zoom in/out, the *other* form control actually changes *its* height (subtly), as exposed in computed style. I think that's a result of the height being dependent on the font-size, or something like that. (But in any case, I wouldn't worry about the zooming behavior too much, like you said.)