-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
prevent calendar showing if readonly attribute is present on the input #2759
Comments
In other versions, this has been a bit of a back and forth with users. In some cases, people want it to behave as you have suggested, in other cases people want to disable the input field so that their end users are forced to use the picker and not manually typing. |
Can confirm. We force users to use the picker by setting the input to readonly. |
I agree with @Antal1609 we also use the readonly attribute to force users to enter a date via the picker. Ultimately the textbox is still readonly to the user, as it can only be updated via code. A big advantage of this method is that the styling of the textbox remains unchanged for readonly elements in many UI frameworks so the user is still invited to click the box, whereas disabled elements look different. |
@Antal1609 comments on a use case, where the value of the the element should be editable (with the widget) and submitted to the server. But what if submitting is required, but editing not wanted. Currently, this is a pain to implement, if the date element is editable with the keyboard and the widget. |
Prerequisites
Proposal
Software prevents opening the calendar if disabled attribute is present on the input. Why not also for readonly?
It is a simple change (perhaps). in tempus-dominus.ts we can change the function _toggleClickEvent :
Motivation and context
Readonly input shuld not be changed.
The text was updated successfully, but these errors were encountered: