Re: [csswg-drafts] [css-boxmodel] Allow the texts in input element to be painted into the top and bottom padding area.

The Working Group just discussed `[css-boxmodel] Allow the texts in input element to be painted into the top and bottom padding area.`, and agreed to the following resolutions:

* `RESOLVED: Spec this in CSS UI 4`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-boxmodel] Allow the texts in input element to be painted into the top and bottom padding area.<br>
&lt;dael> github:<br>
&lt;dael> dbaron: I can comment a bit. This is a long standing interop issue that should be spec somewhere. Overflow behaves slightly differently on input then everywhere else. top and bottom padding is different then left and right. Gecko had to imitate the weird behavior of other impl because it was a compat issue.<br>
&lt;dael> astearns: You're in favor of spec this and it looks like there's rough consensus on putting it in overflow 3<br>
&lt;dael> bradk: Isn't this more of a shadow dom thing where shadow dom doesn't match between brwosers?<br>
&lt;dael> dbaron: I don't think that's why the problem exists. IT's that it responds differently to top/bottom padding to left/right padding. It doesn't have anything to do with the shadow dom<br>
&lt;dael> bradk: Is it a bug or does it need to be spec?<br>
&lt;dael> dbaron: I needs spec because there's sites depending on it. We were last to impl and got substantial # of bugs.<br>
&lt;dael> Rossen_: We went through internap re-impl of the controls to make them more driven my html/css and I think what this issue suggests is for some controls there are missing box model features that would allow one to create the compat input type. We had to add a custom/private flexbox property value that's not publicly exposed to handle that behavior.<br>
&lt;dael> Rossen_: So what bradk is saying is partially true that we have a different structure inside the shadow dom, but I also know there are some missing layout primitives that would allow one the flexibility of creating a compat control and I think this is one.<br>
&lt;dael> bradk: I don't know enough about it to object. It just seems weird we're spec special rules for inputs.<br>
&lt;dael> fantasai: I would put this into the UI b/c it seems more a quirk about the control then about overflow impl. You could have it so the input can be sized to take the padding area so its content area expands into padding in veritical axis. That would satisfy constraints w/o overflow<br>
&lt;dael> fantasai: We don't have to spec how it works, but if this is a behavior of form controls we can put it in UI.<br>
&lt;dael> dbaron: I don't think it makes that much sense floating in UI spec.<br>
&lt;tantek> I tend to agree that it should go in box model<br>
&lt;dael> Rossen_: What are the other use cases where we need this behavior so it doesn't belong to UI. If we have those use cases this should go to box model. If we only need it for input parking it in UI for now is fine.<br>
&lt;dael> dbaron: I don't think it has use cases. It's that htis is different. If impl did it the normal way that would be fine, but this isn't want impl do and people depend on it.<br>
&lt;dael> bradk: Is it related to how the ink for a descendor can go into padding?<br>
&lt;dael> dbaron: That's part of the overflow prop. If you have overflow hidden that's cut off.<br>
&lt;dael> tantek: If this is for compat only another option is the compat spec.<br>
&lt;dael> Rossen_: I like that.<br>
&lt;dael> dbaron: I think the goal of the compat spec is it wants to drive itself out of existance as it moves things into other specs.<br>
&lt;dael> tantek: I thought it was a parking ground for things we wish didn't exist.<br>
&lt;dael> dbaron: I think it's for things the spec authors wish didn't exist, but it does in the real world so it needs to exist.<br>
&lt;dael> tantek: A compat section in box model?<br>
&lt;dael> Rossen_: I don't htink there's enough merit for this in box model. Only use case is to allow overflowing text on top of padding area for input type text controls. It's a very quirky control sepecific behavior that we all emulate. Internally we do use something similar to wahts' rpopo here which is allow the quirky bad behavior to exist so we have web compat.<br>
&lt;dael> Rossen_: I don't believe it's requested for general box model. It's too specific. If we put it in box model people will begint o desire it and have quirky use cases.<br>
&lt;dael> astearns: If there's use cases then there's a reason for it to be there.<br>
&lt;tantek> per Rossen reasoning I would prefer Compat spec<br>
&lt;dael> astearns: We're at time. It does seem like it should be css ui, but it is overflow as well so perhaps a note in overflow about this quirk.<br>
&lt;dael> dbaron?: sgtm<br>
&lt;dael> astearns: Obj to spec this in CSS uI 4<br>
&lt;dael> tantek: Everything Rossen_ said about box model is true to UI.<br>
&lt;dael> Rossen_: Use case is input<br>
&lt;dael> tantek: Use case is compat<br>
&lt;dael> dbaron: UI is the placeholder for the to be written form control spec. THat's why it's suggested.<br>
&lt;dael> Rossen_: Precisely.<br>
&lt;dael> tantek: I"m a -0 on it.<br>
&lt;dael> Rossen_: As soon as we have a form control spec I"m in full support of moving the quirk there.<br>
&lt;dael> RESOLVED: Spec this in CSS UI 4<br>
&lt;dbaron> s/dbaron?/dbaron/<br>
&lt;dael> astearns: With that we're done. Thanks everybody for calling.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 10 January 2018 18:03:14 UTC