- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Jan 2018 02:21:49 +0000
- To: public-css-archive@w3.org
I'm OK with putting this in UI-4 this, but we're going to need more details about what the behavior is. The spec cannot just be to allow text to be painted in the top and bottom padding, because I don't think there's anything forbidding it in the first place. If you do the same thing with a div instead of the input, the content will overflow into the padding. I suppose that if we're defining how `<input>` does it's layout, we actually need to say more than just "can paint into (logical) top/bottom paddings but not left/right paddings", and actually define the actual layout model: - the text is centered vertically despite no css property asking for it to me (and how is it centered, by the way? Is that baseline based, bounding box based, embox based...?) - The `line-height` property has no effect - it preserves white space and doesn't wrap regardless of what the when the `white-space` property says otherwise? That `text-overflow:ellipsis` takes effect even when `overflow` is `visible` (which would turn it off on other elements)… I suppose there's more, but I don't know it off the top of my head, and would greately appreciate input from browsers, so that I don't have to do much reverse engineering. By the way, is this best explained in terms of a dedicated and simple (given that there's only ever a single line of plain text) layout model, or should this be explained in terms of existing CSS things applied to various anonymous / shadow boxes, with some amount of property hoisting? -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1941#issuecomment-356803852 using your GitHub account
Received on Thursday, 11 January 2018 02:21:51 UTC