-
-
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. |
Any update to restore "readonly" to its "meaning"? |
Please see this announcement: #2694 From the sample code provided in issue #2912 I personally feel that the control is behaving as expected. I would suggest that if the readonly attribute on a text box affected separate and distinct elements outside of that textbox it could lead to confusion and unexpected behaviour. Whilst there are probably many methods to achieve the functionality that you describe in issue #2912, I have found that instead of using data attributes, attaching a 'click' event handler to the 'button' and triggering display (or not) of the widget based on the status of the readonly attribute of the text input to be the simplest. |
@vt-cloud I mean, why was ignoreReadonly parameter removed? I can't use disable because it removes the input value from the serializeObject so I have to use readonly to have it in there but the user may not change it themselves depending on what they are entering. Sad about the announcement, I searched a long time for a viable library and implemented in early October... just my luck |
I have no idea, I'm not the developer. However there are at least half a dozen ways to achieve what you need and they can all be implemented with a line or two of script, here are a few suggestions:
Options 1 and 2 are what I use depending on the situation and take just a moment to implement. Option 3 is a bit of a 'hack' in my opinion, but happens so fast that it is usually seamless and I have seen it used fairly often over the years. I personally use two or three date picker libraries and this is still the most reliable/versatile. All the others have issues that their developers do not seem to want to fix, such as incorrect paging when the month has < 30 days or awful display of the time picker component. |
@vt-cloud well I did a hacky thing now by removing the element and adding it again without the picker as I don't see how to use option 1, which takes my preference. I'm no expert in javascript or typescript or whatever it is these days :) Thank you! |
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: