Don't clip range/checkbox/radio overflow to border box.

[emilio]

This fixes #10024.

• At least two implementers are interested (and none opposed):

  • Gecko
  • Chromium transitively via Use UA styles rather than prose to define <input> clip. #9994, probably :). This is a spec bugfix to match behavior of every browser.

• Tests are written and can be reviewed and commented upon at:

  • https://bugzilla.mozilla.org/show_bug.cgi?id=1872509

• Implementation bugs are filed:

  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1872006
  • Others: N/A, this is a bug fix to match existing behavior.

• MDN issue is filed: …

• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/rendering.html ( diff )

[emilio]

We might want to give the same treatment to checkbox/radio... People use appearance: none to build custom checkboxes, and for the non-none appearance case there's no way to cause overflow. I haven't seen issues with those in the wild tho, thoughts?

[nt1m]

@emilio I wonder if the styles should be applied on input:is([type=button i], [type=reset i], [type=submit]) instead. I would prefer avoiding applying the clip unnecessarily.

[emilio]

@nt1m, can you elaborate on why?

File inputs at least also clip overflow (and can generate overflow otherwise) cross-browser. Text-like inputs do also clip overflow, and due to text being the fallback type, it's non-trivial to define that via CSS (probably need to use revert).

So IIUC that leaves checkbox/radio/image/range left which don't need / have this special clipping behavior, right? Also the spec used to say "anything but image".

So not opposed I guess, if you have a better way to specify this, but :not(range, checkbox, radio, image) seems slightly preferable to me. Otherwise we need prose to define what text inputs and such do which doesn't seem amazing.

[emilio]

That is, from my perspective, the most we can get to explain replaced-ish controls like "(inline-)block + overflow: clip, with unspecified stuff inside", the better.

[emilio]

#10025 (comment) was indeed a real issue, see https://bugzilla.mozilla.org/show_bug.cgi?id=1872509, so I've updated the PR accordingly.

[mfreed7]

Seems reasonable to me, assuming your compat analysis shows that this is web compatible.

[annevk]

@emilio data:text/html,<input%20type=file%20style=width:10px;height:10px> does not clip for me in Safari. In fact, WebKit has code that ensures all form controls get painted correctly when their CSS box is smaller than the size they need for painting.

[annevk]

cc @pxlcoder

[emilio]

@emilio data:text/html,<input%20type=file%20style=width:10px;height:10px> does not clip for me in Safari. In fact, WebKit has code that ensures all form controls get painted correctly when their CSS box is smaller than the size they need for painting.

That doesn't match the spec either before or after my change tho, right? Gecko has always clipped file inputs, and forcefully since https://bugzilla.mozilla.org/show_bug.cgi?id=1543477 (to match Chromium and the spec).

[annevk]

I think with respect to #9994 that's true, but the claim above about it happening across browsers is not. And as you are now suggesting normative changes I do think it warrants consideration.

[emilio]

Yeah, I think I mis-tested Webkit, thanks for pointing that out. However I think this is still a progression (and the change proposed doesn't change behavior wrt file inputs in particular, fwiw).

[annevk]

I think what I'd like is that as part of this change we add test coverage for all types and get agreement that's where we want to end up. So we don't keep changing this around. And for WebKit that should probably be decided by @pxlcoder and @nt1m among others.

[emilio]

Tests in https://phabricator.services.mozilla.com/D197457 cover all input types, fwiw. Other than that, I agree. I think barring any further compat issues (which are, IMO, unlikely) this is a much better state to be in than pre - #9994, and is a step to have beter interop here.

[annevk]

If we do this as-is and thus agree clipping is preferred, #9546 (switch) will need to add , input[type=checkbox i][switch] presumably.

[emilio]

If we do this as-is and thus agree clipping is preferred, #9546 (switch) will need to add , input[type=checkbox i][switch] presumably.

You mean set overflow: clip explicitly on input[type=checkbox][switch]? I'm not convinced you'd want that.

In general I don't think "clipping is preferred" is correct. Just "clipping is the long-standing interoperable behavior for most input types, and this defines it in a way that integrates correctly with other CSS features, instead of magic prose".

[emilio]

It also happens to be the case that a negation is the easiest (only?) way to target text inputs with the rule, given the "random input type falls back to text" behavior.

[annevk]

I discussed this with @pxlcoder and we're okay with going in this direction. We haven't fully evaluated yet if this is possible for all controls, but making incremental progress is okay with us. Does that work?

If so, I can merge this.

[emilio]

That sounds good. I'll push the tests then. Thanks Anne!

[annevk]

Hmm, I was about to merge this, but upon rereading

These also don't create any overflow unless they are appearance: none, so they don't need the magic clip prose anyways.

strikes me as incorrect for WebKit on macOS which does have its own minimal sizes for controls for painting purposes. Would that still require magic clip prose then?

[emilio]

strikes me as incorrect for WebKit on macOS which does have its own minimal sizes for controls for painting purposes. Would that still require magic clip prose then?

Not really right? My understanding is that you're not clipping it, so this would preserve your current behaviour.

[annevk]

Ah right, but I should remove the remark as they can cause overflow in some implementations for appearance:auto.