feat(datepicker): add support for choosing time #5648
Assignees
Labels
area: material/datepicker
feature
This issue represents a new feature or feature request rather than a bug or bug fix
material spec
Issue related to the Material Design spec https://material.io/design/
P2
The issue is important to a large percentage of users, with a workaround
Comments
mmalerba
added
feature
Closed
This comment has been minimized.
This comment has been minimized.
|
If there is no estimation on when this might become available, can anyone recommend a date/timepicker to use in the meanwhile? |
|
We're probably not going to have time to work on this until 2018. One possibility in the mean time is to use the datepicker for the date component and a select box or group of select boxes for the time component. |
|
Ah cheers for the heads up. I'll do that. Seems so obvious I'm not sure why I didn't think of it. :) |
This comment has been minimized.
This comment has been minimized.
Closed
|
I found this possible temporary implementation (until an official version is released): |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Im currently using https://github.com/vlio20/angular-datepicker |
1 task
|
I have just created a repository to give users ability to choose time, based on material 5 and mat-dialog. https://owsolutions.github.io/angular-material-clock-time-picker/ Is there any specific way to merge this repository into material itself? |
|
I've built a complete DatePicker with time selection forking the official module, but got no answer from @crisbeto on LinkedIn to know how to contribute it |
|
They won't accept contribution on this. Big changes like this need to have a design doc first and need to follow the official material design guideline (and the version that is currently publicly available doesn't even have datetimepicker for desktops). Just release it as a third party component. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
We have the implemented a fully working version now. All bugs are fixed, and working fine with angular 5 material. Please check these before: |
|
@torabian this issue is about integration of a timepicker into the datepicker, so you can choose date and time in the same input / model, rather than having to manually join them after the fact.. |
|
We did that: https://www.youtube.com/watch?v=ZSM_GxfFahg |
|
@matheo Wow great! Is there any way I can use this too in my project? |
|
@matheo yea, but then again, there components like that already http://code.promactinfo.com/md2/#/datepicker (change Picker Type to date time) and they have the same problem as yours will likely have, and that is duplicating / forking datepicker functionality, since it's not quite reusable / extendable (especially the input part). |
|
@mseltene awesome! Looks like very good alternative. |
Hi, @airtonferreira. Thank you. I just want to clarify @dhutaryan is the awesome maker of this. |
|
@mseltene oh, I'm sorry. I got confused. Congrats @dhutaryan |
|
@mseltene @airtonferreira thank you guys. Do my best 🙂 |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. ### FAQ #### Why did it take so long? One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. #### Doesn't Material Design have a timepicker? Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. #### What are some alternate designs that you considered? Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. #### Why this design? We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added
P2
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 1, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 3, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Oct 3, 2024
Addresses a long-time feature request by adding a component that allows users to select a time. The new component uses a combination of an `input` and a dropdown to allow users to either type a time or select it from a pre-defined list. Example usage: ```html <mat-form-field> <mat-label>Pick a time</mat-label> <input matInput [matTimepicker]="picker"/> <mat-timepicker #picker/> <mat-timepicker-toggle [for]="picker"/> </mat-form-field> ``` Features of the new component include: * Automatically parses the typed-in value to a date object using the current `DateAdapter`. Existing date adapters have been updated to add support for parsing times. * Time values can be generated either using the `interval` input (e.g. `interval="45min"`) or provided directly through the `options` input. * Integrated into `@angular/forms` by providing itself as a `ControlValueAccessor` and `Validator`. * Offers built-in validation for minimum, maximum and time formatting. * Offers keyboard navigation support. * Accessibility implemented using the combobox + listbox pattern. * Can be used either with `mat-form-field` or on its own. * Can be combined with `mat-datepicker` (docs to follow, see the dev app for now). * Includes test harnesses for all directives. * Works with Material's theming system. * Can be configured globally through an injection token. * Can be used either as an `NgModule` or by importing the standalone directives. One of the main reasons why we hadn't provided a timepicker component until now was that there's no universally-accepted design for what a timepicker should look like. Material Design has had a [specification for a timepicker](https://m3.material.io/components/time-pickers/overview) for years, but we didn't want to implement it because: 1. This design is primarily geared towards mobile users on Android. It would look out of place in the desktop-focused enterprise UIs that a lot of Angular developers build. 2. The time dial UI is complicated and can be overwhelming, especially in the 24h variant. 3. The accessibility pattern is unclear, users may have to fall back to using the inputs. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. The time dial requires very precise movements if the user wants to select a specific time between others (e.g. 6:52). This can be unusable for users with some disabilities. 6. The non-dial functionality (inputs in a dropdown) don't add much to the user experience. There are [community implementations](https://dhutaryan.github.io/ngx-mat-timepicker) of the dial design that you can install if you want it for your app. Some libraries like [Kendo UI](https://www.telerik.com/kendo-angular-ui/components/dateinputs/timepicker), [Ignite UI](https://www.infragistics.com/products/ignite-ui-angular/angular/components/time-picker) or [MUI](https://mui.com/x/react-date-pickers/time-picker/), as well as Chrome's implementation of `<input type="time"/>` appear to have settled on a multi-column design for the dropdown. We didn't want to do something similar because: 1. The selected state is only shown using one sensory characteristic (color) which is problematic for accessibility. While we could either add a second one (e.g. a checkbox) or adjust the design somehow, we felt that this would make it look sub-optimal. 2. The UI only looks good on smaller sizes and when each column has roughly the same amount of text. Changing either for a particular column can throw off the whole UI's appearance. 3. It requires the user to tab through several controls within the dialog. 4. It's unclear how the time selection would work on non-Westernized locales whose time formatting isn't some variation of `HH:MM`. 5. Each column requires a lot of filler whitespace in order to be able to align the selected states to each other which can look off on some selections. We chose the current design, because: 1. Users are familiar with it, e.g. Google Calendar uses something similar for their time selection. 2. It reuses the design from existing Material Design components. 3. It uses an established accessibility pattern (combobox + listbox) and it doesn't have the same concerns as the multi-column design around indicating the selected state. 4. It allows us to support a wide range of locales. 5. It's compact, allowing us to do some sort of unified control with `mat-datepicker` in the future. Fixes angular#5648.
|
Cannot belive we finally will have this feature!!!!!!!!! i had lost any hopes! thank you! |
|
|
|
👏 |
|
Finally ... |
|
UHUUUUUUU 🥳🥳🥳 FINALLY! |
|
Truly a day that will go down in the history books! The effort is much appreciated! |
|
Yayyyyy, time has come 🥳🎊 Thanks folks 🙏 |
|
what a time to be alive |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
Should be able to choose, just date, just time, or date & time
The text was updated successfully, but these errors were encountered: