Open basile-parent opened 1 month ago
The approach you suggest here is going to result in a breaking change. I do understand the intent here, but I would rather not make a breaking change for a relatively simple feature introduction. I'm ok with the idea of additional contentEditableProps (can even call it attributes
), but there's no need to remove/alter the contentEditableClassName
.
Your right for breaking changes. I will get class name back.
Can I push a deprecated notice on it (as it's covered by the general "attributes" / "props") ? That way, you could delete it in few versions.
The "props" suffix seems clearer for me (as you pass props directly to this child componen) but if you think "attributes" is better, I'll follow you ^^ Do you wants just "attributes" or "contentEditableAttributes" ?
@petyosi The className is back and flagged deprecated. For the naming convention, I let you decide (see previous comment)
Hello @petyosi, do you think this PR (and the #552) could be merged ? Thank you :-)
@basile-parent Referring to both PRs, I'm very hesitant to merge a large change given that the final outcome should be a couple of changed attribute values.
This being said, I will try to find the time to examine the intended attribute change from your PRs and find a way to apply those changes in a less intrusive manner.
OK, as you want :-) Accessibility is always a matter of few attribute values ^^
Thank you for your time
Second part of the improvments proposed in #544 : giving access to all content editable component props so we can customize the textbox as we want (such as putting an id, a dynamic aria-label or any a11y prop we want)
I add some examples in the "examples" folder