I am 👎 on doing this change. If we stopped sanitising ids, the rendered HTML would change with the next update potentially breaking applications as CSS selector may not be applied anymore. I don't think that's worth the hassle.

I see your point about the hassle. But keeping it like it is (i.e. over-patronizing) forever, isn't good either...

About breaking existing implementations, let's look at the full scenario: When you try to use something like 1-foo as id, and then notice that it's being sanitized to -foo: Would you then happily write a CSS selector of #-foo?? I bet everybody would go back and change the id!
So I doubt that changing it would really affect somebody in userland.

But keeping it like it is (i.e. over-patronizing) forever, isn't good either...

Why? What is the disadvantage of not being able to use everything as an id?

When you try to use something like 1-foo as id, and then notice that it's being sanitized to -foo: Would you then happily write a CSS selector of #-foo?? I bet everybody would go back and change the id!

I have seen enough teams where the people doing writing the CSS are not the same people that write the form types and that don't even know where the id is coming from. In those cases they will simply copy the id that they see in the HTML and reuse that in their CSS selectors.

Disadvantage: Well, just like any restriction... If using uppercase letters in variable names would be forbidden, you could surely cope with it too. But it would be annoying.
I had a real use case where an id like 1-foo would have been handy for JavaScript (split at -) - that's how I discovered this issue in the first place.

Teams: Gosh, indeed. But what I meant is: Nobody uses such a weird string as id just for fun. They certainly have some further processing in mind (like my JavaScript), and if they see that it doesn't work out, they'll probably change it back.

But I agree that some users will be affected (in my estimate only a handful), so it would be a BC break. But adding it to v8.0 seems fine to me.

But adding it to v8.0 seems fine to me.

This would still require a deprecation in 7.x.

What would you wanna write?:

Relying on the over-sanitation of weird strings is deprecated...

lol

Seriously, this only affects the generated HTML output of forms, right? How were changes like this handled in the past? Since this is not something the user is actively doing, I don't think it can be deprecated.

What would you wanna write?:

Relying on the over-sanitation of weird strings is deprecated...

lol

@xabbuh raised the valid concern of backwards compatibility. What you are proposing is a change of behavior and there might be projects our there that rely on that very behavior. I think, his remark deserves a respectful answer.

Since this is not something the user is actively doing, I don't think it can be deprecated.

You can make the behavior configurable and trigger a deprecation if the app did not opt-in to the new behavior and the new behavior would produce a different result than the old one.

lol = laughing out loud = joke
The respectful answer was immediately below.

My question was: I'm sure the HTML rendering of forms (or of anything else) has been changed in the past. How were these changes handled? I bet you didn't create a new configuration option for each minor change ;-)

I don't remember that we did a change with a similar potential impact in the past.

I bet you didn't create a new configuration option for each minor change

How's this a "minor change" again? You already admitted that it would be a BC break and suggested to ship it with the next major release.

If you want to change behavior in an incompatible manner, create a way to opt-in to the new behavior and make it the default in the next major. This is the way.