Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use align-content for form control centering instead of html "magic" #10396

Open
bfgeek opened this issue Jun 5, 2024 · 7 comments
Open

Use align-content for form control centering instead of html "magic" #10396

bfgeek opened this issue Jun 5, 2024 · 7 comments

Comments

@bfgeek
Copy link
Member

bfgeek commented Jun 5, 2024

What is the issue with the HTML Standard?

Now that align-content is more widely implemented we can switch the control centering magic to just use align-content instead.

We are starting to get some bug reports that web developers would desire to control this behaviour in form controls, e.g.
https://issues.chromium.org/issues/344643705

This would basically mean adding something like:

button {
  align-content: safe center
}

input[type="button" i],
input[type="color" i],
input[type="reset" i],
input[type="submit" i] {
  align-content: safe center;
}

input:not([type]),
input[type="date" i],
input[type="datetime-local" i],
input[type="email" i],
input[type="month" i],
input[type="number" i],
input[type="range" i],
input[type="search" i],
input[type="password" i],
input[type="search" i],
input[type="tel" i],
input[type="text" i],
input[type="time" i],
input[type="url" i],
input[type="week" i] {
  align-content: unsafe center;
}

And removing all the special text for the centering behaviour in the form control part of the spec.

There is a small compat risk, but we'd be happy to take on that risk.

cc/ @dholbert @emilio

@annevk
Copy link
Member

annevk commented Jun 10, 2024

Sounds nice!

cc @pxlcoder @nt1m @whatwg/forms

@nt1m
Copy link
Member

nt1m commented Jun 10, 2024

Seems like a decent idea.

@zcorpan
Copy link
Member

zcorpan commented Jun 10, 2024

The button layout magic covers more than safe centering, do you intend to keep those as-is or try to remove them also?

@Pol2507

This comment was marked as spam.

@bfgeek
Copy link
Member Author

bfgeek commented Jun 21, 2024

The button layout magic covers more than safe centering, do you intend to keep those as-is or try to remove them also?

@zcorpan - Blink M126 just rolled out with block-layout buttons enabled by default. And we didn't include the anonymous block described by that part of the spec. (I suspect this was added just for centering purposes, but you really don't need it). So I intend to remove that also.

I'll prepare a PR so we can see what this looks like.

@dholbert
Copy link
Contributor

dholbert commented Jun 21, 2024

@bfgeek is there an easy way that I can opt in to the new behavior, in my local Chrome 127 "dev channel" installation? (You mentioned enabled by default in 126, but I don't think I'm seeing the behavior, if I understand the proposal correctly. I did also try "Experimental Web Platform Features:enabled" in chrome://flags but I don't think that does it.)

RE webcompat risk: if I'm understanding correctly, this proposal does mean that buttons with display:flex or grid will start vertically aligning their content where they didn't previous do so, correct? That seems probably-fine, but it is a behavior change and could conceivably break some content. Here's a testcase to illustrate what buttons look like without vs. with align-content: safe center:
https://jsfiddle.net/dholbert/cds9jxa5/

(There's no difference for display:block, but the button's label moves from the top to the center for display:flex and display:grid. Cosmetically, it does seem like an improvement, but it is notable as a behavior-change.)

@emilio
Copy link
Contributor

emilio commented Jun 22, 2024

My understanding is that the way blink implemented this doesn't affect grid or flex, which is a bit unfortunate because it's replacing some magic for another.

@bfgeek is the idea to eventually apply this to all buttons as proposed in your comment? Or something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

7 participants